Thin content pages

Generated sets. A page per city, per colour, per combination of filters, each built from one template with a few values substituted. The set can be enormous and every page says the same thing.

Placeholders that shipped. A section created during a launch, given a heading and a sentence, and never finished. These are usually few and easy to fix.

Pagination and filtered views of a listing, where the page contains only links and the product descriptions live elsewhere.

Tag and category archives that contain a single item, which are effectively duplicates of that item with extra navigation.

Syndicated or scraped text republished with nothing added, where the page exists but the substance belongs to someone else.

Google's guidance describes helpful content in terms of whether a page satisfies the person who arrived, not its length, and it states plainly that there is no minimum number of words.

The practical reason to distrust length is what optimising for it produces: an introduction restating the title, a history section nobody asked for, and a conclusion repeating the introduction. The page gets longer and less useful, which is the failure it was meant to fix.

A better internal question is whether the page contains anything a reader could not get from the page that links to it. If the answer is no, length will not save it.

Where a count does help is as a floor for triage on a large site: pages with almost no text are worth looking at first, not because the number condemns them but because it is a cheap way to find the ones nobody finished.

In Google Search Console, the Page indexing report's 'Crawled — currently not indexed' category is the closest thing to a direct answer. It means Google fetched the page and chose not to index it, which for a thin page is exactly what you would expect.

On a page, compare the text inside the main content region with the text in the header, navigation and footer. A page where the boilerplate outweighs the content is thin however long the HTML is.

Across a site, look at the distribution rather than individual pages. A cluster of near-identical short pages produced by one template is one decision to make; twenty scattered short pages are twenty small edits.

Merge. Several thin pages on closely related subjects usually want to be one page that covers the subject properly, with the old URLs redirected to it. This is the most common right answer and the one that reduces the page count.

Fill. A page with a real reason to exist and nothing on it should be written or removed. Deciding which is the work; leaving it half-written is the state to avoid.

Remove and redirect. A page that exists because a template generated it, and that nobody would miss, can go. Redirect it if anything links to it, serve 410 if the removal is deliberate and permanent.

What does not work: adding text to pass a threshold, spinning one page into twenty variants, or asking for re-indexing without changing the page. Google's judgement was about the content, and only the content changes it.

`structure.html_quality` examines the served HTML of each crawled page and reports pages whose own content is very small relative to the document, with the URL of each.

It sits beside `structure.duplicate_content`, because thin and near-duplicate usually travel together: a generated set is both.

The report gives you the list and the shape. Whether a given short page is a stub or a perfectly good short answer is a judgement about intent, and no crawler has access to that.