Google Search Console Pages Suddenly Not Indexed: Causes and Fixes

You open Search Console on a Monday morning and the green line has fallen off a cliff. Last week 1,400 pages were indexed. Today it says 600. Nothing was changed, as far as anyone on the team will admit.

This happens to healthy sites all the time, and in most cases the pages come back. But the fix depends entirely on which of about a dozen causes you are dealing with, and guessing wastes days. This guide walks through how to confirm the drop is real, how to read the report, and how to fix each cause in the order they most often turn up.

First, Check Whether the Drop Is Real

Before touching the site, spend ten minutes ruling out a false alarm. A surprising share of “sudden” drops are reporting quirks.

1. Look at the date on the report. The Page indexing report runs a few days behind. A drop that appears today may reflect something that happened last week, so line it up with deployments from that period, not from yesterday.
2. Confirm you are in the right property. http://, https://, www and non-www are separate URL-prefix properties. After an HTTPS or domain change, the old property empties out while the new one fills up. A Domain property shows everything in one place.
3. Inspect five affected URLs. Paste each into the URL Inspection bar. If it says “URL is on Google,” the page is indexed and the chart is lagging or recategorising.
4. Search for the page. Put a full sentence from the page in quotation marks and search Google. If your page appears, it is indexed.
5. Compare with traffic. Open the Performance report. If clicks and impressions are steady, the missing pages were probably ones that never earned traffic, such as tag archives or parameter URLs.

If the inspected URLs say “URL is not on Google” and clicks are falling too, the problem is real. Keep reading.

Read the Reason Google Gives You

Scroll below the chart to “Why pages aren’t indexed.” Sort by the Pages column and click the reason that grew the most. That one line tells you where to look. Here is what each common reason means in plain terms.

Reason shown	What it means	Usual culprit
Excluded by ‘noindex’ tag	The page told Google not to index it	A plugin setting, a staging config pushed live, an HTTP header
Blocked by robots.txt	Google is not allowed to fetch the page	An edited or replaced robots.txt file
Server error (5xx)	Your server failed when Googlebot asked	Hosting trouble, overload, a broken plugin
Blocked due to access forbidden (403)	The server refused Googlebot	Firewall, CDN bot protection, security plugin
Not found (404)	The URL no longer exists	Deleted pages, changed URL structure
Soft 404	The page loads but looks empty or like an error	Thin pages, empty categories, out-of-stock products
Page with redirect	The URL forwards somewhere else	Migration, trailing-slash or HTTPS rules
Alternate page with proper canonical tag	The page points to another URL as the main version	Normal for duplicates; a problem only if the canonical is wrong
Duplicate, Google chose different canonical than user	Google disagrees with your canonical	Near-identical pages, mixed signals
Crawled – currently not indexed	Google read the page and decided not to keep it	Quality, duplication, weak internal links
Discovered – currently not indexed	Google knows the URL but has not fetched it yet	Slow server, too many low-value URLs

Some of these are harmless. “Page with redirect” and “Alternate page with proper canonical tag” are Google doing what you asked. Worry about them only when the numbers jump and the URLs listed are ones you want in search.

Cause 1: A Noindex Tag Got Onto Live Pages

This is the most common reason for a large, sudden drop, and the easiest to fix.

How It Happens

• In WordPress, someone ticked “Discourage search engines from indexing this site” under Settings > Reading.
• An SEO plugin update reset the indexing setting for posts, categories or a custom post type.
• A staging site, which is rightly set to noindex, was copied to production with that setting intact.
• The server or CDN adds an X-Robots-Tag: noindex header. This one is invisible in the page source.

How to Confirm

Inspect a URL and look at “Indexing allowed?” under Page indexing. Then check the page yourself:

curl -sI https://example.com/your-page/ | grep -i x-robots-tag
curl -s https://example.com/your-page/ | grep -i "noindex"

The first command checks the header, the second checks the HTML. A set of meta tag checker tools will do the same across many URLs at once.

How to Fix

Remove the tag or header at its source, clear every cache layer, and run the live test in URL Inspection until it says indexing is allowed.

Cause 2: Robots.txt Is Blocking Google

A single line can take out a whole site: Disallow: /. It usually arrives with a redesign, a new theme or a hosting move.

Open yoursite.com/robots.txt in a browser and read it. Then check Settings > robots.txt in Search Console, which shows the version Google last fetched and when. If that fetch failed with a server error, Google may stop crawling the site altogether until it can read the file again. We cover that case in what to do when Google is unable to crawl robots.txt, and the syntax itself in our robots.txt guide.

