How Many Pages Should a Business Website Have? A Page Plan

The most common question at the proposal stage is this: "how many pages should our site have?" It sounds innocent, but it carries an assumption — that the page count is a budget line. In projects built on that assumption the page count becomes a bargaining chip, it drops from eight to five, and three months after launch it gets reopened because "it turns out we need that page too" — and every reopening means a fix to the address structure.

The page count is not a cost line, it is a decision about which questions get an answer. Every page is a door that someone walks through with a question. If the door is not there, the person asking either goes to a competitor's door or wanders around the site and leaves. So the right question is not "how many pages" but "which questions come to us, and where do we answer each of them".

What follows explains how to build the page plan as a table: which question is answered on which page, when a separate page per service is needed, how many headings the menu carries, and how to set the plan up from the start if a second language is coming.

Page count is not a budget line, it is a decision about answering questions

What determines a site's page count is not the size of the business but the number of questions the business has to answer. If a two-person consultancy offers six separate services, there are six separate families of questions. If a fifty-person manufacturer sells a single product group, there may be only one.

Deciding the page count without making that distinction produces mistakes in both directions. When too few pages are opened, one page tries to answer several questions at once and answers none of them well enough; the visitor cannot find the detail they came for, and the search engine cannot work out which question the page corresponds to. When too many pages are opened, pages that look very much alike appear, none of them stands apart from the others, and an archive that nobody maintains piles up.

The right starting point is the question, not the budget. The questions the sales team answers most often on the phone, the recurring topics in incoming emails and, if there are any, the existing queries in the search console — put the three together and a list emerges. The page plan is that list, grouped.

Every page answers a question: page–intent mapping

The core of a page plan is a one-line sentence: "This page meets a person who arrives with this question and takes them to this next step." If that sentence cannot be written for a page, the page has no reason to exist.

The sentence has three parts. The first is the question: what does the person want to know. The second is the answer: what is the essence of the reply the page gives. The third is the next step: what the person should do once they have the answer — fill in a form, make a call, move to another page, or simply leave better informed.

The third part is the one skipped most often. "Leaving better informed" is a valid next step too, and for some pages it is the right one; but it has to be a conscious decision. Putting the same contact form on every page is not a decision, it is not deciding.

Once this mapping is written, the page count reveals itself. Two rows that ask the same question in two different ways merge into one page; two rows that need different answers become separate pages.

A separate page per service, or a section on one page

This is the structural decision that comes up most often. The deciding criterion is not aesthetic; it is the answer to three concrete questions.

Do the services go to different audiences? If the same person needs both services, a section on one page can be reasonable. If different audiences arrive with different questions, a separate page is needed, because copy that addresses two different people at once on the same page fully serves neither of them.

Is there a distinct scope, process and set of limits to explain for each service? Explaining a service honestly usually takes a few hundred words: what gets done, how it progresses, what it does not cover, what it is measured against. If those four headings can be filled, the service earns its own page. If they cannot, it is not a service but part of another one.

Is a separate address needed? If you will link straight to that service from a sales conversation, a proposal, an email or an ad, it needs its own address. Linking to a section of a single page is possible, but the visitor lands in the middle of the page and misses the context.

If all three questions come out "yes", it is a separate page; if all three come out "no", it is a section. If the answers are mixed, the default choice is a section, because promoting a section to a page later is cheaper than demoting a page to a section — the second means removing an address and writing a redirect.

"Who" versus "what": sector pages and service pages

The most productive split in a page plan is separating the pages that explain what you do from the pages that explain who you do it for. The two arrange the same information around a different question.

A service page answers the "what" question: what does this work cover, how does it progress, what does it not promise. The visitor knows the name of the service and is looking for the detail.

A sector page answers the "who" question: how does this work run in our sector, what are our constraints. The visitor may not know the name of the service; they are looking for a page that describes their own situation.

These two pages explain the same service but meet different people, and their content is genuinely different: the sector page holds the constraints, regulations and typical objections specific to that sector, while the service page holds the scope and the process. This site is split the same way; on our solutions page you can see why the sector-based pages stand apart from the service pages.

When the split is not made, both pages say the same thing, suppress each other, and it becomes unclear which one answers which question. We covered the cost of producing pages that describe the same service over and over, and how to build a topic cluster, in detail in our article on semantic content strategy.

Is the blog part of the page plan?

In most projects the blog gets thrown into the "we'll deal with it later" box, and that is one of the most costly postponements made at the planning stage. A blog is not a content area, it is an address space: whether it opens, which address structure it uses and whether it has category pages are all part of the page plan.

The decision rests on three questions. Will there be regular output? Even one post a month is a rhythm; if nothing will be produced, opening an empty blog section weakens the site. Which questions will the blog answer? Questions that carry no purchase intent but show the business's expertise belong to the blog; questions with purchase intent stay on the service page. Who will write? If the answer is unclear, the blog stays in the plan but does not go live.

If the blog is going to open, its address structure should be decided at the start. Putting a date or a category into post addresses means that when the category changes later, the address changes too. A plain, permanent address structure makes every later edit cheaper.

