Why Pages Get Deindexed and How to Diagnose It

A page gets deindexed when Google removes it from the index entirely, so it can no longer rank for anything. The most common causes are server errors and crawl backoff, broken or conflicting canonical tags, entity confusion in schema, and thin or duplicated templated pages. Diagnose it in Search Console before you touch the content.

Three failures that look the same and are not

Before you fix anything, name the problem correctly. Three different failures all show up the same way in a traffic chart, a line that drops, and the wrong diagnosis wastes weeks. They are deindexation, rank decay, and AI-Overview cannibalization, and the fix for each is different.

• Deindexation. The page is gone from the index. It ranks for nothing, including its own brand-plus-title query. A site: search for the exact URL returns nothing. This is a technical and trust problem, not a content problem.
• Rank decay. The page is still indexed. It still shows up for a site: query and still ranks for something, just lower than it used to. A competitor wrote a better page, the query intent shifted, or your topical authority slipped. This is a relevance problem.
• AI-Overview cannibalization. The page ranks fine in the classic blue links, but it gets fewer clicks because an AI Overview or featured snippet now answers the query above it. Impressions hold or rise while clicks fall. This is a SERP-real-estate problem, not an indexing or ranking problem.

The test that separates them takes two minutes. Run a site: search for the exact URL and a Search Console URL Inspection. If the URL is not in the index, you have deindexation. If it is indexed but ranks lower, you have decay. If it ranks but impressions stay flat while clicks fall, you have cannibalization. Everything below is about the first one, because deindexation is the one most teams misdiagnose and fix from the wrong end.

What actually causes deindexation

Pages do not get deindexed at random. There is almost always a signal Google read as “do not keep this,” and it usually sits in the substrate of the site, not in the prose. These are the recurring causes, roughly in the order we find them:

• Server errors and crawl backoff. When Googlebot hits repeated 5xx responses, including 500, 503, and the 508 resource-limit error that shared hosting throws when entry processes are exhausted, it slows its crawl rate to avoid hurting the site. If the errors persist, pages already in the index can be dropped because Google could not reconfirm they still serve a 200. Hosting instability is the single most underrated cause of deindexation, because the symptom (missing pages) looks nothing like the cause (a maxed-out server).
• Missing or conflicting canonical tags. A canonical tag tells Google which URL is the real one. When a page canonicalizes to a different URL, or two pages each claim to be canonical, or the canonical points at a redirected or noindexed URL, Google may drop the page in favor of the version it thinks you prefer. Trailing-slash and HTTP-versus-HTTPS splits create the same conflict by accident.
• Entity confusion in schema. Duplicate Organization nodes, an author @id that resolves nowhere, or two different identities claiming to be the same company tell search engines and AI systems that the site’s identity is unsettled. Confused entity signals erode the trust that keeps borderline pages indexed, and they directly hurt your odds of being cited in AI answers.
• Thin or duplicated templated pages. Location pages, service-area pages, and product pages cloned from one template with a city name swapped get read as near-duplicates. Google crawls them, decides they add nothing, and parks them in “Crawled, currently not indexed.” Programmatic pages with no unique value are the most common version of this.
• Content pruned without redirects. A page deleted or unpublished and left to return a 404 or 410 is deindexed by design, which is fine if you meant it. The damage comes when the page had links and rankings and nobody set a 301 to the replacement. The signal evaporates instead of moving.

How to diagnose each cause

Diagnosis is where most audits go wrong, because people start editing copy before they know whether the page is even reachable. Work the substrate first. Here is the order we run it.

1. Read the Search Console index-coverage states. The Pages report sorts your URLs into reasons. Two states matter most for deindexation. “Crawled, currently not indexed” means Google fetched the page, looked at it, and chose not to index it, which usually points to thin, duplicated, or low-value content. “Discovered, currently not indexed” means Google knows the URL exists but has not prioritized crawling it, which often points to crawl-budget strain or a server that has been slow or erroring. A page that flips from “Indexed” to either of these states is your deindexation, named.

2. Run URL Inspection on the specific URL. This is the ground truth. It tells you Google’s last crawl status code, the canonical Google selected versus the one you declared, whether the page is marked noindex, and whether it is in the index right now. A declared canonical that does not match the Google-selected canonical is one of the fastest wins you will find.

3. Check crawl stats for the non-200 rate. In the Crawl Stats report, look at the breakdown of response codes over time. A rising share of 5xx responses, or host-status flags, confirms a hosting or resource problem and explains a broad drop that hit many pages at once. Deindexation that arrives in a cluster is almost always a server story.

4. Run a paced re-crawl of the affected URLs. Pull the affected URLs and fetch each one yourself, slowly, checking the live status code, the final URL after redirects, and whether a canonical tag is present and self-referential. Pace the requests so you do not add load to a server that may already be the problem. This catches canonical conflicts, accidental noindex tags, and redirect chains that the index-coverage report only hints at.

