Who should receive domain and hosting renewal notices?

What domain ownership actually means

When a domain is registered, it's tied to an account at a registrar — a company like GoDaddy, Namecheap, Google Domains, or one of dozens of others. Whoever controls that account controls the domain. They can renew it, transfer it, point it somewhere else, or let it expire. The business name on the website, the person who paid for it, or the organization it represents — none of that matters to the registrar. Account access is ownership.

In practice, domains are often registered by whoever was available at the time: a web developer hired for a project, a founder who has since left, an IT vendor, or an employee who no longer works there. This is one of the most common infrastructure problems small businesses discover — usually at the worst possible moment.

How to find out who registered it

Start with a WHOIS lookup. Go to lookup.icann.org and enter your domain name. The result will show the registrar (the company where the domain is registered) and, if privacy protection isn't enabled, the registrant contact information. Even with privacy protection active, you'll see the registrar name — which tells you where to start.

Once you know the registrar, the question becomes: does anyone at your organization have login credentials for an account there? Check with anyone who was involved in setting up the original website. If the domain was registered by a vendor or developer, contact them directly and ask for the account credentials or a transfer.

What to do if you can't get access

If the person who registered the domain is unreachable, or if they're unwilling to transfer it, you have options — but they take time. Most registrars have a formal transfer or account recovery process that requires proof of business ownership. This typically means submitting documentation to the registrar's support team. It's not fast, but it works in most cases.

If the domain has already expired and lapsed into a redemption period, the situation is more urgent. Domains in redemption can still be recovered by the original registrant, but the window is limited. After that, the domain may become available for anyone to register — including competitors or domain squatters.

The right long-term setup

The domain should be registered in an account that the business owns and controls, using an email address the business will always have access to — not a personal address, not a vendor's account. Auto-renewal should be enabled. At least one other person in the organization should know where the account is and how to access it.

If your current situation doesn't match that description, it's worth addressing before something forces the issue. Web Relevant can help identify who controls a domain, what a transfer would involve, and how to make sure the same problem doesn't recur.

It's common for small businesses to start with whatever email is convenient — a Gmail address, a personal account, whatever the founder already had. Over time, that address becomes the contact point for vendors, clients, account registrations, and service notifications.

The problem isn't the email provider. The problem is that the address belongs to a person, not the business. When that person leaves — or when the relationship between the person and the business changes — the business loses access to years of correspondence, vendor contacts, and account recovery options tied to that address.

A branded organizational email address (one that ends in your domain name, like [email protected]) belongs to the business. It can be transferred, reassigned, or handed off without losing the history or the relationships attached to it.

Setting up branded email is not complicated or expensive. The more important work is migrating existing accounts and vendor relationships away from the personal address — which takes some time but is entirely manageable.

If your business currently depends on a personal email address for important correspondence or account access, it's worth addressing before a transition makes it urgent.

DNS stands for Domain Name System. It's the part of the internet infrastructure that translates a domain name — like yourbusiness.com — into the actual addresses of the servers that host your website, handle your email, and run other services connected to your domain.

For most businesses, DNS works quietly in the background and never requires attention. But when something changes — a new website, a new email provider, a hosting migration — DNS records need to be updated. If they're not updated correctly, or if they're updated in the wrong place, things stop working.

The most common DNS problem for small businesses is not knowing where their DNS is managed. A domain can be registered at one company, have its DNS managed at another, and be hosted at a third. If you don't know which company controls the DNS, you can't make changes — and finding out can take longer than expected.

A secondary problem is that DNS changes take time to propagate — typically a few hours, sometimes longer. This means mistakes aren't always immediately obvious, and corrections take time to take effect.

Web Relevant helps businesses understand where their DNS is managed, what records exist, and what changes are needed. For businesses that have recently changed hosting providers or email services and are experiencing problems, DNS is usually the first place to look.

A key-person dependency is any situation where one individual is the sole owner, sole contact, or sole person with knowledge of something the business depends on. It's not a formal term — it's just a description of a common and underappreciated risk.

In small businesses and organizations, key-person dependencies are almost universal. The person who set up the website still owns the hosting account. The office manager is the only one who knows the WiFi password and the name of the IT vendor. The founder's personal Gmail is the recovery address for the company's Google Workspace account.

These situations are easy to ignore when everything is working. They become serious problems when the person involved leaves, becomes unavailable, or has a falling out with the organization. At that point, recovering access can range from inconvenient to genuinely difficult.

The most common key-person dependencies in small businesses involve: domain and hosting accounts, email administration, shared passwords and credentials, vendor and service relationships, and undocumented processes that only one person understands.

Addressing key-person dependencies doesn't require a formal audit or a large project. It usually starts with a straightforward inventory: what does the business depend on, who controls it, and what would happen if that person were suddenly unavailable? Web Relevant helps organizations work through that inventory and address the gaps.

When a website stops working unexpectedly, the cause is almost always one of a few things: the domain has expired, the hosting has lapsed, a DNS record has been changed or broken, or something on the website itself has stopped functioning.

The first thing to check is the domain. Go to a domain lookup tool (whois.domaintools.com is a reliable one) and search for your domain name. Look at the expiration date. If the domain has expired — or is close to expiring — that's likely the problem. Domain renewals are easy to miss, especially if the renewal notices are going to an email address that's no longer monitored.

If the domain is current, the next thing to check is hosting. Log in to your hosting account (if you know where it is) and confirm that the account is active and the hosting plan hasn't lapsed. Hosting accounts that are paid annually are easy to forget.

If both the domain and hosting appear to be active, the problem may be DNS — a misconfiguration that's pointing the domain to the wrong place, or a recent change that hasn't propagated correctly. This is harder to diagnose without knowing where the DNS is managed.

If you can't identify the cause, or if you don't have access to the domain or hosting accounts, Web Relevant can help. These situations are common and usually resolvable — the main challenge is often just finding out who controls what.

Most small businesses manage passwords the same way: a mix of reused passwords, credentials stored in email threads or spreadsheets, and login information that exists only in one person's memory. This works until it doesn't.

The problems this creates are predictable. When someone leaves, the business loses access to accounts they managed. When a password needs to be changed, nobody knows where all the places it's used are. When an account gets compromised, it's hard to know which other accounts might be affected.

A password manager solves these problems by giving the business a single, organized place to store credentials — one that can be shared appropriately, updated when things change, and accessed by the right people without depending on any one person's memory.

For small businesses, the most practical options are tools like 1Password Teams or Bitwarden for Business. Both are designed for shared use, reasonably priced, and straightforward to set up. The more important work is the migration: identifying what accounts exist, what the current credentials are, and getting everything into the system.

