A single-page app that builds every route in the browser with no server-rendered fallback can serve crawlers a near-empty shell. Each route needs real HTML on first response. SPA routes have no server-rendered equivalent. Routes that only exist client-side can be hard to crawl and index reliably.
Why does client-side routing with no ssr fallback matter for AI search?
Routes that only exist client-side can be hard to crawl and index reliably.
How do you fix it?
Provide SSR/prerendered routes with real URLs and proper status codes.
How do you find it on your site?
- Request a deep route with curl and check whether real content comes back or just an app shell.
- Test the route in URL Inspection and read the rendered result.
- Confirm each route returns its own server-rendered or pre-rendered HTML.
- Add SSR, static generation or prerendering for crawlable routes.
Which ranking and citation factors does it touch?
Routes that exist only after client-side rendering are slow and risky to index. Server-rendered routes are indexed reliably and quickly.
What is the impact?
High for affected routes. Direct (documented SPA guidance).
What is the evidence?
Use proper status codes and ensure SPA routes are crawlable/renderable. Google Search Central, Understand JavaScript SEO Basics
Frequently asked questions about client-side routing with no ssr fallback
What does "Client-side routing with no SSR fallback" mean?
SPA routes have no server-rendered equivalent.
How do you fix client-side routing with no SSR fallback?
Provide SSR/prerendered routes with real URLs and proper status codes.