# SEO for Single Page Applications: A 2026 Guide > SEO for single page applications fails quietly. Here's how to prove your SPA has a rendering problem and what to fix when a rewrite isn't an option. **Author:** Ben Montejo — Freelance SEO Consultant, Valencia, Spain **Published:** 2026-09-24 **Category:** technical-seo **Canonical:** https://seobeni.com/blog/seo-for-single-page-applications-2026/ **Spanish version:** https://seobeni.com/es/blog/seo-para-aplicaciones-spa-2026/ --- SEO for single page applications is the practice of making an app that renders in the browser return real, indexable HTML to crawlers. Unlike a traditional server-rendered site, where the first response already contains the content, a single page application ships an empty shell and builds the page with JavaScript after it arrives — which means the content exists for users long before it exists for search engines, and in some cases never exists for them at all. **According to [Google Search Central](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics), rendering JavaScript is a deferred second pass: Google crawls your raw HTML first, then queues the page for rendering later.** That queue is the whole problem. **Google also downgraded dynamic rendering from a recommendation to a documented workaround, explicitly steering teams toward server-side rendering instead.** And the newer issue almost no SPA guide addresses: **the crawlers behind AI answer engines fetch your HTML and do not execute JavaScript — so content that only exists after hydration is invisible to them entirely, regardless of how well you rank in Google.** If you want the short answer: fetch one of your important URLs without executing JavaScript. If the content isn't in that response, you have a problem — not a theoretical one, a measurable one. The rest of this post is how to prove it, how to size it, and what to do when rewriting the app isn't on the table. ## Why SEO for Single Page Applications Fails Silently The reason this issue survives in so many companies is that nothing looks broken. The site loads fast. The marketing team can see every page. Analytics reports traffic. There is no error in Search Console screaming about it. What actually happens is that Googlebot makes its first request and receives something close to `
` plus a JavaScript bundle. No headline, no body copy, no internal links. It files the URL away and moves on. The content arrives later — when the render queue gets to it. In my experience auditing JavaScript-heavy sites, the damage is rarely total. It is partial and uneven, which is far harder to diagnose. Your homepage renders quickly because it has crawl priority. Your 400 programmatic landing pages sit in the queue for days, get rendered inconsistently, and half of them never accumulate enough signals to rank. The team concludes the content "just isn't working" and rewrites it. The content was fine. It was never seen. Two things make this worse in 2026 than it was in 2020. First, sites are bigger, and render budget is finite. Second, Google is no longer the only crawler that matters. ## The AI Crawler Problem Nobody Puts in the SPA Checklist Every SPA SEO guide tells you Google renders JavaScript. That was the reassuring headline for a decade, and it is still true. It is also now beside the point. The crawlers that feed AI answer engines — GPTBot, ClaudeBot, PerplexityBot and the rest — fetch your HTML the way a crawler did in 2005. They do not run a headless Chromium instance. They do not wait for hydration. They take what the server sends and that is the end of it. So a React app can rank perfectly well in Google, pass every Core Web Vitals threshold, and simultaneously not exist in ChatGPT or Perplexity answers. Not rank poorly — not exist. When those tools cite a competitor instead of you on a query you own in Google, this is usually why. This changes the business case. "Google can handle it" used to be a defensible reason to skip server-side rendering. It no longer is, because Google handling it only buys you one channel. If you are tracking [AI visibility alongside organic rankings](https://seobeni.com/blog/ai-visibility-tracking-guide-2026/), a client-rendered SPA puts a hard ceiling on one of them that no amount of content work will lift. ## How to Diagnose SEO for Single Page Applications in Four Steps You do not need developer access or a staging environment to establish whether you have this problem. You need about twenty minutes. Run these in order — each one narrows the diagnosis. 1. **Fetch the raw HTML.** Run `curl -s https://yoursite.com/your-page/ | head -100` in a terminal, or use "View Source" in the browser (not DevTools' Elements panel — that shows the *rendered* DOM and will lie to you). Look for your actual headline and body copy. If you see an empty div and a script tag, the content is client-rendered. This single check answers the main question. 2. **Compare against Google's rendered view.** Open the URL Inspection tool in Search Console, run a live test, and view the rendered HTML. If the content appears here but not in step 1, Google is rendering you successfully — you are dependent on the queue, but not invisible. If it is missing here too, rendering is failing outright and this is urgent. 3. **Test an invalid URL for soft 404s.** Request a URL that should not exist — `https://yoursite.com/this-page-does-not-exist-12345/` — and check the HTTP status code, not what the page displays. Most SPAs return `200 OK` with an empty shell for every unmatched route, because the server is configured to hand all paths to the app. Google then has no way to distinguish real pages from garbage, and starts indexing empty URLs or discarding real ones. This is one of the most damaging and least noticed SPA failures. 4. **Check whether routes are real URLs at all.** Click through the site's main navigation and watch the address bar. If the URL never changes, or changes to a fragment like `/#/products/shoes`, those views have no independent URL for a crawler to reach. Nothing that lives behind a click without a URL change can be indexed, no matter how good the content is. By the end of step 4 you know three things: whether content is in the HTML, whether Google is rendering it, and whether your routing is crawlable. That is a complete diagnosis, and it is enough to brief a developer properly rather than forwarding them a tool report they will ignore. ## Choosing a Rendering Strategy Without Rewriting the App Here is where most advice becomes useless. Every guide concludes with "use Next.js" — which is a fine recommendation for a greenfield project and an impossible one for a team with a shipped React app, a roadmap and no appetite for a six-month migration. The realistic options, roughly in order of cost: **Static generation for the pages that matter.** If your indexable content is a blog, a docs section or a set of marketing pages, those do not need to be part of the SPA at all. Build them as static HTML and serve them from the same domain. This is the cheapest genuine fix and it is under-used because it feels like a step backwards. It isn't. It is putting each type of content on the rendering model that suits it. Once the rendering layer is in place, your [SEO copywriting](https://seobeni.com/blog/seo-copywriting-guide-2026/) choices — intent match, passage structure, opening sentences — can actually do their job. **Prerendering for existing routes.** A prerendering service or build step visits each route, captures the finished HTML, and serves that snapshot to crawlers. It requires no application rewrite. The cost is a cache that drifts out of sync with the live site if nobody maintains it, and an ongoing bill. Treat it as a bridge, not a destination. **Incremental server-side rendering.** Frameworks that support SSR let you migrate route by route rather than all at once. Server-render the public, indexable pages; leave the authenticated dashboard client-rendered, where it belongs. This is the right end state for most businesses, and framing it as incremental is usually what gets it approved. What I would not do is reach for dynamic rendering — serving bots a prerendered version while users get the app. [Google's own documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) now presents it as a workaround rather than a recommended solution, and it doubles your surface area for bugs. If you are going to build rendering infrastructure anyway, build the kind that serves everyone the same HTML. Whichever route you take, this is a decision with real engineering cost attached, and it benefits from someone who has watched it go wrong before. It is a standard part of a [technical SEO engagement](https://seobeni.com/services/technical-seo/) precisely because the diagnosis is easy and the trade-off analysis is not. ## The SPA Fixes That Are Not About Rendering Rendering gets all the attention, but three adjacent problems account for a lot of lost traffic in single page applications and are much cheaper to fix. **Per-route metadata.** In a naive SPA, every route inherits the shell's title and meta description. Google then sees a hundred pages with identical titles, which is a textbook [keyword cannibalization](https://seobeni.com/blog/keyword-cannibalization-seo-2026/) setup. Every route needs its own title, description and canonical, set server-side if possible and client-side at minimum. **Real status codes.** Following on from step 3 above: invalid routes must return 404 or 410 from the server, not 200. Removed products must not silently become empty shells. Configure your server or edge function to return the correct status for unmatched paths before the app ever loads. **Crawlable links.** Navigation built on `onClick` handlers with `
` elements is not navigation as far as a crawler is concerned. Internal links must be real `` elements. This is trivial to fix and it is wrong on a surprising share of SPAs — and it quietly undermines any [internal linking strategy](https://seobeni.com/blog/internal-linking-strategy-seo-2026/) you build on top of it. None of these three require a rendering change. If you are waiting on an SSR decision, ship all three now. ## What to Tell Your Developers The conversation goes badly when it starts with "our SEO is broken." It goes well when it starts with evidence. Bring the output of step 1 — the raw HTML showing an empty shell. Bring the status code from step 3 showing a nonexistent URL returning 200. Those are two facts a developer can verify in thirty seconds and neither is a matter of opinion. Then ask the specific question: *which of our routes need to return finished HTML, and what is the cheapest way to get there?* That framing works because it is an engineering question with an engineering answer, not a marketing complaint. Teams that have this conversation early tend to land on incremental SSR for public routes. Teams that have it eighteen months in tend to have already spent the content budget that would have paid for it. SEO for single page applications is not a matter of tricking a crawler or adding a plugin. It is deciding, route by route, whether a page is an application view or a document — and making sure every page in the second category returns real HTML to everything that asks for it, Google included and Google not the only one that counts. If you want a second opinion on where your own app sits, that is exactly what a [technical SEO audit](https://seobeni.com/services/seo-audit/) is for. ## Frequently Asked Questions ### Can React be used for single-page applications? Yes — React is the most widely used library for building single-page applications, and that is exactly why React SPAs show up so often in SEO audits. React itself renders on the client by default, so a plain create-react-app or Vite build ships an empty div and loads content via JavaScript. To make a React SPA reliably indexable you need a rendering layer on top: Next.js for server-side rendering, or a prerendering step that produces real HTML per route. ### Is SSR better than SPA? For anything you want found in search, yes — server-side rendering is better, because it removes the dependency on a crawler executing your JavaScript. But this is a false opposition: SSR and SPA are not alternatives. Modern frameworks let you server-render the first response and then hydrate into a full single page application, so users still get SPA navigation while crawlers get real HTML. The genuine trade-off is infrastructure cost and complexity, not user experience. ### Can you give me some examples of single-page applications? Gmail, Google Maps, Trello, Figma and Spotify's web player are all single-page applications — the page shell loads once and everything after that updates through JavaScript. Notice the pattern: they are logged-in tools, not content sites. That is the healthiest way to think about SPAs. They are excellent for application interfaces behind a login and risky for the public, indexable pages that need to rank. ### Is Angular a single-page application? Angular is a framework for building single-page applications, not an SPA itself. By default an Angular app renders client-side and has the same indexing exposure as any other SPA. Angular ships an official server-side rendering package (formerly Angular Universal, now part of @angular/ssr) which produces real HTML per route — if you are running Angular on public pages that need to rank, this is the fix. ### What are some common single-page application frameworks? React, Angular, Vue and Svelte are the common choices for building single page applications, each with a matching server-rendering framework: Next.js for React, @angular/ssr for Angular, Nuxt for Vue, and SvelteKit for Svelte. From an SEO point of view the framework barely matters. What matters is whether the route returns finished HTML or an empty shell, and you test that the same way regardless of which one your team picked. If you want that checked properly across your whole site, that is what a [freelance SEO consultant](https://seobeni.com/freelance-seo-consultant/) is for. ## Frequently Asked Questions **Can React be used for single-page applications?** Yes — React is the most widely used library for building single-page applications, and that is exactly why React SPAs show up so often in SEO audits. React itself renders on the client by default, so a plain create-react-app or Vite build ships an empty div and loads content via JavaScript. To make a React SPA reliably indexable you need a rendering layer on top: Next.js for server-side rendering, or a prerendering step that produces real HTML per route. **Is SSR better than SPA?** For anything you want found in search, yes — server-side rendering is better, because it removes the dependency on a crawler executing your JavaScript. But this is a false opposition: SSR and SPA are not alternatives. Modern frameworks let you server-render the first response and then hydrate into a full single page application, so users still get SPA navigation while crawlers get real HTML. The genuine trade-off is infrastructure cost and complexity, not user experience. **Can you give me some examples of single-page applications?** Gmail, Google Maps, Trello, Figma and Spotify's web player are all single-page applications — the page shell loads once and everything after that updates through JavaScript. Notice the pattern: they are logged-in tools, not content sites. That is the healthiest way to think about SPAs. They are excellent for application interfaces behind a login and risky for the public, indexable pages that need to rank. **Is Angular a single-page application?** Angular is a framework for building single-page applications, not an SPA itself. By default an Angular app renders client-side and has the same indexing exposure as any other SPA. Angular ships an official server-side rendering package (formerly Angular Universal, now part of @angular/ssr) which produces real HTML per route — if you are running Angular on public pages that need to rank, this is the fix. **What are some common single-page application frameworks?** React, Angular, Vue and Svelte are the common choices for building single page applications, each with a matching server-rendering framework: Next.js for React, @angular/ssr for Angular, Nuxt for Vue, and SvelteKit for Svelte. From an SEO point of view the framework barely matters. What matters is whether the route returns finished HTML or an empty shell, and you test that the same way regardless of which one your team picked. --- Source: https://seobeni.com/blog/seo-for-single-page-applications-2026/ · Author: Ben Montejo (https://seobeni.com/freelance-seo-consultant/)