Is JavaScript navigation without URLs ruining your site’s mobile-first indexing?

What does "navigation without URLs" mean in this context?

Navigation without URLs refers to an architecture where the user navigates the site but the URL in the browser's address bar never changes. Typically, everything happens on example.com and the content displays via overlays, modals, or JavaScript DOM changes.

This pattern is common in poorly configured Single Page Applications (SPAs) — those that do not implement the History API or URL fragments. Google sees only one page with a single initial content, and cannot access subsequent "states" that require JavaScript interactions.

How does mobile-first indexing exacerbate the problem?

With mobile-first indexing, Google primarily crawls and indexes the mobile version of the site. If this mobile version relies entirely on JavaScript for navigation and does not generate unique URLs, Googlebot cannot discover or index the hidden content behind these interactions.

Before mobile-first, the desktop version — often with normal URLs — served as a safety net. Now, if the mobile version is broken, all the content disappears from the index, even for desktop users. It's a point of no return.

Which architectures are specifically at risk?

At-risk architectures include SPAs without client-side routing (React, Vue, Angular without React Router, Vue Router, or Angular Router), sites with navigation via AJAX modals without URL changes, and applications that use only hash fragments (#section1, #section2) for internal navigation without a real URL.

On the other hand, a correctly implemented SPA — with Server-Side Rendering (SSR), Static Site Generation (SSG), or Dynamic Rendering — generates unique and crawlable URLs for each state. This is not an issue as long as each "page" has its own URL.

• At-risk architecture: SPA without routing, navigation via modals/overlays without URL change, hash fragments only
• Safe architecture: SPA with SSR/SSG/Dynamic Rendering, unique URLs per page, use of the History API
• Mobile-first impact: The mobile version becomes the reference — if it’s broken, the entire index is compromised
• Warning signal: If you navigate your mobile site and the URL never changes, you are likely affected

Is this statement consistent with real-world observations?

Yes, and it’s a classic. Cases of mass deindexing after switching to mobile-first related to poorly configured SPAs have been documented for years. Google has always stated that unique URLs are needed for each piece of content — nothing new in principle.

What’s changing is the irreversible impact of mobile-first. Previously, a site could manage with a crawlable desktop version and a shaky mobile version. Now, that’s over. Sites that have neglected the technical implementation of their SPA are paying the price.

What nuances should be added to this statement?

First nuance: Google executes JavaScript, but with limits. If your JavaScript navigation generates unique URLs (via History API) and the content is rendered in the initial HTML or quickly after loading, it works. The problem arises when you have to click or interact to make the content appear.

Second nuance: not all JavaScript sites are affected. A React site with Next.js in SSR or Gatsby in SSG generates crawlable URLs and pre-rendered HTML — no issues. The problem occurs only for architectures where everything stays on example.com without distinct URLs. [To verify]: Google rarely communicates about the JavaScript execution time allocated per page — hard to know exactly where the line is between "it works" and "it breaks".

What should you do if your current architecture is affected?

If you are already in production with an SPA without URLs, you have three options: complete overhaul with SSR/SSG, implementation of Dynamic Rendering (serving pre-rendered HTML to Googlebot), or migration to a hybrid architecture with unique URLs per section.

Dynamic Rendering is often a temporary fix — Google tolerates it but prefers SSR. A complete overhaul is heavy but sustainable. In any case, a prior technical audit is essential to assess the extent of the damage and prioritize risk areas.

How can you check if your site is affected by this issue?

Test manually: open your site on mobile (or in responsive mode in Chrome DevTools) and navigate through the main sections. Does the URL change with each navigation? If you’re stuck on example.com with overlays appearing, you are in the danger zone.

Next, use the Search Console: check the "Coverage" tab and look for pages with the status "Crawled, currently not indexed" or "Detected, currently not indexed". If you have hundreds matching important sections, it’s a warning signal. Complete this with a Screaming Frog crawl with JavaScript mode enabled — if the crawler finds only one URL while your site has dozens, the diagnosis is made.

What corrective actions should be prioritized?

If you are on an SPA without routing, immediately implement the History API to generate unique URLs with each content change. Each "page" or "section" must have its own URL (example.com/page1, example.com/page2, etc.).

Next, set up Server-Side Rendering or, failing that, Dynamic Rendering to serve pre-rendered HTML to Googlebot. Next.js, Nuxt.js, and Angular Universal greatly facilitate this step. If you do not have the resources for an immediate overhaul, Dynamic Rendering (via Rendertron or Prerender.io) can serve as a temporary solution — but Google is clear: it is a workaround, not a long-term solution.

What should you do if you are launching a new JavaScript project?

From the design phase, choose a modern framework with integrated SSR/SSG: Next.js for React, Nuxt.js for Vue, Angular Universal for Angular, SvelteKit for Svelte. These tools natively generate crawlable URLs and pre-rendered HTML.

Set up client-side routing from the start — never let navigation rely solely on JavaScript without URLs. Finally, consistently test with Google Search Console and the URL inspection tool before launch. A technical SEO audit in pre-production can prevent post-launch disasters.

• Manually test mobile navigation and check that the URL changes with each section
• Analyze the Search Console for pages "Crawled, currently not indexed"
• Crawl the site with Screaming Frog in JavaScript mode to count discovered URLs
• Implement the History API if you are on an SPA without routing
• Set up SSR, SSG, or Dynamic Rendering to generate crawlable HTML
• Choose a modern framework with integrated SSR/SSG for any new JavaScript project