Why Did Google Deindex Your Pages? Causes and Recovery (2026)

Google deindexes pages for one of two reasons: something on your site changed — a directive, a redirect, a server response — or Google re-evaluated the pages and dropped them below its indexing threshold. Site-side changes cause most deindexing and produce a sudden drop; re-evaluation produces a gradual bleed.

That split is the whole diagnostic: read the pattern first, then match it to a cause. This guide covers how to read the drop pattern in Search Console, the seven causes ranked by how often they are responsible — each with its detection step and fix — the four-step recovery workflow, and realistic re-indexing timelines per cause.

TL;DR — Quick Summary

• Deindexing means pages that were in Google's search index dropped out — they stopped being eligible to appear for any query
• The most common causes are your own changes: an accidental noindex in a deploy, a robots.txt block, canonical or redirect changes, and persistent 5xx errors
• The Google-side causes: quality re-evaluation after core updates (gradual), plus rare and explicit manual actions and security issues
• A sudden mass drop points at a technical or directive change aligned with a deploy; a gradual bleed points at quality re-evaluation
• Recovery is cause-first: identify the change window, fix the cause, re-request crawling, and monitor re-indexing
• Timelines run days to weeks — technical causes recover at recrawl speed, quality-driven drops recover slowest

---

Sudden Mass Drop or Gradual Bleed? Read the Pattern First

The shape of your indexed-page curve names the cause class before you inspect a single URL. A cliff — hundreds of pages gone within days — is a technical or directive change that shipped site-wide. A slope — the indexed count sliding for weeks — is quality re-evaluation or slow decay.

Read the curve in Google Search Console under Indexing → Pages: the indexed-count chart dates the drop, and the "Why pages aren't indexed" table names the states absorbing your URLs. Then compare the drop date against your deploy history — the overlap usually closes the case.

---

What Causes Google to Deindex Pages? The 7 Causes, Ranked

Pages leave the index when a recrawl finds a noindex, a block, an error, a redirect, or a canonical pointing elsewhere — or when Google's quality re-evaluation demotes them below the indexing threshold. Seven causes cover nearly every deindexing event.

Cause 1: An Accidental Noindex Shipped in a Deploy

The most common cause of sudden deindexing is a noindex directive that went live by mistake — a staging configuration deployed to production, a CMS or SEO-plugin toggle flipped site-wide, or an X-Robots-Tag: noindex header added at the CDN. The directive takes effect per URL on the next recrawl, so your most frequently crawled pages vanish first and the drop spreads down the crawl schedule.

Detection: view the source of an affected URL and search for noindex in the meta robots tag, check the response headers for X-Robots-Tag, and confirm with URL Inspection — deindexed URLs report "Excluded by 'noindex' tag."

Fix: remove the directive, verify the live page no longer serves it, and request recrawling. The pages return as Googlebot refetches them.

Cause 2: A Robots.txt Block Froze Recrawling and the Pages Decayed

A robots.txt block does not remove pages directly — it controls crawling, not indexing — but it stops Google from refreshing them. The stored copies go stale, listings degrade to bare snippet-less entries, and the blocked URLs bleed out of the index over time. One sharper variant: a robots.txt file returning 5xx errors is treated as a temporary full disallow, halting crawling of the entire site.

Detection: watch the "Blocked by robots.txt" and "Indexed, though blocked by robots.txt" rows rising in the Pages report, and test affected URLs against your live rules.

Fix: delete the blocking rule, confirm the file itself returns 200, and let recrawling resume.

Cause 3: Canonical or Redirect Changes Point Signals at Other URLs

A new redirect or a changed canonical tells Google the page now lives elsewhere, and Google consolidates it into the target — correct during a migration, deindexing-shaped when accidental. The page has not vanished from Google's view; canonical URL selection folded it into another URL's cluster, and only that URL appears in results.

Detection: inspect an affected URL and read the Google-selected canonical. A canonical you did not intend means a stray tag, a template bug, or a redirect shipped by mistake — the override mechanics are covered in fixing "Duplicate, Google chose different canonical than user".

Fix: remove the unintended redirect or tag, re-point every signal at the URL you want indexed, and recrawl both sides of the cluster.

Cause 4: Quality Re-Evaluation After a Core Update

Google re-scores sites during core updates, and pages near the indexing threshold drop below it — the gradual bleed. Thin, duplicative, and unvisited sections drop first, and the deindexed URLs resurface in the Pages report under "Crawled - currently not indexed": Google still fetches them, and now declines to store them.

Detection: the decline aligns with a documented update window, no directive or error explains it, and the losses concentrate in your weakest sections.

Fix: treat it as a content problem — consolidate thin and overlapping pages, deepen the ones worth ranking, and remove what serves nobody. The full content-side playbook is in fixing "Crawled - Currently Not Indexed".

