“Crawled, currently not indexed” in Google Search Console means Google fetched the page but decided not to add it to the index, at least for now. On JavaScript sites the most common causes are pages that look empty or duplicate after rendering, pages that show an error state because data failed to load, resources Google could not fetch, and client-side changes to canonical tags or titles. Diagnose each URL with the URL Inspection tool’s rendered view, fix what Google actually sees, then request indexing for a sample.
What the status means, and what it does not
Google’s documentation describes this status as a page that was crawled but not indexed, which may or may not be indexed in the future, and says there is no need to resubmit it. It is not an error in itself. Many sites have some pages in this state, such as thin tag pages or filtered listings. It becomes a problem when important pages, such as services, products or articles, are affected, or when the number grows sharply after a release.
It is different from “Discovered, currently not indexed”, where Google knows the URL but has not crawled it yet, usually because of crawl capacity or low perceived importance.
Step 1: check what Google rendered
- In Search Console, open URL Inspection for an affected URL.
- Click “Test live URL”, then “View tested page”.
- Look at the HTML tab: is the main content there, or only a loading state or empty containers?
- Look at the screenshot: does the page look complete?
- Open “More info” and check for page resources that could not be loaded and JavaScript console messages.
Step 2: match the symptom to the cause
| What Google’s rendered view shows | Likely cause | Fix |
|---|---|---|
| A loading spinner or empty main area | Content fetched in the browser too slowly or failed during rendering | Render main content on the server or at build time |
| “Not found” or “Something went wrong” text with status 200 | API call failed and the app showed an error state; Google may treat it as a soft 404 | Return real status codes from the server; render content server-side |
| Missing styles or broken layout, resources flagged as not loaded | robots.txt blocks JavaScript, CSS or API paths | Allow Googlebot to fetch the resources the page needs |
| Content present but nearly identical to other URLs | Template pages with little unique text, or parameter duplicates | Add unique content, consolidate, or canonicalise duplicates |
| Canonical in the rendered HTML differs from the initial HTML | JavaScript changes the canonical after load | Set the canonical once, in the server HTML |
| Everything looks correct | Google judged the page low value compared with others | Improve content, internal links and uniqueness |
Step 3: check the initial HTML as well
Google renders JavaScript, but most AI crawlers do not, and Google’s own rendering can be delayed. Fetch the page without JavaScript to see what the server sends:
$ curl -s https://www.example.com/services/audit/ | grep -c "<h1" # 0 means the main heading is added by JavaScript
Our AI crawler access checker does this for ten crawlers at once. If the initial HTML is empty, fixing it solves problems for Google and for AI search together. The Next.js checklist covers server rendering in detail.
Step 4: common framework-specific causes
- Next.js pages marked “use client” that fetch their content in useEffect
- Single-page apps where every route returns the same index.html with status 200, including routes that do not exist
- Client-side routing that changes the URL without a real link Google can follow
- Metadata such as titles and canonicals set in the browser by a library after load
- Infinite scroll without paginated URLs, leaving deeper items undiscovered
Step 5: validate and monitor
- Deploy the fix and test a few affected URLs with “Test live URL” to confirm the rendered HTML is complete.
- Request indexing for a small sample of the most important URLs.
- Use “Validate fix” on the issue in the Page indexing report.
- Watch the count over the following weeks. Not every page will be indexed; the important ones should be.
Frequently asked questions
Should I request indexing for every affected page?
No. There is a daily limit, and requesting does not override Google’s quality judgement. Fix the cause, then request indexing for a sample.
Can internal links help?
Yes. Pages with more relevant internal links from important pages are seen as more important. Orphan pages are more likely to stay unindexed.
How long until pages are indexed after a fix?
From days to a few weeks, depending on how often Google crawls the site.
Sources
- Search Console Help, “Page indexing report”
- Search Console Help, “URL Inspection tool”
- Google Search Central, “Understand the JavaScript SEO basics” and “Fix Search-related JavaScript problems”