Web Relevant doesn't sell or endorse specific software, but we do help businesses get their credential situation organized — which usually means a combination of choosing the right tool, migrating existing credentials, and establishing a simple process for keeping things current.

It's not a brush-off

When someone in IT tells you to restart your computer, it can feel like they're not taking the problem seriously. In most cases, the opposite is true. A restart is one of the most effective first steps available because it addresses several common failure modes simultaneously — without requiring any diagnosis of which specific one is actually causing the problem.

What a restart actually does

When a computer runs for days or weeks without restarting, several things accumulate. Memory fills with processes that were started and never fully closed. Software updates that were downloaded sit waiting for a restart to finish installing. Background services that have gotten into a bad state keep running in that bad state. Temporary files and caches grow. Network connections that have gone stale stay stale.

A restart clears all of that. Memory is freed. Pending updates install and take effect. Services start fresh from a known good state. Network connections are re-established. For a large category of problems — slow performance, software behaving unexpectedly, connectivity issues, applications that won't open — a restart resolves the issue completely without any further intervention.

Why it's the right first step

From a troubleshooting standpoint, a restart is valuable because it's fast, free, and reversible. If the problem goes away after a restart, you've solved it. If it comes back, you've learned something: the problem is reproducible and probably worth investigating further. If it doesn't go away at all, you've ruled out the most common causes and can move on to something more specific.

Skipping the restart and going straight to more complex troubleshooting often wastes time. Many support calls that take an hour would have taken two minutes if the restart had happened first.

A practical habit

Most IT professionals recommend restarting computers at least once a week — not just when something is wrong. Regular restarts keep systems running cleanly, ensure updates are applied promptly, and reduce the likelihood of the slow accumulation of problems that makes computers feel sluggish over time.

If your organization is dealing with recurring computer problems that a restart doesn't resolve, that's a different conversation. Web Relevant can help identify whether the issue is hardware, software, network, or something else — and what a practical fix looks like.

Two different things

Web hosting and website maintenance are related but distinct. Hosting is the infrastructure that keeps your website accessible on the internet. Maintenance is the ongoing work of keeping the website itself functioning, current, and secure. You can have one without the other — and many businesses do, which is where problems start.

What hosting is

When you pay for web hosting, you're renting space on a server — a computer that stays connected to the internet and serves your website files to anyone who visits. Hosting providers keep the server running, handle the physical infrastructure, and typically provide tools for managing files, databases, and email. What they don't do is manage the content or software running on your site. That's your responsibility, or your developer's.

Hosting is usually billed monthly or annually. It's easy to set up and easy to forget about — until the renewal lapses, the server has a problem, or something about the hosting environment changes in a way that affects your site.

What maintenance is

Website maintenance covers everything that keeps the site working correctly over time: software updates (especially for platforms like WordPress), security monitoring, broken link checks, content updates, performance checks, and backups. It also includes responding when something breaks — a plugin conflict, a failed update, a form that stops sending submissions.

Maintenance is often informal for small businesses. The developer who built the site handles things as they come up, or nobody handles them at all. This works until a security vulnerability goes unpatched, an update breaks something, or the developer is no longer available.

Where the confusion comes from

Many hosting providers offer maintenance-adjacent features — automatic backups, one-click updates, security scanning — and market them as part of their hosting plans. This blurs the line. It's worth understanding exactly what your hosting plan covers and what it doesn't, so you know whether there's a gap.

Similarly, some website developers or agencies include hosting as part of a maintenance retainer, or bundle both under a single monthly fee. That arrangement can work well, but it's worth knowing what happens to both the hosting and the maintenance if you ever decide to change providers.

The practical question

For most small businesses, the right question isn't which provider to use — it's whether both hosting and maintenance are actually covered, by someone who is accountable for them. If the answer is unclear, that's worth sorting out. Web Relevant can help assess what's currently in place and identify any gaps.

DNS does more than point to your website

Most people think of DNS as the thing that connects a domain name to a website. That's part of it. But DNS also controls where your email is delivered, how receiving servers verify that your messages are legitimate, and a range of other services tied to your domain. When you change DNS settings, you're not just changing where the website points — you're potentially affecting everything connected to that domain.

The specific record that controls email

Email delivery is governed by a DNS record type called an MX record — short for Mail Exchanger. MX records tell the internet which mail servers should receive email sent to your domain. If those records are removed, overwritten, or pointed to the wrong place during a DNS change, incoming email stops arriving. Depending on the change, it may bounce back to senders, disappear silently, or queue up waiting for a record that no longer exists.

There are also supporting records — SPF, DKIM, and DMARC — that help receiving mail servers verify that messages from your domain are legitimate. These are separate DNS records. If they're lost during a migration, your outgoing email may start landing in spam filters, even if delivery itself appears to be working.

Why this happens during website changes

The most common scenario: a business moves to a new website host or platform. The new host provides instructions for updating DNS — often a simple "point your domain here" step. Those instructions are written for the website. They don't account for the email records that were already in place. If the person making the change replaces all DNS records rather than adding or updating specific ones, the email records go with them.

This is especially likely when DNS is being moved from one provider to another entirely. Migrating DNS zones requires exporting all existing records and importing them at the new provider before making the switch. If that step is skipped, every service tied to the old DNS — email, calendar integrations, third-party verifications — stops working when the migration completes.

Before making any DNS change — stop here

