> Content index: https://quillly.com/blogs/llms.txt > Canonical page: https://quillly.com/blogs/seo-for-single-page-website --- title: SEO for Single Page Website: What Can Actually Rank description: SEO for single page website work splits in two: a one-page site starves for URLs, an SPA ships empty HTML. Run the render test to see which you have. keywords: seo for single page website, single page website seo, seo single page application, single page application seo published: 2026-09-20 updated: 2026-09-20 url: https://quillly.com/blogs/seo-for-single-page-website word_count: 2878 --- # SEO for Single Page Website: What Can Actually Rank > A one-page site and a single page application fail in search for opposite reasons. Run the 60-second render test, then fix the one you actually have. Canonical: https://quillly.com/blogs/seo-for-single-page-website Published: 2026-09-20 ## Related Pages - [Crawled Currently Not Indexed: A 284-Page Test](https://quillly.com/blogs/crawled-currently-not-indexed) - [Reverse Proxy Blog Subdirectory: The 2026 SEO Setup](https://quillly.com/blogs/reverse-proxy-blog-subdirectory) - [IndexNow: Get Your Blog Indexed in Bing and ChatGPT](https://quillly.com/blogs/indexnow-bing-chatgpt-indexing) - [CMS SEO: Which Platform Actually Ranks in 2026](https://quillly.com/blogs/cms-seo-platform-comparison) - [Blog SEO Checklist: 14 Items Ranked by Real Data](https://quillly.com/blogs/blog-seo-checklist) - [How to Get Indexed on Google Fast in 2026](https://quillly.com/blogs/get-indexed-on-google-fast) - [Core Web Vitals for Blogs: Fix a Slow Blog in 2026](https://quillly.com/blogs/core-web-vitals-for-blogs) ![a laptop computer sitting on top of a wooden desk](https://images.unsplash.com/photo-1678690832311-bb6e361989ca?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTM1MDJ8MHwxfHNlYXJjaHwxfHxzaW5nbGUlMjBwYWdlJTIwd2Vic2l0ZSUyMGRlc2lnbiUyMG9uJTIwbGFwdG9wJTIwc2NyZWVufGVufDB8MHx8fDE3ODk4NjQ1MjB8MA&ixlib=rb-4.1.0&q=80&w=1080) *Photo by [Carriza Maiquez](https://unsplash.com/@carzmaiquez?utm_source=quillly&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=quillly&utm_medium=referral)* Your site looks great. It loads fast, the copy is sharp, the design is clean, and everyone you showed it to said so — and then six months after launch you open Search Console and find that Google shows it for exactly one query: your own brand name. Nothing else you built is competing for anything at all. **The short answer:** a one-page site and a single page application fail in search for opposite reasons. The one-page site has too few URLs — one page can own one query cluster, not twenty. The single page application usually has plenty of URLs, but ships them as an empty HTML shell, so there's nothing to index until JavaScript runs. The query "SEO for single page website" hides those two completely different problems, and most guides answer only one of them. Before you touch a meta tag, you need to know which machine you're working on — because the fix for one does nothing for the other. ## SEO for Single Page Website: The Two Setups People Mean When someone says "single page," they mean one of two things: - **A one-page site.** One URL. Everything lives on it — hero, features, pricing, contact — and the nav scrolls you to `#pricing` instead of loading a new document. Typical of portfolios, local businesses, launch pages and link-in-bio sites. - **A single page application (SPA).** Many routes (`/features`, `/pricing`, `/blog/post`), but one HTML shell. React, Vue, Angular or Svelte swap the view client-side using the [History API](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState) instead of asking the server for a new page. That split isn't academic. When we pulled the live Google top ten for this query in September 2026, two of the ten results were Reddit threads — one asking whether a simple one-page personal site can rank at all, the other asking whether single page applications are bad for SEO. Same query, two different machines, and the people asking couldn't tell which one they were running. The confusion matters because the diagnosis is inverted. The one-page site has *real HTML and not enough URLs*. The SPA has *plenty of URLs and not enough HTML*. Advice aimed at the wrong one is worse than no advice — you'll spend a weekend on server rendering when your actual problem is that you only have one page. ![Decision tree: does clicking your nav change the URL, and does the page source contain your copy, sorting a site into one-page site or single page application](https://quillly.com/serve/v1/019c64a2-a62f-7793-aa68-2c78316d3309/images/7eb89b55da8d2a925411f4aea80d856bbec906dc.webp) Run that test on your own site right now. It takes ten seconds and it decides everything that follows. ## The Render Test: See What Google Sees in 60 Seconds Your browser is a liar. It runs your JavaScript, paints your content and shows you a finished page. A crawler's first pass sees the raw HTML response — and Google renders JavaScript in a second pass that can lag the first, as [Google's JavaScript SEO documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) explains. So check the raw response, not the rendered one: The first command prints the HTML exactly as a crawler first receives it. The second counts how many words survive with JavaScript switched off. ```bash curl -sL https://quillly.com/blogs | head -c 2000 curl -sL https://quillly.com/blogs | sed 's/<[^>]*>/ /g' | wc -w ``` Swap in one of your own URLs. Three outcomes: | What you see in the raw HTML | Verdict | What to do | | --- | --- | --- | | Your headline, body copy and links | Server-rendered — healthy | Nothing. Move to content and links. | | A `
` and a script tag | Client-only SPA | Render on the server (next section) | | Copy present, but every route identical | Shared shell | Give each route its own title, meta and canonical | The second row is the classic single page application SEO failure. Google can still render it — but rendering is a queue, not a guarantee, and pages that arrive empty compete for a budget that server-rendered pages never spend. If yours are already stuck, our breakdown of [what "Crawled – currently not indexed" actually means](https://quillly.com/blogs/crawled-currently-not-indexed) walks through the same signal from Search Console's side. Want the machine version of this check? Our free [SEO checker](https://quillly.com/tools/seo-checker){cta=tool} fetches a URL the way a crawler does and scores what comes back. ## SEO Single Page Application Fixes, Ranked by Payoff Most single page application SEO advice stops at "use server rendering." That's the right headline and a useless priority list. If the render test put you in row two, these are the fixes in order of how much they actually move, top-down — stop when your raw HTML contains your content. 1. **Render on the server.** SSR or static generation turns the shell into a real document. Frameworks ship this now: Next.js, Nuxt, SvelteKit and Remix all prerender by default, and Next.js documents the [single page application patterns](https://nextjs.org/docs/app/guides/single-page-applications) that keep client-side routing while still shipping HTML. If a rewrite isn't on the table, prerender the routes that matter — marketing pages, blog posts, docs — and leave the logged-in app client-side. Nobody needs to index your dashboard. 2. **Give every route a real URL.** Hash routes (`/#/pricing`) are not separate pages; everything after the `#` is never sent to the server. Use path-based routing so each view has its own address. 3. **Make links real `` elements.** A `
` is invisible to a crawler. Framework link components render anchors — use them, and make sure the `href` is populated in the HTML, not attached at runtime. 4. **Set per-route titles, meta descriptions and canonicals.** One shared `` across forty routes is forty pages that look like duplicates. Google's guide to [consolidating duplicate URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) covers how canonicals resolve that. 5. **Ship a sitemap that lists the routes, not the shell.** If your sitemap has one entry, so does your index coverage. Two things to skip. Dynamic rendering — serving a prerendered copy to bots only — is described by Google as a [workaround, not a long-term solution](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering), and it doubles your surface area for bugs. And the old `#!` escaped-fragment scheme has been dead for years; don't resurrect it from a 2015 blog post. ![Comparison card contrasting a one-page site and a single page application across URL count, HTML content, main failure mode and the correct fix](https://quillly.com/serve/v1/019c64a2-a62f-7793-aa68-2c78316d3309/images/5c4eefa344b002f5fe832ff9a107cd00f9658282.webp) ## Single Page Website SEO: Why One URL Caps Your Ceiling Now the other half. If your render test came back clean and you still rank for nothing, you don't have a technical problem — you have an inventory problem. A search engine ranks documents. Your pricing section is not a document; it's a paragraph inside one. Google can link to `#pricing` from a site link or a passage result, but the unit competing in the index is still the single page. That's the whole single page website seo trap: you can optimize one URL beautifully and it still only competes in one place at a time. The arithmetic is unforgiving. A page realistically holds one primary intent plus a handful of close variants. Ten intents need something closer to ten pages — which is why [Ahrefs' guide to single-page websites](https://ahrefs.com/blog/single-page-website/) lands on the same conclusion: they work for narrow, branded, local intent and cap out fast beyond it. ![Bar chart illustrating how the number of distinct search intents a site can realistically target scales with its number of indexable URLs](https://quillly.com/serve/v1/019c64a2-a62f-7793-aa68-2c78316d3309/images/75d2b1b3e580ac1435d8270b825f0e1dd7bd2025.webp) This is illustrative arithmetic, not a measurement — plenty of pages rank for dozens of long-tail variants of one intent. But the direction holds: URLs are the unit of supply, and one is a very small number. ## What a One-Page Site Can and Can't Rank For Being one page isn't a penalty. It's a constraint, and constraints have shapes: | Query type | One-page site | Why | | --- | --- | --- | | Your brand name | Ranks well | Exact-match intent, no competition | | "plumber in Leeds" | Can rank | Local intent, one dominant job, maps pack matters more | | "portfolio of a Berlin illustrator" | Can rank | Narrow, few competitors | | "how to fix a leaking radiator valve" | Won't rank | Needs a dedicated document | | 40 service and comparison queries | Won't rank | Needs 40 documents | ![Decision flow for judging whether one query needs its own URL or can be won by an existing single page](https://quillly.com/serve/v1/019c64a2-a62f-7793-aa68-2c78316d3309/images/a45dc07dbaccd15d5c17bcb31079e4c4c50dd3b8.webp) If everything you want sits in rows one to three, stop reading and go get citations and links instead. If you want rows four and five, no amount of on-page work on a single URL gets you there. You need more pages — which is the next section, and it's easier than a rewrite. Either way the work after the diagnosis is publishing, and [that part can run from your AI assistant](https://quillly.com){cta=signup}. ## Adding Real URLs Without Rebuilding Your App The instinctive fix is "migrate to a CMS." That's a big swing when the goal is just to publish indexable documents alongside an app you like. Three lighter options: - **Prerender the marketing routes only.** Keep the app client-side; statically generate the handful of pages that need to rank. Most frameworks support mixing both in one project. - **Put the content on a subdomain.** Fast to stand up, but it starts its own authority from zero and shares little with your root domain. - **Serve a subdirectory through a reverse proxy.** `yoursite.com/blog` stays on your domain and inherits its authority, while the pages themselves are rendered somewhere else. We covered the routing rules in [the reverse proxy subdirectory setup](https://quillly.com/blogs/reverse-proxy-blog-subdirectory). That third option is what Quillly does. Your posts, docs and changelog entries are server-rendered as real HTML at real URLs under your own domain, with their own titles, meta, canonicals, sitemap and RSS feed — so the render test above passes on day one without touching your application code. Each publish notifies eight engines: Google through the sitemap and RSS feeds submitted via Search Console, and Bing, Yahoo, Yandex, Naver, Seznam, Yep and Amazon through [a single IndexNow submission](https://quillly.com/blogs/indexnow-bing-chatgpt-indexing). (Google doesn't participate in IndexNow, so the two channels are genuinely separate.) We run this blog on that pipeline, so the numbers are ours to check rather than ours to claim: 155 published items as of September 2026, 145 of them indexed on at least one engine. Coverage is never 100% — Bing lags hardest for us — which is exactly why the section below tells you to watch indexed counts instead of assuming a publish equals an index. If you're choosing between platforms for this layer, our [CMS SEO comparison](https://quillly.com/blogs/cms-seo-platform-comparison) puts the trade-offs side by side, and the [getting-started guide](https://quillly.com/docs/getting-started){cta=docs} shows the connect-once setup. ## How to Tell If It Actually Worked Ship the fix, then verify it from outside your own browser — the same discipline any [blog SEO checklist](https://quillly.com/blogs/blog-seo-checklist) applies: 1. **Re-run the render test.** Your copy should now appear in `curl` output. If it doesn't, nothing downstream matters. 2. **Use the URL Inspection tool in Search Console.** "View crawled page" shows the HTML Google actually stored. Compare it to what you expect. 3. **Watch coverage, not rankings.** Rankings move slowly; indexed-URL counts move first. A route set that stays at one indexed URL means the routes aren't reaching the index at all. 4. **Check your sitemap lists every route.** Submitted versus indexed is the cleanest early signal you have. 5. **Give it weeks, not days.** Discovery and rendering are queues. If you need the short version of speeding that up, we wrote [how to get indexed on Google fast](https://quillly.com/blogs/get-indexed-on-google-fast). One more thing worth measuring: server-rendered pages usually improve loading metrics too, because the browser isn't waiting on a JavaScript bundle before painting text. [Rendering on the web](https://web.dev/articles/rendering-on-the-web) lays out the trade-offs, and our guide to [Core Web Vitals for blogs](https://quillly.com/blogs/core-web-vitals-for-blogs) covers what to watch after the switch. ## The 30-Minute Audit for Either Setup Every SEO for single page website audit comes down to two numbers: how many URLs you own, and how much HTML each one ships before JavaScript runs. Here's how to get both in half an hour. ![Checklist card with a shared audit section plus separate columns of fixes for single page applications and one-page sites](https://quillly.com/serve/v1/019c64a2-a62f-7793-aa68-2c78316d3309/images/09e388943c713de9cb9861919e62d0334ccd072e.webp) Thirty minutes tells you whether you're facing a weekend of rendering work or a quarter of publishing. Most sites discover it's the second one — and that's the better answer, because it compounds. > **Publish real pages without rewriting your app** > Connect your domain once, then your AI assistant writes, scores and publishes server-rendered posts, docs and changelogs at real URLs — submitted to eight search engines on publish. > → [Start with Quillly](https://quillly.com) ## Key Takeaways - SEO for single page website work splits in two: a one-page site is an inventory problem, a single page application is a rendering problem. - The render test settles it. `curl` the URL; if your copy isn't in the raw HTML, JavaScript is hiding your content from the first crawl. - For an SPA, server rendering beats every other fix, and dynamic rendering is a workaround Google itself discourages. - For a one-page site, no on-page tweak adds URLs. One page competes for roughly one intent. - Adding indexable pages doesn't require a rewrite — prerendered routes or a proxied subdirectory keep the authority on your domain. - Verify with coverage data, not rankings. Indexed-URL counts move first. ## Frequently Asked Questions ### Is SEO for single page website work harder than for a normal site? Not harder — narrower. The technical checklist is shorter because there's less to break. The constraint is supply: one URL competes for roughly one intent, so the difficulty is in deciding which intent to own rather than in optimizing the page itself. ### What does SEO single page application mean in practice? It means making sure each client-side route arrives as real HTML at its own path, with its own title, meta description and canonical. In practice that's server rendering or static generation for public routes, path-based routing instead of hash routes, and anchor elements instead of click handlers. ### Can Google index JavaScript content at all? Yes. Google renders JavaScript and indexes what it finds. But rendering happens in a second pass that can lag the initial crawl, so a page that arrives empty is slower to index and more likely to stall. Server-rendered HTML removes that dependency entirely. ### Do anchor links like #pricing count as separate pages? No. Everything after the `#` is never sent to the server, so anchors can't be indexed as separate URLs. Google may deep-link to a section through site links or passage matching, but the competing document is still the single page. ### Should I move my one-page site to a multi-page site? Only if you want queries a single document can't hold. Keep the one-page design for brand, local and narrowly scoped intent. When you need more coverage, add pages beside it rather than rebuilding — the landing page keeps doing its job while new URLs go after new queries. ### How long before the fix shows up in search? Expect weeks. Discovery, crawling and rendering are queues, and a newly server-rendered route still has to be recrawled before anything changes. Watch indexed-URL counts in Search Console for the first movement; ranking changes trail them.