A URL is the unit of indexing
Search engines index URLs. If two views share a URL, they cannot rank separately. If a view has no URL that works on direct request, it cannot be indexed at all.
Client-side routing makes both mistakes easy. The router can change the visible view without producing an address that survives being requested from outside the running application.
Routing requirements for indexable views
- Every indexable view has its own distinct URL
- That URL returns the correct content on a direct server request
- Missing content returns a genuine 404, not a 200 shell
- Redirects are handled server-side with proper status codes
- One canonical URL per piece of content, with variants consolidated
- Links between views are real anchors with resolvable destinations
- Query parameters that change content are handled deliberately
- Trailing-slash and casing variants resolve consistently
Soft 200s are the most common routing defect
When a client-side router receives a URL it doesn't recognize, the server has usually already responded 200 with the app shell. The app then displays a not-found screen, but the status code says the page exists.
Search engines treat these as real pages until they conclude otherwise, which wastes crawl activity, creates thin duplicate URLs and can obscure genuine coverage problems in reporting.
Fixing routing is usually cheap
Compared with changing rendering strategy, routing fixes tend to be small and contained: correct status codes for unknown paths, real anchors for navigation, consistent canonical URLs, and server-side handling of redirects.
They are also high leverage, because routing determines whether the rest of your SEO work has an address to accumulate against.