A page disappeared from Google: how to tell what changed

A page missing from one search is not automatically a penalty or deindexation. Use this evidence-led sequence to establish what changed before choosing a fix.

A stakeholder searches for a page that was visible last week and cannot find it. A quick check in Search Console appears to show the same thing. The immediate conclusion is often that Google has removed the page or that the site has received a penalty.

That conclusion may be wrong. The page may still be indexed but ranking lower, another URL may have replaced it, the search may have changed by location or device, or a recent technical change may have affected access. Search Console data may also be delayed or represent a wider set of searches than the one being checked.

“Disappeared” is an observation, not a diagnosis. The useful first question is: is the page unavailable, unindexed, represented by another URL or simply less visible? This article sets out a calm order of checks so you can answer that question before changing the page or escalating the issue.

Start by defining what has disappeared

These symptoms sound similar, but they lead to different investigations:

• Not visible for one query: the page does not appear in one manual search.
• A substantial ranking decline: the page still appears for some searches, but much lower or less often.
• Another URL is appearing: Google is showing a different page from the same site for the query.
• The URL is not indexed: Google has not selected that URL as an indexed page or has removed it from the index.
• The page is unavailable: users or Google cannot retrieve it reliably because of a server response, redirect, access restriction or rendering problem.

A page can remain indexed and still not appear for the query you tested. Google’s URL Inspection guidance says that “URL is on Google” means the URL has been indexed and is eligible to appear, not that it will appear for every query. URL Inspection documentation is useful here, but it is not a ranking guarantee.

That distinction matters commercially. A visibility problem may call for further ranking and demand analysis or continued observation. An indexing or access problem may require a technical fix. Treating both as “the page has disappeared” encourages the wrong response.

Follow the checks in this order

The sequence below moves from the cheapest and most clarifying checks to the more involved ones. Each step should narrow the possibilities. None should be treated as conclusive in isolation.

1. Confirm the observation

Record the exact URL, query, date, country, language, device and search environment that produced the concern. If possible, save the search result or ranking-tool observation rather than relying on memory.

Then repeat the check carefully. Use an incognito window or a clean test environment where appropriate, and compare more than one related query. Search results can vary by location, language, device, recent searches and personalisation. Google explains some of these sources of variation in its guidance on why search results differ and how results can be customised.

This does not mean the concern is imaginary. It means one manual search is weak evidence. A single rank-tracker reading has a similar limitation. Search Console’s average position describes a set of impressions, not one fixed position that every user sees; its position metric is better used for trends and comparisons.

At this stage, ask:

• Is the page missing from one query or from several closely related queries?
• Is another page from the same site now appearing?
• Did impressions, clicks and average position change, or is the concern based only on a manual search?
• Did the search context change?
• Is the date recent enough that Search Console processing or reporting delay could be involved?

Search Console is not a real-time monitoring system, and Google documents data-processing delays and anomalies. A one-day drop should therefore be checked against a longer trend rather than treated as a confirmed search change. See Google’s guidance on data anomalies and debugging search traffic drops.

2. Inspect the URL and its index status

Put the exact URL into Google Search Console’s URL Inspection tool. Check whether Google reports the URL as being on Google, whether it can be crawled, which canonical URL Google selected and when the URL was last crawled.

This gives you evidence about the inspected URL’s known index state. It does not explain every ranking change. A URL can be indexed but not rank for the query, and a URL can be known to Google without being indexed. Google describes these as distinct stages in its index coverage guidance and URL Inspection documentation.

Read the result as a set of clues:

• URL is on Google: the page is eligible to appear, but this does not guarantee visibility for the tested query.
• URL is not on Google: investigate the reason given, such as a noindex directive, duplication, a crawl issue or another excluded-page status.
• Google-selected canonical differs: another URL may be representing substantially similar content.
• Inspection cannot fetch or test the URL: move quickly to live access and technical checks.

