How Many Pages Does a Site Need Before Search Takes It Seriously?

Someone has told you your site is too small. Possibly an audit, possibly a competitor with four hundred blog posts sitting above you in the results. The recommendation attached to it is almost always a number: publish sixty articles, reach two hundred pages, and then search will take you seriously. There is no such number. Chasing one is a reliable way to acquire the exact problem you came in to solve.

The honest answer is that a site needs enough pages to cover one subject completely, from the angle a real person arrives at it. That is a question about coverage, not volume. Site size and SEO are related, but not in the direction the question assumes. Size is a consequence of having covered something properly. It has never been the cause of being taken seriously.

This distinction is not academic. It decides whether the next two quarters produce an asset that keeps earning attention, or three hundred pages that need pruning by someone who has to work out which of them ever mattered. Those two outcomes cost roughly the same to produce. Only one of them is worth having.

Page count is the wrong unit

Search engines do not hold a threshold at which a domain becomes credible. What they hold is a set of judgements about individual pages and the relationships between them. Does this page answer the query someone typed? Is there anything on it that is not available on twenty other pages? Does the rest of the site support the claim this page is making, or contradict it?

A page count is a proxy for those judgements, and a poor one. Three hundred pages restating the same advice in different words establish nothing except that somebody has a content calendar. Thirty pages answering thirty genuinely different questions, linked to each other in a way that shows how they relate, establish quite a lot.

This matters because "publish more" is among the most common findings in a bought audit. It is easy to produce, easy to invoice against and hard to argue with in a meeting. Our parent company has written on how to read an audit you were sold, and the same test applies to any volume recommendation: ask what it predicts will happen, by when, and how you would know if it had not.

Our position, stated plainly: the smallest site that fully answers one subject will out-perform the largest site that partially answers ten. We would rather defend thirty pages that a specialist wrote than three hundred that a schedule produced, and that preference has practical consequences for how a plan gets built.

What site size and SEO really measure

If the number is not the target, something has to be. The target is coverage of a topic a searcher would recognise as a topic. Two ideas do most of the work here, and both of them are checkable without a tool.

A topic a searcher recognises

A topic is not a keyword and it is not a heading in your navigation. It is a subject a person would recognise as the thing they currently have a problem with, described in their words rather than yours. Warehouse automation is a topic. Choosing warehouse automation software is a topic. "Our capabilities" is not a topic. It is a page about you, filed under a subject nobody searches for.

The practical difference shows up in the second question a reader has. On a real topic, you can predict it. Someone reading about choosing warehouse software next wants to know what integration with an existing stock system involves, what happens to historical records, and who in their team ends up owning it. Each of those is a page. On a fake topic, there is no second question, because nobody was asking a first one.

The question set test

Write down every question a buyer asks between first suspecting they have this problem and signing something. Not the questions you wish they asked. The ones that actually arrive by email, in calls, in support tickets and in the awkward pause halfway through a proposal.

If you can answer all of them in public, with a page each where the question genuinely deserves its own page, you have covered the topic. That list is your page count. It is usually smaller than the audit suggested and larger than a founder hoped, and it has the useful property of being finite. Assembling those answers into something a search engine can follow is the subject of building a cluster search can actually read.

Thin content is not short content

A two-hundred-word page that answers one specific question completely is not thin. A long page that restates the query, defines the terms, offers five generic tips and closes with a call to action is thin, because a reader finishes it knowing nothing they could not have guessed on the way in. Length is a symptom people measure because it is easy to measure. Usefulness is the actual variable.

Five signs a page is thin, none of which involve a word count:

• It would work with a competitor’s logo on it. Nothing in the page depends on who wrote it, what they do, or what they have seen go wrong.
• Nothing in it could be wrong. There is no claim anyone could disagree with, which means there is no claim.
• It answers the question in paragraph one, then keeps going. The remainder exists to reach a length, and readers can feel it by the third subheading.
• Nobody in the business would read it voluntarily. If your own specialists skim it, a buyer with three tabs open will not read it at all.
• Deleting it would change nothing. No other page depends on it, no query needs it, and no reader would notice it had gone.

Thin pages are not neutral, which is the part teams underestimate. They absorb internal links that should be pointing at pages you want to win with, and they spread a subject across so many weak documents that no single one reads as the answer. That is why internal linking is the cheapest work available and also the first thing a bloated site loses. Google’s own guidance on people-first content is unusually direct about this: the question is whether someone leaves satisfied, not whether a page hit a target.