If you are considering a DNS change and your domain handles email: do not proceed without first documenting every existing DNS record. Log in to wherever your DNS is currently managed, take a full export or screenshot of all records, and identify which ones are related to email (MX, SPF, DKIM, DMARC, and any records with your email provider's name in them). Those records need to be preserved or recreated exactly at the new location before the old ones are removed.

If you are not certain which records are safe to change, that is the right moment to stop and get help. A DNS mistake that breaks email can take hours to propagate a fix, and email sent during that window may be lost permanently.

If email is already broken

If a DNS change has already been made and email has stopped working, the first step is to identify what records are currently in place and compare them to what your email provider requires. Most email providers publish the exact DNS records needed for their service. The fix is usually restoring the correct MX and supporting records — but the timeline for recovery depends on DNS propagation, which can take several hours.

Web Relevant can help identify what went wrong, what records need to be restored, and how to make sure the same situation doesn't happen again the next time a website or hosting change is needed.

What's actually happening

Multi-factor authentication (MFA) adds a second step to logging in — typically a code sent by text message or generated by an app on a specific device. The intent is to make accounts harder to compromise. The unintended consequence, in organizations that don't plan for it, is that account access becomes tied to a specific person's phone. When that person leaves, the second factor leaves with them.

This situation is more common than most organizations expect. It affects email accounts, social media profiles, domain registrars, hosting platforms, financial accounts, and any other service where MFA was enabled using a personal phone number or a personal authenticator app. The account still exists. The password may still be known. But without the second factor, the login is blocked.

The legitimate recovery path

Every major platform has an account recovery process for exactly this situation. The process varies by provider, but it typically involves verifying your identity and your relationship to the account through alternative means — a backup email address, backup codes that were generated when MFA was set up, answers to security questions, or documentation submitted to the platform's support team.

Start by checking whether backup codes were ever saved. When MFA is first configured on most platforms, the system offers a set of one-time backup codes and strongly recommends saving them. If someone saved those codes — in a password manager, a secure document, or even a printed sheet — they can be used to bypass the missing second factor and regain access.

If no backup codes are available, look for a backup email address or secondary phone number associated with the account. Many platforms allow multiple recovery methods, and one of them may still be accessible to the organization.

If none of those options exist, the path forward is the platform's formal account recovery process. This typically requires submitting a support request with documentation — proof of business ownership, government-issued ID, or other verification the platform specifies. It is not fast, but it is the correct and legitimate route. Do not attempt to work around it.

What not to do

Do not contact the former employee and ask them to approve a login or forward a code. That approach creates ongoing dependency on someone who is no longer part of the organization, and it does not solve the underlying problem. The goal is to restore organizational control of the account — not to borrow access from someone who has left.

Preventing it from happening again

Once access is restored, the MFA configuration should be updated immediately. The second factor should be tied to a device or phone number the organization controls — not a personal device belonging to any individual employee. Where platforms support it, use an authenticator app on a shared or organizational device, or configure MFA to a role-based phone number rather than a personal one.

Backup codes for every critical account should be stored in the organization's password manager, not in any individual's personal files. The same applies to recovery email addresses — they should be organizational addresses that survive staff changes.

Web Relevant helps organizations work through account recovery situations and put the right structures in place so that a single departure doesn't create an access crisis. If you're currently locked out of a critical account, get in touch — we can help identify the recovery path and what documentation you'll need.

Start by reading it carefully

Before doing anything else, read the review without defensiveness. Ask whether the experience described could have happened. Ask whether the complaint reflects something a reasonable customer might genuinely feel, even if the details are imprecise or the tone is unfair. The answer to that question determines almost everything that follows.

A review that describes a real experience — even an exaggerated or one-sided version of one — is different from a review that describes something that couldn't have happened, names a service you don't offer, or appears to be about a different business entirely. Treating them the same way is a mistake.

If the review reflects a real experience

Respond publicly, briefly, and without arguing. Acknowledge that the experience fell short. If there's a specific correctable problem, note that you've addressed it or are looking into it. Keep the response short — a few sentences. The audience for your response isn't the reviewer; it's everyone else who reads it afterward. A calm, professional response to a negative review often does more for your reputation than the review itself damages.

Do not respond with a detailed rebuttal, a list of everything the reviewer got wrong, or a request to contact you privately to resolve it. Long defensive responses read poorly to outside observers. If the reviewer is willing to update or remove the review after a genuine resolution, that's their choice — don't make it the explicit goal of your public response.

After responding, look at the underlying issue. If multiple reviews mention the same problem, that's a signal worth taking seriously — not as a reputation management exercise, but as operational feedback.

If the review appears to be fraudulent or mistaken

Google allows businesses to flag reviews that violate its policies — reviews that are spam, that describe a competitor's business, that contain prohibited content, or that were clearly posted by someone who was never a customer. The flagging process is straightforward: find the review in your Google Business Profile, select the flag option, and choose the relevant policy violation.

Be realistic about outcomes. Google reviews flagged reviews only when they clearly violate a specific policy. A review that is unfair, exaggerated, or one-sided but describes a plausible customer experience is unlikely to be removed. The threshold for removal is policy violation, not inaccuracy.

What not to do

Do not solicit fake positive reviews to offset a negative one. Do not ask friends, family, or employees to post reviews. Do not use a review generation service that incentivizes or manufactures reviews. These practices violate Google's policies, can result in penalties to your Business Profile, and are detectable. The short-term rating improvement is not worth the risk.

Do not attempt to contact the reviewer through channels outside the review platform in ways that could be perceived as pressure or harassment. If you recognize the reviewer as a former customer and want to reach out, keep it brief, professional, and focused on understanding — not on asking them to change or remove the review.

The longer view

A single negative review rarely determines how a business is perceived, especially if it's surrounded by a pattern of positive ones. The most durable response to a poor review is continuing to deliver good work and making it easy for satisfied customers to share their experience — not through incentives, but by simply asking at the right moment.

If your business is dealing with a pattern of negative reviews, or if a review situation has become complicated, Web Relevant can help think through the right approach.

Working and understood are not the same thing

There's a category of operational risk that doesn't show up until something changes. The website loads. Email arrives. The software runs. Payments process. Everything appears to be functioning normally — and it is. The problem is that nobody in the organization can explain why, or what would need to happen to keep it working if something changed.

This situation is extremely common in small businesses and organizations that have grown organically, changed vendors over time, or relied on one person to manage technical infrastructure. The systems work because they were set up correctly at some point, and nothing has disrupted them since. That's not the same as having systems that are understood and maintainable.

What the risk actually looks like

The fragility becomes visible at moments of change: a staff departure, a vendor transition, a hosting migration, a platform update, a new hire who needs access. At that point, the organization discovers that the person who knew how things worked is gone, or that the documentation doesn't exist, or that the credentials are stored somewhere nobody can find.

The cost of that discovery varies. Sometimes it's a few hours of frustration. Sometimes it's days of downtime while someone tries to reconstruct what was in place. Sometimes it's a permanent loss — an account that can't be recovered, a configuration that can't be replicated, a vendor relationship that existed only in one person's head.

Hidden dependencies are the core issue

Most of the risk in "everything works but nobody knows why" comes from hidden dependencies — connections between systems, accounts, and people that aren't visible until they break. The domain auto-renews because a credit card on file belongs to someone who left two years ago. The website stays up because a developer still has an active hosting account they've never been asked to transfer. The email works because a DNS record was set up correctly in 2019 and nobody has touched it since.

None of these are problems right now. All of them are problems waiting for a trigger. The trigger might be a credit card expiration, a vendor account closure, a staff departure, or simply someone making a well-intentioned change without realizing what else depends on it.

What to do about it

The goal isn't to document everything — that's an unrealistic standard for most small organizations. The goal is to identify the things that would cause serious disruption if they stopped working or became inaccessible, and make sure those things are understood, owned, and recoverable.

A practical starting point: make a list of the services and systems the organization depends on daily. For each one, ask three questions. Who controls the account? What happens if that person is unavailable? Is there a backup or recovery path? The answers will quickly surface the highest-risk dependencies.

The second step is making sure critical credentials and account information are stored somewhere the organization controls — not in any individual's personal accounts or memory. A shared password manager with appropriate access controls is the standard solution.

Before making changes to things that are working

If you're planning to change something that currently works — a new website, a new email provider, a hosting migration — take time to document what's currently in place before touching it. What DNS records exist? What accounts are involved? What does the current configuration look like? That documentation is far easier to create before a change than after something breaks.

Web Relevant helps organizations work through this kind of inventory — identifying what's in place, who controls it, and what would need to happen to keep things running through a transition or a staff change. If your organization is in a "everything works but nobody knows why" situation, that's a reasonable place to start a conversation.

The replacement isn't just a design project

A new website involves more than swapping out pages and visuals. The existing site may have indexed URLs that appear in search results, DNS records that control email and other services, integrations with third-party tools, forms that route to specific destinations, and tracking or analytics configurations that took time to set up. None of that transfers automatically. If it isn't documented before the old site is replaced, some of it will be lost.

The goal of this kind of preparation isn't to reproduce everything from the old site — some of what's there may be outdated, redundant, or worth leaving behind. The goal is to make deliberate decisions about what to carry forward, rather than discovering after launch that something important is missing.

URLs and indexed pages

Search engines index specific URLs. If those URLs change when the new site launches — because the page structure is different, or slugs are formatted differently — any search visibility associated with the old URLs is lost unless redirects are in place. Before replacing a site, document the URLs that matter: pages that appear in search results, pages that are linked from other sites, and any URLs that are referenced in printed materials, email signatures, or social profiles.

If the site is connected to Google Search Console, review the coverage report before the transition. It shows which URLs Google has indexed and flags any existing errors. That information is useful both for deciding which pages to redirect and for verifying that the new site is being indexed correctly after launch.

DNS records — stop here before making changes

DNS controls more than the website. It also controls where email is delivered, how outgoing messages are verified, and any other services tied to the domain. Before making any DNS changes as part of a website transition, export or screenshot every existing DNS record from wherever the domain's DNS is currently managed.

Identify which records are related to email — MX records, SPF, DKIM, and DMARC — and make sure those are preserved exactly when DNS is updated. A website migration that inadvertently removes email records will break email delivery, sometimes immediately and sometimes hours later as changes propagate. If you are not certain which records are safe to change, stop and get help before proceeding.

Domain ownership and access

Confirm that the organization has direct access to the domain registrar account — the account where the domain is registered and renewed. This is separate from the hosting account and separate from wherever DNS is managed. If the domain is registered under a former employee's account, a previous agency, or a vendor who is no longer involved, that needs to be resolved before the transition begins, not after.

Forms and integrations

Document every form on the existing site and where submissions go. Contact forms, quote request forms, newsletter signups, and booking forms may route to email addresses, CRM systems, or third-party services. When the new site is built, those routing configurations need to be deliberately recreated — they don't carry over automatically. Verify after launch that each form is delivering submissions to the right place.

The same applies to any third-party integrations embedded in the existing site — scheduling tools, chat widgets, payment processors, review widgets, or anything else that was added over time. Make a list of what's present, what account it's connected to, and whether it should be carried forward to the new site.

Analytics and tracking

If the site uses analytics or tracking — Google Analytics, Search Console verification tags, ad platform pixels, or similar — document the account IDs and configuration before the transition. These are typically implemented as code snippets or DNS records. They need to be reinstalled on the new site and verified as working after launch. If they're not carried over, the historical data remains in the platform but new data collection stops.

Content and assets

Download copies of any content or assets from the existing site that aren't stored elsewhere: images, documents, PDFs, video files, and any written content that isn't duplicated in another system. Hosting accounts are sometimes closed quickly after a transition, and content that wasn't backed up may not be recoverable.

Pay particular attention to content that has been linked to from other sites or shared externally — staff bios, service descriptions, downloadable resources. If that content is moving to a new URL, a redirect from the old URL is worth setting up.

What you don't need to preserve

Not everything from the old site deserves to come forward. Outdated content, obsolete service descriptions, broken functionality, and pages that were never useful don't need to be recreated. The transition is a reasonable moment to make deliberate decisions about what the new site should actually contain — rather than treating the old site as a template to reproduce.

Web Relevant helps organizations prepare for website transitions — documenting what's currently in place, identifying dependencies, and making sure the things that matter are carried forward intentionally. If a website replacement is coming up, get in touch before the work begins.

The short version

Stop interacting with whatever you clicked. Don't click anything else on the page, don't download anything, and don't enter any information. If you downloaded a file, don't open it. If you already opened it, note what it was. Then work through the steps below in order, based on what actually happened.

What probably happened

Most suspicious clicks fall into a few categories. A phishing link — designed to look like a legitimate login page — may have prompted you to enter credentials. A malicious download may have placed a file on your device. A drive-by page may have attempted to run code in your browser. Or the link may have gone nowhere meaningful at all. The severity of each scenario is different, and the response should match.

The most important question to answer first: did you enter any information — a username, password, payment details, or personal data — on the page the link took you to? If yes, that's the highest priority to address. If no, the risk profile is lower, though not zero.

If you entered credentials

Change the password for the affected account immediately — but do it from a different device if you have any reason to believe the device you clicked on may be compromised. Use a known-clean device: a phone that wasn't involved, a different computer, or a trusted device at a different location.

After changing the password, check the account's active sessions or recent activity log if the platform provides one. Look for logins from unfamiliar locations or devices. If you see activity you don't recognize, log out all other sessions and review what the account has access to.

If the same password was used on other accounts — which is common — change those as well. This is also a reasonable moment to move those accounts to unique passwords stored in a password manager, if you haven't already.

If a file was downloaded or opened

If a file was downloaded but not opened, delete it without opening it. If it was opened, note the filename and file type. On a Windows device, run a scan with Windows Defender or another endpoint protection tool. On a Mac, macOS has built-in protections, but a scan with a reputable tool is still reasonable.

For home users and very small offices, Web Relevant commonly recommends Sophos Home as one option for endpoint protection — it's straightforward to set up and covers both Windows and Mac. It's not the only option, and it's not a substitute for professional incident response if the situation warrants it, but it's a practical starting point for environments that don't have managed security in place.

If a business, financial, or administrative account may be involved — stop here

If the account that may have been compromised has access to business finances, payroll, client data, administrative systems, or sensitive organizational information, do not attempt to handle this alone. Disconnect the affected device from your network — turn off Wi-Fi and unplug any ethernet cable — to limit any potential lateral movement. Then contact your IT provider, managed security provider, or a professional incident response resource before taking further action. The steps above are appropriate for individual accounts; business-critical systems warrant a different level of response.

Document what happened

Before the details fade, write down what you remember: what the link looked like, where it appeared (an email, a text message, a website), what page it took you to, what you did on that page, and what happened afterward. This documentation is useful if the situation escalates and you need to involve IT support, your organization's security team, or a professional.

What not to do

Don't go back to the suspicious page to investigate further. Don't forward the suspicious message to colleagues to ask their opinion — that spreads the risk. Don't assume that because nothing obvious happened, nothing happened at all. And don't delay changing credentials if you entered them, even if you're not sure the page was actually malicious.

If you're uncertain about the severity of what happened, or if the situation involves organizational systems, Web Relevant can help assess the situation and identify the right next steps.

The short version

Do not click any links in the email. Instead, open a new browser tab and navigate directly to the service by typing the address yourself. Log in normally and check whether anything looks different — recent activity, unfamiliar sessions, changed settings. If everything looks normal, the email was most likely a routine probe or a mistake, and no action beyond awareness is needed.

What probably happened

Unsolicited password-reset emails are common and usually fall into one of three categories. Someone typed your email address by mistake when trying to reset their own account. An automated tool or bad actor submitted your email address to the reset form — a low-effort probe that costs nothing and requires no special access. Or, less commonly, someone with your email address and some knowledge of your accounts is attempting to gain access.

The email itself is not evidence that your account has been accessed. A password-reset email is generated when someone submits a reset request — it does not mean the reset was completed, and it does not mean anyone has logged in. The risk is in what happens next, not in the email itself.

How to check the account safely

Navigate to the service directly — type the URL yourself, or use a bookmark you've used before. Do not click the link in the email, even to check whether it looks legitimate. Phishing emails are designed to look exactly like real reset emails, and the difference is often not visible.

Once you're logged in, look for a recent activity or security log. Most major platforms — Google, Microsoft, Apple, banking services, social media — provide a view of recent logins, including the device type and location. If you see sessions you don't recognize, that's a signal worth acting on. If everything looks familiar, the account is almost certainly fine.

When to change your password

If the account's activity log shows logins you don't recognize, change the password immediately — from a device you trust. Choose a password that's unique to this account and not used anywhere else. Enable multi-factor authentication if it isn't already active. Then review what the account has access to and whether any settings, connected apps, or forwarding rules have been changed.

If the activity log looks normal and you see no evidence of unauthorized access, changing the password is optional but reasonable — particularly if the account is important and the password is old or reused. It's a low-cost precaution.

The difference between a reset request and a compromised account

A reset request means someone submitted your email address to a reset form. A compromised account means someone has successfully logged in and has access. These are different situations. The first is common and usually benign. The second requires immediate action. The way to tell the difference is to check the account's activity log — not to assume one way or the other based on the email alone.

If you receive multiple reset emails in a short period

A pattern of reset emails across multiple services in a short window is worth taking more seriously. It may indicate a coordinated attempt to access accounts, or that credentials from a data breach are being tested. In that case, review the activity logs for each affected service, change passwords for any that show unfamiliar activity, and consider whether a password audit across your accounts is overdue.

If the pattern involves business accounts or systems with access to sensitive organizational data, treat it as a security event and involve your IT provider or a professional. Web Relevant can help assess the situation and identify whether further action is warranted.

The short version

A backup you have never restored from is an untested backup. It may work perfectly. It may have been silently failing for months. You cannot know which without testing. The goal of this article is to help you understand what to check and how to verify that your backups would actually be useful when you need them.

What backup software actually does — and doesn't do

Backup software copies data from one location to another on a schedule. When it runs successfully, it creates a copy. When it fails — because of a permissions error, a full storage volume, a network interruption, a software conflict, or a configuration problem — it may log an error, or it may simply stop running without obvious notification. Many backup failures are silent.

The backup dashboard showing a green status or a recent timestamp is not proof that the backup is complete and restorable. It's proof that the software ran. Whether the resulting backup is intact, complete, and actually restorable is a separate question that requires a separate check.

What to check right now

Start with the backup logs, not the dashboard summary. Most backup tools maintain a detailed log of each job. Look for error messages, warnings, or jobs that completed with exceptions. A job that says "completed with warnings" is not the same as a clean backup. Identify what was skipped, what failed, and why.

Next, check the backup destination. Is the storage location accessible? Is it filling up? A backup that runs out of space will either fail silently or overwrite older backups without creating new ones. Check how much space is available and how long the current backup history extends.

Then check the retention policy. How many versions are kept, and how far back do they go? A backup that keeps only the last 24 hours of data is very different from one that maintains 30 days of history. If the data corruption or deletion you're trying to recover from happened three weeks ago, a 24-hour retention window won't help.

The restoration test — stop here if you haven't done this

If you have never performed a test restoration from your backup, you do not actually know whether your backup works. This is not a criticism — it's extremely common. But it's worth being honest about. A backup that has never been restored from is an assumption, not a verified safety net.

A restoration test doesn't have to be a full recovery exercise. Start small: restore a single file or folder from a backup that's at least a few days old to a test location. Verify that the file opens correctly and the content is intact. If that works, you have evidence that the backup mechanism is functioning. If it doesn't — if the file is corrupted, incomplete, or the restoration fails — you've discovered a problem before it became a crisis.

Single-copy dependencies

A backup stored in the same location as the original data is not a backup in any meaningful sense. If the device fails, the backup fails with it. If the account is compromised, both the data and the backup may be affected. A reliable backup strategy involves at least one copy stored separately — a different physical location, a different cloud account, or both.

This applies to cloud storage as well. Files stored in a cloud sync service — Dropbox, Google Drive, OneDrive — are accessible from multiple devices, but they are not backups. If a file is deleted or overwritten, the change syncs to all connected devices. Version history may help recover from some of those situations, but it has limits and is not a substitute for a proper backup.

What good backup monitoring looks like

A backup system that requires manual checking to know whether it's working is a backup system that will eventually be forgotten. Reliable backup monitoring means automated alerts when a job fails or hasn't run within the expected window — sent to an email address that someone actually reads. If your current backup setup doesn't send failure alerts, that's worth addressing.

Web Relevant helps organizations assess what's actually being backed up, whether the backups are restorable, and whether the current setup would survive the scenarios it's meant to protect against. If you're not certain your backups work, that's a reasonable place to start a conversation.

The short version

File syncing keeps copies of your files consistent across multiple devices or locations. A backup creates a recoverable snapshot of your data at a point in time. They are not the same thing, and one does not substitute for the other.

What syncing does

When you use a service like Dropbox, Google Drive, OneDrive, or iCloud, files you save are copied to the cloud and made available on other connected devices. If you edit a file on your laptop, the change appears on your phone. If you delete a file, it disappears from all connected devices. That's the point — consistency across locations.

The problem is that sync propagates everything, including mistakes. If a file is accidentally deleted, the deletion syncs. If a file is corrupted by ransomware or a software failure, the corrupted version syncs. If a folder is moved or renamed in a way that breaks something, the change syncs. The cloud copy reflects whatever happened to the local copy — good or bad.

What a backup does

A backup creates a point-in-time copy of your data that is stored separately and is not automatically updated when the original changes. If a file is deleted today, yesterday's backup still has it. If data is corrupted, a backup from before the corruption can be used to restore a clean version. The value of a backup is precisely that it doesn't automatically reflect the current state of your data.

Most backup tools also maintain version history — multiple snapshots over time — so you can recover not just from the most recent backup but from a point days or weeks in the past. This matters for scenarios like ransomware, where the damage may not be immediately obvious and the corruption may have started before you noticed.

Where sync services provide partial protection

Most major sync services do include some version history and a trash or recycle function. Google Drive keeps deleted files for 30 days. Dropbox maintains version history for 30 to 180 days depending on the plan. OneDrive has a recycle bin and version history as well. These features can help recover from accidental deletions or overwrites within their retention windows.

But these are not backups in the full sense. The retention window is limited. The history may not cover all file types or all changes. The recovery process is manual and file-by-file. And the data is still stored in a single cloud account — if that account is compromised, suspended, or closed, the history goes with it.

The practical question

The right question isn't whether you have sync or backup — it's what scenarios you're actually protected against. Sync protects against device failure (your files are in the cloud). Backup protects against data loss, corruption, and deletion (you can recover a prior state). If your only protection is sync, you're covered for one scenario and exposed for the other.

For most small businesses, a practical backup strategy involves a dedicated backup tool — separate from the sync service — that runs on a schedule, stores copies in a location the sync service doesn't touch, and maintains enough version history to be useful. What that looks like in practice depends on what data matters most and what the acceptable recovery window is.

Web Relevant helps organizations understand what's actually protected, where the gaps are, and what a practical backup setup would look like for their situation. If you're relying on sync as your primary data protection, that's worth a closer look.

The short version

Find out what renewed, what it costs, what it does, and whether the organization actually uses it. Then decide whether to keep it, cancel it, or negotiate. After that, use the situation as a prompt to build a simple inventory of what else might renew without notice.

Why this happens

Most software, hosting, and technology services renew automatically by default. The vendor's interest is in continued revenue; the default setting reflects that. Renewal notices are sent to the email address on file when the account was created — which may be a former employee's address, a role that no longer exists, or an inbox that nobody monitors. The charge appears on a card or account that has enough available balance to process it, and nobody notices until the statement arrives.

This is especially common with annual subscriptions, where the renewal is easy to forget between billing cycles, and with services that were set up by a vendor or contractor who is no longer involved. The service may still be running. The organization may have no idea what it does or whether anyone uses it.

What to check immediately

First, identify the service. Find the charge on the statement and match it to a vendor. If the vendor name isn't immediately recognizable, search for it — many billing descriptors are abbreviated or use a parent company name rather than the product name.

Second, find the account. Who set it up? Is there a login? What email address is associated with it? If the account was set up by a former employee or a vendor, you may need to go through account recovery to gain access. Do that before making any decisions about the service — you need to be able to log in before you can cancel, modify, or transfer it.

Third, determine whether the service is actually in use. Check with the people who would know. Look at whether anything in the organization depends on it — a website, an email system, a tool someone uses daily. Canceling a service that something else depends on can create a larger problem than the unexpected charge.

Cancellation windows and refund policies

Most services have a cancellation window after renewal — often 30 days — during which a refund is possible. Check the vendor's terms. If you're within that window and the service isn't needed, contact support and request a cancellation and refund. Be direct: state that the renewal was unexpected, the service is not in use, and you're requesting a refund under the cancellation policy.

Not all vendors will refund automatically, and some services have non-refundable renewal terms. If a refund isn't available, the practical question becomes whether to use the service for the remainder of the paid period or simply cancel to avoid the next renewal.

Preventing the next surprise

The longer-term fix is a simple inventory of recurring technology services: what the organization pays for, when each renews, what it costs, who owns the account, and what it does. This doesn't need to be elaborate — a shared spreadsheet or a section in a password manager is sufficient. The goal is to make sure renewals are visible before they happen, not after.

For each service in the inventory, confirm that the renewal notification goes to an email address the organization actively monitors, and that the billing card or account is one the organization controls. If either of those is tied to a former employee or a vendor who is no longer involved, update them now.

Web Relevant helps organizations build this kind of inventory as part of a broader operational review — identifying what's running, what it costs, who controls it, and whether it's still serving a purpose. If an unexpected renewal has surfaced a larger question about what the organization is actually paying for, that's a reasonable place to start.

The short version

Stop trying to get the vendors to agree with each other. Instead, focus on identifying exactly where the failure is occurring — which system, which component, which handoff point. Once you know where the problem lives, it becomes much harder for either vendor to credibly claim it belongs to the other.

Why this happens

Technology systems at small businesses are rarely built by a single vendor. A website might be hosted by one company, built by another, and use email from a third. A business phone system might integrate with a CRM from a different vendor. When something breaks at the point where two systems connect, each vendor's support team sees only their side of the boundary — and their natural inclination is to confirm that their side is working correctly and suggest the problem is elsewhere.

This isn't always bad faith. Support teams are trained to diagnose their own systems. They often genuinely don't have visibility into what the other vendor's system is doing. But the result for you is the same: two vendors, each saying their system is fine, and a problem that isn't getting fixed.

Identify the boundary

The most useful thing you can do is describe the failure precisely. Not "email isn't working" or "the integration is broken" — but specifically what is happening, at what step, and what the expected behavior would be. Where does the data or process leave one system and enter the other? What is each system supposed to do at that handoff? What is actually happening instead?

If you can get a specific error message, a log entry, or a timestamp for when the failure occurs, that information is far more useful than a general description of the symptom. Error messages often name the system or component that generated them — which is frequently the system where the problem actually lives, regardless of what either vendor claims.

Ask each vendor a specific question

Rather than asking each vendor to diagnose the problem, ask them a specific, bounded question about their own system. "Can you confirm that your system is successfully sending the data to [endpoint] at [time], and show me the log entry?" or "Can you confirm that your system received the request and what response it returned?" A vendor who can answer that question with evidence has demonstrated their side is working. A vendor who cannot answer it — or who deflects to the other vendor without providing evidence — has identified where to look next.

Who owns the integration?

Many integration problems live in the configuration layer — the settings that tell one system how to talk to the other. That configuration was set up by someone: the vendor who built the integration, the IT provider who connected the systems, or someone internally. Whoever set it up is usually the right person to diagnose it, because they understand both sides of the connection.

If the integration was set up by a vendor who is no longer involved, or if nobody currently knows who configured it, that's a separate problem worth surfacing. An integration that nobody understands and nobody owns is a dependency waiting to fail permanently.

Escalation within each vendor

Front-line support teams at most vendors are trained to handle common issues within their own system. Cross-vendor integration problems are often outside their scope. If you've been working with first-level support and getting nowhere, ask to escalate to a technical specialist or an integrations team. Frame the request specifically: "I need someone who can review the API logs for this specific transaction and confirm what your system sent or received."

Document everything

Keep a written record of what each vendor has told you, when, and what evidence they provided. This serves two purposes. It prevents each vendor from repeating the same deflection without accountability. And if the situation escalates — to a formal support case, a contract dispute, or a decision to replace one of the vendors — the documentation is the foundation of that conversation.

Web Relevant helps organizations navigate exactly this kind of situation — identifying where a failure is actually occurring, working with vendors to get specific answers, and determining whether the problem is a configuration issue, a vendor failure, or a gap in how the systems were set up. If you're stuck in a loop between two vendors, get in touch.

DNS changes are not just website changes

When someone says they need to update DNS, they usually mean they want to point the domain to a new website or hosting provider. That's a legitimate reason to change DNS. But DNS records control more than the website — they also govern where email is delivered, how outgoing messages are authenticated, and a range of third-party services that may have added their own records over time. Changing one record without understanding what else is in the zone can break things that had nothing to do with the original task.

Start by exporting everything that's currently there

Before making any change, log in to wherever the domain's DNS is currently managed — the registrar, a hosting provider, or a dedicated DNS service — and document every record that exists. Most DNS management interfaces have an export function; if not, take a full screenshot or copy the records manually. The goal is a complete picture of the current state before anything is touched. This takes a few minutes and makes every subsequent decision easier.

Website records

The records that point the domain to a website are typically A records (which map the domain to an IP address) or CNAME records (which point one domain name to another). These are usually what the new hosting provider's instructions are asking you to change. They're also the records most likely to be replaced correctly, because the instructions are written specifically for this purpose. The risk is not usually in the website records themselves — it's in what else gets changed or deleted in the process.

Email records — the most common casualty

Email delivery depends on MX records, which tell the internet which mail servers should receive messages sent to your domain. If MX records are removed or overwritten during a DNS change, incoming email stops arriving. Depending on how the change was made, messages may bounce back to senders or disappear entirely. MX records should never be changed unless you are deliberately moving to a new email provider — and even then, the new records should be in place before the old ones are removed.

Supporting email records — SPF, DKIM, and DMARC — are separate TXT records that help receiving mail servers verify that messages from your domain are legitimate. These are easy to overlook because they don't affect whether email arrives; they affect whether it's trusted. If they're lost during a DNS change, outgoing email may start landing in spam filters, sometimes days after the change when the effects propagate.

TXT records used for verification

Many third-party services add TXT records to a domain as a way of verifying ownership. Google Search Console, Google Workspace, Microsoft 365, and various security and marketing platforms all use this mechanism. These records don't do anything visible day-to-day — they just sit in the DNS zone confirming that the domain owner authorized the service. If they're deleted, the verification lapses, and the service may lose its connection to the domain. Restoring verification usually requires going back through the setup process for each affected service.

CNAMEs and other service dependencies

CNAME records are used for a wide range of purposes beyond the main website: subdomains for specific services (mail.example.com, app.example.com, calendar.example.com), third-party platform integrations, and custom domains for hosted tools. Before changing or removing a CNAME, it's worth understanding what it points to and whether anything depends on it. A CNAME that looks unfamiliar may be supporting a service that someone in the organization uses regularly.

If you're moving DNS to a new provider entirely

Migrating a DNS zone — moving all records from one provider to another — requires recreating every existing record at the new provider before the migration is completed. The new provider's nameservers should be serving all the correct records before the domain is pointed at them. If the migration is done by simply switching nameservers without recreating the records, everything that depended on the old DNS — email, verifications, subdomains — stops working the moment the switch propagates.

If you're not certain which records are safe to change, or if the DNS zone contains records you don't recognize, that's the right moment to stop and get help. A DNS mistake that breaks email can take hours to propagate a fix, and messages sent during that window may be lost permanently. Web Relevant can review an existing DNS zone, identify what each record does, and help plan a change that doesn't break anything in the process.

The domain is more than the website address

Most people think of a domain name as the address of a website. That's accurate, but it's only part of what a domain does. The domain is also the foundation for email addresses, the anchor for DNS records that control a range of services, and the identifier used by third-party platforms to verify ownership and connect accounts. When a business doesn't have clear control over its domain, it often doesn't have clear control over any of the things that depend on it.

The website

The most visible dependency. DNS records — typically A records or CNAMEs — point the domain to a web hosting provider or platform. If the domain lapses, is transferred, or has its DNS changed without planning, the website goes down. This is usually the first thing people notice, which is why domain ownership tends to surface as an issue at the worst possible moment: when the site is already offline.

Email

Business email addresses that use the domain — [email protected] — depend on DNS records (MX records) that route incoming messages to the right mail servers. The domain also carries authentication records (SPF, DKIM, DMARC) that tell receiving servers whether to trust messages sent from it. If the domain is lost or its DNS is changed carelessly, email delivery can break in ways that aren't immediately obvious — messages may bounce, arrive in spam, or simply disappear.

Google services

Google Workspace accounts (business Gmail, Calendar, Drive, Meet) are tied to the domain. Google Search Console — which tracks how the site appears in search results — is verified through a DNS record or a file on the website. Google Business Profile may reference the domain as the business website. If domain access is lost, the ability to manage or recover these accounts becomes significantly more complicated.

Third-party verification records

Many platforms verify domain ownership by asking the owner to add a specific TXT record to DNS. Microsoft 365, various security tools, marketing platforms, and analytics services all use this mechanism. These records are invisible in normal operation — they just sit in the DNS zone confirming that the domain owner authorized the service. Losing control of the domain means losing the ability to add, update, or remove these records, which can affect the organization's ability to manage those services.

Subdomains and hosted tools

Many businesses use subdomains — app.example.com, portal.example.com, mail.example.com — to host specific tools or services. These are configured as DNS records pointing to the relevant platforms. They may support customer-facing tools, internal systems, or integrations that staff use daily. Because subdomains are often set up by vendors or developers and then forgotten, they can be easy to overlook when taking stock of what depends on the domain.

Why domain ownership is usually the right starting point

When an organization is trying to understand its web infrastructure — what it has, who controls it, what depends on what — the domain is usually the most logical place to begin. Whoever controls the domain controls the DNS zone, which means they control the routing for the website, email, and every service that depends on a DNS record. Establishing clear, direct ownership of the domain before working through anything else avoids the situation where other problems are solved but the underlying control question remains unresolved.

If the domain is registered under a former employee's account, a previous agency, or a vendor who is no longer involved, that's worth resolving as a priority — not because something is broken right now, but because every other dependency on that domain is only as secure as the domain itself. Web Relevant helps organizations work through this kind of infrastructure review, starting with domain ownership and working outward from there.

Working and in order are different things

A website that loads correctly tells you that the current configuration is functioning. It doesn't tell you who controls the domain, whether the hosting account will renew, whether the email records are intact, or whether anyone in the organization could recover access if something changed. These are questions about the infrastructure behind the website, not the website itself — and they're worth answering before something goes wrong rather than after.

Domain ownership and access

The most fundamental question: does the organization have direct, confirmed access to the domain registrar account where the domain is registered? Not through a vendor, not through a former employee's login, but through an account the organization controls directly. If the answer is uncertain, that's the first thing to resolve. Everything else — the website, the email, the DNS records — depends on the domain, and the domain is only as secure as the account it's registered under.

While you're in the registrar account, confirm the contact email is current, the payment method is valid, and auto-renewal is enabled. A domain that lapses because of an expired card or an unmonitored inbox is a preventable problem.

DNS records

Log in to wherever the domain's DNS is managed and review what's there. You don't need to understand every record in detail, but you should be able to identify the records that control the website (A records or CNAMEs pointing to the hosting provider), the records that control email (MX records, and supporting TXT records for SPF, DKIM, and DMARC), and any verification records added by third-party services. If there are records you don't recognize and can't account for, that's worth investigating — not because they're necessarily a problem, but because understanding what's there is part of knowing the infrastructure is in order.

Hosting account and renewal

Confirm that the organization has direct access to the hosting account — the account that pays for the server or platform where the website lives. Check the contact email and payment method, the same way you would for the domain registrar. If the hosting is managed by a vendor or developer, confirm that the organization has its own login and that the account could be managed independently if that relationship ended.

Email dependencies

If the organization uses email addresses at the domain, confirm that the email service is running under an account the organization controls. Check that the MX records in DNS match what the email provider requires. If the email service has its own renewal or billing cycle, confirm that's also current. Email is often the last thing people think to check and the first thing that causes serious disruption when it breaks.

Google properties

If the organization uses Google Search Console, Google Analytics, or Google Business Profile, confirm that the organization has administrative access to each — not just view access, and not access that depends on a former employee's personal Google account. These accounts are connected to the domain and to the business's online presence; losing access to them is harder to recover from than most people expect.

Account recovery methods

For each critical account — domain registrar, hosting, email, Google properties — confirm that the recovery options are current. Recovery phone numbers and backup email addresses that belong to former employees are a common gap. If an account needs to be recovered and the recovery path leads to someone who is no longer with the organization, the recovery process becomes significantly more complicated.

Basic documentation

None of the above requires formal documentation, but it does require that someone in the organization knows the answers. At a minimum: who controls the domain registrar account, who controls the hosting account, where DNS is managed, what email service is in use and under what account, and where the credentials for each are stored. If that information lives only in one person's memory, the organization has a key-person dependency on its own infrastructure.

Web Relevant helps organizations work through this kind of review — not as a formal audit, but as a practical exercise in understanding what's in place and identifying anything that needs attention. If the answer to most of these questions is uncertain, that's a reasonable place to start a conversation.

Why this matters

Google Search Console, Google Analytics, and Google Business Profile are three separate Google products, each with its own access controls. They're commonly set up by whoever built the website or handled the initial marketing setup — which means they're often tied to a personal Google account that belongs to an individual rather than the organization. When that individual is no longer involved, the organization may have no way to access, modify, or recover the account.

Google Search Console

Search Console is verified through a connection to the domain — either a DNS record, an HTML file on the website, or a tag in the site's code. Whoever added that verification owns the property in Search Console. If the property was added under a vendor's personal Google account and the vendor is no longer involved, the organization may not have access to its own Search Console data. The verification itself may still be in place — the DNS record or tag is still there — but the account that can read the data and manage the property belongs to someone else.

The practical consequence is that the organization can't see how the site is performing in search results, can't submit a sitemap, can't review crawl errors, and can't receive notifications from Google about issues with the site. These aren't catastrophic problems in the short term, but they represent a gap in visibility that compounds over time.

Google Analytics

Analytics properties are similarly account-dependent. The property is created under a Google account, and access is granted to additional users from there. If the property owner's account is inaccessible, the organization may be able to view data if it was granted access, but it may not be able to manage the property, add users, or change configuration. If the organization has no access at all, historical data is effectively locked away — and new data collection may have stopped if the tracking code was never properly installed or has since been removed.

Google Business Profile

Business Profile is the listing that appears in Google Maps and in search results when someone searches for the business by name. It's claimed and managed through a Google account. If the account that claimed the listing belongs to a former employee or vendor, the organization may not be able to update the listing's hours, address, phone number, or description — or respond to reviews. In some cases, the organization may not even know who claimed the listing or when.

What appropriate ownership looks like

Each of these properties should be owned by — or have administrative access granted to — a Google account that the organization controls directly. The most durable approach is a Google Workspace account at the organization's own domain ([email protected], for example), rather than a personal Gmail account. Personal accounts are tied to individuals; a Workspace account at the organization's domain can be managed, transferred, and recovered through the domain owner.

How to check access right now

For Search Console and Analytics: log in to each with a Google account you control and check whether the property appears. If it does, check the user management settings to see who else has access and at what level. If the property doesn't appear, it may be owned by a different account — check with whoever built the website or set up the original marketing configuration.

For Business Profile: search for the business name on Google and look for a "Claim this business" or "Own this business?" prompt. If the listing is already claimed, it will show a "Manage" option when you're logged in to the owning account. If you can't find who owns it, Google's account recovery process for Business Profile allows the current business owner to request access — but the process requires verification and takes time.

Recovery when access has been lost

Recovery options vary by product. For Search Console and Analytics, if the original property owner can be contacted, the simplest path is to have them grant administrative access to an account the organization controls, then transfer ownership. If the original owner is unreachable, Google's account recovery processes apply — which are designed for individual account recovery, not organizational access disputes, and may not resolve the situation quickly.

For Business Profile, Google provides a verification path for business owners who believe they should have access to a listing. This typically involves verifying the business's physical address or phone number. It's a slower process than a direct transfer, but it's the standard path when the original claiming account is inaccessible.

Web Relevant helps organizations identify who currently has access to their Google properties, what the gaps are, and what the practical recovery options look like. If access to any of these accounts is uncertain, that's worth resolving before it becomes urgent.