5. Validate schema for duplicate entities. Run the page through a structured-data validator and check for more than one Organization node, an author or organization @id that does not resolve to a real entity, and conflicting identity claims across templates. If the machines cannot tell who publishes the page, that is a trust signal worth fixing before you write a word.

How to recover, in the right order

The mistake we see most is teams that rewrite the content first. If the substrate is broken, better prose gets crawled into the same wall. Recover from the bottom up.

1. Fix hosting stability first. If crawl stats show 5xx or 508 errors, nothing else matters until the server reliably returns 200. That may mean raising resource limits, fixing a runaway plugin or script, or moving off shared hosting that maxes out under crawl load. A page cannot be reindexed if Google cannot fetch it.
2. Fix canonical hygiene next. One canonical URL per page, self-referential, matching the version you actually want indexed. Resolve trailing-slash and HTTP-to-HTTPS splits with redirects. Make sure no canonical points at a redirected, 404, or noindexed target.
3. Fix trust and entity signals third. Collapse duplicate Organization nodes into one, give your author a resolvable @id, and keep one consistent identity across every template. This is the same work that earns AI citations, because a clean, single entity is what AI systems attach your mentions to. It is where our AI-search visibility work concentrates.
4. Fix the on-page substance last. Only after the page is reachable, canonical, and trusted does content quality move the needle. Merge thin templated clones into fewer strong pages, add the unique value that “Crawled, currently not indexed” was rejecting, and set 301s for anything you pruned.
5. Request reindexing once the page is genuinely fixed. Use URL Inspection to request indexing, or resubmit the sitemap for a batch. Requesting reindexing on a page you have not actually fixed just resets the same rejection. Earn the recrawl by giving Google a reason to keep the page this time.

Deindexation triage table

Map the symptom to the likely cause to the fix tier. Substrate fixes (Tier 1) come before content fixes (Tier 3) every time.

The short version

Deindexation is a substrate problem more often than a content problem. Name it first by separating it from rank decay and AI-Overview cannibalization, because the fix for each is different. Diagnose it in Search Console with the index-coverage states, URL Inspection, and crawl stats before you open the editor. Then recover from the bottom up: hosting, canonicals, entity trust, and only then on-page, and request reindexing once the page is genuinely worth keeping. Doing it in the wrong order is how teams spend a quarter rewriting pages a server outage deindexed.

For a portfolio of pages across multiple domains or basins, this work scales into enterprise SEO, where crawl health and entity consistency are managed as a system rather than page by page. If you want a second set of eyes on a deindexation event, that is the kind of diagnosis our SEO agency does.

Frequently Asked Questions

What does it mean when a page is deindexed?

A deindexed page has been removed from Google’s index entirely, so it can no longer appear for any search, including its own exact title. That is different from a page that still ranks but has dropped in position. You confirm deindexation with a site: search for the exact URL and a Search Console URL Inspection.

What is the difference between deindexed and “crawled, currently not indexed”?

“Crawled, currently not indexed” is a specific Search Console state where Google fetched the page, evaluated it, and chose not to index it, usually because the content reads as thin, duplicated, or low value. Deindexed is the broader outcome of a page no longer being in the index, and “Crawled, currently not indexed” is one of the common reasons a page lands there.

Why did Google deindex my pages all at once?

A cluster of pages dropping together almost always points to a server problem rather than a content problem. When Googlebot hits repeated 5xx or 508 resource errors, it slows its crawl and can drop pages it cannot reconfirm. Check the Crawl Stats report for a rising non-200 rate before you touch the content.

Can a canonical tag cause deindexation?

Yes. If a page canonicalizes to a different URL, or its declared canonical does not match the one Google selects, or the canonical points at a redirected or noindexed target, Google may drop the page in favor of the version it thinks you prefer. URL Inspection shows the declared canonical against the Google-selected one, which is the fastest way to catch this.

How do I get a deindexed page reindexed?

Fix the actual cause first, in order: hosting stability, then canonical hygiene, then entity and trust signals, then on-page content. Once the page reliably returns a 200, has a clean self-referential canonical, and carries unique value, request indexing through URL Inspection or resubmit the sitemap. Requesting reindexing before the fix just repeats the same rejection.

Is losing clicks to an AI Overview the same as being deindexed?

No. If your page still ranks in the classic results but impressions hold while clicks fall, an AI Overview or featured snippet is answering the query above you. That is a SERP-real-estate problem solved by improving AI-answer presence, not an indexing problem. Confirm the page is still indexed before you treat it as deindexation.

Find out which of your pages Google has dropped

Pages fall out of the index quietly, and most teams notice only when the traffic is already gone. Our index-health check pulls your indexed pages, flags the ones Google has dropped or refused, and traces the cause back to the issues covered above. You walk away knowing what is missing and what to fix first. We go through the results together on a discovery call.

Book a discovery call