Why JavaScript Pages are Crawled but Not Indexed
In Brief
Crawled does not mean indexed. Once Google can fetch a JavaScript page, the next question is whether the rendered result is clear, canonical, stable, useful, and worth storing. Rendering support helps, but it does not overcome weak content, confused canonicals, blocked resources, unstable metadata, poor internal links, or duplicate pages.
"Crawled but not indexed" is one of those Search Console statuses that sounds more helpful than it is.
It tells you Google found the URL. It does not tell you whether Google found enough useful content, trusted the canonical, rendered the page successfully, discovered a near‑duplicate, hit a quality issue, or decided the page was not worth storing.
On JavaScript‑heavy sites, the diagnosis is often made too late. People assume that because Google can render JavaScript, the JavaScript is not the problem. That is the wrong conclusion. Rendering support is not the same as an indexing guarantee.
A page can be crawlable and still be weak. It can return 200 and still have no useful body content before rendering. It can render correctly for you and fail for crawlers because of blocked resources, timing, auth, errors, or unstable metadata. It can have content and still lose the canonical battle.
The job is to separate discovery, rendering, indexing, and ranking. They are related, but they are not the same failure.
First, Check What Google Can Fetch Without Your Browser
Start with the boring checks.
For the affected URL, confirm:
- status code
- final URL after redirects
- canonical URL
- robots meta tag
- X‑Robots‑Tag header
- robots.txt rules
- hreflang where relevant
- sitemap inclusion
- internal links pointing to the page
Do this before opening React DevTools. A JavaScript site can still have a plain HTTP problem.
If a page is blocked by robots.txt, has noindex, points its canonical elsewhere, redirects unexpectedly, or only appears in a stale sitemap, indexing may fail before rendering becomes relevant.
Google's documentation on JavaScript SEO basics, robots.txt, and sitemaps is worth keeping close during this kind of work. It is easy to chase framework details while missing a directive that says "do not index this".
Compare Raw HTML with Rendered HTML
Raw HTML is what the crawler receives first. Rendered HTML is what exists after JavaScript has run.
Both matter.
If the raw HTML is a thin app shell, the page depends heavily on rendering. That might be acceptable for some pages, but it raises the cost of indexing. It also makes the page more fragile: a failed API request, blocked script, uncaught error, or slow third‑party dependency can leave the rendered output incomplete.
For each affected template, compare:
- raw document title
- rendered document title
- meta description
- canonical
- h1
- body copy
- internal links
- product, article, or service details
- structured data
- image alt text
- pagination links
The page does not need every word in the first response, but it should not depend on a fragile browser‑only chain to expose its main meaning.
This is why optimising HTML markup for SEO is still relevant on modern React and Next.js sites. Better rendering does not remove the need for coherent document structure.
Look for Metadata That Changes After Load
Client‑side metadata is a common cause of confusion.
A page might show the right title in your browser tab after the app has loaded, but the crawler may initially see a generic title. The same can happen with meta descriptions, canonicals, Open Graph tags, and structured data.
Check whether metadata is:
- present in server‑rendered output
- route‑specific
- stable before and after hydration
- consistent with the canonical URL
- consistent with visible content
- free from staging or preview values
React SPAs often rely on libraries to patch metadata during route changes. That can work, but it is easier to get wrong than a server‑rendered metadata model. If a page matters for search, metadata should not be treated as a late client‑side side effect.
Check the Canonical Decision
Many "not indexed" problems are really canonical problems.
Google may crawl the URL, inspect it, and decide that another URL is the better representative. That may be right. It may also be a signal that your site is creating duplicate or near‑duplicate pages.
Check for:
- canonical pointing to the wrong environment
- canonical pointing to the homepage or category page
- multiple URLs with the same content
- filtered pages without a crawl strategy
- uppercase and lowercase variants
- trailing slash differences
- query parameters that create duplicates
- pages with identical titles and descriptions
If a JavaScript app builds page state from URL parameters, it can accidentally create many crawlable variants. Search engines then have to decide which one, if any, deserves to be indexed.
Canonicalisation is not a magic fix for weak content. It is a signal. If the signal conflicts with internal links, redirects, sitemap entries, or visible content, do not expect it to solve the problem alone.
Internal Links Decide Whether the Page Looks Important
Sitemaps help discovery. Internal links explain importance and context.
If an important page is only reachable through a search form, filter interaction, infinite scroll, client‑side state, or a button with no real href, crawlers may not treat it as part of the main site structure.
Review:
- top navigation
- breadcrumbs
- category links
- related articles
- product or service cross‑links
- footer links
- pagination
- HTML anchors generated before hydration
Anchor text matters as well. "Read more" repeated 200 times is less useful than links that describe the destination. This is not just an accessibility concern. It helps the page estate describe itself.
If the article supports a commercial service, connect it naturally to the relevant service page. For example, pages affected by rendering or indexation issues should point readers towards technical SEO for JavaScript applications or JavaScript SEO rendering and indexing fixes where the service genuinely fits.
Rendering Success Does Not Fix Thin Content
Sometimes JavaScript is blamed because it is visible and technical. The real issue is content quality.
A page can render correctly and still be ignored because it is too similar to other pages, too thin, not internally supported, or not clearly useful. That is especially common with location pages, tag pages, filtered commerce pages, and programmatically generated templates.
Ask:
- Does this page answer a distinct query?
- Is the content meaningfully different from adjacent pages?
- Would a user be satisfied if this URL appeared in search?
- Does the page have enough internal support?
- Does it link to useful next steps?
- Is the title aligned with the content, not just the template?
The technical work gives the page a fair chance. It does not create substance for it.
A Practical Debugging Order
When a JavaScript page is crawled but not indexed, I would usually work through this order:
- Confirm the URL is meant to be indexed.
- Check status code, redirects, robots, noindex, and canonical.
- Check sitemap and internal links.
- Compare raw HTML and rendered HTML.
- Inspect server logs or crawl data if available.
- Check browser console errors and failed network requests.
- Compare affected and indexed templates.
- Review duplicate content and canonical clusters.
- Strengthen the page content, links, and metadata if the technical surface is sound.
- Request validation only after the root cause is fixed.
That order avoids one of the most common mistakes: asking Google to reprocess a page that has not actually changed.
Wrapping Up
"Crawled but not indexed" is not a single diagnosis.
On JavaScript sites, it usually means you need to check the whole path from discovery to rendered meaning: HTTP response, directives, canonical, raw HTML, rendered HTML, internal links, and page quality.
Google can render JavaScript, but your job is not to make Google work harder than necessary. Important pages should expose their purpose clearly, link into the site properly, and avoid fragile client‑side dependencies for core content and metadata.
Key Takeaways
- Crawling, rendering, indexing, and ranking are different stages.
- Check directives and canonicals before blaming JavaScript.
- Compare raw and rendered HTML for affected templates.
- Make important metadata stable before hydration.
- Use crawlable internal links with descriptive anchor text.
- Do not expect a technically valid page to index if the content is thin or duplicated.