JS

Service 03 · Rendering

JavaScript SEO Services for Modern Frameworks

Make sure Googlebot sees the same page your users do — content, links and metadata in the HTML, not waiting in a render queue.

Our JavaScript SEO services start where most SEO consultants stop: in your build output. We compare raw server HTML with the rendered DOM template by template, trace every gap to a component, router or data-fetching decision, and work with your developers until the fix ships — on Next.js, React, Nuxt, Vue or Angular.

2–4 weeks

Framework-aware

Remote · UK & EU

render-checks.yml

RAW HTML

content, links and metadata before JavaScript runs

RENDERED DOM

what Google’s headless Chromium builds after execution

ROUTING

History API, hash URLs, status codes in SPAs

LINKS

crawlable anchors, pagination, infinite scroll

HYDRATION

SSR / ISR output, hydration errors, JavaScript cost

Sound familiar?

Signs your JavaScript is costing you rankings.

View-source shows an empty app shell and almost none of your actual copy.

New pages take weeks to get indexed, while server-rendered competitors appear in days.

Search Console flags product URLs as soft 404s or “Crawled – currently not indexed”.

Titles, canonicals or structured data look right in the browser but not in Google’s rendered HTML.

Category pages load more items on scroll, and Google only ever sees the first twelve.

Organic traffic dropped after moving to React, Next.js or a headless front end.

How Google renders JavaScript

Crawl, queue, render — and where it breaks.

Google processes JavaScript pages in two waves: it crawls and parses the raw HTML first, then places the URL in a render queue for a headless, evergreen Chromium before indexing the result.

The first wave is fast and cheap. Links present in the raw HTML are queued for crawling immediately, and signals such as the title, canonical and meta robots are read straight away. The second wave depends on Google’s rendering resources: the page waits its turn, the Web Rendering Service executes your scripts within a limited time and resource budget, and anything that depends on a click, a scroll, a blocked API or a slow third-party call may never appear. If a noindex sits in the raw HTML, the page is not rendered at all — so a script that later removes it changes nothing. And many other crawlers, including most AI crawlers, never execute JavaScript in the first place.

That is why JavaScript SEO is an engineering problem rather than a checklist. The answer is rarely “add prerendering”; it is deciding which content, links and metadata must exist in server HTML, choosing the right rendering mode per route, and keeping it that way release after release. We usually start from the crawl and index view of a technical SEO audit, and pair rendering work with Core Web Vitals optimization — the same hydration cost that delays rendering also drags down INP. Where JSON-LD is involved, it ties into our schema markup work.

What’s included

Every layer between your code and the index.

Scoped to your framework, router and hosting — and to the templates that carry organic revenue.

01

Raw vs rendered diffs

Template-level comparison of server HTML and rendered DOM: copy, headings, links, canonicals, robots and JSON-LD.

02

Routing & SPA status codes

Client-side routing checked for real URLs, History API use, hash fragments and soft 404s that return 200 instead of 404.

03

Link discoverability

Navigation, pagination, facets and infinite scroll checked for crawlable anchor tags with real hrefs — not click handlers.

04

Metadata & structured data

Titles, canonicals, hreflang and JSON-LD moved into the initial HTML instead of being injected late by client code.

05

Next.js & React

App and Pages Router, server components, generateMetadata and ISR revalidation — and SSR or prerendering paths for React SPAs.

06

Nuxt, Vue & Angular

Nuxt SSR and hybrid route rules, Vue Router history mode, Angular SSR and hydration — fixed the framework-native way.

07

Lazy loading & hydration

Content hidden behind interaction, viewport-triggered loading, hydration mismatches and the JavaScript cost of each route.

08

CI render checks

Automated tests that fail a build when the H1, links, canonical or JSON-LD disappear from server-rendered HTML.

How we work with developers

Built into your workflow, not bolted on.

Deliverables

Raw vs rendered diff for every key template

Rendering-mode recommendation per route

Tickets with code-level acceptance criteria

PR reviews on SEO-critical changes

CI render checks your team owns

Walkthrough with your front-end leads

01

Map the stack

Framework and version, router, data fetching, rendering mode, CDN and edge configuration. We read the repository or build output, not just the live site.

02

Diff raw vs rendered

Each key template is fetched as raw HTML and as rendered by headless Chromium, then checked against Search Console’s URL Inspection to confirm what Google actually indexed.

03

Fix with your team

Every gap becomes a ticket naming the component at fault, with acceptance criteria. We review the pull requests and verify the server output on staging before release.

