Single-page applications route between views without a full page reload, updating the URL and swapping content entirely through JavaScript. It's a good pattern for interactive apps, and it's also one of the more reliable ways to accidentally make large parts of a site invisible to search engines, because the entire concept of "a URL that returns content" gets more fragile than it looks.
The problem isn't client-side routing as a concept. It's a handful of specific implementation choices that assume every visitor, crawlers included, will always arrive at the root of the app and navigate from there.
The Core Assumption That Breaks
Client-side routing typically works by intercepting navigation, updating the browser's URL via the History API, and rendering the matching view entirely in JavaScript, without a new request to the server. That's fine when a user clicks a link from within the already-loaded app. It becomes a problem the moment something, a crawler, a shared link, a bookmark, requests one of those routes directly.
If the server doesn't know how to respond to a direct request for /products/some-item with meaningful content, and instead serves the same generic shell it serves for every route, a crawler arriving at that URL cold gets nothing useful before JavaScript has a chance to run and correct the mismatch.
Where This Shows Up in Practice
The most common failure is a server configuration that serves the same static shell for every route, relying entirely on client-side JavaScript to read the URL and render the correct view after the fact. If a crawler's rendering pass completes before that client-side redirect and content swap finishes, or fails to trigger it at all, the crawler indexes the generic shell instead of the actual page content.
A related pattern shows up with routes that depend on data fetched after the initial render, where the route itself resolves, but the content within it doesn't exist until a subsequent API call completes. If that call is slow, fails silently, or depends on browser-only state like local storage, the rendered version can end up just as empty as the pre-render shell.
Redirect logic implemented entirely in JavaScript compounds this further. A route that exists only to immediately redirect somewhere else, using client-side navigation rather than an HTTP redirect, requires a crawler to execute that logic correctly to ever reach the destination content, and adds a failure point that a server-level redirect simply wouldn't have.
How to Confirm Whether This Is Actually Happening
The most direct check is requesting a specific route's URL cold, without navigating from within the app first, and inspecting what the server actually returns before any JavaScript executes. If that response is a generic, content-less shell regardless of which route was requested, the site is fully dependent on client-side rendering succeeding for every single route to have any indexed content at all.
Comparing that raw response against what Google Search Central's URL Inspection tool shows as the fully rendered version for the same URL tells you whether Google's renderer is successfully bridging that gap or not. A significant difference between the two, especially on routes with unique, valuable content, is worth treating as a priority fix rather than a curiosity.
Fixing It Without Rewriting the Whole App
The most complete fix is moving to a framework that supports server-side rendering or static generation for individual routes, so each URL returns meaningful content directly from the server rather than relying entirely on client-side JavaScript to construct it after the fact. Frameworks built on top of React, including meta-frameworks like Next.js, support this per-route rather than requiring an all-or-nothing migration, which makes a gradual transition realistic for an existing app.
Where a full framework change isn't feasible in the short term, ensuring that redirects happen at the server or edge level, rather than purely in client-side JavaScript, removes one of the more fragile failure points without touching the rest of the routing architecture. Prioritizing server-rendering for the specific routes that carry the most search-driven traffic, rather than attempting to convert the entire app at once, is usually the more realistic path.
"Teams treat JavaScript rendering as a browser problem, but Googlebot's renderer is really a second, slower browser with its own queue and its own budget. If you're not regularly checking what it actually sees, you're optimizing for a version of your site that doesn't exist in the index." - Dennis Traina, founder of 137Foundry
A Common Edge Case: Hash-Based Routes and Sitemaps
An older but still surprisingly common pattern uses hash fragments, a URL like /#/products/item, to represent different views within a single-page app. Search engines have generally treated the portion of a URL after a hash fragment as not part of the request sent to the server, which means two URLs that differ only after the hash can be treated as the same page rather than two distinct, individually indexable routes.
Sites still running this pattern often see it interact badly with sitemaps, since a sitemap listing hash-based URLs is asking a crawler to treat fragments as if they were real, separate paths, which doesn't reliably hold. Moving to real path-based routing using the History API resolves this cleanly and is usually a smaller change than it sounds, since most routing libraries support both modes and switching is often a configuration change rather than a rewrite of the routing logic itself.
It's worth auditing an existing sitemap specifically for hash-based entries if a site has any history of using this pattern, since a stale sitemap referencing routes that no longer resolve the way it assumes can quietly waste crawl budget on URLs that were never fully indexable in the first place.
What This Means for Internal Linking Too
Client-side routing issues don't just affect whether a crawler can reach content directly, they also affect how link equity flows through internal links built entirely with client-side navigation. If an internal link is implemented purely as a JavaScript click handler rather than a real anchor tag with an href pointing at the destination URL, a crawler that doesn't execute that handler correctly never discovers the link at all, regardless of how well the destination page itself renders.
This is worth checking independently of the routing issue described above, since a site can fix its route-level rendering while still burying internal links behind non-standard navigation patterns that a crawler can't follow. Using real anchor tags for internal navigation, even within a framework that intercepts the click for a smoother client-side transition, keeps both users and crawlers able to reach the same destinations through the same underlying markup.
Testing the Fix
After making changes, the same cold-request test from earlier is the fastest way to confirm progress: request a specific, previously-empty route directly and check whether the server response now contains real content rather than a generic shell. Following up with a Search Console URL Inspection live test on the same route confirms Google's own renderer agrees with what you're seeing locally.
Wikipedia's overview of web crawling is a useful refresher on how automated crawling fundamentally differs from a real user's browsing session, which is the underlying reason client-side-only routing causes problems that don't show up in normal QA testing. For the fuller diagnostic process behind catching rendering gaps generally, this guide on JavaScript rendering and SEO covers the tools and signals in more depth than a single post can.
Client-side routing and search visibility aren't fundamentally incompatible. They only conflict when every route depends entirely on JavaScript succeeding perfectly, with no server-level fallback for the moment something arrives at that URL cold. https://137foundry.com
Top comments (0)