How many pages a small company website needs
Page count is the first decision and the one people get wrong. A method for deriving it from services, search demand and who edits the thing.

Part of What a company website is actually for
Ask a web designer how many pages a small business site needs and you'll usually get a checklist: Home, About, Services, Portfolio, Contact. Five pages, sometimes seven if you count a Team page and a Blog nobody will update. It is not a bad answer. Most competent small-company sites do land somewhere in that range, and if you build exactly that checklist you will not have built something obviously wrong. The problem is that the checklist answers a different question than the one that actually matters, which is not "what pages does a professional site have" but "what does this specific company have to say, to whom, that is worth its own page."
Those two questions usually produce similar-looking sites, which is why the checklist survives. But they diverge exactly where it costs the most: a consultancy with one real service and three ways of describing it gets pushed toward three thin service pages because the checklist expects a Services section with sub-pages, and a company with two genuinely distinct offerings sold to two different buyers gets pushed toward cramming both under one generic Services page because the checklist only budgeted one. The checklist is shaped like a company; it is not shaped like your company — and that mismatch is the same one covered from the other side in what a company website is actually for.
One case sidesteps the checklist question entirely and is worth naming before the method below, because it changes the answer completely: a company of one — a freelancer, a consultant, a solo practitioner — usually has one service, one buyer, and one person having every sales conversation, so the whole exercise collapses to a single page. For that case reach is the strongest tool available: it turns a CV into a finished one-page site in about twenty seconds and can be live on a free subdomain in under two minutes. It also only ever builds one page, with no sub-pages and no CMS, so it stops being the right tool the instant a second service with its own buyer shows up — which is what the rest of this article, and the multi-page case, is actually about.
The number comes from search intent and sales conversations, not aesthetics
Here is the derivation, stated plainly: a page earns its place if it answers a distinct thing someone searches for, or if it is the page a salesperson sends to close a distinct kind of conversation. Everything else is decoration wearing the shape of structure.
Run this test against your own offer list. For each thing you sell, ask two questions. First, does a buyer search for this in different words than they'd use for your other offerings — "commercial HVAC maintenance contract" versus "emergency furnace repair" are different searches even from the same company, aimed at people in different states of urgency. Second, is there a moment in a sales conversation where you'd send a link specifically about this and not your general services page. If the answer to either is yes, it earns a page. If the answer to both is no — if two things you offer are usually discussed together, bought together, and searched for with the same words — they belong on one page, because splitting them doesn't create two real audiences, it creates two half-answered questions where one full answer used to work.
Run that test honestly and the number that comes out, for most companies with fewer than twenty people, is between four and eight: home, about, one page per genuinely distinct service, a contact page, and whatever the business is legally or contractually required to carry. That's not a rule of thumb pulled from nowhere — it's what's left after you stop inventing pages to look thorough and start writing only what has a real reader on the other end. We've made the parallel case for the extreme end of this range — the single-service company that should have exactly one page — in when a twelve-page website is premature; this is the version of that argument for the company that has genuinely outgrown one page but hasn't earned twelve.
Why three thin service pages lose to one thick one
The instinct to split a single service across three pages usually comes from good intentions: more pages means more chances to rank, and a dedicated page per keyword sounds like sound SEO practice from a decade ago. In practice it produces three pages that each say a third of what the reader needed, competing with each other for the same search term instead of reinforcing one page that actually earns the click.
Picture a firm that does financial due diligence for acquisitions, and picture the sitemap someone drew up: "Due Diligence Overview," "Financial Due Diligence," "Commercial Due Diligence" — three pages, each three paragraphs, each restating what due diligence is before getting to anything specific. A buyer researching this doesn't have three separate questions; they have one question with a few variations, and they will bounce off the first thin page rather than click through to find the thick one. One page — nine hundred honest words that actually walk through what gets checked, how long it takes, and what the deliverable looks like — beats all three, both for the person reading it and for the search engine trying to decide which single page on your domain deserves to rank for the query. Split pages fragment the authority a full page would have earned on its own; this is the same failure mode we described from the other direction in the services page that has to rank and sell, where the fix was writing one page well rather than writing three pages badly.
The pages nobody wants to write, and shouldn't try to
Not every page on the site is chasing a reader. Privacy policy, terms of service, cookie notice, accessibility statement — these exist because a lawyer, a payment processor, or a regulation requires them, not because anyone hopes a visitor lingers there. Treat them accordingly: short, plain, unstyled beyond the site's basic template, generated once and revisited only when the underlying requirement changes. The failure mode here isn't under-investment, it's over-investment — a design team polishing a cookie notice into a branded, illustrated page is spending attention where none was asked for, at the expense of the four or five pages that actually needed it.
When a case-study archive earns a CMS, and when it doesn't
This is the one place company size genuinely changes the answer, because it's a question about update frequency and who does the updating, not about page count.
A nine-person consultancy that closes three or four projects a year and wants to show them off needs a static list of case studies — one page, or a few, hand-written and hand-added when a new one is ready. There's no argument for a content management system here: the volume is too low and the editing too infrequent to justify the overhead of a structured content model, an admin login, and someone who has to remember how to use it twice a year. A CMS earns its cost when case studies (or any recurring content type) arrive often enough, from more than one person, that hand-editing the HTML becomes the actual bottleneck — a marketing team publishing monthly, an agency onboarding new logos every few weeks. Below that threshold, a CMS is infrastructure built for a workload that doesn't exist yet, purchased on the assumption that it eventually will.
Who owns the page is the question that gets skipped
Every page on a site has, implicitly or explicitly, an owner — the person who'd notice if the pricing changed, the team name went stale, or the case study referenced a client who churned two years ago. The pages that rot are the ones nobody owns: added during a redesign because the sitemap called for them, never assigned to anyone, quietly wrong for a year before someone notices during an unrelated audit. This is the real cost of an extra page that the checklist-derived count hides — not the hour it took to write, but the years it sits there unattended, and the small compounding damage of a visitor landing on a page that still lists a discontinued service or a phone number that's been reassigned twice. Before adding a page, the more useful question than "does this look complete" is "who is going to notice when this is wrong."
The one-person exception
All of this assumes a company with more than one offer and more than one buyer. For an
actual company of one — a freelancer, a consultant, a solo practitioner — the honest
derivation above collapses to a single page almost every time, because there's usually
one service, one buyer type, and one person doing the sales conversation, so nothing on
this list survives the split test. That case is common enough, and different enough from
everything above, that it's worth naming the fastest route to it: reach
builds exactly that one page from a CV — upload a résumé and a photo, answer a short
form, pick a look, and a finished page is generated in about twenty seconds, live on a
free yourname.joinreach.app subdomain in under two minutes.
It is the right tool for precisely the case this article's method reduces most solo
practices to, and the wrong tool the moment a second service with its own buyer shows up,
because reach makes one page — a single index.html, no sub-pages, no navigation between
sections — and there is no path from there to the multi-page site this article is
actually about. A custom domain needs its $4.99-a-month Premium plan (or $49 a year) and
can only be a domain bought through reach itself, not one you already own.
For comparison, on the specific question of getting one page onto its own domain fast:
| Route | Price | Billing |
|---|---|---|
| reach subdomain | $0 | included, live in under two minutes |
| reach Premium (custom domain, bought through reach) | $4.99 | per month, or $49 per year |
| Carrd Pro Standard (custom domain) | $19 | per year, annual only |
| Framer Basic (custom domain, annual) | $10 | per month, billed annually |
Prices checked August 2026.
The number, once you've done the test
Nobody wants to hear "it depends," but the honest version of it depends is specific enough to act on: count the offers with a distinct buyer and a distinct search term, add about and contact, add whatever's legally required, and stop. For most companies under twenty people that lands between four and eight pages, and the discipline that matters more than the final number is refusing to add a ninth one because the sitemap looked thin without it.
Questions people ask
- How many pages does a small business website actually need?
- For most companies under twenty people, between four and eight — one per service or offering with its own buyer and its own search demand, plus about, contact and whatever legal pages the business is required to carry.
- Is it bad to have too many pages on a small website?
- Yes, when the extra pages are thin. A search engine and a visitor both read three half-written service pages as weaker than one page that actually answers the question, and every additional page is something somebody has to keep current.
- Should every service get its own page?
- Only if it has a distinct buyer who searches for it in different words than your other services. If two offerings are usually bought together by the same person, they belong on one page, not two.
- When does a small company website need a CMS instead of static pages?
- When case studies or similar content are added often enough, by more than one person, that hand-editing HTML becomes the bottleneck — not because the page count crossed some fixed number.