04

Guard it in CI

Render checks run in your pipeline, so a refactor that drops the H1, internal links or canonical from server HTML fails the build instead of reaching production.

What changes

Your developers keep their framework and their velocity. Google gets complete HTML on every route that matters, and you stop discovering rendering regressions in Search Console weeks after release.

Sample output

A render diff, template by template.

The core of every engagement: what exists in server HTML versus what only appears after JavaScript runs — and which gaps cost you indexing.

render-diff · /category/shoes · illustrative

SIGNAL

RAW HTML

RENDERED DOM

Title tag

✓ present

✓ present

H1 heading

✗ missing

✓ present

Product links

0 links

48 links

Canonical

✓ present

✓ present

JSON-LD

✗ missing

✓ present

3 gaps · 5 signals shown

→ fix: server-render H1, links & JSON-LD

Rendering strategies, compared for SEO

Most modern frameworks let you choose per route. The right mix depends on how often content changes and whether the page needs to rank.

rendering-strategies · comparison

STRATEGY

HOW THE HTML IS PRODUCED

SEO SAFETY

BEST FOR

CSR

Server sends a near-empty shell; the browser builds the page from the JavaScript bundle.

Risky

Logged-in apps, dashboards

SSR

Server renders full HTML on each request; the client hydrates it for interactivity.

Safe

Personalised, fast-changing pages

SSG

HTML is built once at deploy time and served straight from the CDN.

Safe

Docs, marketing, editorial

ISR

Static HTML regenerated in the background on a timer or on demand.

Safe

Large catalogues, listings

Dynamic

Bots receive prerendered HTML while users get the client-rendered app.

Stopgap

Legacy SPAs, short term only

Who it’s for

Teams who need JavaScript SEO.

SINGLE-PAGE APPS

React & Vue SPAs

Client-rendered apps that rank poorly because Google sees an empty shell — or sees the content days late.

FRAMEWORK TEAMS

Next.js, Nuxt & Angular builds

Teams already on SSR who need the output verified and rendering choices kept SEO-safe as the codebase grows.

REPLATFORMING

Moving to a JS front end

Going headless or rebuilding in a framework? Bring us in before launch. See website migration SEO.

Investment

Fixed scope, quoted upfront.

Scope depends on the number of templates, frameworks and environments involved. After a 30-minute call with you and a developer, you’ll receive a fixed quote — review only, or review plus implementation support.

Get a fixed quote →

FAQ

JavaScript SEO questions.

Anything else? Ask us directly — we reply within two working days.

Can Google index JavaScript websites?

Yes. Googlebot renders pages with an up-to-date version of Chromium, so client-side content can be indexed. The risk is in the details: rendering happens after crawling and can be delayed, scripts that time out, wait for user interaction or call blocked APIs leave content out, and many other search engines and AI crawlers don’t execute JavaScript at all. Server-rendered HTML for critical content removes that uncertainty.

Is SSR always better than client-side rendering for SEO?

For pages you want to rank, server-side rendering or static generation is the safer default because content, links and metadata arrive in the first response. Client-side rendering is fine for logged-in areas and app-like screens that don’t need to be indexed. Most modern frameworks let you mix modes per route, which is usually the right answer.

Do you still recommend dynamic rendering?

Only as a temporary bridge. Google describes dynamic rendering as a workaround rather than a long-term solution, and maintaining a separate bot-facing render adds infrastructure cost and parity risk. We use it to stop losses on a legacy SPA while a proper SSR or static migration is planned.

Which frameworks do you work with?

Next.js (App and Pages Router), React SPAs built with Vite or similar tooling, Nuxt and Vue, and Angular with SSR — plus headless front ends on Shopify, WordPress and other CMSs. We work at code level, so we review your actual components, routes and build configuration rather than only the live pages.

How do you work with our developers?

Through your existing tools and rituals. Findings become tickets naming the responsible component with acceptance criteria, we review SEO-relevant pull requests, and we add automated render checks to CI so regressions are caught before release rather than in Search Console.

How can I check whether Google sees my JavaScript content?

Run the URL Inspection tool in Search Console, view the crawled page’s rendered HTML and compare it with view-source. If your main copy, internal links, canonical or structured data only appear in the rendered version — or not at all — you have a rendering dependency worth fixing.

Next step

Make your framework work for search.

Send your URL, your framework and the pages that aren’t indexing. You’ll get a scoped proposal with a fixed price within a few days.

Scroll to Top