"How many pages does my website need?" has a tidy answer that every proposal is happy to supply — five for a starter, ten for growth, twenty for custom. Treat that as packaging, not planning. A service-business site needs exactly enough pages to answer the important buying questions without forcing unrelated services, locations, proof, and next steps to share one page. For some businesses that is five useful pages. For others it is twenty-five. You arrive at the number by doing the work, not by picking it first.
The rule that produces a defensible number is simple. Give a topic its own page when at least one of these genuinely changes: the reader, the question or service, the evidence, the availability or location, the next action, or a legal or operational requirement. Keep things together when those stay the same. That beats both "every small business needs five pages" and "more pages are better for SEO," and the rest of this article is how to apply it.
Why page count is such a tempting shortcut
Page count feels concrete, and it drops neatly into a proposal: five-page starter, ten-page growth, twenty-page custom. Packaging around a page allowance is fine. Treating pages as identical units is not. A contact page with verified details and one form is nowhere near the work of a service page that needs interviews, original photos, eligibility rules, pricing factors, technical review, proof, and a quote workflow. Two ten-page sites can hide completely different amounts of planning, writing, design, integration, and testing. Page count is a useful number after the page jobs are understood. Before that, it is a container count wearing a strategy costume.
Start from decisions, not navigation labels
The familiar nav — Home, About, Services, Gallery, Contact — is a reasonable starting pattern, not a content strategy. Begin with what the prospective customer has to be able to decide:
- Am I in the right place?
- Do they provide the service I need?
- Do they work in my area or situation?
- What is included, excluded, or likely to change the scope?
- What proof is relevant to this decision?
- What happens if I call, book, or submit a form?
Then map those decisions onto pages. One page can answer several related questions well. One page should not be asked to serve five unrelated readers just to protect a package number.
Six changes that justify a separate page
The reader changes. A commercial property manager and a homeowner may need different information about the same broad service. Don't split on the audience label alone — split when the page would genuinely need different qualifications, proof, process, language, or next step. If one honest explanation serves both, keep it together.
The service question changes. Emergency repair, planned installation, and ongoing maintenance can each deserve a page because the buyer's situation, timing, proof, and next step differ. Three internal names for minor variations of one service usually do not. The test is not whether you can list the item separately; it is whether the reader benefits from a distinct answer.
The evidence changes. A separate page earns its place when it can carry its own real proof — different credentials, different project photos, different process details, different customer questions, different constraints. If every version would repeat the same two paragraphs and the same testimonial, the split is a search tactic without substance.
Availability changes. Distinct locations, licensed territories, service areas, hours, or routing paths can justify distinct pages. A city name by itself cannot. Google's spam policies describe doorway abuse as spinning up near-identical pages — including regional or city pages — that funnel everyone to the same place. A location page has to reflect real differences a visitor would care about, not a find-and-replace on the city name. (The dedicated RP article on service-area pages works through that specific decision.)
The next action changes. Emergency service may want a phone path; a custom project, a quote form; a standard consult, online booking; a job opening, an application rather than the sales form. When the visitor's next step and the information supporting it both shift, a separate page reduces ambiguity and is easier to test.
A required function changes. Some pages exist because the business or the site needs a distinct legal or operational function — a privacy notice, terms, accessibility information, financing or warranty disclosures, licensing details, a customer portal, confirmation and error states. Which ones you actually need depends on your business, jurisdiction, data practices, and services. Don't copy another company's policy set and assume it covers you; get qualified advice where it matters.
A starter map (a planning example, not a minimum)
| Page or page type | Its job |
|---|---|
| Home | Orient the visitor, establish fit and initial proof, route the next decision. |
| Service overview | Help visitors tell the major service categories apart. |
| Individual service page(s) | Explain one distinct service — fit, limits, proof, next step. |
| About | The people, the responsibility, the credentials, the relevant operating story. |
| Proof or project page(s) | Hold the context that won't fit responsibly in a short testimonial. |
| Service-area / location page(s) | Explain real availability and operating differences. |
| Pricing or cost explanation | Prices, ranges, examples, or cost drivers, where useful and supportable. |
| FAQ | Cross-page questions that don't each deserve a full page. |
| Contact or quote page | Set expectations; provide a usable contact path. |
| Required policy pages | The business's actual legal and data practices. |
A small, focused business may fold several of these together. A multi-service or multi-location business may need several of some. The move that matters is writing the job before counting the page.
When one page is enough
A single-page site can be a rational choice when the business has one clear offer, a narrow audience and service area, a short explanation, limited proof to organize, a simple next action, and no separate search intents to support. It is also a reasonable first version while an owner is still settling the offer.
The tradeoffs show up when unrelated questions start competing for the same scroll. Navigation turns into a set of jumps instead of real destinations. A visitor can't easily share one focused service explanation. Search has fewer specific pages to choose from. And you lose page-level measurement — with everything on one URL, your analytics can't tell you which service is actually pulling inquiries, which is exactly the signal a growing service business wants next. None of that makes one-page sites wrong; it makes their fit conditional.
When separate service pages are worth it
Split out a service page when you can write a genuinely different answer to most of these: What is the service? Who is it for? What situations fit or don't? What does the process involve? What affects price or timing? What proof applies? Where is it available? What should the visitor do next? If the answers are materially different, separate pages help the visitor and give you cleaner destinations for internal links, campaigns, and measurement. If the answers are identical except for a keyword, combine them.
A page for every city? Usually not
Serving a city does not automatically justify a city page. A location page earns its URL when it can honestly carry real differences — a staffed location, different services or availability, different licensing, genuine local project evidence, a distinct routing path, meaningful travel or scheduling or pricing detail, or questions specific to that market. Cloning a page and swapping the city name creates maintenance work and little reader value, and drifts toward the substantially-similar pages Google flags. The RP article on separate city pages goes deeper; the page-count rule here is just: geography has to change the useful answer.
Should every FAQ become a page?
No. Promote a question to its own page when it represents a substantial reader job that deserves a complete, independently useful answer. Keep it in the FAQ when the answer is short, depends on the parent page, or would go thin and repetitive on its own. A separate page should earn its URL — which also keeps a content plan from turning into fifty keyword-shaped fragments whose main purpose is linking back to the service page.
Page count and search, briefly
More pages do not buy a ranking advantage. Google's SEO Starter Guide recommends organizing a site logically and using clear titles and useful internal links because that helps people and search engines understand how pages relate — none of which turns quantity into a guarantee. A new page becomes a useful search destination when it answers a distinct query with enough real information to stand on its own; a new page can just as easily dilute attention, duplicate material, go stale, or compete with another page on your own site. Before adding one for search, ask whether it answers a distinct decision, is meaningfully different from what exists, can be linked to naturally, holds enough to stand alone, and can actually be maintained. If not, a section on an existing page is the better search page.
Page count and cost, briefly
More distinct pages usually mean more work — discovery, copy and fact-checking, design or template work, proof and photography, forms and integrations, redirects, accessibility review, analytics setup, testing, and approvals — but the work does not rise in clean per-page units. One complex page can cost more to settle than several straightforward ones. Worth knowing: not every provider prices by the page at all; some (including flat-package builders) price the outcome and fold the page set into a fixed scope, which is one more reason page count alone won't tell you what a site should cost. The companion article on small-business website cost covers the full model; for the sitemap, just remember that "more pages" and "more expensive" are not the same axis.
The page-decision worksheet
This is the asset I would actually use to judge a sitemap, because it makes a provider explain the architecture in business terms. Before you approve the sitemap, complete one row per proposed page:
| Proposed page | Primary reader | Distinct question | Distinct proof | Availability difference | Next action | Why not combine it? |
|---|---|---|---|---|---|---|
| Emergency repair | Customer with an urgent failure | Can someone help now, and what counts as an emergency? | Relevant response/process evidence | After-hours rules | Call | Timing, qualification, and action differ from planned service. |
Then mark each page keep (clearly distinct reader value), combine (useful content, not its own destination), defer (worth it once a service or its evidence is ready), or remove (exists only because a template or package expected it).
Comparing two proposals with different page counts
If one proposal lists five pages and another lists fifteen, don't assume the bigger number is more complete. Compare what the pages actually cover: which reader decisions are handled; which services and locations get distinct, substantive pages; who writes and approves the content; which pages are custom versus shared templates; what proof and media must be produced; which forms, integrations, and tracking events are included; what existing URLs must be preserved or redirected; what happens when a planned page has no real content; what a page added later costs; and who maintains the larger set after launch. You may find the five-page proposal quietly merges three important services into one vague page — or that the fifteen-page proposal manufactures ten variations with nothing distinct to say. The count answers none of that by itself.
Build the smallest complete site — then count
Build the smallest website that fully supports the important reader decisions, and no smaller. Split a page when the reader, question, proof, availability, action, or required function genuinely changes; combine it when the answer stays the same; defer the pages that don't yet have honest substance to fill them.
Then count. That number is the one worth putting in a proposal, because every page in it has a reason to exist.