Do not use a site: search as the final verdict on indexation. It is an additional clue, but it does not replace URL Inspection or a review of the page’s technical state.

3. Test what users and crawlers can actually access

Open the page in a browser, then check the live response and the page source or rendered HTML. Look for:

• an unexpected server error, timeout or redirect;
• a redirect to a different page or URL;
• a noindex directive in the HTML or an HTTP header;
• a robots.txt rule that prevents crawling;
• login, geo-blocking, firewall or other access restrictions;
• content that only appears after rendering and is not available as expected;
• a page that returns a 200 response but now behaves like a soft 404 because its useful content has gone.

Google’s technical guidance covers HTTP responses, redirects, robots.txt, indexing directives and soft 404s. A 200 response is helpful, but it does not guarantee indexation. A page can still be treated as a duplicate, soft 404 or unsuitable indexable result.

Check the rendered versions that matter to the affected search environment, including mobile where the site serves materially different output. A deployment can leave one version looking normal while changing the rendered output, internal links or directives on another template variant.

Do not request indexing repeatedly just because the URL is missing. A request can be reasonable after a confirmed technical correction, but it does not replace fixing the access, directive, canonical, duplication or content problem. Google does not guarantee immediate recrawling, indexation or ranking recovery after a request. Google’s URL Inspection guidance explains these limits.

4. Compare canonical signals

Canonicalisation is Google’s process for selecting the main URL when several pages are duplicates or substantially similar. A canonical signal might come from a rel="canonical" link, redirects, internal links, sitemaps or the content itself.

Compare the site’s declared canonical with Google’s selected canonical in URL Inspection. If they differ, inspect both URLs. Check whether the alternative page contains the same content, whether the preferred URL redirects and whether internal links consistently point to the intended version.

Google may select a different canonical from the one declared by the site. A duplicate or alternate URL may then not be indexed independently as the selected version. See Google’s documentation on canonicalisation and canonicalisation troubleshooting.

That is not automatically an error. If two URLs genuinely duplicate one another, Google selecting one can be the intended outcome. The question is whether the selected URL is the page that should receive visibility and whether it serves the same user need.

For a deeper explanation of how canonical attribution can affect reported URLs and clicks, see this guide to Search Console canonical attribution.

5. Review recent changes before changing anything else

Look at deployment history, CMS changes, redirects, template edits, internal-link changes, international settings and releases to robots.txt, sitemaps or structured data. Compare the current page with a known-good version from before the disappearance.

Pay particular attention to changes that affect many URLs at once:

• a template adding noindex or changing canonical logic;
• a migration or redirect rule sending pages to the wrong destination;
• a release removing category or contextual internal links;
• a server, CDN or firewall change blocking crawlers;
• a CMS change making useful content disappear or creating near-duplicate URLs;
• a market or language configuration changing the page Google sees.

Write down the timing rather than assuming that the most recent release caused the problem. A credible link between a deployment and a matching technical symptom is stronger evidence than coincidence. Equally, a page may be recrawled and reprocessed after a change without there being a defect.

6. Look for a pattern beyond the individual URL

Once the URL itself is understood, widen the view. Compare affected and unaffected pages by template, directory, country, device, query group and search appearance. In Search Console, look at clicks, impressions and average position over a sensible comparison period rather than one day.

Google recommends comparing dimensions and affected areas when debugging search traffic changes. These comparisons can show whether the issue is isolated or patterned, although they do not prove the cause. Google’s traffic-drop guidance is a useful starting point.

A pattern across an entire template or market makes a shared implementation issue more plausible. A change limited to one query, device or location makes contextual variation, competition or SERP composition more plausible. These are investigative inferences, not conclusions supplied by Search Console. Breadth raises or lowers the priority of an investigation; it does not identify the cause by itself.

