Crawled Currently Not Indexed: Causes, Fixes

Crawled currently not indexed is a Google Search Console status meaning Googlebot fetched your page and then chose not to add it to the index. The cause is almost never the crawl itself. It is a verdict on the page, or on where the page sits in your site. Pages with this status cannot rank, so the status matters for every URL you actually want found.

This guide is for site owners and marketers who opened the Page indexing report and found a long list. It gives you a diagnostic sequence that splits the causes into quality, duplication and internal links, then a before and after test plan so you can tell which fix worked. If you need the report basics first, start with our Google Search Console guide.

On this page

• What does crawled currently not indexed mean?
• Step 1: sort out the URLs that should stay out
• Step 2: rule out rendering and technical blocks
• Is duplication the cause?
• Are weak internal links the cause?
• Is the content itself the cause?
• A before and after test plan
• Getting indexing problems under control

What does crawled currently not indexed mean?

The status means Google visited the URL, read it, and decided not to keep it for now. Google’s Page indexing report documentation defines it in one line: the page was crawled by Google but not indexed. The same page adds that it may or may not be indexed in the future, and that you need not resubmit the URL for crawling.

Do not confuse it with its neighbor. “Discovered - currently not indexed” means Google found the URL but has not crawled it. Google says that usually happens because it expected the crawl to overload the site and rescheduled it. That is a capacity story, covered in our crawl budget guide. “Crawled” is different: Google spent the request and still passed.

That gives you the working assumption for everything below. Google has seen the content. So the question is not “can Google reach this?” but “what did Google see, and why was it not worth keeping?” The diagram below lays out the order in which to ask.

Scroll the diagram sideways to see all of it.

Step 1: sort out the URLs that should stay out

Many URLs in this report are there for good reasons, and the first job is to remove them from your worry list. Feeds, pagination, tracking parameters, filtered views and non-canonical versions can sit under this status without harming anything. Marie Haynes makes the same point in her walkthrough: set aside the normal exclusions before you judge quality.

Export the list from the Page indexing report and tag each URL as one of three kinds.

• Never meant to be indexed: feeds, search results pages, parameter variants. Leave them, or stop linking to them.
• Meant to be indexed: pages you want to rank. These are your real work.
• Unsure: thin tag archives, old landing pages, near-empty category pages. Decide whether each deserves to exist.

Only the second group goes into the steps below. Our XML sitemap guide covers keeping the sitemap limited to that second group, which also stops you sending Google mixed signals about what matters.

Step 2: rule out rendering and technical blocks

Run a live URL test before you touch the content. In URL Inspection, test the live URL and view the rendered page. If the render shows little or no text, the cause is technical, and no amount of rewriting will fix it. Marie Haynes calls technical causes rare, but her example shows how they hide: a robots.txt rule that blocked parameter URLs a theme needed for its CSS and JavaScript, which left most of the page invisible to Google.

Check four things in this step.

1. The rendered HTML contains the main text, not just a shell.
2. There is no stray noindex directive in the HTML or the response headers.
3. Scripts and stylesheets the page depends on are not blocked by robots.txt.
4. The page returns a clean 200 status and does not flicker between errors and success.

If the live test shows your content, move on. If it does not, fix rendering first and read our notes on JavaScript rendering for AI crawlers, since the same fixes help there too.

Is duplication the cause?

Duplication is the cause when Google folded your page into a different URL. The question to answer is simple: which canonical did Google select? Open URL Inspection, find “Google-selected canonical,” and compare it with the canonical you declared.

Google’s documentation on consolidating duplicate URLs says Google decides which pages are duplicates based on similarity of content, and picks the version it judges best to show to users. It describes redirects, rel="canonical" links and sitemap inclusion as the methods for stating your preference, in decreasing order of strength. A preference is not a command.

Three patterns show up again and again.

• Template twins: pages that share almost all their text and differ by a city name or product code. Google keeps one and leaves the rest.
• Parameter and protocol copies: the same page reachable at several URLs. Pick one, redirect or canonicalize the rest.
• Scraped or syndicated copies: another site’s version won the canonical choice.

If the selected canonical is another URL on your site, the status is working as designed, and your task is to decide which version should win. Our duplicate content guide explains why there is no penalty here, only consolidation, and the canonical tag guide covers the mistakes that make Google ignore your hint. If the pages are near-duplicates that each deserve to exist, they need genuinely different content, which is a Step 5 problem.

