SEO Single Page vs Multiple Pages

I start with a simple rule: if you can name three distinct search queries your site should rank for, you need multiple pages. For a recent client who sold SEO audits, content writing and web design, they had a single page trying to cover all three. Monthly organic traffic was stuck at 200 visits. I split the content into three separate pages, each focused on one service. Within six months, combined traffic hit 850 visits, and each page ranked in the top 10 for its primary term. That swing convinced me. Single-page wins only when the offer is that narrow – a wedding photographer whose only keyword is "wedding photographer in Bristol", or a landing page for a single course with one call to action. In those cases, the page can concentrate all link equity and internal optimisation on one URL. But you sacrifice the ability to create a content hierarchy and build topical depth. If you ever plan to blog, add case studies or expand services, multi-page is the only choice. I also consider the user experience: single-page sites can be fast if done right, but Google often struggles to anchor scroll sections in search results. Multiple pages let you control the snippet for each intent. That said, I've seen edge cases where a single page with strong internal anchors and a table of contents ranked well for multiple related queries – but that required every section to be substantial and unique. My rule: when in doubt, err on the side of more pages. You can always consolidate later (and I've done that too). Use a clear [website structure](/website-structure/) with categories and subcategories that mirror your keyword groups. And always pair this with a [technical SEO](/technical-seo/) baseline that ensures each page is indexable and fast.

The most common mistake I see is forcing a single-page site to cover unrelated topics. The page becomes a keyword salad – it ranks for nothing because it matches no intent cleanly. Google sees a page about "SEO services, wedding photography and dog walking" and gives up. Equally damaging is the opposite: splitting one coherent topic into ten thin pages, each with 200 words. I learned that the hard way with a travel site. We had a full walkthrough to "backpacking in Thailand" – one page that ranked #3 with 3,000 words. In a misguided attempt to target more keywords, I broke it into pages for "hostels", "itineraries", "food" and so on. Each new page got 400 words, and within a month the original page dropped to page 2 and the new pages never ranked. Google's algorithm values depth, and a thin page rarely competes. Another pitfall: treating anchor links as if they were separate URLs. I've had clients ask if they can count each section of a single page as an independent SEO entity. They cannot. Google indexes the URL as one unit. If you want distinct rankings, you need distinct URLs. Then there's the crawlability trap. Single-page applications that rely on JavaScript to load content often hide sections from Google unless you implement SSR or dynamic rendering. I dealt with a React-based single-page site where the "about" section never appeared in the index because it was a JS-generated anchor. A [sitemap](/sitemap/) and proper [canonical tags](/canonical-tag/) are critical for multi-page sites to avoid [duplicate content](/duplicate-content/) issues. For multi-page structures, beware of pagination problems when you have many similar pages – implement rel next/prev or proper canonicalisation to direct link equity. A [pagination](/pagination/) audit should be part of your launch checklist.

I'll start with the consolidation disaster I hinted at. Two years ago, I was working with an e-commerce client who had twenty product pages each selling the same widget but in different colours. Each page was thin – 150 words and a product photo. I decided to consolidate all colour variations into a single product page with a dropdown selector. The result? That one page ranked well for the main widget keyword but lost all long-tail colour-specific traffic. The colour-specific queries like "blue widget London" disappeared from the index. I should have kept separate canonicalised pages for each colour, or used [JavaScript SEO](/javascript-seo/) to switch content without losing URL uniqueness. That mistake taught me that consolidation is only wise when the individual pages are too thin to stand alone AND they target the same core intent. Another thing I got wrong was underestimating the impact of single-page load times. For a portfolio site I built as a single page with heavy images, the page took 8 seconds to load. I thought it would be fine because all content was on one URL. But the user experience was terrible, and Google's Core Web Vitals penalised it. I ended up splitting the site into five portfolio pages, which improved load times by 40% because each page only loaded its own assets. I also used to believe that a single page was always bad for SEO. I've softened on that. A well-optimised single page with a strong internal anchor structure can work for a very focused offer, but the moment you add a second intent you need a second page. I now see the question less as a binary and more as a spectrum: you choose the number of pages based on the number of distinct intents you serve. Finally, I used to ignore internal linking between pages when moving from single to multi-page. I'd just create pages and hope. Now I always map out a linking hierarchy, using breadcrumbs, related posts and contextual links to pass equity between pages.