Crawled – currently not indexed: how to fix it

"Crawled – currently not indexed" in Google Search Console means Googlebot fetched your page without trouble but Google decided not to add it to its index, at least for now. It isn't a penalty or a server error, and pressing Request indexing again won't change it. To fix it, give Google a reason to keep the page: unique, substantial content, internal links and a correct canonical that show the page matters, and on JavaScript sites like Next.js, the full content in the rendered HTML.

Google's own Page indexing report documentation says such a page "may or may not be indexed in the future; no need to resubmit this URL for crawling." Put simply, the status won't move until the page does.

What does "Crawled – currently not indexed" actually mean?

Googlebot reached the page, read it, and chose not to store it. Nothing technical went wrong: robots.txt blocks, 404s and noindex tags each get their own rows in the report.

In Search Console, go to Indexing → Pages and scroll to "Why pages aren't indexed". Each reason has a different fix, so check which one you're looking at first.

All five definitions come from Google's Page indexing report help page.

Should you fix every URL in the report?

No. Fix the URLs that should rank and ignore or remove the rest. Export the list and sort it into three piles:

• Pages that should rank: services, products, category pages, location pages and your key articles. Fix these.
• Pages that never need to rank: tag archives, internal search results, sorted or filtered URLs, paginated archives, feeds, thank-you pages and WordPress attachment pages. Leave or noindex them, and drop them from the sitemap and internal links.
• Pages that shouldn't exist: old test pages, staging copies and URLs created by parameters. Redirect them or let them 404.

The URL Inspection tool is the most useful thing in Search Console here: it shows whether the URL is indexed, which canonical Google picked, and what Googlebot renders.

Why does Google crawl a page but not index it?

Because Google doesn't think the page is valuable or different enough, isn't convinced it matters, or can't see the main content. The causes I check, roughly by how often they show up:

1. Thin content. The page doesn't say enough to earn a place: a short service blurb, a product with a one-line description, a location page that only swaps the city name.
2. Duplicate or near-duplicate content. The same content lives at several URLs, or several pages say nearly the same thing.
3. Weak internal linking. The page is an orphan, or it's only linked from the sitemap or from somewhere deep in the site.
4. Conflicting signals. The canonical points one way, the sitemap lists another URL and internal links point to a third.
5. Rendering problems. The main content only appears after JavaScript runs, so the HTML Google renders is close to empty.
6. Pages that look like errors. Empty listings, "no results" pages or loading screens that return a 200 status.

If a big share of your URLs are low-value, the good pages can get lost among them, so clearing out junk is worth doing. Google's guidance on creating helpful, people-first content describes what its systems look for.

How do you fix thin or duplicate pages?

Merge or expand thin pages. Point every duplicate at one canonical URL with 301 redirects and self-referencing canonical tags.

For each thin page, ask whether it answers something no other page on the site answers. If not, fold it into the stronger page with a 301. If it does, add what's missing: specifics, your process, pricing factors, real FAQs, original images or examples. Location pages and near-identical product variants are the usual offenders; canonicalise variants to the parent product or write copy that's actually different.

For duplicates, pick one URL per piece of content. The usual sources are http and www variants, trailing slashes, query parameters and WordPress archives that repeat the same posts. Use 301 redirects at the server or framework level and a self-referencing canonical on every indexable page. Google's guide to consolidating duplicate URLs explains how it weighs redirects, canonicals and sitemaps against each other.

Can internal linking and sitemaps get a page indexed?

Often, yes. Internal links and the sitemap tell Google whether a page matters. A page that sits in the sitemap but is linked from nowhere looks like an afterthought.

• Link to the page from related pages with descriptive anchor text, not "click here".
• Link key pages from hub pages or the main navigation, so they're a few clicks from the home page.
• Only list canonical, indexable URLs that return 200 in the sitemap. No redirects, noindexed pages or parameter URLs.
• Only update lastmod when the content really changes.
• Submit the sitemap in Search Console and reference it in robots.txt.

A sitemap is a hint, not an instruction. Google's guide to consolidating duplicate URLs treats redirects and rel=canonical as stronger signals than sitemap inclusion, so make sure all three point at the same URL.

How do canonical tags cause "crawled but not indexed"?

A wrong canonical tells Google another URL is the main version, so it skips the page you wanted indexed. These bugs are quiet and can hit every page at once:

• Every page has a canonical pointing to the home page, thanks to a theme or plugin bug.
• Canonicals point to URLs that redirect or 404.
• Canonicals use the wrong domain, like a staging site or a preview URL.
• The canonical in the HTML disagrees with the sitemap and internal links.

