Indexing drop recovery
Find why your indexed pages dropped sitewide.
A sitewide indexing drop almost always traces to one change: a deploy, a plugin update, or a migration that altered something every page shares. We find that shared cause instead of fixing pages one at a time.
- Reads the exclusion reason, not just the page count
- Lines the drop up against your actual deploy history
- No promise on Google's recrawl schedule after a fix
How we work a sitewide indexing drop
One shared cause, found once.
The evidence we pull first
We open the Page Indexing report and read which specific exclusion reason grew at the same time your indexed count fell, rather than treating the drop as one number. A rise in pages Google discovered but has not crawled is a different problem from a rise in pages Google crawled and chose not to index.
The triage order we follow
We check for a sitewide technical change first, since a drop that hits many pages at once usually shares one cause: a robots.txt rule, a canonical tag, an hreflang setup, or a noindex flag altered by a deploy, a plugin update, or a migration. Only after ruling that out do we look at content quality page by page.
What usually fixes it
Reverting or correcting whatever sitewide technical change lines up with the timing, resubmitting your sitemap once it is fixed, and spot checking a sample of affected pages with URL Inspection to confirm Google now reads them the way you intend, rather than waiting on a full recrawl to find out.
What we cannot promise
We cannot promise Google recrawls and restores indexed pages on any fixed schedule once the technical cause is corrected. And if the drop turns out to be a genuine quality judgment rather than a technical block, the fix is ongoing content work, not a one-time correction, and we will tell you plainly which situation you are in.
The exclusion reason and the timing tell you where to look
If pages sitting under discovered, currently not indexed rose sharply
then Google knows the pages exist but has not gotten around to crawling them, which points at a crawling or prioritization issue rather than a content problem. Check server response times, a sudden increase in low value URL variations, or a sitemap that ballooned with junk pages competing for the same crawl budget.
If pages sitting under crawled, currently not indexed rose sharply
then Google looked at the pages and decided against indexing them, which is a quality judgment, not a technical block. Check for a page type introduced or changed around the same time that reads as thin or highly repetitive across many URLs, since that pattern is what usually earns this label.
If the drop lines up exactly with a specific deploy date
then pull that deploy's changes directly rather than auditing the whole site. Look for a changed robots.txt rule, a canonical tag now pointing somewhere unintended, an hreflang error that makes Google fold your pages into a different regional version, or a noindex flag a plugin or theme update quietly flipped on.
If the decline is gradual across months rather than a sudden step down
then this pattern fits a slow quality or authority erosion more than a single technical block, and no one deploy is likely to explain it. That calls for ongoing content and link work rather than a one-time fix, and it is worth saying so honestly instead of hunting for a deploy that does not exist.
How the engagement runs
01
Isolate the exclusion reason
We read the Page Indexing report trend and pin down exactly which exclusion category grew when your indexed count fell.
02
Trace it to a shared cause
We check your deploy history, plugin updates, and any migration against that timing to find the one change most pages share.
03
Fix and verify
We correct the shared cause, resubmit your sitemap, and spot check affected URLs with URL Inspection before waiting on a full recrawl.
Indexing drop recovery questions
Not necessarily, and it matters which one you actually have. If your indexed page count in the Page Indexing report fell alongside traffic, that is a real indexing problem. If your indexed count stayed roughly flat but impressions or clicks fell, your pages are still indexed and the issue is ranking or demand, which needs a different diagnosis entirely.
Discovered, currently not indexed means Google knows a page exists but has not gotten to crawling it yet, usually a crawl budget or prioritization issue. Crawled, currently not indexed means Google did crawl it and chose not to add it to the index, which is a quality decision. Confusing the two leads to fixing the wrong thing.
Check your CMS or hosting platform's own change log, your plugin or app update history, and your git history if you have one, using the date the Page Indexing report shows the exclusion count starting to rise as your anchor. Most sitewide drops have a change log entry even when nobody on the team recalls making one.
Rarely by itself. A sitemap tells Google which URLs exist, but it does not override a robots.txt block, a noindex tag, or a quality judgment already made. Resubmitting helps once the actual cause is fixed, as a way to prompt a recrawl faster, but submitting a sitemap while the underlying block remains will not change anything.
There is no schedule Google publishes for this, and it varies by site and by how often Google was already crawling you before the drop. Some pages get reindexed within days of a fix and a request through URL Inspection; others take longer. We will not give you a firm date, because Google does not give us one either.
Get a straight read on your indexing drop
Send us access to Search Console and tell us roughly when you noticed the drop. We will trace it to a shared cause and lay out the fix, and send you a free proposal inside one business day.