A Technical SEO Checklist for Sites That Render in JavaScript
The specific places a client-rendered app goes wrong for search engines and social scrapers — gathered from fixing them, not from a generic best-practices list.
A server-rendered site mostly gets correctness for free. A client-rendered one has to earn every one of these — because the default state a crawler meets, before any JavaScript has run, is an empty page. This is the list we actually check, built from fixing each item after it went wrong first.
Verify with the right identity, not your own browser
A plain request to the site tells you almost nothing if crawlers and normal visitors are served differently — which, on a prerendered site, they are by design. Check with the actual crawler user agent, and check the ones people forget: Google's ad-quality crawler and Bing's are both real, both distinct from the main indexing bot, and neither contains the substring most bot-detection code is written to match.
Confirm the sitemap describes reality, not the plan for it
- Every URL in the sitemap actually resolves — checked with a real request, not assumed from the route table
- The file is regenerated on a schedule, or on every publish — a sitemap that was correct on launch day and never touched again is a liability with a delay timer on it
- A generator that writes a sitemap should refuse to write anything if its own self-check fails, rather than overwrite a good file with a broken one
Assume the fallback has not really been tested
Fallback logic almost always gets tested against the failure that is easiest to simulate — the backend being completely down. The failure that reaches production is usually the other kind: something responds, just not with what was expected. Test that path specifically, not just "unplug it and see".
Distrust anything that looks cached
If a fix does not appear to be live, check every caching layer between the origin and the browser individually — a CDN, a reverse proxy, a disk-level render cache, and, on a site with a Service Worker, the browser's own cache are four different systems that can each independently decide to serve something stale, and clearing one says nothing about the other three.
Give every distinct piece of content its own identity
- A canonical tag that actually points at itself, not at the homepage by accident
- Open Graph tags built per page, not inherited wholesale from a static shell meant only for the loading state
- A noindex meta tag that means "not ready yet", never confused in code with "does not exist" — a thin page and a missing one need different HTTP behaviour
None of this is exotic. It is the list of specific ways a client-rendered site quietly disagrees with what search engines and social scrapers see — checked directly, once, rather than assumed correct because the site looks fine in a browser.
Have something like this to fix?
Describe the problem and we will tell you what it takes.
Get in touchAll posts