Low Content Pages

What this issue means

Pages with very little substantive content relative to what the query needs. Not every short page is a problem, but a page that fails to satisfy the intent it targets usually is.

That phrasing carries the whole idea, so it is worth sitting with. "Thin" is a ratio, not an absolute. The denominator is what the query demands. A page answering "what time does the London Stock Exchange open" needs one line and a timezone note; padding it to a thousand words makes it worse, not better. A page targeting "how to migrate from Universal Analytics to GA4" needs configuration steps, screenshots, and edge cases, and a three paragraph overview is thin no matter how well written.

This is why word count thresholds fail as a diagnostic. Run a crawl, sort by word count, and the top of that list will contain perfectly good reference pages while genuinely thin content hides at 800 words because someone padded it. The word count is a place to start looking, not a verdict.

Why it matters

Low-content pages struggle to rank, often end up "Crawled: currently not indexed," and in volume they dilute your site's overall quality signal. Google evaluates quality at the site level, so thin pages drag down the strong ones around them.

The Search Console status deserves attention because it is the most direct feedback Google gives you. "Crawled: currently not indexed" means the crawler fetched the page, read it, and decided not to store it. That is a quality judgement rather than a technical error, which is why there is no configuration change that fixes it. Contrast it with "Discovered: currently not indexed," which usually points at crawl budget or internal linking instead, and needs a completely different response.

The site level element is the part that catches people out. A page can be individually acceptable and still be part of a pattern that costs you. If a section of the site consists of hundreds of near identical URLs generated from one template, the assessment is made against that pattern, and improving one of those pages changes nothing. That is the reasoning behind step three in the triage above: the template is the unit of work, not the page.

Finding them without guessing

Three data sources, cross referenced, will produce a defensible list. Any one of them alone produces noise.

The Near Duplicates report is the one that changes the shape of the project. Set the similarity threshold to around 90 percent and it will group your templated pages into clusters, which converts a list of 400 individual tickets into one template fix. Enable "Store HTML" and "Near Duplicates" in the crawl configuration before you run it, because neither is on by default and neither can be computed retroactively.

How to fix it

1. Expand the page with genuine value (original detail, examples, data) if the topic deserves it.
2. Consolidate several thin pages on one topic into a single strong resource and redirect the rest.
3. Remove or noindex pages that will never deserve to rank.
4. Fix the source: templates or processes that mass-produce thin pages.

A note on the order of those four

Those options are listed by type, not by preference, and the order you apply them matters more than the list itself. In practice, expansion and consolidation resolve the large majority of cases, and removal should be the last resort rather than the opening move. Deleting a URL discards whatever query coverage, internal link equity, and external links it had accumulated, and none of that comes back. A page that ranks for nothing today may still be receiving impressions for long tail queries that never surface in a clicks report.

Before removing anything, check three things: whether the URL has any external links pointing at it, whether it has impressions for any query in the last twelve months, and whether it is the only page covering a subtopic your competitors do cover. If any of those is true, enrich or merge instead. Reserve removal for URLs that are genuinely artefacts: expired inventory with no successor, test pages, tag archives created by accident.

What enrichment actually means

Adding words is not enrichment. The test is whether a reader who arrives with the target query leaves without needing another tab. Practically, that means adding the things a general purpose summary cannot contain:

• Specifics you can only get from doing the work: the exact menu path, the actual header value, the error message as it really appears.
• A worked example with real inputs and real outputs, rather than a description of what an example would look like.
• Decision criteria: when this approach applies and when it does not. The boundary conditions are usually the most valuable part and the most commonly missing.
• A table or diagram that reorganizes the information rather than restating it, which is also what tends to get quoted by AI answer engines.
• The failure modes: what breaks, what it looks like when it breaks, and how to tell it apart from a similar looking problem.

When consolidating, redirect with a 301 from every merged URL to the survivor, and make sure the survivor genuinely absorbs the unique content from each source rather than just being the longest of them. A merge that quietly drops the one useful paragraph from each of five pages produces a sixth thin page.

Related: Duplicate Content FAQ

Two further references worth having open while you work: the thin content definition covers how the concept is assessed, and the Search Console page indexing report guide explains how to read each exclusion status so you do not treat a quality problem as a crawling one. If you are working through a large backlog, the content audit process gives the sequence for prioritizing at volume.

FAQ