Are weak internal links the cause?

Weak internal links are the cause when a page is reachable but nothing important points to it. Google’s guidance on crawlable links says that every page you care about should have a link from at least one other page on your site, and that Google generally follows a link only if it is an anchor element with an href. A button that runs a script on click does not count.

Run this check on each page in your “meant to be indexed” group:

Weak links alone rarely explain a status, because Google has already crawled the page. But a page with one footer link and thin content gets no benefit of the doubt. Our internal linking guide walks through hub and spoke structures and orphan pages, and the fix is usually an hour of editing, not a rewrite.

The diagram below sets the three causes side by side so you can match a pattern to a fix.

Scroll the diagram sideways to see all of it.

Is the content itself the cause?

Content is the cause when steps 2 to 4 find nothing. This is the hardest diagnosis to accept, and it is the most common one on sites with many similar pages. Marie Haynes says most cases she sees involve commodity content, meaning pages that repeat what already exists and add nothing new, and she warns that recovery is hard for sites with a large number of them. Yoast lists the same family of causes: thin pages, duplicated pages and a Google that has become pickier as similar content multiplies.

Google gives you the test in its helpful content guidance. Two of its self-assessment questions apply directly: does the content provide original information, reporting, research or analysis, and does it provide substantial value compared to other pages in search results? Answer them honestly for one stuck page, with the top results open beside it.

Look for these gaps:

• No first-hand material: no data you collected, no process you ran, no photos or examples of your own.
• Same outline as everyone else: your headings match the top five results one for one.
• A page that exists for a keyword, not a reader: a service-by-city page where only the city changes.
• Thin variants: pages that could be a section of a stronger page.

When the answer is “nothing new,” you have two honest options. Rewrite the page so it contains something the top results lack, or merge it into a stronger page and redirect. Publishing more pages of the same kind makes the pattern worse. If you used AI drafting at scale, read what we found about Google’s stance in is AI content bad for SEO.

One caution. A site-wide pattern with no technical cause points at overall quality, not at individual pages, and Marie Haynes notes that Google may crawl and index less of a site when it has serious quality concerns. In that case, fixing one page at a time will not move the total.

A before and after test plan

A fix only counts if you can see it work, and indexing is slow and noisy, so test in small batches with a record. The plan below is a method, not a promise. Google does not guarantee indexing for any page, however good.

1. Baseline (day 0). Export the list. Pick 10 to 20 URLs from the “meant to be indexed” group. Save the Page indexing status, the Google-selected canonical, the last crawl date, and the number of internal links to each.
2. Split into groups. Put pages with the same suspected cause together. Change one cause per group: links for one, duplication for another, content for a third. Leave a small control group untouched.
3. Make the change. Record exactly what you edited and the date. Update the sitemap so it lists the final URLs.
4. Hold. Do not keep editing. Google’s documentation says new content can take a few days to be indexed, and a new page or site about a week or so to be crawled. It advises asking for a recrawl only after an important change that Google has not noticed for a week or more.
5. Read (day 14 or later). Re-inspect each URL. Compare against the baseline and against the control group. Validation in Search Console typically takes up to about two weeks and can take much longer, so a clean read may need more time.

Scroll the diagram sideways to see all of it.

What counts as success? A moved status for the treated group that the control group does not share. If both groups moved, something site-wide changed, such as a Google-side reporting shift, and you have learned nothing about your fix. If neither moved, the diagnosis was probably wrong, so go back one step in the sequence.

Getting indexing problems under control

Handle this status as a sorting problem first and a fixing problem second. Most lists shrink once you set aside the URLs that were never meant to be indexed. The remaining pages usually fall into one of three piles: rendering or technical blocks, duplicates Google folded together, or pages that are weak on links or on content. Each pile has a different fix, which is why the order matters.

Keep two habits. Check the Page indexing report on a schedule, which our Search Console routine lays out. And decide before publishing whether a new page earns its place, because a page that adds nothing is the cheapest one to avoid. If you would like a second pair of eyes on a site with a long list, our AI visibility audit checks indexing signals alongside the items AI crawlers depend on, and the checklists library has step-by-step lists for the technical items.