You open Search Console, go to the Pages report (officially the Page indexing report), and the Indexed line is falling in clean stair-steps: Monday 1200, Tuesday 1100, Wednesday 1050. About 150 URLs gone, and you changed nothing.
Fastest answer: this is almost always Google’s periodic re-evaluation, not a penalty. Google continuously re-asks “is this page still worth indexing?”, decides no for some pages, and quietly drops them from Indexed into a “Not indexed” bucket. There is no error banner and no Manual Action. The fix is to (1) find which bucket grew, (2) diff the URL lists to see exactly which URLs left, and (3) decide per URL whether to win it back or let it go formally. Do not mass-request-indexing on everything.
Symptoms
- The Pages report shows a clean step-down in the Indexed count
- No new error categories appear
- You changed nothing on the site
- Performance (Search results) traffic may track the drop (if the lost URLs had traffic) or stay flat (if they were zero-traffic URLs)
Quick verdict
Routine re-evaluation. Google periodically demotes pages it now considers low-value, duplicate, or stale. Your job is to identify which URLs got demoted and decide, per URL, whether they should re-enter the index.
Which bucket are you in?
Open the Pages report and look at the bottom table, “Why pages aren’t indexed.” Sort by which status grew the most in the last 28 days. The status name tells you the cause and the fix.
| Status (exact label) | What it usually means | What to do |
|---|---|---|
Crawled - currently not indexed | Google fetched the page and judged it not worth indexing (quality/value) | Deepen the page, add internal links, then request indexing |
Discovered - currently not indexed | Google knows the URL but has not crawled it (crawl-budget / value signal) | Improve internal linking and value; do not just re-request |
Duplicate, Google chose different canonical than user | Your canonical was overruled; Google folded the page into another URL | Check the chosen canonical; merge or differentiate the content |
Duplicate without user-selected canonical | No canonical set and Google picked one for you | Set an explicit canonical |
Alternate page with proper canonical tag | Working as intended (canonicalized variant) | Usually leave it; this is not a loss |
URL marked 'noindex' | A noindex tag is present (often an accidental regression) | Most alarming. Confirm whether it was intended |
Not found (404) / Soft 404 | Page returns 404 or thin/empty content | Restore the page or return a deliberate 410 |
Blocked by robots.txt | Crawl blocked at the robots layer | Unblock if the page should be indexed |
Note: as of June 2026 the report uses URL marked 'noindex', not the older “Excluded by noindex” wording. The canonical statuses are Duplicate, Google chose different canonical than user and Duplicate without user-selected canonical. Use the exact strings when you search Google’s docs.
Common causes
1. Google re-clustered duplicates
The consolidation algorithm runs continuously. An article can get tagged as a duplicate of another URL, the canonical flips, and the original moves from Indexed into Duplicate, Google chose different canonical than user.
How to confirm: export your Indexed URL list (before vs. now) and diff for the drops. For each dropped URL, run URL Inspection and read the “Google-selected canonical” field. If it points at a different URL, that page was folded into another.
2. Demoted after a core or quality update
Google ships broad core updates and spam updates several times a year, and they can demote pages site-wide. The most recent broad core update before this article’s window, the March 2026 Core Update, ran March 27 to April 8, 2026 (the March 2026 Spam Update ran March 24–25). Many site owners reported pages sliding into Crawled - currently not indexed in the weeks after.
How to confirm: check the Google Search Status Dashboard and Search Engine Roundtable for any ranking or indexing update that rolled out in the 30 days before your drop. If the timing lines up, the drop is largely about content quality, not a technical bug.
3. Internal-link signal eroded as new content shifted the graph
You published 50 new articles, your “Related articles” module defaults to the newest posts, and older articles lose all their internal links. They become orphans, and orphaned pages eventually slide out of the index.
How to confirm: crawl your own site (Screaming Frog, Sitebulb, or any link crawler) and look at the “inlinks” count for the dropped URLs. Pages with 0–1 internal inlinks are the prime suspects.
4. Old content went stale and got algorithm-demoted
Year-anchored titles like “Best of 2023…” read as outdated by 2026. Google demotes content it judges no longer fresh or relevant.
5. Historical server 5xx errors
If your server was unstable for a few days, Google failed to fetch some URLs repeatedly and temporarily removed them. This usually recovers within 1–2 weeks after the server is fixed.
How to confirm: Settings → Crawl stats → “By response” and look for 5xx (server error) spikes in the last 90 days.
6. Low crawl rate, URLs not fetched in a long time
Google occasionally purges URLs that have not been crawled in a long time and lack fresh inbound links.
7. It was a reporting artifact, not a real drop (check this first if it is Performance, not Pages)
If the “drop” you noticed is in the Performance (Search results) report rather than the Pages report, you may be looking at Google’s own data fix, not a loss. A logging error over-reported impressions from May 13, 2025 until April 27, 2026; when Google corrected it, properties saw impressions, CTR, and average position step down. Clicks were not affected. Google documents this on its Data anomalies in Search Console page. If your Indexed count is steady but impressions fell around late April 2026, you are most likely reading the correction.
Shortest path to fix
Step 1: Drill into the biggest dropping bucket
In the Pages report, scroll to “Why pages aren’t indexed” and see which status grew fastest. A typical pattern:
Crawled - currently not indexed: +180
Duplicate, Google chose different canonical than user: +45
URL marked 'noindex': +12 ← watch for accidental regressions
Sort by growth and fix the biggest bucket first. If URL marked 'noindex' jumped, treat that as priority one: it usually means a deploy shipped a noindex tag by accident.
Step 2: Diff the URL lists
If you have a prior Pages report export, find exactly which URLs left:
# Find "just-dropped" URLs
sort old-indexed.csv > old.txt
sort new-indexed.csv > new.txt
comm -23 old.txt new.txt > dropped.txt
wc -l dropped.txt
# e.g. 150 lines = 150 URLs dropped
Note: the example-URL list inside a single status is capped at 1,000 rows, so for large sites export from each status bucket and concatenate before diffing.
Step 3: URL Inspection on a sample of dropped URLs
# Sample 10 URLs to check in Search Console URL Inspection
head -10 dropped.txt
Paste each into the URL Inspection bar at the top of Search Console. The result tells you the specific status and the Google-selected canonical:
Duplicate, Google chose different canonical than user→ consolidation issue (read the chosen canonical)Crawled - currently not indexed→ quality / value issueURL marked 'noindex'→ technical regression (most alarming)Not found (404)→ server or routing issue
The manual URL Inspection tool is rate-limited (roughly 10–12 fresh inspections per property per day on a rolling 24-hour window; Google does not publish an exact number). For bulk checks use the URL Inspection API instead, which allows up to 2,000 queries per day per property.
Step 4: For URLs worth keeping — deepen, link, then request indexing
For each URL you want back in the index:
- Add genuine content density (specific steps, screenshots, tables, first-person experience). Thin or templated pages are exactly what
Crawled - currently not indexedpunishes. - Add internal links from 3–5 closely related articles so the page is not an orphan.
- Run URL Inspection → Request Indexing once. Requesting repeatedly does not speed it up and burns your daily quota.
Step 5: For URLs that should not be indexed — noindex or 410, and drop from the sitemap
Many “dropped” URLs are legitimately low value (auto-generated, duplicate, or obsolete). Let them leave formally instead of leaving them in limbo.
Add a noindex tag (keep follow so link equity still flows):
<meta name="robots" content="noindex, follow" />
Or return HTTP 410 Gone for pages that are permanently removed (a clearer signal than 404):
res.status(410).send("This page has been removed.");
Then remove these URLs from your sitemap. Proactively shedding low-value pages is healthy — it frees crawl budget for the pages you actually want indexed.
Step 6: Wait 4–8 weeks for the next evaluation round
The Pages report fluctuates and lags. After your fixes, check again in 4–8 weeks:
- Did the fixed URLs return to Indexed?
- Has the overall drop trend flattened?
If it is still dropping, re-run Step 1 on the new biggest bucket.
How to confirm it is fixed
- The status bucket you targeted (for example
Crawled - currently not indexed) stops growing week over week in the Pages report. - Spot-check 3–5 of the URLs you improved with URL Inspection: they now show “URL is on Google” (or “Indexing requested” while pending).
- The total Indexed count stabilizes or ticks back up over the next 4–8 weeks.
- If your concern was Performance, confirm clicks (not impressions) held steady — clicks were unaffected by the 2025–2026 impression logging bug.
When this is not on you
The Pages report lags and can show transient drops during update rollouts. Judge by a weekly trend, not a single day. And if only impressions fell around late April 2026, that is Google’s data correction, not your site (see cause 7).
Easy to misdiagnose
- Sudden drop ≠ Google penalty. Real penalties appear in the Manual Actions report.
- “Every drop needs fixing.” Dropping low-value URLs is healthy and frees crawl budget.
- “No traffic moved, so no problem.” Dropped pages may all be zero-traffic, but a signal change still warrants a look.
- “Search Console is real-time and exact.” Indexing data lags 2–3 days and example URLs are sampled (capped at 1,000 per status).
- “My impressions crashed, so I was deindexed.” Around late April 2026 that was likely the impression-logging fix; check whether clicks and the Indexed count actually moved.
Prevention
- Track the Pages report weekly and investigate any 10%-or-more drop immediately.
- Keep a content-audit cadence so the catalog stays clean (routinely noindex thin pages).
- Periodically reactivate important URLs: update the content and add fresh internal links so they are never auto-purged orphans.
- Export the weekly Search Console Pages CSV so you can diff URL lists.
- Distinguish “traffic page dropped” from “zero-traffic page dropped” and fix the former first.
FAQ
Q: Is a drop in the Indexed count always bad? A: No. Shedding low-value or duplicate URLs improves overall site quality and frees crawl budget for your good pages. Only investigate when the dropped URLs had traffic or are pages you want indexed.
Q: How do I see exactly which URLs dropped?
A: Drill into each status in the Pages report and export the URL list (capped at 1,000 example rows per status). Better: save a weekly export and diff old vs. new with comm -23 to get the precise dropped set.
Q: Can I recover every dropped page? A: You can’t and shouldn’t. Sort dropped URLs into “should return” (deepen, link, request indexing) and “let go” (noindex or 410, remove from sitemap).
Q: My impressions cratered in late April 2026 — was I deindexed? A: Probably not. Google fixed a logging error that had over-reported impressions from May 13, 2025 to April 27, 2026, so the correction looks like a drop. Clicks were unaffected. Check your clicks and your Indexed count before assuming a real loss.
Q: How long until requested URLs come back? A: There is no guarantee. Requesting indexing puts a URL in a priority queue, but Google still decides on value. Expect days to weeks, and reserve the manual request (roughly 10–12 per property per day) for your most important URLs.
Related
Tags: #SEO #Google #Search Console #Indexing #Troubleshooting #Deindex