Website disappeared from Google: six checks
Treat this as a fault you can isolate, not a mystery you have to guess at.
Pick one page that used to appear in search. Write down its old URL and the URL you expect to work now. Test that pair all the way through this guide. Do not use the home page as a stand-in for a missing product, service page, or article.
Six failures are worth ruling out first because each gives you a direct yes or no answer:
- The domain no longer resolves.
- The TLS certificate is invalid or expired.
- The page says
noindex. robots.txtblocks the page.- The canonical points somewhere else.
- A migration left the old URL without a working redirect.
Use that order unless the loss started with a migration, redesign, or URL change. In that case, check the domain and certificate first, then jump straight to redirects. A migration changes the odds, and it is wasteful to inspect five page tags while the old URLs return 404.
1. Does the domain still resolve?
What it feels like
The whole site is gone. The browser says it cannot find the server, the hostname does not exist, or the connection never reaches a web server. The failure affects every path on the same hostname.
The one check
Run a public DNS lookup for the exact hostname in the missing URL. Check www.example.com if that is the URL people used, not only example.com. The hostname should return an address or an alias that eventually returns an address.
No DNS answer does not prove the domain expired. It proves that nobody can reach the site by that hostname. The next check belongs at the registrar: is the domain active, and does it still use the intended nameservers?
If this confirms the problem
If the registration expired, renew it with the registrar today. If the registration is active, repair the nameservers or DNS records with the DNS provider. Do not change SEO settings while the hostname itself is broken.
You do not need a monitoring product to repair this. You need the registrar or DNS provider that controls the domain.
If this rules it out
The exact hostname resolves publicly. Move to the certificate.
2. Can a browser establish a valid HTTPS connection?
What it feels like
The hostname resolves, but the browser shows a privacy or certificate warning before it loads the page. A crawler may fail before receiving any HTML. The problem may affect the whole domain or only one hostname, such as www.
The one check
Inspect the certificate served by the exact hostname. Confirm that it has not expired, that the hostname is covered, and that the certificate chain is accepted. The SSL and domain expiry checker gives you the public result without asking you to change anything.
If this confirms the problem
Renew or reissue the certificate through the host, CDN, or certificate provider that terminates HTTPS. Then verify the live hostname again. Renewing a certificate in one dashboard is not enough if the load balancer or CDN still serves the old one.
An expired certificate is an access failure. It is not proof that Google has already removed the pages, but restoring access comes before every page-level diagnosis.
If this rules it out
The exact HTTPS URL loads without a certificate error. If the loss followed a migration or redesign, go to step 6 now. Otherwise continue to noindex.
3. Does the page tell search engines not to index it?
What it feels like
The page loads normally for people, but it is absent from search. Search Console may report that the URL is excluded by noindex. Other pages on the same site may be unaffected.
The one check
Inspect the live response for both forms of the directive:
- A
<meta name="robots" content="noindex">tag in the page. - An
X-Robots-Tag: noindexHTTP response header.
The answer you need is simple: does either one contain noindex for the crawler you care about? Use the indexability checker for the page and the X-Robots-Tag checker for the response header.
If this confirms the problem
Remove the directive at its source. That source might be a CMS visibility setting, an SEO plugin, a theme condition, an application header, or a staging rule copied into production. Recheck the live response after publishing. Do not stop at the dashboard setting.
Once the live page no longer returns noindex, use URL Inspection in Google Search Console to check the URL and request another crawl if appropriate. Removal of the directive does not mean the search result returns immediately.
If this rules it out
Neither the HTML nor the HTTP headers return noindex. Move to robots.txt.
Where to go next
Use the platform-specific fixes if you need the exact setting that produced the directive.
4. Does robots.txt block the exact URL?
What it feels like
Search Console says the URL is blocked by robots.txt, or Google cannot fetch the page even though a browser can. You may also see a bare URL in search with no useful description.
The one check
Test the exact page URL against the live /robots.txt, for both the relevant crawler and the User-agent: * group. A rule that looks broad is not enough. You need to know whether the final rule actually matches this path. The robots.txt tester answers that question.
If this confirms the problem
Remove or narrow the matching Disallow, publish the change, and test the same URL again.
Do not confuse crawling with indexing. A Disallow rule stops a compliant crawler from fetching the page. It does not guarantee that the URL disappears from search. Google can still list a blocked URL without its content. A page-level noindex also cannot do its job while robots.txt prevents Google from seeing it.
If this rules it out
The exact URL is allowed for the relevant crawler. Move to the canonical.
Where to go next
Use the platform-specific robots.txt fixes to find the real editor, generated file, or setting for the site.
5. Does the canonical point at the wrong page?
What it feels like
The page loads, can be crawled, and does not say noindex, but Google treats another URL as the main version. One page or a cluster of similar pages disappears while the rest of the site remains visible.
The one check
Inspect the live page’s rel="canonical" value. It should point to the URL that is meant to represent this content, usually the page itself. The canonical checker shows the value returned by the page.
A canonical is a hint, not an access control. A wrong value is a concrete fault. A correct self-referencing value does not force Google to choose it if other signals disagree.
If this confirms the problem
Correct the canonical in the CMS, template, SEO plugin, or application output that generated it. Publish, then recheck the live page. Check more than one affected URL before changing a shared template, because one bad template can rewrite a whole section.
Do not redirect pages merely because a canonical is wrong. Fix the canonical first unless the content has genuinely moved.
If this rules it out
The live canonical points to the intended URL. If Search Console still chooses another canonical, compare the duplicate pages and internal links before changing the tag again.
Where to go next
Use the platform-specific canonical fixes for the exact field or template that owns the value.
6. Do the old URLs reach the right new pages?
What it feels like
The loss began after a migration, redesign, domain change, or slug cleanup. New pages load when someone knows their URLs, but old search results return 404, redirect to the home page, loop, or land on unrelated content.
The one check
Run the old URL through the redirect checker. Start with the URL that had links, traffic, or a search result before the move. Do not test only the new URL.
The healthy result is a permanent redirect, normally 301 or 308, that goes directly to the equivalent new page and finishes with a successful response. Record every hop. A redirect chain can hide one stale mapping in the middle.
If this confirms the problem
Create an old-to-new URL map and add a permanent redirect for each page that moved. Send each old URL to its closest current equivalent. Do not send every missing URL to the home page. If there is no replacement, returning a real 404 or 410 is more honest than an irrelevant redirect.
Use the platform’s redirect table where it has one. On a self-hosted site, the mapping may live in the web server or application instead. Retest the public old URL after the change.
If this rules it out
The old URL reaches the matching new page through a direct permanent redirect. Test several affected URLs, including one page, one collection or category, and one deep content URL. One working redirect does not prove the migration map is complete.
Where to go next
Use the platform-specific migration fixes for the exact redirect table, automatic-slug behavior, and path limits on the site.
If all six checks pass
Stop changing directives. This guide has ruled out six technical access and routing failures. It has not proved that the page ranks, deserves to rank, or is still in Google’s index.
Inspect the exact URL in Google Search Console. Check whether Google crawled it, whether it is indexed, which canonical Google selected, and whether the property has a manual action or security issue. Then separate an indexing loss from a ranking loss. A page can be indexed and still stop appearing for the query you are watching.
If the page is accessible, indexable, crawlable, correctly canonicalized, and reached by its old URLs, the next diagnosis is outside this checklist. Keep the evidence you collected. Do not manufacture a second technical problem by toggling settings that already passed.
Before you close the incident
Re-run the failed check against the public URL. Record the result and the time. Then check at least one sibling page that shares the same template or platform setting.
The fix is complete when the live response is correct. A saved dashboard setting, a successful deploy, or a green plugin notice is only a step on the way there.
Related guide: why organic traffic drops overnight — the triage list.