One trap to know: blocking a page in robots.txt does not remove it from the index, and it stops Google from seeing a noindex tag on that page. Use one or the other, not both.

Cause 3: The Server Is Failing or Refusing Googlebot

If the growing reason is “Server error (5xx)” or “Blocked due to access forbidden (403),” the site is turning Google away. Pages that keep returning errors are dropped from the index.

How to Confirm

• Go to Settings > Crawl stats. Check “Host status” and the “By response” breakdown for a spike in 5xx, 403 or 429 responses.
• Ask your host whether there was downtime, a resource limit or a new firewall rule around the date of the drop.
• Check the security log of your CDN or security plugin for blocked requests from Googlebot.

How to Fix

For 5xx errors, fix the capacity or the faulty code. Cheap shared plans often buckle when Googlebot and real visitors arrive together, so it may be time to look at hosting that suits SEO. For 403s, allow verified Googlebot through the firewall, CDN or plugin that is refusing it. Bot protection that cannot tell Googlebot from a scraper is a frequent offender, and the volume of automated traffic described in our bot traffic statistics explains why so many hosts have tightened their rules.

Cause 4: Canonical Tags Point to the Wrong Place

A canonical tag says “this other URL is the real one.” When a template bug points every page’s canonical at the home page, or at the HTTP version, or at a staging domain, Google drops the pages as duplicates.

Inspect a URL and compare “User-declared canonical” with “Google-selected canonical.” If the first is wrong, fix the template. If the first is right and Google picked something else, the two pages are too alike. Either merge them or make each one clearly different.

Cause 5: A Migration or URL Change

After a redesign, platform move or URL restructure, old URLs leave the index and new ones enter. For a few weeks the report looks alarming. That is expected. What is not expected is the new URLs failing to appear.

Check three things:

• Every old URL returns a single 301 redirect to its matching new URL, not to the home page.
• Internal links and the sitemap use the new URLs.
• There are no redirect chains or loops. “Redirect error” in the report is the sign.

Cause 6: Soft 404s and Deleted Pages

A rise in “Not found (404)” means pages were removed or their URLs changed without redirects. Restore them or redirect them to the closest equivalent.

“Soft 404” is subtler. The page returns a normal 200 status but Google thinks it is empty. Typical cases are category pages with no products, search result pages with no results, and posts with a heading and two lines of text. Add real content, or return a proper 404 or 410 if the page should not exist.

Cause 7: A Surge in “Crawled – Currently Not Indexed”

This one frustrates people most, because nothing is technically broken. Google fetched the page, read it and chose not to store it.

When many pages move into this bucket at once, Google has usually reassessed the site, often around a core update. The pages affected tend to share a pattern:

• Short posts that repeat what a hundred other sites say.
• Near-duplicate pages, such as one service page copied for forty cities.
• Old posts nobody links to and nobody visits.
• Mass-produced content published faster than anyone could review it.

Requesting indexing again will not help. Improve the pages, merge the overlapping ones, and delete what has no purpose. Our piece on content pruning and content decay explains how to choose. We also have a step-by-step guide to the crawled, currently not indexed status on its own.

Internal links matter here as well. A page that is four clicks deep with one link pointing at it looks unimportant. Link to it from related, stronger pages. Internal linking tools can find those opportunities quickly.

Cause 8: A Surge in “Discovered – Currently Not Indexed”

Here Google has the URL on its list and has not fetched it. Two things cause a sudden build-up.

The first is a slow or struggling server. When responses slow down, Googlebot backs off to avoid making things worse. Check average response time in Crawl stats. If it climbed before the drop, speed is your problem, and fixing issues like a slow Largest Contentful Paint often goes hand in hand with fixing server response.

The second is a flood of new low-value URLs: filter combinations, calendar pages, session parameters, internal search results. Google spends its crawl on those and gets to your real pages late. Block the junk patterns in robots.txt and take them out of the sitemap.

Cause 9: A Manual Action, Security Issue or Removal Request

Three places in Search Console that people forget to check:

• Security & Manual Actions > Manual actions. A penalty for spam, thin content or unnatural links can remove pages or the whole site. The report says what the issue is and offers a reconsideration request once it is fixed.
• Security & Manual Actions > Security issues. Hacked sites get flagged and can lose pages. Spam injected through comments, forums or profile pages is a common route in, which we cover in our guide to protecting a site from user-generated spam.
• Indexing > Removals. Anyone with access to the property can submit a temporary removal, and it hides the URL or a whole directory for about six months. Check that nobody did this by accident, and cancel the request if they did.

