Dricomm web design and SEO agency London
← Back to blog
SEO28 October 2026· 6 min read

Crawled – Currently Not Indexed: What It Means and How to Fix It

"Crawled – currently not indexed" is the Search Console status that causes the most panic and deserves the least. Here is what Google actually means by it, how to sort the URLs that matter from the ones that never will, and what fixes the real problems, with a worked example from my own site.

D
Serghei Drici

Sooner or later every site owner opens the Page indexing report in Google Search Console and finds a grey bar labelled Crawled – currently not indexed, with a list of URLs underneath. It looks like Google has rejected those pages. Sometimes it has. More often, the list is mostly noise.

This guide covers what the status means, how to separate the URLs that matter from the ones that never will, and how to fix the problems that are real. It ends with the actual export from my own site, because the breakdown surprised me as much as it surprises most clients.

What Google Actually Says

Google's own definition in the Page indexing report documentation is short:

The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.

Two things follow from that. Google has already visited the page and read it, so this is not an access problem. And it has decided, for now, that the page is not worth adding to the index. It is a judgement, not an error and not a penalty.

It is easy to confuse with a neighbouring status, Discovered – currently not indexed, which Google describes differently: the page "was found by Google, but not crawled yet", usually because crawling it was expected to overload the site. Discovered means Google hasn't looked yet. Crawled means it looked and passed.

First, Work Out Whether It's a Problem at All

Before fixing anything, export the list and put every URL into one of three piles.

  • Pages that should never be indexed. Script and style files, image endpoints, feeds, search results, filter and sort parameters, thin tag archives. Google crawling them is normal. Leave them alone, or keep them out of your sitemap if they are in it.
  • Old URLs that already redirect. Addresses from a previous version of the site that now send visitors somewhere else. Google keeps reporting them until it recrawls them and notices the redirect. They clear on their own.
  • Pages you actually want in search. Service pages, articles, product pages. This is the only pile that needs work, and it is usually much smaller than the report suggests.

One warning while you sort. If you see files from a folder such as /_next/static/ on a Next.js site, or its equivalent on another platform, do not block that folder in robots.txt to tidy the report. Google needs those files to render your pages, and blocking them can do far more damage than a grey bar ever will.

Why Google Skips Pages You Want Indexed

For the third pile, the cause is almost always one of these.

  1. Duplicate or near-duplicate content. Twenty location pages with the same text and a different town name, printer-friendly copies, the same product under several URLs. Google picks one and ignores the rest.
  2. Two pages chasing the same search. Two articles on the same topic, or a service page and a blog post answering the same question. Google usually keeps one and drops the other. This is called cannibalisation, and it is more common than people think.
  3. Thin content. A page with very little on it that is unique or useful. Google has no reason to show it to anyone.
  4. Weak internal linking. A page with few or no links from the rest of your site looks unimportant. Orphaned pages are a classic cause.
  5. Content that only appears after JavaScript runs. If the initial HTML is nearly empty and everything is assembled in the browser, Google may see much less than your visitors do. The URL Inspection tool's "View crawled page" shows you what Google actually got.
  6. A young site without much authority. On a new domain Google indexes selectively, and marginal pages wait longest. This one improves with time, quality content and links from other sites, and not much else.

How to Fix It

Work through the real pages one at a time.

  • Merge, don't multiply. If two pages target the same search, combine them into one strong page and put a permanent 301 redirect on the weaker URL.
  • Make the page earn its place. Add what is genuinely missing: specifics, examples, prices, answers to the questions people actually ask. Padding it out with filler makes things worse, not better.
  • Link to it from pages that matter. A few contextual links from related, well-performing pages do more than any submission tool.
  • Keep your sitemap honest. List only canonical URLs you want indexed, and only change the last-modified date when the content really changes. Google stops trusting that date if it moves on every deploy.
  • Check what Google renders. If the crawled page is missing content, fix the rendering, usually by generating the HTML on the server rather than in the browser.
  • Then request indexing once. After a real change, use URL Inspection and request indexing for that URL. Not before the change, and not every day.

Afterwards, use "Validate fix" in the report and give it time. Recrawling takes days, and a status clearing can take a few weeks. For the wider context of how long SEO changes take to show up, see how long SEO takes.

What Not to Do

  • Don't block the pages in robots.txt. Blocking crawling does not remove a page from the index, and it stops Google seeing a noindex tag you might want it to see.
  • Don't mass-request indexing. Resubmitting unchanged pages achieves nothing, which is exactly what Google's definition says.
  • Don't pay for "instant indexing" services. At best they do nothing lasting. At worst they attach your site to spam.
  • Don't bulk up pages with generated filler. Longer is not better. Useful is better.

A Worked Example: My Own Site

When I exported this report for dricomm.com, it listed 17 URLs as crawled but not indexed. It looked like a serious problem. Sorted into the three piles, it was mostly nothing.

  • 13 were old WordPress addresses from a previous version of the site. All of them already redirected correctly. Google simply had not recrawled them yet.
  • 1 was a JavaScript file from the site's build folder, and 1 was an image endpoint used for social sharing previews. Neither was ever meant to be indexed.
  • 2 were genuine dead links, old addresses that returned a 404. Both now redirect to the closest current page.

The one real finding was not a broken page at all. Two of my own articles covered almost the same topic, and Google had indexed the newer one and quietly skipped the older one. That is cannibalisation, point two above, and no amount of requesting indexing would have fixed it. The only fixes are merging the two or rewriting one to answer a different question. I merged them into one article and redirected the old address to it.

That is the pattern I see on most sites. The report is long, the real list is short, and the cause behind it is usually a structural decision rather than a technical fault.

When It Is Worth Worrying

If your service pages, pricing page or best articles have sat in this report for weeks, that is a genuine signal. It usually points to duplication, thin content or weak internal linking, and it is worth fixing properly. My technical SEO checklist covers the wider set of checks, and why most websites don't rank covers the causes that sit above the technical layer.

If you would rather have someone go through the list with you, send me your site through the free audit. I will tell you which URLs matter, which don't, and what is keeping the important ones out of Google.

Free audit

Want me to check your site?

I'll run a full technical and SEO audit and send you a report within 24 hours, completely free.