Is thin content the same as short content?

No. A 90-word answer that fully resolves the question is short and complete. A 1,200-word page that never answers it is long and thin. Length correlates with thinness because thin pages tend to be short, but the correlation runs the wrong way to be used as a test.

What should I do with hundreds of thin pages?

Pick one of three actions per group and apply it at the template level. Delete where the page serves nobody, merge where several thin pages together make one useful page, and noindex where the page has to exist for people but has nothing to offer a search result. Rewriting them one by one is rarely the right answer.

Do tag and archive pages count as thin content?

They do when they hold one or two items, which is most tag pages on most sites. An archive listing thirty relevant posts is a useful index. An archive with a single post is a worse copy of that post, and it should either not exist or not be indexed.

Thin content is a failure to satisfy, not a failure to fill

Thin is a judgement about whether someone got what they came for. It is not a word count, it has no threshold, and the pages that fail it hardest are usually the ones with the most text on them.

The short answer

Thin content is a page that does not satisfy the reason someone opened it, which is a judgement about substance rather than about length. It is manufactured at volume by four templates: auto-generated location pages, tag and archive pages with one item, product pages carrying only a manufacturer description, and stub profiles. Delete, merge, or stop indexing.

ImportantAudit check · Thin content

A verdict about satisfaction, not about volume

The test is whether a person arriving from a specific search leaves with the thing they were looking for. A page that does that in a hundred and forty words is not thin. A page that fails to do it in three thousand is, and the length made it worse rather than better, because the reader spent longer finding out.

Three shapes of failure, and none of them is short:

The page circles the question. Definitions, context, history, a paragraph about why the subject is interesting, and no answer. Common on pages written to a word target.
The page answers a different question. The searcher wanted to know whether the thing fits their situation. The page explains what the thing is. Both are about the same subject and only one was asked.
The page defers. The answer is behind a form, a call, a demo request or a login. Whatever the merits of that as a business decision, the visit ended without a resolution and the page will be treated accordingly.

This is why the check cannot be a threshold. Satisfaction is relative to an intent, and an intent is not a property of your HTML. What a report can do is rank your pages against each other on the signals that correlate with failing this test, and hand you the worst end of the list to read.

Four templates that manufacture it at volume

Individual thin pages are an editing problem. Thin pages in the hundreds are always a template, and it is nearly always one of these four.

Tag and archive pages a CMS creates by default. One heading, a list of three links, the site chrome. Multiply by every tag anyone has ever typed. These are the largest source of thin URLs on the web and almost none of them were a decision.
City and service permutations. The service page crossed with the location list. Twelve services in forty towns is four hundred and eighty pages, differing by a place name, and the pattern is well understood by the systems you are publishing them for.
Filtered result views with nothing in them. A facet combination that returns two products, or none. Crawlable, indexable, empty, and generated in the thousands by any faceted navigation left open.
Stubs waiting for content. A glossary of two hundred terms with fourteen written. A documentation tree with a page per method and a sentence in each. Genuine intent, shipped early, and indexed in the state it shipped in.

Volume changes the character of the finding. One thin page is a page. Four hundred is a pattern, and patterns get evaluated as patterns.

A site where most indexable URLs are template output has told a search engine something about itself as a whole, and that assessment is not repaired by improving one of them. This is the reason to treat a large thin-content finding as an architecture decision rather than a writing backlog: the question is not how to fill four hundred pages, it is whether four hundred pages should be indexable.

Delete, merge, or stop indexing

Writing more is the fourth option and the least often correct. Work through the first three before you reach it.

Delete, and redirect to the nearest useful page.Right when the page has no audience and no reason to exist. Empty tag archives, abandoned stubs, permutations nobody searches for. Deleting content feels like a loss and is usually a gain, because what you remove was competing with the pages you care about for crawl attention and for the site's overall assessment.
Merge upward into one strong page. Right when forty thin pages are facets of one subject. Twelve service pages become one service page with twelve sections, each answerable and each linkable by anchor. You lose forty URLs and gain a page that can actually compete.
Keep it and remove it from the index. Right when the page has a job that is not search: an internal filter, a printable view, a step in a flow. A noindex is the correct answer here and it is under-used, because teams treat de-indexing as an admission of failure rather than as saying what a page is for.
Write the page properly. Right when the intent is real, the traffic exists, and nobody has done the work. This is the expensive option, so spend it where the query is worth having and decline it everywhere else.