Cannibalisation: the cost of splitting one intent

Cannibalisation is what happens when several of your pages chase the same intent. Not the same keyword, necessarily. The same underlying want. Three articles on choosing a supplier, written eight months apart by three people, each covering most of what the others cover.

The symptom is a position that oscillates between pages rather than improving, and a set of results where the page you would want someone to land on is never the one that appears. The cause is nearly always a plan built from a keyword tool rather than from questions, because a tool will happily hand you nine variations of one intent and call them nine opportunities.

The fix is consolidation, and it is unglamorous. Choose the page that should win, fold the useful parts of the others into it, then redirect the rest permanently so the accumulated value has somewhere to go. Doing this at scale, over an archive with years of history behind it, has its own method, set out in how to migrate ten years of pages. Deleting without redirecting is not consolidation. It is subtraction.

Thirty considered pages against three hundred spun ones

Both plans consume a similar budget. They differ on almost everything that happens afterwards, and the differences compound in opposite directions.

A site is taken seriously when a reader can finish a question on it, not when it reaches a page count somebody quoted.

How to size a cluster from real queries

Here is the method we would use to arrive at a number you can defend. It takes a couple of days and it replaces the guess entirely.

Where the questions come from

Four sources, in descending order of usefulness: the questions your team answers in sales conversations, the questions arriving in support, the queries already bringing people to the site in Search Console, and the phrases a keyword tool suggests. That order is deliberate. The first two are evidence of demand from people who were prepared to spend time on you. The fourth is a hypothesis with a volume estimate attached.

1. Collect the raw questions verbatim. In the words they arrived in, without tidying them into marketing phrasing. The tidying is where the meaning gets lost.
2. Group by intent, not by wording. Two questions belong together when the same answer satisfies both. That test is stricter than similarity and it prevents most cannibalisation.
3. Discard the ones you cannot answer better than anyone. A page you write only because a tool suggested it will read exactly like a page written for that reason.
4. Assign a page to each surviving group. The count of surviving groups is your cluster size. That is the number you were looking for, and it came from evidence rather than a benchmark.
5. Name the hub. One page has to be the entry point that links to all the others and states the position. Without it you have a list, not a cluster.
6. Decide what would make you delete a page. Write the condition down now, while nobody is attached to anything, and revisit it in a year.

Where one page ends and the next begins

The boundary rule we apply: split into two pages when a reader arriving at each one would be in a different situation, and keep them together when they would be the same person at the same moment. Someone deciding whether they need a thing and someone comparing two vendors of that thing are different people. Someone asking about price and someone asking about contract length are usually the same person, mid-decision, and deserve one page.

When more pages genuinely is the answer

The argument above has a boundary, and it would be dishonest not to draw it. Some sites are legitimately large, and their size is not padding. A catalogue with thousands of distinct products, a documentation set covering every endpoint, a directory where each entry carries information that exists nowhere else: in all of those the page count is high because the distinct facts are numerous, which is the only good reason for a page to exist.

Once a site is genuinely large, the questions shift from editorial to structural. Crawlability, sitemap hygiene, faceted URLs, pagination and template quality start to matter more than any individual page does, which is the territory of technical SEO rather than of writing. It is also the point at which performance work stops being optional, and we have written about how far to take that in whether Core Web Vitals are worth chasing.

What does not follow is the middle case that gets sold most often: a services business with a dozen real offerings publishing weekly for a year because volume is the plan. That is not a large site. It is a small site wearing a large one, and the maintenance bill arrives regardless.

Where we would start

With an inventory, not a brief. Every existing page, the question it answers, and whether it answers it better than the first result currently does. That exercise usually produces three lists: pages to merge, pages to improve, and a short set of questions nobody has answered yet. Work that order. An audit that starts from questions rather than from a crawl gives you a plan instead of a task list.

The constraint that stops most of these plans is not writing. It is publishing: the specialist has the answer, and getting it live requires a developer, a ticket and a week. That gap is what a structured content workspace exists to close. A tool such as Acrosite generates the files, commits them and triggers the deployment, so the person who knows the subject is not queuing behind a release. Fix that before blaming the calendar.

And if you want one rule to take away: stop asking how many pages you need, and start asking which question you are willing to become the best answer to. Then count how many pages that takes. Usually it is fewer than thirty for a first cluster, and the second cluster only begins once the first one is finished. If you would like a second opinion on where a site stands, tell us what you publish and who writes it, and we will tell you what we would cut. Content and organic growth is where that work sits.