JavaScript SEO from a consultant who builds in Next.js.
I'm Miroslav Planansky. A lot of JavaScript SEO advice comes from people who have never shipped a React app. I handle technical SEO for Flashscore's betting section across 20+ markets, and the site you're reading is Next.js I wrote myself. Remote, CET.
On this page
The discipline
What is JavaScript SEO?
JavaScript SEO makes sure search engines can crawl, render and index sites built with JavaScript frameworks like React, Next.js and Vue. It's the branch of technical SEO that deals with what happens between the moment Google downloads a page and the moment it understands what's on it.
On a classic HTML site, the content arrives from the server finished. Google sees it immediately in the source code. A JavaScript site adds an extra step: part of the content only exists after the browser executes JavaScript.
That rendering step is where SEO breaks most often. When key text, links or metadata are generated client-side, Google may process them late or miss them entirely. The site looks fine to every visitor while the index sees a different, thinner page.
How it works
How does Google render JavaScript?
Google processes the raw HTML first, queues the page for rendering, and executes the JavaScript later, when rendering capacity allows. Rendering is a deferred phase and can take seconds or longer, so critical content should not depend on a fragile client-side path.
Crawl: HTML first
Googlebot downloads the HTML and immediately processes what's in it: text, links, metadata. Anything missing from the HTML doesn't exist at this stage.
Queue: waiting for render
Pages with a 200 response move into the render queue, unless a robots meta tag or header already excludes them from indexing. The delay isn't fixed, which adds another dependency before client-rendered content gets processed.
Render: JavaScript runs
Google renders the page in a headless Chromium, executes the JavaScript, and only now sees the content that was built client-side.
Executing JavaScript adds work after crawling. The more a site relies on client-side rendering, the more ways network requests, blocked resources or runtime errors can prevent the final content from being processed.
The risk grows on sites with many templates, products or frequent updates, because the same rendering dependency repeats at scale. The practical rule is simple: place important, indexable content and links in the initial HTML when the framework allows it.
Rendering strategy
SSR vs SSG vs ISR vs CSR: which one for SEO?
The safest option for SEO is content that's finished in the HTML on load, which means SSR, SSG or ISR; pure CSR, where the page arrives nearly empty and JavaScript builds it in the browser, is the riskiest for indexation. The right choice mostly comes down to how often the content changes.
SSRServer-side rendering
HTML is generated on the server for every request.
When to choose: Content that changes often or needs personalization. Safe for indexation since the content is in the HTML immediately.
SSGStatic site generation
HTML is pre-generated once at build time and served as a static file.
When to choose: Content that rarely changes. Usually the fastest option, and it keeps indexable content in the initial HTML.
ISRIncremental static regeneration
A Next.js approach that regenerates static pages in the background after a set interval.
When to choose: Large sites with regular updates. Combines static speed with freshness.
CSRClient-side rendering
The HTML arrives nearly empty and JavaScript builds the content in the browser.
When to choose: Riskiest for public, indexable content, since Google only sees it after rendering. Often appropriate for logged-in app views instead.
| Method | How it works | When to choose |
|---|---|---|
| SSRServer-side rendering | HTML is generated on the server for every request. | Content that changes often or needs personalization. Safe for indexation since the content is in the HTML immediately. |
| SSGStatic site generation | HTML is pre-generated once at build time and served as a static file. | Content that rarely changes. Usually the fastest option, and it keeps indexable content in the initial HTML. |
| ISRIncremental static regeneration | A Next.js approach that regenerates static pages in the background after a set interval. | Large sites with regular updates. Combines static speed with freshness. |
| CSRClient-side rendering | The HTML arrives nearly empty and JavaScript builds the content in the browser. | Riskiest for public, indexable content, since Google only sees it after rendering. Often appropriate for logged-in app views instead. |
React & Next.js
What does SEO for React and Next.js involve?
React SEO comes down to one question: does the crawler get finished HTML, or a bundle of JavaScript it has to assemble first? A plain React SPA gives it the bundle. Next.js exists largely to give it the HTML, but only when the rendering features are used correctly.
The App Router renders Server Components to HTML by default and its metadata API generates titles, descriptions and canonicals server-side, so they're in the document on load. That covers the basics, and it's also where teams stop too early. The failure points sit deeper.
Hydration mismatches
The server HTML and what React builds on the client drift apart. React patches the DOM, and Google can end up indexing something different from what users see.
Soft 404s from client-side routing
The router catches a non-existent URL and shows an error view, but the server already answered 200. Google usually flags these as soft 404s and leaves them unindexed, but keeps recrawling and wasting budget on them.
Browser-only content paths
Content loaded only in effects, after interaction or through browser-only APIs may be absent from the server response. The page works for users, but crawlers depend on a successful render.
Metadata set after load
Titles or canonicals updated only on the client are still picked up after Google renders the page, but a mismatch with the initial HTML makes it unpredictable which version gets used. Next.js metadata APIs keep them in the server response, so there's nothing to reconcile.
A working example is one tab away: this site is Next.js App Router, statically generated, with metadata, structured data and hreflang handled server-side. View source and everything that matters is in the HTML.
From audits
Common JavaScript SEO failures I see in audits
The recurring failures are links without a real <a href>, content that only appears after interaction, metadata set client-side, and pages answering 200 where they should answer 404. None of them are visible by looking at the site. They show up in the index.
Links as onClick handlers
Navigation wired through JavaScript without an href attribute. Google doesn't reliably follow these, so whole sections of the site can go undiscovered.
Content only after interaction
Products or text loaded after a scroll, click or tab switch. The crawler doesn't click or scroll during rendering, so pagination-free infinite scroll hides everything past the first batch — though lazy-loading wired correctly through IntersectionObserver still fires and gets seen.
Soft 404s
Non-existent URLs returning 200 with an empty or error view instead of a real 404 status. Google may flag such a page as a soft 404 and leave it unindexed, or index the empty version by mistake. In both cases it keeps crawling the URL and wasting budget on it.
Client-only metadata and canonicals
Titles, descriptions or canonicals added only after client-side execution are still read once Google renders the page, but a mismatch with the raw HTML makes the outcome unpredictable. Server-rendered metadata avoids the gap entirely.
Blocked JavaScript resources
Scripts or API endpoints the render depends on disallowed in robots.txt. The render comes back broken, and what Google indexes is the broken version.
Fragile structured data injection
Google can process JavaScript-generated structured data, but runtime errors or delayed API responses can still break it. Server output is easier to test and monitor.
The common denominator: what Google sees differs from what users see. Every check in my audit reduces to closing that gap.
Method
How I audit a JavaScript site
The core of a JavaScript SEO audit is comparing what the server sends with what Google renders, then tracing every difference to its cause in the code. Four lines of evidence, cross-checked against each other.
Raw vs rendered HTML diff
I compare the server response with the rendered DOM for each key template. Content, links and metadata that only exist after rendering are the audit's primary suspects.
Search Console URL inspection
The live URL test shows the page as Google renders it: the final HTML, blocked resources and indexation status. Ground truth for what the index actually holds.
Screaming Frog with JS rendering
A full crawl in JavaScript rendering mode, raw and rendered side by side, across the whole site. It turns single-page findings into site-wide patterns per template.
Log file analysis
Server logs show where Googlebot really spends its crawl: which templates it hits, how often, and what status codes it gets back. Often far from what the team expects.
The deliverable is a developer brief ranked by impact: what to change, where, why it matters and how to verify it shipped. Tickets your team can paste into Jira, written by someone who works in the same framework they do.
Pricing
How much does a JavaScript SEO audit cost?
A JavaScript SEO audit starts at €900 and scales with site size and the number of templates. Pricing is public on purpose: you should know the cost before we ever get on a call.
JavaScript SEO audit
from €900
one-off · scales with site size
Rendering strategy, indexation, internal linking, metadata and Core Web Vitals for your specific stack. Output: a developer brief ranked by impact.
Consulting
from €100
/ hour
Rendering decisions, framework migrations, second opinions on dev plans. No mandatory package; I review your site before the call.
Enterprise advisory
€150+
/ hour
For in-house SEO and dev teams that need a senior outside view on JavaScript rendering at scale. Workshops and knowledge transfer.
I quote the final price after the free 15-minute intro call, once I've seen the site. For engagements beyond the JavaScript layer, see SEO consulting.
Why me
Why JavaScript SEO with me
I approach JavaScript SEO as someone who develops in Next.js, so I understand both the rendering and how search engines read it. The recommendations come from building and operating sites, backed by 8+ years in marketing and 6+ years in SEO and brand.
Next.js is my main stack
This site runs on it and I wrote it. Rendering strategy, metadata generation, sitemaps and canonicals are decisions I make in code, in the same files your developers work in.
Livesport & Flashscore
I am responsible for technical SEO of Flashscore's betting section across 20+ markets. Rendering and indexation issues at that scale can multiply across countries.
Own tooling in Python
For repetitive technical work, like redirect mapping during migrations, I use my own Python scripts, including a Python + BERT redirect mapper. Faster and more precise than manual work.
Common questions
7 questions
01Does Google execute JavaScript?+
Yes. Googlebot renders pages in a Chromium-based Web Rendering Service and executes JavaScript. Rendering is a deferred phase, so client-only content depends on scripts, network requests and runtime code succeeding. Important content, links and metadata are more robust when they are present in the initial HTML.
02Is Next.js good for SEO?+
Yes, when the rendering strategy matches the content. SSR, SSG and ISR all ship finished HTML to the crawler, and the App Router's metadata API generates titles, descriptions and canonicals server-side. The framework doesn't make a site rank by itself, but it removes the structural obstacles a pure client-side React app has. This site runs on Next.js App Router and I built it myself.
03Does client-side rendering hurt rankings?+
There is no blanket penalty for CSR. The trade-off is reliability: content built in the browser adds rendering, network and runtime dependencies before it can be processed. For pages that need to rank, placing important content in the initial HTML is usually more robust. CSR remains a natural fit for many logged-in application views.
04Do I need SSR for everything?+
No. SSR earns its server cost on pages that change often or are personalized. Content that changes rarely is better served as SSG, and large sites with regular updates fit ISR, which regenerates static pages in the background. The deciding question is how often the content changes and whether the page needs to rank at all.
05Can a React SPA be fixed for SEO without a full rebuild?+
Usually yes, in stages. The typical sequence: real <a href> links instead of onClick handlers, server-side metadata and canonicals, correct 404 status codes, then prerendering or SSR for the templates that matter for search. A framework migration can come later if it's justified. I scope the order in the audit so your developers fix the highest-impact gaps first.
06How much does a JavaScript SEO audit cost?+
A JavaScript SEO audit starts at €900 and scales with site size and the number of templates. Consulting runs from €100 per hour, and enterprise advisory for in-house teams starts at €150 per hour. The 15-minute intro call is free, and I quote the final price after it, once I've seen the site.
07How do you work with our development team?+
I write findings as tickets: what to change, where, why it matters and how to verify the fix shipped. Your team can paste them into Jira or Linear as they are. Because I build in Next.js myself, the briefs respect how the framework actually works, and I stay available async during implementation. Remote, English-speaking, CET.
Close the rendering gap
Find out what Google actually sees on your JavaScript site.
In 15 minutes I'll look at your site, tell you whether a JavaScript SEO audit makes sense and what it would focus on. The call is free, no commitment.
Book a consultationmarketing@mipaco.cz