Crawled but Not Indexed: What It Means and How to Fix It

Crawling and indexing are two different decisions

Crawling is Googlebot requesting a URL and downloading its content. Indexing is a separate process where Google evaluates that content and decides whether to store it in the index it serves results from. A page can be crawled successfully, with no technical error at all, and still fail the indexing decision because Google judged the content not worth adding.

Plenty of guides skip that distinction and treat a crawled but not indexed page as a technical bug, to be debugged like a broken redirect. Usually it's a judgment about quality and context, so the fix lives in the content and the page's place on your site rather than in a crawler directive. Start with the content.

Why a page ends up crawled but not indexed

A few mechanisms drive this decision, and they usually overlap. Duplicate or near-duplicate content is the most common: if a page says roughly what another page on your own site already says, or what a dozen competitor pages say with the same structure, Google has no reason to index a copy when it already has a version it treats as canonical. This is exactly why templated pages built from the same outline, thin location pages, spun product descriptions, auto-generated category pages, are far more likely to be left out than pages with distinct content. Make each page different.

Thin content triggers the same outcome even without duplication. A page with a short paragraph, a stock image, and a contact form gives Google nothing distinctive to index. The site's overall authority plays a role too: a brand-new page on a site Google hasn't built much trust in gets a more conservative indexing decision than the same content published by an established site.

There's a rendering-specific version of this problem as well. If a page's content only appears after client-side JavaScript runs, Google has to queue the page for rendering before it can evaluate what's on it. Google's JavaScript SEO guide says a page can wait in that queue for a few seconds or longer, so a page that depends on it can sit unindexed longer than one whose content is already in the raw HTML.

Weak internal linking

A common cause, alongside duplication and thin content, is a page Google can crawl that gets almost no internal links. A page buried several clicks from the homepage with nothing else on the site linking to it sends a weak signal about its importance. Google reads that isolation as evidence the page isn't worth prioritizing for the index, even when the content itself is fine. Link to it.

Canonical tag mistakes cause the same symptom from a different direction. If a page has a canonical tag pointing to a different URL, even by accident, Google treats that as an instruction to index the other URL instead and leaves this one out, regardless of how good the content is. Check the tag.

The quality bar behind the decision

Thin and duplicate content are the mechanical reasons a page gets left out, and underneath both is a judgment about usefulness. Google's guidance on helpful content asks whether a page provides "original information, reporting, research, or analysis" and adds value beyond other pages. A page with no author and no supporting context gives Google little reason to add it to an index that already holds similar pages.

This is why two pages with a similar word count and similar structure can get different indexing outcomes. One has author information, internal links to and from related, substantive pages, and content that goes beyond restating what the top five search results already say. The other reads like a rewritten summary of that same information with nothing added. I've covered what builds those trust signals in what E-E-A-T is and how you build it, and it's worth reading before you spend more time rewriting a page's word count instead of its substance.

Why migrations cause indexing to collapse

A wave of pages moving from crawled and indexed to crawled but not indexed right after a site migration is one of the more alarming patterns in Search Console, and one of the most avoidable. Two mechanisms usually drive it. The first is the rendering issue covered above: a site that moves from static HTML to a JavaScript framework without server-side rendering makes Google render every page before it can evaluate the content. That takes time.

The second is internal link loss. A migration that changes URL structures, folder depth or menus without carefully mapping the old internal link graph onto the new one can leave previously well-linked pages suddenly orphaned or several clicks deeper than they used to be. Since internal links are one of the clearest signals Google uses to judge a page's importance, losing them mid-migration can tip a page that indexed easily under the old structure into the crawled but not indexed state under the new one, even though the content itself didn't change.

What changes when you move from WordPress to Next.js covers this failure mode: the rendering and linking decisions made during a move, more than the platform change itself, determine whether Google keeps treating your pages the way it did before.

Indexing decisions are separate from the other two technical basics worth ruling out first: page speed, covered in Core Web Vitals explained, and crawl budget, which almost never applies to a site this size but gets blamed anyway. More in the Technical SEO archive. If technical issues like these keep resurfacing, that's usually a sign the site needs a proper technical SEO audit rather than another one-off fix.

A worked example: diagnosing a stuck page

Say a service page has sat in crawled but not indexed for six weeks. Start with URL Inspection and check the page fetch and rendered HTML side by side. If the rendered version is missing content you can see in a plain browser, whatever handles client-side rendering isn't finishing before Google's evaluation, and that's your answer. Fix the rendering.

If the rendered HTML looks complete, check the canonical tag Google chose to trust, shown in URL Inspection under user-declared canonical versus Google-selected canonical. If those two don't match, Google has decided a different URL represents this content, and no amount of content editing on this page will change that until the canonical mismatch is fixed. Fix that first.

If the canonical is correct and the content renders fine, pull up the page in a private browser window and read it next to the top three ranking pages for its target query. Often the content covers the same ground as those competitors without adding a detail, an example or an explanation they lack. No crawler directive fixes that. The fix is going back into the content and giving Google a reason to prefer this page over the ones already occupying the results.

Then check internal links pointing to the page. If it's linked only from a sitemap and nowhere else on the site, add at least one contextual link from a page that already ranks and gets crawled regularly. That link is often what tips a borderline page from excluded to indexed on the next crawl, even without a single word of the content changing.

How to fix it

Start by checking whether the page duplicates content that already exists elsewhere on your site. Merge or differentiate rather than publishing near-identical versions. Next, check internal links. A page that matters should be linked from your menu, a relevant blog post or a related service page, rather than sitting where nothing points to it.

Verify the canonical tag points to itself unless you deliberately intend otherwise. Then look at content depth honestly: does the page say something a competitor's page on the same topic doesn't already say better? If the answer is no, that's the real problem, and resubmitting the URL in Search Console won't change Google's evaluation of the content. Change the page first.

Check the page's rendered HTML in URL Inspection as well as the plain source, since the rendered version is what Google evaluated for indexing.

Resubmitting through URL Inspection after making real changes can prompt a faster recrawl than waiting for the natural cycle, but it doesn't override the underlying quality decision. If the content and links haven't changed, a forced recrawl returns the same result, only sooner.