Key takeaways
- "Crawled – currently not indexed" is a quality judgement: Google fetched the page and decided it was not worth storing.
- "Discovered – currently not indexed" is usually a crawl-budget or perceived-value problem, not a technical error.
- The most common cause on large sites is many pages that are one template with a word swapped.
- Fixing it means making pages genuinely different or removing them from the index — there is no third option.
- Recovery takes weeks to months, because Google must re-crawl before it can re-evaluate.
The three buckets, and why the difference matters
Google Search Console groups unindexed pages into buckets, and people tend to read them all as "broken". They are not the same problem and they do not have the same fix.
Discovered – currently not indexed means Google knows the URL exists but has not fetched it. That is usually about perceived value: Google allocates crawl attention based on how worthwhile a site has proved to be, and if it has already crawled hundreds of similar pages from you, it will deprioritise the rest. It can also be a genuine crawl-budget problem on very large sites.
Crawled – currently not indexed is harsher. Google fetched the page, read it, and chose not to store it. There is no technical fault to fix — this is a quality judgement. Something about the page did not justify a slot in the index.
Duplicate, Google chose a different canonical means Google found another page it considers the better version of the same content. Often that other page is yours.
Alternate page with proper canonical tag is normal and expected — that is your canonical working as designed. It is not an error, and a surprising number of people try to "fix" it.
The most common cause: pages that are the same page
On sites with more than a few dozen URLs, the usual culprit is scaled templating — a service page cloned across cities, an industry, or a product variant, where the only thing that changes is a name.
Google is explicit that scaled content abuse is a spam policy violation, and its detection does not require exact duplication. Spun text, reordered sections and synonym swaps are caught by the same systems. If a page could be produced by find-and-replace on another page, it is at risk.
The test worth applying: strip the navigation and footer, then ask whether the remaining content contains a single fact that could not appear on the sibling page. If the answer is no, the page is not going to be indexed, and it may be dragging the rest of the site down with it.
The second cause people miss: your HTML has no content in it
If your site is a single-page application — React, Vue, Angular — check what the server actually sends. Open the page, then view source rather than using the browser inspector. The inspector shows the DOM after JavaScript has run; view-source shows what the crawler receives first.
It is common to find that every URL on the site returns the same shell, with the real content painted in afterwards by JavaScript. Google can render JavaScript, but rendering is queued and deferred, and the first-pass signal is the raw HTML. If that HTML is identical across every URL, every URL looks like a duplicate at the moment Google is deciding whether to bother.
This is worth checking before rewriting any content, because no amount of content improvement helps if the crawler never receives it. Server-side rendering or a build-time prerender fixes it.
How to actually fix it
Start with the diagnosis, not the cure. Export the Page Indexing report and group the affected URLs by pattern. If more than a third of them share a template, that is your problem, and adding content to individual pages will not solve it.
For each templated group, there are only two honest outcomes. Either the page can carry information that genuinely differs from its siblings — real local detail, real sector-specific application, real distinct specification — or it cannot, in which case it should carry a noindex and be removed from the sitemap. Keeping a page indexable in the hope Google changes its mind does not work.
De-index with `noindex,follow` rather than deleting. It is reversible, it keeps the page available for paid traffic and direct links, and the follow directive means any link equity the page holds still flows through to the pages you kept.
Then fix the internal linking. Pages sitting in "Discovered – not indexed" frequently have very few internal links pointing at them. Google follows links to decide what is worth crawling, and an orphan page is telling it the page does not matter.
What to expect afterwards
Two things will happen that look like regressions and are not. Your "Excluded by noindex" count will rise, sometimes dramatically — that is the de-indexing working. And your total indexed page count will fall before it recovers. A smaller set of pages Google is willing to index is worth more than a large set it refuses.
Timing is measured in weeks, not days. Google must re-crawl before it can re-evaluate, and crawl frequency on a site with a quality problem is low by definition. Four to eight weeks before the buckets start moving is normal. Submit the trimmed sitemap, use Validate Fix on each bucket, and request indexing on your most important pages — but manual requests are a nudge, not a lever.
When this is not your problem
If your site has fewer than about fifty pages and they are all genuinely distinct, indexing is probably not your bottleneck — authority is. A clean, unique, well-structured site with no inbound links will be indexed and still not rank. That is a different project, and content restructuring will not move it.
Equally, if the pages that are not indexed are ones you never wanted indexed — filtered listings, tag archives, paginated duplicates — the report is working correctly and needs no action beyond confirming the canonicals are right.
Frequently asked questions
- How long does it take for pages to get indexed after fixing the problem?
- Typically four to eight weeks before the Search Console buckets start moving meaningfully, and longer on large sites. Google has to re-crawl before it can re-evaluate, and crawl frequency is itself reduced on a site it has judged poorly, so the first few weeks are usually quiet.
- Will requesting indexing in Search Console force Google to index a page?
- No. It moves the URL into a priority crawl queue, but the indexing decision is unchanged. If the page was refused on quality grounds, requesting indexing gets it re-evaluated faster and refused again.
- Should I delete pages that will not index, or noindex them?
- Noindex, in almost every case. Deleting throws away any links and traffic the page had, breaks anything pointing at it, and is not reversible. A noindex with follow keeps the page usable for ads and direct visitors while removing it from the index, and you can undo it in one line.
- Does having many noindexed pages hurt my site?
- No. What hurts is having many low-quality pages that are indexable. Noindex is how you tell Google not to weigh them against you.
- My pages are unique but still not indexed. What now?
- Check what the server sends before JavaScript runs — view-source, not the inspector. If every URL returns the same shell, the pages are not unique from the crawler's point of view no matter what a user sees. After that, look at internal linking and at whether the site has enough authority for Google to consider the pages worth storing.
Work with us on this
We start every engagement with a written scope after a free discovery call.