JavaScript SEO is one of the most common sources of organic traffic losses that teams discover late. A site built with React, Vue, or Angular - including Next.js apps using client-side data fetching - can appear perfect in a browser while being partially or completely invisible to Googlebot. The reason is how crawlers handle JavaScript: differently from how browsers do, and with meaningful delays and resource constraints that create a persistent gap between "what a user sees" and "what Google indexes."

Ravve Jay Prevendido at Through The Glass Creatives has rebuilt and audited the SEO architecture of multiple JavaScript-heavy sites, including several Next.js applications in TTGC's own client portfolio. The failure patterns are consistent and preventable - but only if the engineering and SEO teams are coordinating on rendering strategy from the beginning of a build, not after the fact.

How Googlebot handles JavaScript

Googlebot crawls and renders pages in two waves. The first wave happens immediately at crawl time - Googlebot fetches the raw HTML. The second wave - JavaScript rendering - happens asynchronously, often hours to days later, when Googlebot's rendering queue processes the page with a headless Chromium instance. Any content that requires JavaScript to display is not indexed until the second wave completes. If your critical SEO content (headings, body text, structured data, internal links) is injected by JavaScript, it may not be indexed for days - or may never be indexed if rendering fails.

The three rendering models and their SEO implications

Common Next.js SEO pitfalls

Next.js offers SSR and SSG by default, but it is easy to accidentally introduce client-side rendering patterns that undermine this. The most common pitfalls: using `useEffect` to fetch and render critical content (invisible to first-wave crawlers); dynamic imports without SSR (`{ ssr: false }`); client-side routing that generates new content without the page being crawled as a separate URL; and `getStaticProps` returning stale data because revalidation intervals are too long. Each of these requires a specific fix - and each requires awareness of how Googlebot's rendering pipeline works.

The most common JavaScript SEO failure is not ignorance of the problem - it's that the developer who built the feature and the SEO who needs the content indexed work in different tickets and never compared notes.

How to audit JavaScript SEO

The practical audit: (1) use Google Search Console's URL Inspection tool to fetch and render any suspect page - compare the raw HTML vs. the rendered HTML; (2) check Google's "crawled - currently not indexed" and "indexed, though blocked by robots.txt" reports for patterns; (3) use the Mobile-Friendly Test to see Googlebot's rendered view; (4) run a Screaming Frog crawl with JavaScript rendering enabled and compare the crawl counts with and without JS. Any significant discrepancy in content between the two crawls is a flag. For a complementary technical SEO diagnostic, read log file analysis seo.

The fix: prefer SSR and SSG for content that matters for SEO

The architectural principle for JavaScript SEO: any content that you want indexed must be present in the server-rendered HTML before JavaScript executes. In Next.js, this means using `getServerSideProps` or `getStaticProps` for content fetching rather than `useEffect`. For dynamic or personalised content that cannot be SSR'd, use a hybrid approach: render the structural content server-side and enhance it client-side. What should never be client-side only: page headings, body text, internal links, meta tags, and structured data.