One-Page vs Multi-Page Websites: SEO and UX Trade-offs

A client came to us last year with a beautifully designed one-pager for a three-service B2B consultancy. Great typography, tasteful scroll reveals, sub-second load. It ranked for exactly one thing: the company name. Eighteen months live, 1,900 words of copy on a single URL, and Search Console showed eleven impressions a day.

We split it into five pages. Same copy, mostly, reorganised so each service got its own URL, title tag and H1. Within four months it was ranking on page two for two of the three service terms in its city. Nothing clever happened. It just stopped asking Google to rank one document for three different jobs.

That’s the core of the single page vs multi page question, and it’s not really an SEO question or a UX question. It’s a question about how many distinct things you need to be found for, and whether your content is deep enough to deserve separate URLs.

Get the terminology straight before you argue about it

Half the blog posts on this topic are useless because they conflate two unrelated things.

A one-page website is a content architecture: all your content lives in one HTML document, navigated by anchor links, usually with a sticky nav and scroll-spy highlighting. Think conference sites and app landing pages.

A single-page application is a rendering architecture: a JavaScript app that swaps views client-side while the URL changes via the History API. An SPA can have 400 indexable URLs. Next.js, Nuxt and Astro with client routing all produce multi-page sites from an SEO point of view, because each route resolves to its own URL with its own metadata.

So you can have a one-page site built as static HTML, a one-page site built in React, and a 200-page site built as an SPA. The SEO consequences follow the URL count, not the framework. Everything below is about content architecture.

What one page website SEO can and cannot do

It can do more than the doom-mongers claim. A single URL can rank, rank well, and hold a featured snippet. Google has no penalty for one-page sites. What it has is a set of structural limits you inherit the moment you commit to one document.

The limits, concretely:

• One title tag and one meta description. Your most powerful on-page relevance signal, and you get exactly one. Try writing a title that targets “fractional CFO services”, “startup bookkeeping” and “R&D tax credit claims” at once. You’ll write something generic.
• One H1, and section H2s doing double duty. Headings on a one-pager serve navigation, so they get short and label-like (“Services”, “Pricing”, “About”). Those are terrible headings for search. The fix is to write them as descriptive phrases, which then look odd in the nav.
• No internal linking structure. Internal links distribute relevance and tell Google what a page is about. On one URL there is nothing to link to. You also lose the anchor text signal entirely, which on client sites is often the cheapest ranking win available.
• Search Console gives you one row. Every query for every topic collapses into a single page report. You lose the ability to see that your pricing section pulls 40 percent of non-brand impressions, because there is no pricing URL.
• Anchors do not create URLs. Browsers never send the fragment to the server. Google has indexed fragment URLs in rare cases when a page uses them as primary navigation, but treat it as unavailable. Plan for /#pricing to never appear in the SERPs.

What still works fine: structured data (Organization, LocalBusiness, Service, FAQPage all sit happily on one document), image optimisation, backlinks, Core Web Vitals, local pack rankings. If your entire search demand is “[brand name]” plus one service term in one city, a one-page website will do the job and you can stop reading.

The 3,000-word one-pager problem

Teams try to solve the depth problem by making the one-pager enormous. We’ve audited 6,000-word single pages. They don’t rank for the long tail the way separate pages do, because relevance gets diluted: a document about nine things is strongly about nothing. It also means every visitor downloads all nine things.

The UX case for one page, and where it breaks

Scrolling beats clicking. That part is real. No navigation decision, no page load, no back button, no dead end. On mobile especially, a well-built one-pager with a sticky CTA converts better than a four-page site where the pricing is two taps away. For a single linear story (problem, solution, proof, price, form), the scroll is the funnel.

Where it breaks, in our experience, is around the sixth section. Past that:

• Orientation degrades. Visitors stop knowing where they are or how much is left. Scroll-spy nav helps. A progress bar helps less than designers think.
• Deep linking gets awkward. Sales needs to send a prospect straight to the pricing table. You send site.com/#pricing, the page loads, all of it, then jumps. On a slow connection the jump lands in the wrong place because images above haven’t reserved space.
• Back button expectations break. If you push a history entry on every section, the back button becomes a scroll-up button and users get trapped. Use replaceState, not pushState.
• Analytics turns into guesswork. Every visitor has a session with one pageview. You have to rebuild engagement measurement with scroll and visibility events before you know anything.

Performance: the trade-off almost nobody measures

The claim “one page loads faster” is true for the second interaction and false for the first. A multi-page site loads a small document, then subsequent navigations reuse cached CSS, fonts and JS. A one-pager loads everything once and then nothing. So the comparison depends entirely on payload.

Real numbers from a build we did in 2025: a nine-section one-pager, four full-bleed hero images, two inline video posters, an animation library and a map embed. First load was 2.4 MB on desktop and LCP sat around 3.1 seconds on a throttled 4G profile in Lighthouse. Splitting it into a 380 KB home page plus four sub-pages took LCP to roughly 1.4 seconds, because the visitor no longer downloaded the map embed to read the intro.

If you commit to one page, commit to the discipline that goes with it:

<!-- Above the fold: eager, high priority, explicit dimensions to avoid CLS -->
<img src="/img/hero-1600.webp" srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w"
     sizes="100vw" width="1600" height="900" alt="" fetchpriority="high">

<!-- Every section below the fold: lazy, and decoding off the main thread -->
<img src="/img/case-study-800.webp" width="800" height="600" alt="Dashboard redesign"
     loading="lazy" decoding="async">

<!-- Defer the heavy third party until the section is actually reached -->
<iframe data-src="https://maps.example/embed" loading="lazy" title="Office location"></iframe>

