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

The short answer

“Crawled – currently not indexed” means Googlebot fetched the page successfully, looked at it, and decided not to add it to the index — for now. Nothing technical stopped it: no robots.txt block, no noindex, no server error. Google’s own definition is one line: the page was crawled but not indexed, it may or may not be indexed in the future, and there’s no need to resubmit it for crawling. In practice it’s a judgement call about the page, not a bug in your setup, so the fix is almost always to make the page more clearly worth indexing — more unique, better linked, or merged into a stronger page — rather than to keep requesting indexing.

Where you see it, and what it isn’t

In Search Console, open Indexing → Pages and scroll to Why pages aren’t indexed. The row is labelled Crawled – currently not indexed and its source is “Google systems”, which is Search Console’s way of saying no setting on your site caused it. Click the row for a trend chart and up to 1,000 example URLs.

Two neighbours get confused with it:

• Discovered – currently not indexed — Google knows the URL exists but hasn’t fetched it yet. That one is about crawl scheduling, and it’s covered in the guide to Discovered – currently not indexed.
• Alternate page with proper canonical tag — Google indexed a different URL because your canonical told it to. That’s usually working as intended.

With “Crawled”, Google has the page’s content in hand. It read what you published and chose not to store it. That’s why the fix lives in the content and in how your site points at it.

A real example from this site

I’m writing this partly because CheckSEO has the same problem. Inspecting our own URLs on 23 October 2026, the Meta Tag Generator (last crawled 10 October) and the Domain Age Checker (last crawled 13 October) were both reported as Crawled – currently not indexed. Everything technical checked out in URL Inspection: page fetch Successful, indexing allowed, robots.txt allowed, both listed in the sitemap, and the Google-selected canonical identical to the one the page declares.

So Google could index them and chose not to. Looking at the pages honestly, the reasons were easy to find: each was a working tool wrapped in a short description that said much the same thing as dozens of other “free meta tag generator” and “domain age checker” pages, and very little on the site linked to them — one was reachable mainly from the sitemap and the tools list. The same day, both pages were rewritten with in-depth, tested explanations of what the tool checks and why, linked from the homepage and from related blog posts, and added to a related-tools block that rotates links across the whole tool set.

That is the fix this guide recommends, applied to our own site. I’ll update this section with what Search Console reports once Google recrawls them. For comparison, the most recent guide on this blog, on checking whether an IP is blacklisted, went from published to Submitted and indexed in three days — it covered a narrow question in depth and was linked from the tool it explains.

Why Google crawls a page and still skips it

Google doesn’t publish a checklist for this status, and it doesn’t owe every page a place in the index — its help page for the report says plainly not to expect every URL on your site to be indexed. From the patterns that show up again and again in this bucket, the causes fall into five groups:

• Near-duplicates. Tag and category archives that list the same posts, product variants that differ only by colour, location pages with the city name swapped, parameter URLs. If two of your URLs say the same thing, Google indexes one.
• Nothing new for the query. A page can be original and still add nothing the top results don’t already say. Short tool pages, generic “what is X” posts and lightly rewritten content land here often.
• Weak internal links. A page that only the sitemap points to looks unimportant. Google uses links to decide what matters on your site; an orphan page is telling it the answer is “not much”.
• Content that isn’t in the HTML. If the main text only appears after JavaScript runs and rendering fails or times out, Google may see a near-empty page.
• New or recently changed pages. Sometimes it’s just timing. Google’s wording — “may or may not be indexed in the future” — is literal: pages move out of this bucket on their own.

How to fix it, step by step

Checks you can run from a terminal

# 1. Status code, redirects and any X-Robots-Tag header
curl -sIL "https://example.com/guides/page-speed" | grep -iE "^http|^location|^x-robots-tag"

# 2. A robots meta tag in the HTML (should be absent, or "index")
curl -sL "https://example.com/guides/page-speed" | grep -io '<meta[^>]*name="robots"[^>]*>'

# 3. The canonical tag (should point at this exact URL)
curl -sL "https://example.com/guides/page-speed" | grep -io '<link[^>]*rel="canonical"[^>]*>'

# 4. How much text the server sends before any JavaScript runs
curl -sL "https://example.com/guides/page-speed" | sed 's/<[^>]*>//g' | wc -w

If you prefer a browser, the Canonical URL Analyzer shows the canonical and whether it points back at the page, the Text-to-HTML Ratio Checker shows how much readable text the server actually sends, and the Duplicate Content Checker compares two URLs and reports how much of their text overlaps.

Common page types in this bucket

Should you click “Validate fix”?

Only after you’ve changed the pages. Validation asks Google to recheck every URL in the row, and Google says it typically takes up to about two weeks, sometimes much longer. It doesn’t make a page more likely to be indexed — it just tells you sooner whether your changes worked. If you validate without changing anything, it will most likely fail, and the row stays put.

If validation fails for some URLs, look at those individually: Google checks whether each page is now indexed, and pages that still don’t clear the bar stay in the list. That’s feedback, not a penalty.

When to leave it alone

Not every URL in this list needs rescuing. Search result pages, thank-you pages, login screens, thin tag archives and old paginated pages are often better left out of the index, and spending effort to push them in can dilute the pages that matter. Sort the list by asking one question per URL pattern: would I want a searcher to land here? If not, add noindex or remove the links to it and move on. If yes, it needs one of the fixes above.

If a large share of your important pages sits in this bucket, the issue is site-wide rather than page-by-page — usually templated content or a weak internal linking structure. The internal linking audit guide walks through finding orphan and under-linked pages, and the overview of every “Why pages aren’t indexed” reason helps if your report shows several statuses at once.