The decision that goes wrong most often is choosing the fourth for a set that needed the second. Four hundred pages each grown to eight hundred words is three hundred and twenty thousand words of filler, and the pattern that triggered the finding is still there, now more expensive to undo.

Worst-first is a ranking, and a ranking needs a set

The report orders your pages against each other, because that is the only honest form the finding can take: there is no absolute line above which a page is thick. A verdict on one page in isolation would be an opinion about your subject, which is not something a fetch can have.

This one needs the full crawl

The report ranks your pages worst-first, and a rank is a position among others. Thinness is comparative by definition, so a verdict on one page in isolation would be an opinion rather than a measurement.

The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.

Run the full audit, free

If what you want is the word count for one URL, that is a different check, and it will tell you the number while declining to tell you whether it is enough.

Does this affect AI search?

Yes, and the failure is quieter than it is in search, which makes it worse. A thin page is not rejected. It is retrieved, read, found to contain nothing that answers the question, and passed over silently in favour of a source that does. There is no ranking position to watch drop and no report telling you it happened.

The mechanism is the same one that makes thinness hard to fix by padding. Retrieval competes at the passage level, so what is being judged is whether some paragraph of yours resolves the question better than a paragraph of somebody else's. A page assembled from context and preamble has no such paragraph. A page with one direct answer in it has exactly one, and one is all that is needed.

Which means the remedy for AI visibility and the remedy for thinness are the same remedy, and it is not volume. Answer the question, early, in a passage that stands on its own. That is what answering first is for, and a page built that way is difficult to call thin at any length.

Why this sits above length and below duplication

Above length because it is the thing people mean when they ask about length, and because its verdict survives contact with reality. A page can be long and thin, short and excellent, and the word count cannot tell the difference. When the two checks disagree, this is the one to believe.

Below Critical because a thin page is not kept out of the results by any mechanism. It is indexed and served and it competes badly. Duplication is rated higher precisely because there the page can be excluded, and losing on merit is a different category of problem from not being shown.

The rating also reflects that the fix is often a deletion, and a finding whose remedy is to remove a page cannot be urgent in the same way as one whose remedy is to unblock a crawler. What earns it Important, rather than the bottom of the scale, is scale itself: this is the check most likely to be reporting hundreds of URLs at once, and hundreds of thin pages is a statement about your whole site rather than a note about one of them.

Sorting your own sitemap worst-first

You can approximate the ranking with a sitemap and a shell. It is crude, and it puts the right pages at the top of the list often enough to be worth ten minutes.

rank-thin.sh

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' \
  | while read -r url; do
      html=$(curl -s "$url")
      # words inside the article region only, so the footer does not rescue the page
      body=$(printf '%s' "$html" | tr '\n' ' ' \
        | grep -o '<main.*</main>' \
        | sed 's/<[^>]*>/ /g' | tr -s ' ' ' ' | wc -w)
      # how many of those words are links, a decent proxy for a list-only page
      links=$(printf '%s' "$html" | grep -c '<a ')
      printf '%s\t%s\t%s\n' "$body" "$links" "$url"
    done | sort -n | head -30

Read the first two columns together. A low word count with a high link count is an archive or a navigation page, which is usually a candidate for noindex rather than for writing. A low word count with a low link count is a stub, and it is either worth finishing or worth deleting.

Then take the ten worst and open them. The only reliable version of this check is reading the page and asking what a person searching for it wanted, and whether they got it before they left.

Questions this check raises

Is thin content the same as short content?: No. A 90-word answer that fully resolves the question is short and complete. A 1,200-word page that never answers it is long and thin. Length correlates with thinness because thin pages tend to be short, but the correlation runs the wrong way to be used as a test.
What should I do with hundreds of thin pages?: Pick one of three actions per group and apply it at the template level. Delete where the page serves nobody, merge where several thin pages together make one useful page, and noindex where the page has to exist for people but has nothing to offer a search result. Rewriting them one by one is rarely the right answer.
Do tag and archive pages count as thin content?: They do when they hold one or two items, which is most tag pages on most sites. An archive listing thirty relevant posts is a useful index. An archive with a single post is a worse copy of that post, and it should either not exist or not be indexed.