In URL Inspection, compare the user-declared canonical with the Google-selected one. If they differ, Google doesn't trust your signal, so get the redirects, internal links, sitemap and canonical agreeing on one URL.

Why do Next.js pages get crawled but not indexed?

Usually because the main content isn't in the server-rendered HTML, missing pages return a 200, or preview domains create duplicates. Next.js itself isn't the problem; I build and maintain procol.ai on it. But a handful of patterns cause indexing trouble:

• Main content fetched on the client. If a 'use client' component loads the page's main content in useEffect, the first HTML response is an empty shell. Google does render JavaScript, but client-rendered pages wait for a separate rendering pass with no guaranteed timing. Vercel's research on how Google handles JavaScript is worth a read too. Fetch on the server instead, with Server Components, static generation or ISR.
• Missing content returned as a 200. A dynamic route for a slug that doesn't exist, showing "Not found" text with a 200 status, is a textbook soft 404. Call notFound() so the route returns a real 404. If it runs after streaming has started, Next.js has already sent a 200 and adds a noindex meta tag instead, so call it before any content streams and confirm the status in URL Inspection.
• Metadata set on the client. Titles and canonicals belong in the Next.js Metadata API (generateMetadata and alternates.canonical), not in client-side code.
• Duplicate hosts. Preview deployments, the default platform domain and inconsistent trailing slashes all copy your pages. Set trailingSlash one way, redirect alternative domains and use absolute production URLs in canonicals.
• Blocked assets. A robots.txt rule that disallows /_next/ stops Google loading the JavaScript and CSS it needs to render the page.
• Thin generated pages. Thousands of pages built from a CMS or database, each with a few lines of content.

My Next.js technical SEO checklist covers these in more detail. If the trouble started after a move from WordPress to Next.js, look at your redirects and canonicals first. My free Redirect Map Builder turns old WordPress URLs into a redirects() array for next.config.js.

Does robots.txt cause this status?

Not directly: blocked URLs get their own "Blocked by robots.txt" status. But blocking scripts or stylesheets breaks rendering, and robots.txt is where your sitemap should be declared.

To see how Googlebot treats your robots.txt, use Search Console's robots.txt report and URL Inspection. My free AI Crawler Checker answers a different question: whether 14 AI crawlers, from OpenAI, Anthropic, Perplexity, Google-Extended and others, may fetch your home page, and which sitemaps your robots.txt declares. It doesn't test Googlebot crawling or indexing.

How long does it take to get indexed after a fix?

Nobody can promise a date. Google says Search Console validation typically takes up to about two weeks, sometimes much longer. This is the order I work in:

1. 1

   Export and sort

   Download the affected URLs and split them into pages that should rank, pages that don't need to and pages that shouldn't exist.

2. 2

   Inspect key URLs

   Run important pages through URL Inspection and compare the rendered HTML and Google-selected canonical with what you expect.

3. 3

   Fix the cause

   Improve or merge thin pages, consolidate duplicates, fix canonicals, add internal links and move main content into server-rendered HTML.

4. 4

   Clean the sitemap

   Leave only canonical, indexable URLs that return 200, then resubmit the sitemap in Search Console.

5. 5

   Validate and watch

   Click Validate fix in the Pages report, request indexing once for your top pages, then track impressions in the Performance report.

How much does it cost to have someone fix it?

A technical SEO audit runs from under $500 for an automated report to $1,000–$5,000 for a manual small-business audit, and code fixes are on top. The spread is wide because "audit" means different things to different sellers. These are market ranges:

What moves the price: how many URLs are affected, the platform (a WordPress theme or a custom Next.js app), whether the site was migrated recently, and whether the fixes are code or content. And an audit only finds problems. If the cause sits in templates, rendering or redirects, somebody still has to change the code. That's why my technical SEO service covers the diagnosis and the fixes, not one without the other.

What should you ask a developer before hiring?

Five questions tell you whether you'll get a real diagnosis:

• Will you need Search Console access? The answer should be yes.
• How will you decide which URLs to fix and which to leave?
• Can you change templates and code yourself?
• How will you check what Google renders on JavaScript pages?
• How will we measure success? Key pages indexed and their impressions, not the total count of indexed URLs.

If the pages dropped out after a redesign or replatform, start with what to do when traffic drops after a website redesign.

Want me to look at your report?

Run your key URLs through URL Inspection and export the "Crawled – currently not indexed" list from Search Console. Then book a 20-minute call and we'll go through it together. I'll tell you which URLs matter, what's causing the problem and whether it's a content fix or a code fix. If it's code, I can make the changes myself on WordPress or Next.js through my technical SEO and Core Web Vitals service.