Pages fall out of Google's index for a small number of reasons: your site told Google to drop them (a noindex, a 404, a redirect or a canonical change), Google could not reach them for long enough (server errors, DNS problems, firewalls), someone removed them (the Removals tool, a manual action, a legal request), or Google re-evaluated them and decided they no longer earn a place. Inspecting an affected URL in Search Console tells you which group you are in within a minute.
Being indexed is not permanent. Google re-evaluates its index continuously. The task is to tell a technical accident, which you can reverse in days, from a quality reassessment, which takes real work.
First, confirm it is really deindexing
A traffic drop and a deindexing are different problems. Check before you dig.
- Indexing > Pages. Does the green "Indexed" line drop? On what date?
- URL Inspection on a few pages that lost traffic. "URL is on Google" means the page is still indexed and you have a ranking drop, not an indexing one.
- Performance > Search results, compare the last 28 days with the previous period, open the Pages tab and sort by impressions difference. Pages that went to zero impressions are candidates. Pages with fewer impressions but not zero are still indexed.
Do not judge by the result count of a site: search. It is an estimate that fluctuates on its own. How to check properly is covered in how to check if a page is indexed.
Find the reason in the report
In Indexing > Pages, scroll to "Why pages aren't indexed" and click each reason with a large count. Each has its own chart. The reason whose line goes up on the same dates the Indexed line goes down is your cause.
| Reason that increased | What happened | Section below |
|---|---|---|
| Excluded by 'noindex' tag | A directive was added | Accidental noindex |
| Blocked by robots.txt | A Disallow rule now matches | robots.txt changes |
| Server error (5xx), or host issues in Crawl stats | Google could not fetch | Server and access problems |
| Blocked due to access forbidden (403) | Firewall or bot protection | Server and access problems |
| Not found (404) | URLs stopped existing | Removed or moved URLs |
| Page with redirect | URLs now redirect | Removed or moved URLs |
| Alternate page or Duplicate statuses | Canonical signals changed | Canonical changes |
| Soft 404 | Pages look empty to Google | Rendering failures |
| Crawled - currently not indexed | Google declined the page on re-evaluation | Quality reassessment |
Then line the date up with what changed on your side: deployments, plugin or theme updates, CDN or firewall rule changes, hosting moves, migrations, certificate renewals. Most technical deindexing traces back to a release.
Technical causes (fast to fix)
Accidental noindex
The most frequent cause, by some distance. A staging setting reaches production, an SEO plugin setting is changed for a whole content type, a header rule is added at the CDN, or a framework's environment check misfires.
Check both the HTML and the response headers, since an X-Robots-Tag: noindex header is invisible in the page source. The indexability checker tests both along with robots.txt and the canonical. Full tracing steps are in Excluded by noindex tag.
robots.txt changes
A new Disallow does not remove pages immediately. Google can no longer crawl them, so over time they may be dropped, or stay in the index without a description as "Indexed, though blocked by robots.txt". Also important: if the robots.txt file itself returns a server error, Google treats the site as disallowed for a period, and crawling can stop entirely. Settings > Crawl stats > Host status shows robots.txt fetch problems. Test suspect URLs with the robots.txt tester.
Server and access problems
A short outage does no harm. A long one does. Google's documentation on HTTP status codes says that 5xx and 429 responses make Googlebot slow down, and that URLs which keep returning server errors are eventually dropped from the index. The same happens if DNS fails or the connection times out for days.
The less obvious variant: your site is up for you, but not for Googlebot. Bot protection, a WAF rule, rate limiting, a country block or a hosting provider's "security" feature returns 403, 429 or a challenge page to Google's crawlers. Run Test live URL, check Crawl stats > By response, and look at server or CDN logs for the status codes served to Googlebot.
Removed or moved URLs
- URLs changed without 301 redirects, so the old ones return 404 and the new ones start from nothing.
- A migration where redirects were dropped after a few months. Google advises keeping them for at least a year.
- Old pages redirected in bulk to the homepage, which Google tends to treat as soft 404s.
- HTTPS certificate problems after a renewal failure.
Canonical changes
If a template starts emitting a canonical that points to another URL, those pages drop out as "Alternate page with proper canonical tag". If canonicals are removed or internal links change, Google may pick a different URL, and the one you track disappears while its duplicate gets indexed. Inspect the URL and compare User-declared canonical with Google-selected canonical. The canonical checker shows what a page declares right now.
Rendering failures
A front-end release that breaks for Googlebot (a blocked script, a failing API call, a consent wall) leaves Google with an empty page. The result is a wave of soft 404 errors or "Crawled - currently not indexed". Compare the screenshot in Test live URL > View tested page with what users see.
Removals and manual interventions
The Removals tool
Indexing > Removals lists temporary removal requests. A request hides a URL, or everything under a prefix, from results for about six months. Any owner or full user can file one, and a prefix removal can take out a whole section by accident. If you find one that should not be there, cancel it and the URLs return quickly. The Outdated content tab shows requests made by the public through the Refresh Outdated Content tool.
Manual actions
Check Security & Manual actions > Manual actions. If a human reviewer at Google found a violation of the spam policies (for example scaled content abuse, cloaking, link spam, thin affiliate pages, or spam posted by users or injected by hackers), some or all of the site can be demoted or removed. The report names the issue and the affected scope. Fix it properly, document what you did and submit a reconsideration request from that report. If the report says "No issues detected", you do not have a manual action, and speculation about a "penalty" is a distraction.
Security issues
A hacked site can be flagged or have pages dropped. Attackers also add their own noindex directives, redirects or spam pages. Check Security issues, and check Settings > Users and permissions for owners you do not recognise.
Quality reassessment (slow to fix)
If no technical cause or intervention fits, and the affected URLs now show "Crawled - currently not indexed", Google looked again and chose not to keep them. Google's documentation is clear that indexing is not guaranteed, and that holds after a page has been indexed too.
Patterns where I see this:
- Large sets of templated pages with little unique content per page. A sample gets indexed at first, and later most of it is dropped.
- Content that duplicates other pages, on your own site or elsewhere.
- Outdated or abandoned pages: expired events, discontinued products with stripped pages, short news items nobody links to.
- Pages that became orphans after a redesign removed the links to them.
- Timing that matches a core update or spam update. Google's systems evaluate quality across a site, and an update can change how much of a site is kept.
What helps is substantive: improve pages that have a purpose, merge overlapping ones, remove or noindex those that have none, and restore internal links to pages that matter. The method is in Crawled - currently not indexed. Requesting indexing without changing anything rarely reverses a quality decision.
Recovery sequence
- Identify the cause and scope with the steps above. One cause usually explains most of the drop.
- Fix at the source: the template, server config, plugin setting or firewall rule. Purge caches.
- Verify as Googlebot. Run Test live URL on a few affected pages and look for "URL is available to Google".
- Request indexing for the most valuable pages. The button has a daily quota, so prioritise.
- Validate fix on the relevant issue in Indexing > Pages to cover the rest. Google says validation typically takes up to about two weeks and can take much longer.
- Refresh the sitemap: correct URLs only, with accurate
<lastmod>for the restored pages. - Monitor. The Indexed line should start to climb within one to three weeks after a technical fix.
After a technical accident, pages generally come back once recrawled, often near their old positions if the outage was short. After long absences, rankings may need time to settle.
What not to do
- Do not change more things while diagnosing. New URLs, new templates and new redirects blur the evidence.
- Do not file removal requests for URLs you want back.
- Do not block the affected section in robots.txt to "reset" it. Google needs to crawl to see your fix.
- Do not click Request indexing daily for the same URL. Google says repeated requests do not speed things up.
- Do not move the content to new URLs to escape a quality problem. The content is the issue, and it travels with you.
Catch it earlier next time
Deindexing is quiet. Search Console sends emails for some issue spikes, but often days later, and not for every cause.
- Add release checks: fetch key URLs after every deploy and fail if you find
noindex, a non-200 status or a canonical pointing elsewhere. - Review Indexing > Pages and Settings > Crawl stats weekly, and always after migrations and big releases.
- Track index status per URL. TurboIndex inspects your sitemap URLs through the URL Inspection API and records each status change, so a page moving from indexed to "Excluded by 'noindex' tag" or "Crawled - currently not indexed" shows up quickly and not three weeks later in a traffic report. It is free for one site.
If you are looking at a single page that was never indexed in the first place, the right starting point is why is my page not indexed.
Frequently asked questions
- Why did Google deindex my page?
- The most common reasons are an accidental noindex directive, a server that returned errors for several days, a redirect or canonical change, a removal request, or Google reassessing the page as duplicate or low value. Inspect the URL in Search Console. The status shown there identifies which of these applies.
- How do I find out which pages were deindexed?
- Open Indexing, then Pages in Search Console and look for a drop in the Indexed chart. Then check which not indexed reasons increased over the same dates. In the Performance report, compare two date ranges by page and look for pages whose impressions fell to zero.
- How long does it take to get deindexed pages back?
- After the cause is fixed, Google has to recrawl and reprocess each page. Requested URLs are often recrawled within days, while a large set can take weeks. Pages removed for quality reasons come back only if Google's assessment changes, which can take months.
- Can a site be deindexed completely?
- Yes. Causes include a site-wide noindex or robots.txt block, prolonged server or DNS failure, a manual action for spam policy violations, a hacked site, a removal request for the whole site, or an expired domain.
- Does Google deindex old content just for being old?
- Age alone is not a reason. Old pages drop out when they have become thin, outdated, duplicated or disconnected from the rest of the site, so Google no longer sees enough value in keeping them.