What does a spike in “crawled not indexed” pages actually signal?
- Published November 6, 2026
- Linked from 1 answer
- In a cluster of 77
A spike means Google fetched a batch of your pages and has not indexed them. On its own it does not say why: Google’s Page indexing help calls the status “a common message for many sites” and says it “doesn’t necessarily indicate an issue that needs attention”, and for important pages it points to URL Inspection to look for site issues first. The cause can sit in what the pages contain or how alike they are, but also in how they render, which canonical Google chose, or a batch that is still being processed. A spike that lines up with a launch, a migration, or a template change points to a cause you can name.
Find out which pages make up the spike
Open the Page indexing report, select the Crawled – currently not indexed reason, and look at the example URLs. Inspect a few from each group for the Google-selected canonical, the HTTP status and the rendered HTML, then group them:
| Pattern in the affected URLs | Likely explanation |
|---|---|
| All from one template, such as tag pages, filter combinations, or location pages | The template produces pages too similar to each other or too thin to stand alone |
| All published in one batch | The batch repeats existing pages or each other |
| Parameter, sort, or session URLs | Duplicate versions of real pages being discovered and crawled |
| A section that was redesigned | The new template may hide content behind scripts or clicks; check the rendered HTML |
| Pages that used to be indexed | A technical change on those pages, or a re-evaluation; check the first before assuming the second |
The help page’s wording leaves room for movement. A spike of new pages can partly resolve on its own as Google keeps processing; a spike that persists for weeks, on pages you want indexed, is the point to diagnose each group and fix what the inspection shows.
What to do with each group
- Duplicates and parameter URLs: consolidate with canonicals, stop generating the URLs, or keep them out of crawling if they should never exist. These pages do not need to be indexed at all.
- Thin template pages: decide which of them deserve to exist. Keep and improve the ones with a real search job; noindex or remove the rest. Sort them with whether to noindex thin pages or improve them.
- A rendering problem: fix the template so the main content is in the rendered HTML, then request indexing for a sample.
- Pages that used to be indexed: compare them with what now ranks for their queries and improve the strongest candidates first.
Resubmitting will not fix it
Do not mass-resubmit the URLs. Google has already crawled them, and requesting a crawl again does not change whatever is keeping them out. Track the count by group, not as one number: a falling count in the group you fixed tells you the fix worked, while the total can move for reasons unrelated to your change.
Add a comment