Thin content is a ratio between what the page promises and what it delivers.

Someone searching a product's maximum upload size wants a number. A page that explains why file sizes matter, then gives the number at the end, is thin for that intent even though it is long and accurate.

Thinness is therefore measured against what the reader came for, not against a word count. The same page can be substantial for a reader who wants an overview and thin for one who wants to configure something.

This is why the fix is rarely more words. It is usually a decision about which reader the page serves, followed by removing the material written for the other one.

A page that tries to serve a beginner, a practitioner and a buyer at once serves none of them, and reads as thin to all three.

Thin pages fail in recognisable ways. Naming the shape tells you whether to expand, merge or delete.

A model asked to write about a topic will produce the consensus view of that topic, because consensus is what most text in the training data contains. The consensus view is, by definition, what the reader already encounters in the first five results.

It also pads rather than specifies. Filling a shortage of facts with elaboration is the safest available move, so a page without supplied material becomes long and hollow at the same time.

The prompt is usually the limiting factor. A brief naming a keyword and a word count contains no information the model does not already have, so the page can only be a rearrangement of public knowledge.

Supplying one measurement, one work sample and one constraint to the same model produces a materially different page, which is the cheapest experiment available to anyone sceptical of this argument.

Padding is how thin pages pass word counts. The introduction explains why the topic matters, each section restates the previous one, and the conclusion summarises all of it.

A reader scanning for their answer finds the same sentence shape four times and concludes the page has nothing, which is a correct reading of the deliverable even if the topic is covered.

Density of claims is the better measure. Count the sentences that state something checkable and divide by the total. A page where one sentence in six is checkable is a page with a padding problem.

Cutting the padding does not make the page thinner. It makes the thinness visible, which is what you want before deciding whether to add substance or delete the page.

A product page with a name, a price, three specifications and a buy button is thin by every word-count standard and right for its job. The reader came to purchase, not to read.

Definitions, conversion pages and reference entries are similar. They are winning when they are short and complete, and the only measure that matters is whether a reader needs to go elsewhere afterwards.

The danger is template consistency: applying the same long-form structure to a page whose intent is transactional, because the template says 1,500 words. That produces padding where brevity was the feature.

Match the format to the intent before you write a single sentence. Deciding afterwards means deleting most of the draft, and most people do not.

The deletion test: remove each paragraph and ask whether the reader has lost a fact. Paragraphs whose removal changes nothing are padding, and a page made mostly of them is thin.

The question test: write the exact question the page exists to answer, then find the sentence that answers it. If that sentence is absent, or arrives after 600 words of context, the page is thin for its own purpose.

A third test for sets of pages: could two of them be swapped without a reader noticing? If so, one is redundant, and the redundancy is the substance problem rather than a wording problem.

Run all three on the pages that get traffic. Thin pages that nobody visits are not urgent; thin pages that rank are losing you the readers you already earned.

Not adjectives, and not length. These are the five additions that reliably make a page worth reading.

When three pages cover parts of one question, the strongest page is usually a merge. Take the best paragraph from each, delete the rest, keep one URL and redirect the others.

The result is a page that answers more than any of the originals and does not compete with itself. It is also less work than writing three better pages separately.

Merging feels like losing traffic, which is why it is resisted. In practice the page that survives consolidates internal links and signals, and the site's overall visibility improves even as the URL count falls.

Do it in one pass, not gradually. Half-merged content, with pages that link to both versions, leaves the duplication in place and adds a redirect chain.

A word target sets a floor on length and no ceiling on padding. Writers and models both respond by filling, because filling is easier than researching.

Use a claim budget instead. Three additions from the list above in every substantive page, decided in the brief before drafting. It sets the research requirement rather than the word count.

Then let the length fall where it falls. A page with two measurements, one limitation and a decision rule will find its own length, and it will usually be shorter than the template predicted.

Publish it and watch what happens to the query. A short page that ranks and keeps its traffic is evidence that the length was never the problem.

Before publishing, answer three questions in writing: what question does this page answer, what does it contain that the top results do not, and who is accountable for it being right.

If any answer is blank, the page is thin and you know it before anyone else does. The options are to add substance, merge it into a page that has some, or not publish.

The third option is under-used. A deleted draft costs nothing and a thin page costs credibility every time someone lands on it, which is a compounding loss rather than a one-off.

Keep the answers in the page record. The next person maintaining it will need to know what it was supposed to be, and that record is also what stops a thin page quietly returning in a refresh.