Scroll animation is the other silent tax. Animating dozens of sections with a scroll handler that reads layout properties will wreck INP on mid-range Android. We wrote up the measurement approach in micro-interactions and scroll animation without wrecking performance, and the short version is: IntersectionObserver plus transform and opacity only.

Anchor routing done properly

Most one-pagers we inherit get three things wrong: the sticky header covers the section heading after a jump, smooth scrolling ignores reduced-motion preferences, and the nav highlight is driven by a scroll event firing 60 times a second. All three are a few lines to fix.

:root { --header-h: 72px; }

/ Offsets anchor jumps so the sticky header does not cover the heading /
section[id] { scroll-margin-top: var(--header-h); }

/ Only smooth-scroll for users who have not asked for less motion /
@media (prefers-reduced-motion: no-preference) {
  html { scroll-behavior: smooth; }
}

const sections = document.querySelectorAll('main section[id]');
const links = new Map(
  [...document.querySelectorAll('.nav-link[href^="#"]')].map(a => [a.hash.slice(1), a])
);

const spy = new IntersectionObserver((entries) => {
  for (const entry of entries) {
    if (!entry.isIntersecting) continue;
    links.forEach(l => l.classList.remove('active'));
    links.get(entry.target.id)?.classList.add('active');
    // replaceState keeps the URL shareable without filling the back button with 9 entries
    history.replaceState(null, '', '#' + entry.target.id);
  }
// The negative rootMargin creates a thin band across the viewport middle,
// so only the section crossing the centre line is ever "active"
}, { rootMargin: '-45% 0px -55% 0px' });

sections.forEach(s => spy.observe(s));

Then fix analytics, because one pageview per session tells you nothing. Fire a section-visible event once per section and treat it as your pageview equivalent:

const seen = new Set();
const track = new IntersectionObserver((entries) => {
  for (const e of entries) {
    if (e.intersectionRatio < 0.5 || seen.has(e.target.id)) continue;
    seen.add(e.target.id);
    gtag('event', 'sectionview', { sectionid: e.target.id });
  }
}, { threshold: [0.5] });

sections.forEach(s => track.observe(s));

One more thing that trips people up on static one-pagers: the contact form. There’s no backend to post to, so people bolt on a mailto link (spam magnet, no confirmation) or an third-party embed that drags in 200 KB of JS. A plain POST to a hosted endpoint like WebForms keeps the page static and gets submissions into email or Slack without a server. If the form has more than about seven fields, read our notes on multi-step forms first, because a long form at the bottom of a long scroll is where one-pagers leak conversions.

The hybrid architecture we ship most often

For maybe 70 percent of the marketing sites we build, neither pure option is right. What works: a home page that scrolls like a one-pager and functions as a summary layer, with real pages behind the sections that have search demand.

The rules we apply:

1. One page per distinct search intent. Not per topic, per intent. “Web design” and “web design agency London” are the same intent; “web design” and “Webflow migration” are not.
2. A section earns a page when it has 400-plus words of genuinely unique content and a query someone actually types. Below that, it stays a section. A thin page is worse than no page.
3. Section headings link forward. Each home page section ends with a real anchor link to its page (“See the full pricing breakdown”), giving you internal anchor text you didn’t have before.
4. Home page targets the brand plus the head term. Sub-pages take the long tail. Stop making the home page fight for everything.
5. Never duplicate the sub-page content verbatim on the home page. Summarise in two or three sentences. Duplicating leads to Google picking the wrong URL for the query, which is the messiest version of this problem to debug.

Practically, this is what the better template libraries assume. The one-page demos in Canvas are built as section partials specifically so you can promote a section to a standalone page later without rebuilding the layout, which matters because the promotion happens on roughly every project that succeeds. If you’re evaluating a starting point, the section-partial question is one we’d add to the checklist in how to evaluate an HTML template.

Splitting a one-pager without losing what you have

Good news: the migration is safer than a normal replatform, because your anchors were never indexed. There are no /#pricing rankings to lose. Your one URL keeps its authority as the home page.

What to do, in order:

1. Export 12 months of Search Console queries for the single URL before you touch anything. That query list is your page map. Group queries by intent, and each group with real impressions becomes a page.
2. Keep the home page URL exactly as it is. No redirect. It holds every backlink you have.
3. Handle inbound anchor links client-side, temporarily. Sales decks, email footers and old social posts will keep pointing at /#services. If that section no longer exists on the home page, a small shim saves those visitors.

// Only for sections that MOVED off the home page. Remove after a few months.
const moved = { services: '/services/', pricing: '/pricing/', team: '/about/#team' };
const dest = moved[location.hash.slice(1)];
if (dest && location.pathname === '/') location.replace(dest); // replace, so back still works

4. Rewrite, don’t copy-paste. Each new page needs its own H1, title, meta description and intro. If you paste the section and ship it, you get five thin pages and you’ll conclude, wrongly, that multi-page didn’t help.
5. Submit a fresh sitemap and expect 6 to 12 weeks before the new pages settle. Local service terms tend to move first.

How to decide in five minutes

Count the distinct things people search for to find you. One thing, or one thing plus your brand name? Build the one-pager, keep it under 1 MB, and put your effort into the offer and the form. Three or more things with real search volume, or any plan to publish content? Go multi-page, or hybrid, and don’t let a designer talk you out of it on aesthetic grounds.

The failure mode we see most isn’t choosing wrong at the start. It’s choosing one page for a business that then adds two services, a location and a blog, and nobody revisits the architecture for three years. Set a review trigger: when you add a second service, you add a second page.