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.
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.
Raw vs rendered diffs
Template-level comparison of server HTML and rendered DOM: copy, headings, links, canonicals, robots and JSON-LD.
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.
Link discoverability
Navigation, pagination, facets and infinite scroll checked for crawlable anchor tags with real hrefs — not click handlers.
Metadata & structured data
Titles, canonicals, hreflang and JSON-LD moved into the initial HTML instead of being injected late by client code.
Next.js & React
App and Pages Router, server components, generateMetadata and ISR revalidation — and SSR or prerendering paths for React SPAs.
Nuxt, Vue & Angular
Nuxt SSR and hybrid route rules, Vue Router history mode, Angular SSR and hydration — fixed the framework-native way.
Lazy loading & hydration
Content hidden behind interaction, viewport-triggered loading, hydration mismatches and the JavaScript cost of each route.
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
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.
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.
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.
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.
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.
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.
Related services
Often paired with JavaScript SEO.
Core Web Vitals Optimization
Hydration and bundle cost shape INP and LCP as much as they shape rendering.
Explore Core Web Vitals →
Technical SEO Audit
Full crawl, log and index diagnosis when rendering is one problem among several.
Explore the audit →
Schema Markup
Structured data that ships in server HTML and survives every release.
Explore schema markup →
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.