Cause 5: A Manual Action

A manual action is a human reviewer's penalty, and it is rare and explicit: Search Console lists it under Security & Manual Actions → Manual actions with the violation type and whether it affects specific pages or the whole site. Deindexing with an empty panel is not a penalty — this is the first myth to eliminate.

Detection: open the Manual actions panel; a penalty is never silent.

Fix: remediate exactly what the notice names, then submit a reconsideration request from the same panel and wait for the human review.

Cause 6: Hacked Content or a Security Issue

Compromised sites get flagged in Security & Manual Actions → Security issues, and Google demotes or removes affected URLs — injected spam pages, malicious redirects, and malware all qualify. Hacks also create their own deindexing debris: thousands of injected URLs that later fall out and drag reporting with them.

Detection: the Security issues panel names the problem; unfamiliar URLs in the Pages report or in your site's search results confirm the injection.

Fix: clean the compromise, patch the entry point, and request a security review from the panel.

Cause 7: Persistent Server Errors

Google treats HTTP status codes as instructions: 5xx responses first slow crawling, and URLs that keep failing get dropped from the index — Google's documentation on HTTP status codes and network errors describes exactly this escalation. Expired hosting, lapsed renewals, broken origin servers behind a live CDN, and long outages all deindex pages this way. Pages deleted with 404 or 410 are removed on recrawl by design.

Detection: the "Server error (5xx)" row in the Pages report and a rising 5xx share in Crawl stats date the failure window.

Fix: restore stable 200 responses, then trigger recrawling — Google rebuilds trust in the host as clean responses accumulate.

---

How Do You Recover Deindexed Pages? The 4-Step Workflow

Recovery is cause-first: identify the change window, fix what changed, trigger recrawling, and monitor. Requesting indexing before the fix re-runs the same evaluation and returns the same result.

Step 1: Identify the change window. Date the drop on the Pages report chart, export the affected URLs, and line the date up against deploy history, configuration changes, CDN rules, and hosting renewals. The date typically narrows seven candidate causes to one or two.

Step 2: Fix the cause. Apply the fix matching your cause from the list above — remove the directive, unblock the crawl, realign the canonical, repair the content, remediate the action, clean the hack, or stabilize the server.

Step 3: Re-request crawling. Deindexed pages return only through a recrawl. Use requesting indexing in Google Search Console for the most important URLs — it queues priority fetches but caps at about a dozen manual requests per property per day — and submit the rest in bulk through a direct submission service.

Step 4: Monitor re-indexing. Run the recovered list through the free Google Index Checker to count URLs back in the index, and spot-check individual pages with the five methods compared in how to check if a page is indexed on Google. Watch the Pages report until the indexed count recovers its baseline.

---

How Long Does Re-Indexing Take After the Fix?

Days to weeks. Technical causes recover at recrawl speed — each URL returns when Googlebot refetches it and finds the problem gone — while quality-driven drops recover slowest, because Google must re-evaluate improved content, sometimes across multiple update cycles.

Direct URL submission compresses the recrawl side of every row — the fetch happens in hours instead of whenever the scheduler returns — but no submission channel skips Google's evaluation of what the fetch finds.

---

Frequently Asked Questions

Did Google ban my site?

Almost certainly not. Bans are manual actions, and manual actions are explicit — named in the Manual actions panel with the violation and scope. An empty panel means the cause is technical or quality-driven, which is the outcome in the overwhelming majority of deindexing cases.

How do I find out which pages were deindexed?

Open Indexing → Pages in Search Console, date the drop on the indexed-count chart, and export the URLs from the states that grew — that export is your deindexed list. Then bulk-check your critical URLs with an index checker to catch pages the report has not refreshed yet.

Will requesting indexing bring deindexed pages back?

Only after the cause is fixed. Request Indexing queues a priority crawl; it does not change the verdict that removed the page. An unchanged page — still noindexed, still erroring, still thin — comes back from the requested crawl to the same outcome.

Can deindexed pages recover their previous rankings?

Pages deindexed by technical causes return to their prior positions once re-indexed, because the underlying signals — links, content, history — never left. Pages deindexed by quality re-evaluation return only as far as the improved content earns; recovering the old rankings requires clearing a bar the old content already failed.

---

Next Steps

1. Date the drop on the Pages report chart and export the affected URLs
2. Classify the pattern: cliff, bleed, one section, or everything
3. Check the Manual actions and Security issues panels to rule out the explicit causes
4. Inspect a sample URL for noindex, robots.txt blocks, canonicals, and server errors
5. Match the evidence to one of the seven causes and apply its fix
6. Request recrawling for priority URLs in Search Console
7. Submit the full recovered list through IndexBolt for crawling within hours
8. Monitor the index checker and Pages report until the count recovers