Cause 10: JavaScript Is Hiding the Content

If the site moved to a JavaScript framework, or a script started failing, Google may be rendering a blank shell. In URL Inspection, run the live test, click “View tested page” and look at the screenshot and the rendered HTML. If your main content is missing there, Google cannot see it. Server-side rendering or pre-rendering solves it, and these JavaScript SEO testing tools help you verify the result.

Cause 11: Sitemap Problems

A sitemap does not get pages indexed on its own, but a broken one slows discovery of new and updated URLs. Under Indexing > Sitemaps, check that the status is “Success” and the “Discovered pages” count is close to what you expect. Common faults are a sitemap URL that now returns 404 after a plugin change, a sitemap listing redirected or noindexed URLs, and an old sitemap still pointing at the previous domain.

Cause 12: The Change Is on Google’s Side

Sometimes you did nothing wrong. Core updates and spam updates change what Google is willing to keep, and occasionally Google confirms an indexing or reporting bug. Check the Google Search Status Dashboard for incidents on the dates of your drop. If there is a confirmed bug, wait. If a core update lines up, treat it as Cause 7 and work on quality.

Match the Pattern to the Cause

The shape of the drop narrows things down before you inspect a single URL.

What you see	Most likely cause
Nearly every page gone within days	Site-wide noindex, robots.txt block, or server refusing Googlebot
One section or one template affected	A plugin or template change for that post type, or a canonical bug
Steady decline over several weeks	Quality reassessment or crawl capacity problems
Old URLs out, new URLs slow to appear	Migration with missing or wrong redirects
Chart fell but clicks are steady	Low-value URLs dropped, or a reporting change
Drop on the same day across many unrelated sites	A Google update or a confirmed bug

How to Get Pages Back Into the Index

1. Fix the cause first. Asking Google to re-index a page that still carries a noindex tag or still returns an error achieves nothing.
2. Test live. Use URL Inspection > Test live URL on several fixed pages. You want “URL is available to Google.”
3. Request indexing for your most important pages. There is a daily limit, so choose the ones that bring revenue.
4. Click Validate fix. Open the reason in the Page indexing report and start validation. Google rechecks the affected URLs and reports progress.
5. Resubmit the sitemap so the remaining URLs are picked up sooner.
6. Add internal links from strong pages to the ones that dropped out.

How long recovery takes depends on the cause. Technical blocks such as a noindex tag or a firewall rule usually clear within days to a few weeks once fixed. Quality-related drops take longer, often until Google next reassesses the site. Our guides on how to make Google index your site faster and how to fix Google indexing issues go further into speeding things up.

How to Stop It Happening Again

• After every deployment, plugin update or hosting change, inspect one URL from each main template.
• Keep a dated log of site changes. When the chart moves, you will know what happened that week.
• Add a release check that fails if a noindex tag or Disallow: / appears on production.
• Look at the Page indexing report weekly, not only when traffic falls.
• Set up uptime monitoring so you hear about server errors before Google does.
• Limit who can submit removals and edit robots.txt.
• Schedule a full technical SEO review at least twice a year.

FAQs

Why Did My Indexed Pages Drop Overnight in Search Console?

A sharp overnight fall nearly always has a technical cause: a noindex tag, a robots.txt block, server errors or a firewall refusing Googlebot. Gradual declines point more towards content quality. Check the reason listed under “Why pages aren’t indexed” to see which it is.

Is It Normal for Some Pages Not to Be Indexed?

Yes. Google does not index every URL on any site. Redirects, duplicates, paginated archives and parameter URLs are expected to sit in the “not indexed” group. It becomes a problem only when pages you want in search end up there.

Does Requesting Indexing Fix the Problem?

Only after the underlying cause is fixed. The request asks Google to look again sooner. It does not override a noindex tag, a block or a quality decision.

How Long Do Pages Take to Be Re-Indexed?

For technical fixes, anywhere from a few days to a few weeks, depending on how often Google crawls the site. For “Crawled – currently not indexed,” it can take months and depends on the content improving.

Can a Google Update Remove Pages From the Index?

Yes. Core and spam updates can lead Google to stop indexing pages it now considers low value. If your drop lines up with an announced update and no technical fault shows up, focus on improving or consolidating the affected content.

My Pages Are Indexed but Traffic Still Fell. Is That the Same Issue?

No. Indexing means a page is eligible to appear. Ranking decides where. If pages are indexed and clicks have fallen, look at the Performance report for lost queries and positions.