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.
Free 15-minute intro call · no commitment
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, neither instant nor guaranteed to be timely, so it's not something to lean on for critical content.
01
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.
02
Queue: waiting for render
Pages that need JavaScript executed wait in a render queue. How long isn't fixed; it depends on capacity and how important Google considers the page.
03
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 for every page costs compute, and Google doesn't spend it freely. The more a site relies on client-side rendering, the longer fresh content can take to reach the index.
A small site with a handful of pages may never notice. An e-commerce site with thousands of products, or any site that changes frequently, carries real risk: new content indexes slowly, or Google works from a stale version of the page. The practical rule is simple: don't hide content you need indexed behind client-side JavaScript.
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.
SSR
Server-side rendering
HTML is generated on the server for every request. The fit for content that changes often or is personalized. Safe for indexation: the content is in the HTML immediately.
SSG
Static site generation
HTML is pre-generated once at build time and served as a static file. Ideal for content that rarely changes. The fastest option and problem-free for indexation.
ISR
Incremental static regeneration
A Next.js approach that regenerates static pages in the background after a set interval. Combines static speed with freshness. Suited to large sites with regular updates.
CSR
Client-side rendering
The HTML arrives nearly empty and JavaScript builds the content in the browser. Riskiest for indexation, since Google only sees the content after rendering. Wrong for public pages that need to rank; fine for logged-in app views.
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 keeps junk URLs in the index and wastes crawl on them.
Client components carrying content
Marking a component "use client" too high in the tree pushes content that should be server-rendered into the browser. The page works; the initial HTML thins out.
Metadata set after load
Titles or canonicals updated client-side after navigation. If they're not in the server response, there's no guarantee Google works with the right version.
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 interact with the page, so infinite scroll without paginated URLs hides everything past the first batch.
Soft 404s
Non-existent URLs returning 200 with an empty or error view instead of a real 404 status. Google keeps them in the index and spends crawl on them.
Missing server-side metadata and canonicals
Title, description or canonical set by JavaScript on the client. If they aren't in the HTML on load, Google may work with the wrong version of the page.
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.
Client-rendered structured data
Schema.org markup injected after load. It tends to be picked up inconsistently, which costs rich results the site already earned.
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 running sites, with six years in SEO and ten in marketing behind them.
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 handle technical SEO for Flashscore's betting section across 20+ markets. Rendering and indexation at a scale where every mistake multiplies 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.
FAQ
Common
questions.
7 questions
Does Google execute JavaScript?+
Yes. Googlebot renders pages in a headless Chromium and executes JavaScript. The catch is timing: rendering is a deferred second phase that sits in a queue, so content that only exists after JavaScript runs can be processed late or, on large sites, inconsistently. Critical content, links and metadata should be in the initial HTML, with JavaScript treated as enhancement rather than the delivery mechanism.
Is 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.
Does client-side rendering hurt rankings?+
There is no penalty for CSR; the problem is reliability. Content built client-side gets indexed after the render queue, which can mean late, partial or stale indexation. For pages that need to rank, the safe pattern is content in the initial HTML. For logged-in app views that shouldn't rank anyway, CSR is perfectly fine.
Do 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.
Can 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.
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. 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.
How 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 consultationplanansky.miroslav@gmail.com