Say Hello

MIGRATING
JS → SSR.

AI bots do not render JavaScript (article N. 08). If your site is CSR-only, AI visibility requires a migration. Three paths - full SSR rewrite, hybrid prerender, service-worker prerender - with cost/benefit per path and decision criteria.

Migration Paths
3
Cost Range
Wide
Citation Impact
Major
Timeline
Months

WHY THIS DECISION MATTERS.

Article N. 08 covers the data: AI bots do not execute JavaScript at meaningful rates. Pages whose content is rendered client-side return empty HTML to the bot, which means zero extraction, which means zero citation potential. The architecture decision compounds across every page on the site.

If your site is built on Create-React-App, Vite-React without SSR, pure Vue SPA, pure Angular SPA, or any other CSR-only framework, you are operating with a hard ceiling on AI visibility. The question is whether to migrate, and if so, by which path.

Finding 01.
Path 01

FULL SSR REWRITE.

What it is: rebuild the site on a framework that produces server-rendered HTML. Next.js, Remix, Astro, Eleventy, plain HTML.

Cost: high. Engineering hours range from weeks (small marketing site) to months (complex application). Plus designer / QA time.

Benefit: complete. Every page becomes AI-visible by default. Performance, SEO, and accessibility usually improve simultaneously.

When it is right: when AI visibility is core to the business model (content publishers, services with citation-driven discovery, SaaS marketing sites where the public-facing site is separate from the application). When the existing CSR codebase is older than 3 years and overdue for refactor anyway.

Finding 02.
Path 02

HYBRID PRERENDER.

What it is: keep the SPA for application functionality, prerender critical content pages at build time. Tools: react-snap, Vite's SSG plugins, Astro's island architecture, Next.js's static export.

Cost: medium. Days to weeks of engineering. The hard part is identifying which pages benefit from prerendering and ensuring the prerender output stays in sync with the SPA's runtime data.

Benefit: partial. Prerendered pages become AI-visible; pages that stay client-side stay invisible. Right when only public marketing/content pages need citation visibility and the application area is appropriately app-shaped (dashboards, tools, account pages).

When it is right: SaaS apps with a public marketing/blog site that should be cited and a logged-in product area that does not need to be. Most B2B SaaS falls here.

Finding 03.
Path 03

SERVICE-WORKER PRERENDER.

What it is: services like Prerender.io, Rendertron, or a custom Puppeteer-based service that detects bot user-agents and serves pre-rendered HTML to them while serving the SPA to humans.

Cost: low engineering, ongoing service cost ($50-$500/month depending on traffic). No code changes beyond a server-side hook to route bot traffic.

Benefit: weakest of the three. Depends on accurate bot detection (some bots fail it). Prerender service can become a single point of failure. Some AI surfaces are stricter about cloaking-style behaviours.

When it is right: legacy sites that cannot be migrated for organisational reasons. The interim fix while a full SSR migration is planned. Not a permanent solution.

WHEN NOT TO MIGRATE.

Some sites are correctly CSR-only and should stay that way:

DECISION CHECKLIST.

Apply in order:

THE BOTTOM LINE.

JS-only architecture is a hard ceiling on AI visibility. The migration is unavoidable if AI visibility matters to the business; the question is timing and path. Three paths with clear cost/benefit; pick once, execute thoroughly. Half-migrating - prerendering some pages and not others without a plan - is the worst of all options.

Stop Guessing What AI Sees

MEASURE THE LEVERS
THAT ACTUALLY EXIST.

If you want this methodology applied to your specific site - your real logs, your real citation data, your real fix list - the audit is the productized way to do it.