Search Console's "Crawled, currently not indexed" status confuses more site owners than almost any other line in the coverage report. It looks like an error. It isn't one, at least not in the way a 404 or a server error is. This is what crawled but not indexed actually means: Google visited the page, read it, and then made a separate decision not to add it to the index.
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 actually serves search 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.
This is the distinction most guides skip. People treat a crawled but not indexed page as a technical problem to debug with the same tools they'd use for a broken redirect. It isn't. It's a quality and context judgment, and the fix lives in the content and the page's place on your site, not in a crawler directive.
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, get excluded at a much higher rate than pages with genuinely distinct content.
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 actual content only appears after client-side JavaScript runs, Google has to queue the page for a second rendering pass before it can evaluate what's really on it. That queue isn't instant, and a page stuck waiting in it can sit in a crawled but not indexed state longer than a page whose content is already present in the raw HTML on the first request.
Work With John
Your site should be your best salesperson. If it is not, that is a fixable problem.
I work with US service businesses and B2B brands to build SEO systems that produce consistent, compounding leads. I will tell you exactly what is broken. No pitch.
Book a free strategy callThe pattern I see most often
The most common cause I run into, more than duplication or thinness, is a page that Google can technically crawl but that gets almost no internal links pointing to it. 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.
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.
The quality bar behind the decision
"Thin content" and "duplicate content" are the mechanical reasons a page gets excluded, but underneath both is a judgment about trust. Google's indexing systems weigh signals connected to E-E-A-T, experience, expertise, authoritativeness, and trustworthiness, when they decide whether a page earns a place in the index competing pages don't already fill. A page written by an anonymous byline with no supporting context reads very differently to those systems than the same information published on a site that demonstrates it knows the subject firsthand.
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 broken down what actually builds those trust signals in more detail 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 to see in Search Console, and one of the most avoidable. Two mechanisms usually drive it. The first is the rendering issue already covered: a site that moves from static HTML to a JavaScript framework without server-side rendering forces Google to queue every page for a second rendering pass, and pages that used to index within days can sit unresolved for weeks while that queue works through the backlog.
The second is internal link loss. A migration that changes URL structures, folder depth, or navigation 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.
This is exactly the failure mode I walk through in what actually changes when you move WordPress to Next.js: the platform change itself isn't the risk, it's the rendering and linking decisions made during the move that 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, not 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.
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.
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. Nine times out of ten in this situation, the content covers the same ground as those competitors without adding a detail, a mechanism, or a specific instance those pages are missing. That's not a technical problem at all, and no crawler directive fixes it. The fix is going back into the content and giving Google an actual 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 actually 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 navigation, a relevant blog post, or a related service page, not orphaned where nothing else points to it.
Verify the canonical tag actually 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.
Check the page's rendered HTML in URL Inspection too, not just the source you see from a plain view-source request, since the rendered version is what Google actually 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 just returns the same result on a faster timeline.
