Crawled – Currently Not Indexed: What to Check First
Four ordered checks for pages Google crawled but didn't index: rendering, template comparison, internal links and technical basics, plus a decision table.
When Search Console lists a page as crawled currently not indexed, Google has fetched the page, evaluated it and decided not to add it to its index, at least for now. Google doesn't say why, so you diagnose it page by page. Is the page worth indexing? Can Google see its content? Can Google find it? Below are four checks in a fixed order, then a decision table that maps each result to a fix.
If you're still setting up the basics, start with our guide to generating sitemap.xml and robots.txt in Next.js. Everything here reflects Google's Search Console Help as I read it on 6 November 2026. Google rewrites these pages, so re-read the page indexing report help before acting on any wording.
What the two statuses mean
"Crawled – currently not indexed" and "Discovered – currently not indexed" sit at different stages of the same journey. They need different fixes.
| Status | What Google says | What it usually points to | Start with |
|---|---|---|---|
| Crawled – currently not indexed | "The page was crawled by Google but not indexed." | An evaluation outcome: Google saw the page and held it back. Think value, duplication, rendering, canonicals. | Steps 1 and 2 |
| Discovered – currently not indexed | "The page was found by Google, but not crawled yet." Google typically expected the crawl to overload the site, so it rescheduled. | Crawl scheduling: server capacity, URL volume or low demand. | Server speed and Step 3 |
Google's crawl-budget guide explains the first status: after crawling, each page "must be evaluated, consolidated, and assessed to determine its suitability for the index." A Discovered URL has an empty last-crawl date in the report, because Google hasn't fetched it yet.
What about crawl budget? That guide targets sites with 1 million or more pages changing about weekly, sites with 10,000 or more pages changing daily, and sites with a large share of URLs stuck in Discovered. Google calls those numbers rough estimates, and says that if your pages are crawled the day they're published, you don't need the guide. On a typical business site, I'd check content, rendering and links before blaming crawl budget.
What Google changed on 3 November, and what it doesn't mean
On 3 November 2026, Search Engine Roundtable reported that Google had updated the help text for this status. As I read it on 6 November, the entry says: "Google doesn't index all pages across the web, so this is a common message for many sites and doesn't necessarily indicate an issue that needs attention."
It's true, and easy to over-read. The next sentence says: "If you see this message for important pages, use the URL Inspection tool and other tools to diagnose if there are any issues on your site that are preventing the pages from appearing." So the change doesn't mean three things.
- Your important pages aren't automatically fine. "Common" describes the web, not your service page.
- The page won't necessarily be indexed later. Google's report help also says it "doesn't guarantee that all pages everywhere will make it into the Google index."
- You can't ignore the money pages. The same entry tells you to diagnose them.
If you've fully diagnosed your site and suspect a complete, site-wide indexing bug, Google points you to its report-an-indexing-issue form. That's the last step, not the first.
When the status is normal, and when it needs diagnosis
The status is normal for URLs you wouldn't miss. It needs diagnosis for pages meant to bring enquiries or sales. Google's report help says: "Don't expect every URL on your site to be indexed."
Before changing anything, export the affected URLs and sort them into three buckets.
- Important: service, product and category pages, location pages with a real offer, key articles, landing pages.
- Secondary: older posts, author pages, deep pages.
- Don't care: filter and sort variants, tag archives, internal search results, old thank-you pages.
Here's a hypothetical example. A Mumbai interior designer's site shows 40 crawled-not-indexed URLs: thirty tag archives and ?sort= variants, six old thank-you pages and four service pages. Leave the 36 alone. The four service pages get the full diagnosis. And if the whole group shares one template, say every location page, treat it as one problem with many symptoms, not 200 separate ones.
Step 1: Fetch the page the way Google does
Start with URL Inspection, which shows what Google saw, and compare it with the raw HTML your server sends. On JavaScript-heavy sites the two can differ.
- Paste the URL into the inspection bar. The default view is the last indexed version, not the live page. Note the last crawl date and the Google-selected canonical.
- Click Test live URL, then view the tested page. Check the screenshot and rendered HTML for your main heading and body text.
- In a terminal, fetch the raw HTML and search it for that heading:
curl -sL https://example.com/your-page/ | grep -i "your main heading"
If the content is in both versions, rendering isn't your problem. Move to Step 2. If it's missing from the raw HTML but present in the rendered view, Google can render the page but depends on a second step. Google's JavaScript guide says a page "may stay on this queue for a few seconds, but it can take longer than that," and that server-side or pre-rendering is still a great idea. If the rendered view is blank, errored or stuck on a loading skeleton, Google can't see your content at all.
On Next.js, this check earns its keep. In the App Router, layouts and pages are Server Components by default, so content rendered there arrives in the first HTML. Trouble starts when the main content loads in the browser afterwards, for example inside a Client Component, because it won't be in the raw HTML. Also watch for "not found" views served with a 200 status, which Google's guide says can create soft 404s in single-page apps.
A clean live test means Google can fetch and see the page. It doesn't check conformity with quality guidelines, according to Google's URL Inspection help, so a pass isn't a reason to expect indexing.
Step 2: Compare indexed and non-indexed pages
Comparing five indexed pages with five non-indexed ones from one template usually shows the pattern faster than any tool. This is my method, not a Google procedure.
| What to compare | What a difference tells you |
|---|---|
| Unique body text | If non-indexed pages are mostly the same words with a name or city swapped, Google may fold them together. |
| Declared and Google-selected canonical | A different Google-selected canonical means Google consolidated the page into another URL. |
| Where the content lives | Raw versus rendered HTML, from Step 1. |
If the pattern is near-duplicate template pages, you have three honest options. Make each page genuinely different. Merge several into one stronger page with redirects. Or drop the weak ones from the sitemap and noindex or remove them. Google's crawl-budget guide recommends consolidating duplicates "to focus crawling on unique content rather than unique URLs."
Not sure which pages deserve indexing? We can sort your Search Console URLs by template and tell you what to fix first.
Request an indexing reviewStep 3: Check your internal links
Google discovers pages through links, so an important page with few links pointing to it is a common suspect. Build a depth map. Crawl your site with any crawler and record, for each non-indexed important page, its click depth from the homepage and its count of internal links.
My rule of thumb, not a Google rule: an important page should be reachable in about three clicks and linked from several relevant pages. A page that appears only in the sitemap is an orphan. Link it from the relevant hub, category or related article with descriptive anchor text, and add it to navigation if it's central.
Check how the links are built, too. Google says it can generally crawl a link only if it's an <a> element with an href attribute, and it can't reliably extract URLs from elements that act as links through script events. A button with an onClick handler that changes the route isn't a link to Google.
If your status is Discovered, check server health too. Google says it rescheduled the crawl to avoid overloading the site, so read your response times and error rates before rewriting copy.
Step 4: Confirm the technical basics
This step rules out the boring causes.
- Canonical: the page should point to itself, or to the URL you want indexed, as an absolute URL. Our guide to metadata and canonical URLs in Next.js shows how to set it.
- Noindex and robots meta: check the raw and the rendered HTML. JavaScript can change a robots meta tag, and a staging setting can ship to production by accident.
- Status codes and soft errors: a live page returns 200, a removed page returns 404 and a moved page redirects cleanly.
- Blocked resources: a page Google fetched wasn't blocked by robots.txt, but blocked CSS or script files can still break rendering, and Google says it won't render JavaScript from blocked files. Check the Step 1 screenshot.
- Sitemap conflicts: list only canonical URLs you want in search results. Don't list noindexed, redirected or duplicate URLs. Google calls a submitted sitemap "merely a hint."
Our technical SEO audit checklist covers the wider list.
Child sitemaps per section
Split your sitemap by section and submit each part. Google's documentation says you can submit several sitemaps and sitemap index files, which helps if you want to track each one in Search Console, and the page indexing report has a filter for a specific sitemap URL. Submit services.xml, locations.xml and blog.xml separately and the crawled-not-indexed count shows up per section. That's a practitioner tip for reading the report, not an official ranking factor, and it doesn't make Google index anything. In Next.js, generateSitemaps produces multiple sitemaps under /sitemap/[id].xml. Keep each file under 50,000 URLs and 50MB uncompressed.
Key figures from Google's documentation
- "A week or so" up to "a few weeks": how long Google says it can take to start crawling and indexing a new page or site, adding that indexing is never instant. Source: Google Search Console Help, Page indexing report (read 6 November 2026).
- 1 million+ pages, or 10,000+ pages changing daily: the rough site sizes the crawl-budget guide is written for. Google says these are estimates, not exact thresholds. Source: Google Search Central, crawl budget guide (read 6 November 2026).
- 50,000 URLs or 50MB uncompressed: the limit for a single sitemap file. Source: Google Search Central, build and submit a sitemap (read 6 November 2026).
Watch: Index coverage status in Search Console - Google Search Console Training
Google Search Central's training video on indexing statuses. Its title says "Index coverage", so the interface may differ from today's report.
Watch on YouTube: Index coverage status in Search Console - Google Search Console Training
When waiting is correct
Waiting is right only after Steps 1 to 4 pass, the page is genuinely distinct and relevant pages link to it. Google's timing guidance is wide: "a week or so" for a new page or site, and "up to a few weeks" before it crawls some or all of a site. I can't give you a number of days, and nobody outside Google can.
Don't resubmit the same URL daily. URL Inspection has a daily request limit, and Google says requesting indexing doesn't guarantee a page will be indexed. For many pages, Google recommends a sitemap with accurate lastmod dates.
Skip the Indexing API too. Google says it's only for pages with JobPosting markup or BroadcastEvent embedded in a VideoObject. A job board qualifies. An ordinary service site doesn't.
Decision table: what to do with each result
Find your result in the first column and follow the third.
| What you find | What it likely means | What to do next |
|---|---|---|
| Content missing from raw HTML, present when rendered | Content depends on JavaScript and the render queue. | Move the main content into server-rendered HTML, then re-test. |
| Rendered screenshot is blank or errored | Google can't see the content. | Fix blocked resources or failing data calls, then re-test live. |
| Page is a near-copy of its template siblings | Low distinct value; likely consolidated. | Rewrite with real differences, merge with redirects, or noindex it. |
| Page has 0 or 1 internal links, or sits deep | Weak discovery signal. | Link it from relevant hubs and add it to navigation if it matters. |
| Google-selected canonical differs from yours | Google consolidated the page elsewhere. | Decide which URL should rank, then align canonicals, links and redirects. |
| Returns 200 but says "not found" or shows an empty list | A soft 404. | Return a real 404, or add genuine content. |
| All checks pass; page is new and distinct | Normal timing. | Wait, re-inspect after a few weeks, avoid repeat submissions. |
When a client brings us this, we audit, diagnose by template, prioritise by business value, fix rendering, links and duplicates, resubmit and monitor. Most fixes land in the build, so it sits with our web development work as much as with SEO.
Running on Next.js and unsure what Google sees? We can compare your raw and rendered HTML and check how your pages are linked.
Ask for a Next.js rendering and indexing checkReference reading
- Google Search Console Help: Page indexing report
- Google Search Console Help: URL Inspection tool
- Google Search Central: JavaScript SEO basics
- Google Search Central: managing large sitemaps with a sitemap index
Frequently Asked Questions
Is "Crawled – currently not indexed" bad for my website?
Not by itself. Google says the message is common and doesn't necessarily indicate an issue that needs attention. The same entry tells you to diagnose it on important pages, so check your service, product and enquiry pages first.
How long should I wait before I worry about crawled currently not indexed pages?
Google says a new page or site can take a week or so, and up to a few weeks before some or all of a site is crawled. Nobody can promise a date, so run the four checks first.
Will requesting indexing in Search Console fix it?
Requesting indexing asks Google to crawl a URL, but Google says it doesn't guarantee indexing, and there's a daily limit. If the page has a rendering, duplication or linking problem, the request won't change the outcome. Fix the cause, then request once.
What is the difference between crawled and discovered currently not indexed?
Crawled means Google fetched the page and chose not to index it, which points to evaluation. Discovered means Google knows the URL but hasn't fetched it yet, which points to crawl scheduling. Check content, rendering and canonicals for the first, and server speed and URL volume for the second.
Can I use the Indexing API to get my pages indexed faster?
Only if your pages carry JobPosting markup or BroadcastEvent inside a VideoObject, because Google's documentation limits the Indexing API to those cases. For other pages, use internal links, a clean sitemap and URL Inspection.