JavaScript SEO
I make sure Google and AI bots see the content of your JavaScript site the way users do. At Flashscore I removed duplicate components in the SSR HTML that Googlebot read as duplicate content.
Common JavaScript SEO failures
The most common failures on JavaScript sites are client-side links without a real <a href>, content that only appears after interaction, metadata missing from the HTML, and pages that answer 200 instead of 404 for URLs that don't exist. You won't spot most of them by looking at the site. They show up in the index.
Hydration mismatch
The server HTML and what JavaScript builds on the client drift apart. React overwrites the content and the render result gets unpredictable. The version that reaches the index may not be the one you tested.
Links without a real <a href>
Navigation wired through onClick or JavaScript with no href attribute. Google doesn't follow these reliably, so it may never reach the pages they point to.
Content that loads only after interaction
Text or products that appear only after a scroll or a click. The crawler doesn't click or scroll while rendering, so it won't see them. Content lazy-loaded correctly through IntersectionObserver does get loaded.
Soft 404
A URL that doesn't exist returns status 200 and an empty or error page instead of a real 404. Google either flags it as a soft 404 and skips indexing, or indexes the empty page by mistake. Either way, it wastes crawl budget.
Missing SSR metadata and canonical
The title, description or canonical only get set by JavaScript on the client. Google picks them up after rendering, and if they differ from the values in the HTML, it may work with a different version than you expect.
A sample technical brief
If you're technical, you want to see an actual brief. The one below is a real finding from an audit of my own site. You can verify every criterion with curl.
Sample finding from my own site, audit 2026-09-05
- Initial state
- The old address /sluzby/seo-audit/ reaches /seo-audit through two 308 hops. The apex domain mipaco.cz returns a temporary 307 to www.
- Evidence
- curl -I, HTTP responses saved in crawl.json, 2026-09-05.
- Decision
- Low priority, low effort: fix in one iteration alongside the contact form. No need to wait for a larger release.
- Developer ticket
- Vercel Domains: switch the mipaco.cz → www.mipaco.cz redirect to a 308 Permanent.
- next.config.ts: checked skipTrailingSlashRedirect; a test run showed a 404 on /sluzby/seo-audit/, so the change was reverted – the two-hop chain was accepted and documented instead.
- Acceptance criteria
- curl -I https://mipaco.cz/ returns 308 with Location: https://www.mipaco.cz/
- curl -IL https://www.mipaco.cz/sluzby/seo-audit/ ends in 200 on /seo-audit in at most two 308 hops
- No other URL from sitemap.xml changed status code (compared against crawl.json).
- Deployment check
- After deployment I re-run curl on both addresses and compare the status of all sitemap URLs against the audit inventory.
Why do JavaScript SEO with me
I approach JavaScript SEO as someone who builds in Next.js, so I understand the rendering and how search engines read it. My recommendations come from hands-on implementation and from running sites in production.
Next.js is my main stack
This site runs on Next.js. I choose the rendering method and handle metadata generation, sitemaps and canonicals directly in the code.
Livesport and Flashscore
In the Betting Content Section I handle content and technical SEO across 25+ markets. Indexing and rendering at a scale where every bug multiplies.
My own Python tooling
For repetitive technical jobs like mapping redirects in a migration, I use my own Python scripts. Automation speeds up the processing and leaves more time for checking the risks.
Testimonials
5.0 / Google ★★★★★ See the reviews on Google
★★★★★
"Thoroughness, quick responses and a passion for the work. Those are the qualities you want. I've really enjoyed working with Mira, and I still do. Recommended."
Patrik Pilous
Freelance consultant
01 / 04
JavaScript SEO audit
The single-area diagnostic costs from €1,200 per project. I go through rendering strategy, indexing, internal linking, metadata and Core Web Vitals for your specific JavaScript stack, and write a dev brief with acceptance criteria and a validation after deployment. The final quote depends on site size, the number of templates and technical complexity. I confirm the price once I've seen the site.
Rendering strategy
How content gets into the HTML, whether SSR, SSG, ISR or CSR is the right fit, and where the site leans on client rendering for no good reason.
Indexing and linking
What Google actually sees after rendering, whether it follows the links, and whether the key pages make it into the index.
Metadata and canonical
Title, description, canonical and structured data in the HTML on load, before any JavaScript runs.
Performance and Core Web Vitals
LCP, INP and CLS, JavaScript size and loading, and how rendering affects speed on mobile and desktop.
Not sure Google sees your JavaScript content?
from €1,200 per projectI set the scope and deliverables with you. Start with the intro consultation (€240).
What JavaScript SEO is and why JS sites run into trouble
JavaScript SEO makes sure search engines crawl, render and index sites built with JavaScript frameworks like React, Next.js and Vue. It's the part of technical SEO that deals with what happens between Google downloading a page and Google processing it.
On a classic HTML site the content arrives from the server finished. Google sees it straight away in the source and has nothing to compute. A JavaScript site has an extra step: part of the content only exists after the browser runs the JavaScript.
That step is where a lot of problems start. When key text, links or metadata depend on a broken client-side implementation, they can be missing from the rendered HTML or reach the index late.
How Google renders JavaScript
Google first downloads the HTML, processes the content and links already in it, and puts pages that return 200 into the render queue. The Web Rendering Service then runs the JavaScript in Chromium and passes the rendered HTML back for processing. The wait in the queue can be a few seconds or longer.
- 1
Fetching and processing the HTML
Google downloads the HTML and processes what's already in it: text, links and metadata. It only sees JavaScript-generated content after rendering.
- 2
The render queue
Pages that return 200 go into the render queue, unless a robots meta tag or header excludes them from indexing. The wait isn't fixed, and for some URLs it can be longer than a few seconds.
- 3
Running the JavaScript
Google renders the page in headless Chromium, runs the JavaScript and only now sees the content that was built on the client.
Google does run JavaScript. For important public content, server or static rendering is still the safer choice. It gets the content to users and crawlers faster and doesn't depend on the JavaScript running flawlessly on the client.
On a small site, client rendering may never cause a visible problem. On an e-shop with thousands of products, or a site that changes often, it raises the bar for testing, monitoring and correct resource loading.
SSR vs SSG vs ISR vs CSR: which to pick
For SEO the safest setup has the content 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 indexing. The right method mostly depends on how often the content changes.
| Method | How it works | When to pick it |
|---|---|---|
| SSRServer-side rendering | The HTML is generated on the server for every request. | Content that changes often or is personalized. Safe for indexing: the content is in the HTML right away. |
| SSGStatic site generation | The HTML is generated once at build time and served as a static file. | Content that rarely changes. The content exists up front and is in the HTML. You still need to verify indexing. |
| ISRIncremental static regeneration | A Next.js approach that regenerates static pages in the background after a set interval. | Large sites with regular updates. Static speed with fresh content. |
| CSRClient-side rendering | The HTML arrives almost empty and JavaScript builds the content in the browser. | The last resort for public, indexable content. More sensitive to bugs and needs more thorough checking. |
SSRServer-side rendering
The HTML is generated on the server for every request.
When to pick it: Content that changes often or is personalized. Safe for indexing: the content is in the HTML right away.
SSGStatic site generation
The HTML is generated once at build time and served as a static file.
When to pick it: Content that rarely changes. The content exists up front and is in the HTML. You still need to verify indexing.
ISRIncremental static regeneration
A Next.js approach that regenerates static pages in the background after a set interval.
When to pick it: Large sites with regular updates. Static speed with fresh content.
CSRClient-side rendering
The HTML arrives almost empty and JavaScript builds the content in the browser.
When to pick it: The last resort for public, indexable content. More sensitive to bugs and needs more thorough checking.
FAQ
What is JavaScript SEO?
JavaScript SEO is the part of technical SEO that makes sure search engines correctly crawl, render and index sites built with JavaScript (React, Next.js, Vue). On a classic HTML site the content is there straight away. On a JS site Google has to render it first, and that extra step is where most bugs appear.
Why do JavaScript sites have SEO problems?
Google first downloads the HTML and puts URLs that return 200 into the render queue. The Web Rendering Service then runs the JavaScript and processes the resulting HTML. If key content, links or metadata depend on a broken client-side implementation, they can be missing from the rendered page.
Which is better for SEO: SSR, SSG, ISR or CSR?
The safest option for SEO is content that's already in the HTML on load: SSR (server-side rendering), SSG (static site generation) or ISR (incremental static regeneration) in Next.js. Pure CSR (client-side rendering) is the riskiest for indexing. The right choice depends on how often the content changes.
How do I check whether Google sees my JavaScript content?
Compare the source HTML from the server with the rendered DOM, and run the live URL test in Google Search Console. Check that the rendered HTML contains the key text, links, metadata and structured data. A difference between source and DOM isn't a bug by itself. What counts is the final content.
Do you do JavaScript SEO audits?
Yes, as a single-area diagnostic for from €1,200 per project. I go through rendering strategy, indexing, internal linking, metadata and Core Web Vitals for your specific JavaScript stack. You get a dev brief with acceptance criteria and a validation after deployment.
Do you work with Next.js directly?
Yes. Next.js is my main stack and this site runs on it. I handle the rendering method, metadata generation, sitemaps, canonical URLs and performance directly in the code, so my recommendations come from hands-on implementation.
Tell me what you need to solve
Tell me what you are working on and what you want to achieve. I propose the next step and a scope of work. We agree on the price before starting.