Services

Fix JavaScript Pages Not Indexing, Rendering and Metadata Problems

This is for React and Next.js sites that are crawled but not indexed, where key content only appears after JavaScript runs or rendered HTML and metadata do not match what search engines need.

Diagnose why Google is not indexing important JavaScript pages before incomplete HTML, unstable metadata, or routing changes keep them out of search.

Short Answer

JavaScript SEO problems usually start when crawlers can reach a route but cannot see stable content, metadata, or links early enough to index it confidently. The useful work is to separate rendering problems from discovery and URL problems, then focus engineering effort on the templates that keep important pages thin, delayed, or missing in search.

Typical Symptoms

  • Pages are published but not indexing reliably or at all.
  • Search engines are seeing incomplete, inconsistent, or delayed content.
  • Metadata or rendered page state does not match the intended output.

Likely Causes

  • Important page data is not available early enough in the rendered output.
  • Link discovery or metadata generation is inconsistent across templates.
  • Rendering assumptions changed during a migration or framework update.

What I Look at First

  • Inspect the raw HTML and metadata on affected templates, then compare them with the hydrated browser state.
  • How content becomes visible to bots on priority routes.
  • Whether the issue is rendering, crawl discovery, or URL management.

How I Help Fix This

  • Separate rendering issues from crawl and URL problems quickly.
  • Identify the templates and page types that need the first fixes.
  • Make engineering changes that improve indexable output without guesswork.

When to Look at This

  • When the issue is clearly technical and broad SEO guesswork is wasting time.
  • When rendering, metadata, and indexing problems are overlapping on important routes.

What Gets Resolved

  • Important JavaScriptrendered pages are checked against the HTML, links, metadata, and structured data search engines actually receive.
  • Lost or underperforming URLs are mapped against rendered HTML and crawl or indexing signals.
  • Redirect, canonical, sitemap, robots, metadata, and schema faults are separated.
  • Fixes are prioritised by commercial search exposure and implementation risk.
  • The team knows which evidence to recheck after release.

How This Usually Works

  1. Technical Diagnostic

    A focused review of affected routes, templates, deployment behaviour, crawl signals, CMS behaviour, performance bottlenecks, or code paths, followed by a prioritised fix plan the team can take into delivery.

  2. Recovery Sprint

    A short, concentrated engagement for a defined technical SEO, performance, CMS, Vercel, migration, or production issue where the business needs the cause isolated and the first fixes moved quickly.

Common Questions

Does this include metadata and Open Graph problems?
Yes, when those issues are tied to the same rendering or indexing failure. The point of this page is to diagnose what bots can actually see and process, not to treat metadata in isolation.
How is this different from crawlability debugging?
Crawlability work is about discovery and route access. This page is for the rendering and indexing side of the problem, where the content or metadata a crawler sees is incomplete, unstable, or delayed.

Contact me about your recovery

A short description of the affected route, Search Console signal, or production symptom is enough. I'll read it and suggest the next step.

Related Case Studies and Project Work

  1. Screenshot of the Nando’s website; part of John Kavanagh's selected project work.

    A Complete Migration and Replatform for Nando’s

    On Nando’s, the migration tied structured data, restaurantpage improvements, local discovery, and measurable search uplift into one Next.js and Vercel delivery.

    View case study
  2. Screenshot of the John Lewis website; part of John Kavanagh's selected project work.

    The Optimisation and Rebrand of johnlewis.com

    On John Lewis, frontend optimisation work on a hightraffic retail platform had to protect searchvisible commercial pages while the brand changed.

    View case study