Also check whether demand or the search results page changed. Competitor activity, seasonality, new SERP features and changes in the way people search can reduce clicks without removing your URL from Google’s index. This is one reason to separate indexation loss from visibility loss before judging performance. Google’s traffic-drop guidance sets out related comparison checks, but it does not provide a universal threshold for deciding when a decline is material.

One page, several possible explanations

Imagine a B2B software company has a comparison page targeting “project management software for agencies”. The page was visible near the top of the results, then a stakeholder cannot find it.

There are several plausible explanations for the same observation:

• Query-level visibility change: the page is still indexed, but the query has become more competitive or Google now prefers a different result format.
• Canonical substitution: a new comparison page has similar content and Google has selected that URL instead.
• Technical change: a template release added a noindex directive or changed the page to redirect elsewhere.
• Normal search variation: the stakeholder searched from a different location or device and saw a different result set.
• Wider reassessment: several related comparison pages lost visibility at the same time, with no obvious access defect.

URL Inspection, a live response check, canonical comparison, deployment history and wider Search Console analysis can help separate these possibilities. The original manual search cannot.

Quality reassessment, a ranking-system change or a spam-related system can remain possible once technical and contextual explanations have been examined. But these are competing hypotheses, not the default explanation for one missing result. Google’s ranking systems guidance and traffic-drop guidance do not provide a page-level report saying that a particular disappearance was caused by quality reassessment.

Why “penalty” is usually the wrong first word

A ranking decline should not automatically be called a penalty. Manual actions and security issues are explicit checks in Search Console. Automated ranking or spam-system effects are not interchangeable with a reported manual action, and the absence of a manual action does not prove that no automated system affected visibility. Google’s guidance on spam updates and traffic changes helps keep those concepts separate.

Calling an unexplained change a penalty too early creates two problems. It can send a team into an unnecessary rewrite and distract from a simple deployment defect. First establish the URL’s state. Then decide whether the evidence points to a technical fix, a canonical decision, continued monitoring or deeper analysis.

What not to do first

• Do not repeatedly request indexing without identifying a problem to correct.
• Do not rewrite the page immediately because it was absent from one search.
• Do not change canonical tags until you have compared the relevant URLs and signals.
• Do not infer deindexation from a site: search or one rank-tracker reading.
• Do not label the event a penalty before checking manual actions, technical access and wider patterns.
• Do not wait indefinitely without checking live access, directives and recent deployments.

This discipline preserves the original evidence. Once several changes are made at once, it becomes much harder to know what solved the problem or whether the page would have recovered naturally.

When should the issue be escalated?

A small, recent and context-dependent movement may be worth monitoring after the basic checks are clean. Escalation becomes sensible when one or more of these conditions apply:

• the URL has a confirmed access, indexing or rendering defect;
• multiple pages in the same template or market are affected;
• a deployment or migration has a credible timing and symptom match;
• the affected page is commercially important and the loss is material;
• the decline persists across related queries, devices or markets;
• the page remains technically available but the evidence does not explain a substantial and sustained loss.

This is a practical working threshold, not an official Google rule. Its purpose is to prevent two common mistakes: escalating every isolated search observation and allowing a confirmed template problem to sit untreated because one page still returns a 200 response.

The practical principle

Start by classifying the symptom. Is the page unavailable, unindexed, represented by another URL or still indexed but less visible?

Only after that classification should you choose a fix or decide to wait. The strongest diagnosis usually comes from several signals agreeing: URL Inspection, live access tests, canonical evidence, deployment history, Search Console patterns and controlled search comparisons. Even then, the evidence may establish the URL’s state without proving the precise ranking cause.

On a small site, these checks may be straightforward. At enterprise scale, the difficult work is often separating a real template-level defect from ordinary search movement, then prioritising a safe implementation and validating the result. A classification-first approach keeps the investigation proportionate and makes the next action easier to justify. Liquid Silver can help diagnose the pattern across a site, prioritise its commercial importance and work through implementation without confusing a visible symptom with its cause.