Services · Rendering & performance

If it needs JavaScript to exist, it may not exist

If a page needs JavaScript to exist, it may not exist as far as the index is concerned. Rendering is where modern catalogs lose the most search traffic, and the failure is the hardest to see, because the page looks fine in a browser. We check every template in the crawl audit, review single templates on demand, and track performance by template on the Retainer and Embedded plans.

Rendering & performance

The page you see is not the page that gets indexed

Open the page and it looks fine. View the source and the product description is not there; it arrives after hydration, from a client-side fetch, sometimes only after a click. Google will often render it anyway, but later, at a cost, and not consistently across tens of thousands of URLs.

The result can be a catalog where some product pages are indexed with their content and the rest are indexed as an empty shell, or not at all. Nothing in your CMS tells the two groups apart.

We compare the raw HTML against the rendered DOM for every template and find exactly which ones fall on the wrong side of that line, and why.

What the work is

Rendering & performance, in four parts.

01

Render-path review

Raw HTML compared against the rendered DOM for every template, across a sample of real URLs rather than a single spot check. The output is a list of templates where the main content, the canonical tag, structured data or internal links exist only after JavaScript runs, with the component or request responsible. A single template can also be reviewed on its own, pay as you go, from $13.

02

SSR and ISR strategy

Which routes need server rendering, which can be generated statically or regenerated on a schedule, and which are fine rendered in the browser. Rendering everything on the server is expensive and rarely necessary; the decision belongs to each route, based on how much search demand it carries and how often its content changes. We write it up as a routing table your developers can implement with whatever your framework provides.

03

Core Web Vitals by template

We measure the template that generates the pages, not a single URL, using field data: the Chrome UX Report at the 75th percentile, grouped by template, plus your own real-user monitoring where URL-level data is thin. A green Lighthouse run on a developer's laptop says little about a shopper on a mid-range Android phone. On Retainer and Embedded, LCP, INP and CLS are tracked per template every month, so a regression can be tied to the release that caused it.

04

Edge and caching review

Cache keys, Vary headers and edge rules regularly serve crawlers the wrong version of a page, most often a geo-redirected, consent-gated or stale one. We request key templates as Googlebot and as a normal browser, compare the two responses, and trace any difference back to the rule that caused it.

What you receive
  • A per-template render report showing what exists before and after JavaScript
  • A rendering recommendation per template: server-rendered, static, or client-side
  • Field-data Core Web Vitals baselines, with a target for each template
  • A re-check after each fix ships, using the same comparison as the original review
Timeline

The render-path review is part of the two-week crawl audit. A single template review is delivered in five working days. Fixes ship on your own release schedule; on the Embedded plan we review up to four deployments a month on staging before they go live.

Who this is for

Sites built on React, Next.js, Vue, Nuxt, Angular, a headless storefront or a headless CMS, particularly in the months after a replatform, before anyone has checked what Googlebot actually receives.

What it costs

Priced on the pricing page — no quote needed to find out.

Questions

About this service.

Is our framework a problem?
No, and it is most of our work. The failures differ between the Next.js App Router and a client-only single-page app, and the fixes differ with them. What matters is which content is in the HTML response and which arrives later.
Do we have to server-render everything?
Almost never. Server-rendering the routes that carry search demand, such as product, category and article pages, and leaving accounts, carts and dashboards client-side is usually cheaper and faster to ship.
Will you work with our developers?
Yes, that is what the tickets are for. Each one names the template, the evidence and a test your developers can run themselves. On Embedded we also hold a monthly call with your engineers and review deployments before release. Your team writes and ships the code.

All questions →

Start with a crawl audit.

$160, fixed price, two weeks. Findings ranked by impact with the evidence attached, and the fee credited against your first month if you continue.

Get in touch