How many headings the menu carries, and where the rest go

The menu is not the page plan itself; it is the most visible slice of the plan. A site can have forty pages and five headings in the menu; that is not a shortfall, it is a choice.

The headings that go in the top menu are the ones that affect the visitor's decision in the first moment they arrive. The rest live at the second level: links from service pages to one another, the footer, related-content blocks and links in the body copy. A page not being in the menu does not make it unreachable; not getting a link from anywhere does.

The practical criterion is this: for every heading in the menu, ask "does this heading correspond to a decision a visitor will make in their first thirty seconds". If the answer is no, that heading belongs not in the menu but inside the page it belongs to.

Menu depth is a decision too. Two levels are enough for most business sites; if a third level seems necessary, that is usually a sign the groups were set up wrong.

If a second language is coming, how to set up the plan from the start

A second language is not a translation job, it is an address decision. Even if it is not yet known at the page-plan stage whether a second language will come, if there is a chance it will, the address structure should be ready for it.

The critical point is this: every language should have its own address. In setups where the language only changes in the browser and the address stays the same, the content in the second language stays invisible to the search engine — because the address being crawled returns content in a single language. This is one of the structural mistakes that is most expensive to fix after launch; we wrote in detail about the address structure options and about two addresses declaring each other reciprocally in our article on multilingual GEO and hreflang.

The second decision on the planning side is scope: not every page has to be translated. Which pages will have a counterpart in the second language is marked in the page plan. Rather than publishing a half-translated section, having the translated pages complete gives a better result.

The cost of splitting one topic across two pages

As a page plan grows, cases appear where the same topic ends up spread over two separate pages. This is not always a mistake — if a topic genuinely divides into two different questions, two pages are right. The mistake is splitting the same question across two pages.

The way to tell the difference is simple: put the two pages' titles side by side and ask "which one should a visitor open". If the answer is not clear, the visitor cannot tell either, and neither can the search engine. In that case the two pages get shown in place of each other, and neither can fully come to the front.

The way to prevent this at the planning stage is to fill in the "question this page answers" field for every page, and if the same question is written in two rows, merge the rows. Fixing it after launch means removing addresses and writing redirects.

Splitting by geography carries the same risk. Duplicating the same service under different city names, when there is no real difference between the pages, produces pages inside the plan that suppress each other; we discussed separately when such pages make sense in our article on city-based service pages.

What a page plan deliverable looks like

A page plan is not a mental model, it is a document. Before moving into design, it should become a table carrying these columns.

The "Content owner" column is the business's concern, not the designer's, and it is exactly the line item that delays projects most: a page waiting for copy cannot go live for longer than a page whose design is finished.

The "Status" column is mandatory in redesign projects; this is where you settle whether an existing page will be moved or not. We set out in detail how the scope is written and what the delivery stages are on our corporate website service page.

Once this table is ready, the skeleton of the brief you will hand to an agency has emerged as well; we covered the scope, revision and handover items separately in our article on the website brief.

If you would like to work out your page plan together and see which questions your current structure leaves unanswered, you can write to us.

Frequently Asked Questions

Is a five-page site too small?

The number on its own says nothing; the criterion is the number of questions the business has to answer. For a business that offers a single service and sells to a single type of customer, five pages can be more than enough, and five well-written pages will do better than twenty pages that repeat each other. On the other hand, for a business with six different services, five pages means that four of the services are not explained in detail anywhere. Before deciding, list the questions the sales team answers most often; the page count comes out of that list.

When is a one-page site the right decision?

A single page can be right when there is only one offer to explain and all the information a visitor needs to decide fits into a single flow: a new venture with one service, a single event, or a page opened for a single product. Its limit is this: because the sections of a single page do not each have their own address, no section can be presented on its own as the answer to a question. If there is more than one service or more than one audience, a single page puts an early ceiling on growth.

Can we be visible without a blog?

Yes, but the scope of that visibility narrows. Well-written service and sector pages answer questions with purchase intent, and for most businesses these pages bring in the real demand. What a blog answers is different: the questions of people who are not ready to buy yet, who are describing a problem or trying to make a decision. Not answering those questions is not a mistake, it is a choice — but it needs to be known that it is a choice. If regular output is not possible, not opening a blog is better than opening one and leaving it empty.

How many headings should we put in the menu?

Using a criterion instead of a number is safer: every heading in the menu should correspond to a decision the visitor makes in the first few seconds. On most business sites the number of headings that pass this test falls between five and seven; the rest live in sub-menus, related-content blocks and the footer. A page that is not in the menu does not become unreachable — the page that becomes unreachable is the one that gets a link from no other page. That is what really needs checking when designing the menu.

Is it expensive to change the page plan later?

It depends on the kind of change. Expanding a page's copy or adding a new page is cheap. What is expensive is the kind of edit that changes the addresses of existing pages: merging pages, splitting them, or rebuilding the address structure. Changes like these require writing redirects, updating internal links and waiting for the search engine to process the new structure again. That is why spending time at the planning stage is clearly cheaper than fixing things after launch.