Thin content checker
Flags pages under 150 words, and under 100 as very thin, ignoring utility pages.
What TMOD checks
- Extracts the visible text of each crawled page and counts words, flagging anything under 150 words as thin and anything under 100 as very thin.
- Excludes essential and utility pages, contact, privacy, terms, and similar, using an AI classifier that recognises them in any language, so a legitimately short contact page is not counted against you.
- Cross-references the AI reviewer's per-page quality judgement, which classifies pages as high value, adequate, thin, low value or placeholder based on what they actually say rather than how long they are.
- Normalises URLs before comparing, so the same page reached with and without a trailing slash or a www prefix is not counted twice.
Why it matters
Thin content is the most frequently cited reason for AdSense rejection and one of the clearest quality signals in search. The reasoning is the same in both cases: a page that does not answer the question it appears to answer wastes the visitor's time, and a site made mostly of those pages is not worth sending traffic to.
Word count alone is a crude measure and we treat it as one. A 120-word page that answers a specific question completely is genuinely fine; a 900-word page that circles a topic without saying anything is not. That is why the AI reviewer's per-page judgement runs alongside the raw count, the count finds candidates, the judgement decides whether they are actually a problem.
The pattern that causes rejections is not one thin page. It is a site where thin pages are the majority, a few real articles surrounded by dozens of stubs, tag pages with one item, or auto-generated location pages. The ratio is what a reviewer responds to.
How to fix it
01Merge rather than pad
The instinct is to expand each thin page to clear the threshold. Resist it. Padding produces long pages that still say nothing, which is a worse signal than the original. Find the thin pages covering related ground, usually the same set flagged as near-duplicates, and combine them into one page that genuinely covers the topic, then redirect the old URLs.
02Delete what should not exist
Some thin pages have no reason to be indexed at all, empty tag archives, near-empty category pages, placeholder service pages you never filled in. Removing them or applying noindex improves the ratio immediately and takes minutes.
03Noindex generated archives you cannot remove
Many CMSs generate tag, author and date archives automatically, and most have almost no content. If you cannot delete them, noindex them, and do it with a meta tag rather than a robots.txt rule, since a blocked page can still be indexed. They are navigation, not content, and they dilute the average.
04Fix the template if every page is thin
If the report flags most of your site, the problem is not individual pages, it is that the template produces stubs. Location pages, product variants and directory entries generated from a database all hit this. Each one needs something genuinely specific, or it should not be its own URL.
Short pages that are meant to be short
Plenty of good pages are under 150 words and always will be. A contact page is an address and a form. A definition page that answers one narrow question in three sentences has done its job, and padding it would make it worse. A product page where the specification table is the content is not thin because the table is not prose.
The classifier excludes utility pages for exactly this reason, so most of these never reach the count. When one still does, the useful question is not how many words it has but whether someone arriving from a search result would feel answered or would immediately go back. If the honest answer is that they would go back, the length is a symptom rather than the problem.
The reverse case is worth watching too. A page can clear every threshold here and still be the emptiest thing on the site, which is why the count sets the floor and the per-page judgement decides. Treat a flagged page as a question rather than a verdict, and treat an unflagged page as unexamined rather than approved.
Where thin pages come from in the first place
Almost nobody sits down to write a stub. They arrive from the machinery around the writing. A CMS generating a tag archive for every tag ever used. An import that created a page per row of a spreadsheet. Drafts published to reserve a URL and never returned to. A category structure with more categories than articles.
The keyword-variant page is the deliberate one, and the one worth being honest about. Splitting a topic across near-identical pages to catch different phrasings produced traffic years ago; now it produces a set of pages that each cover a fraction of a subject, compete with each other, and fail the depth threshold together. One page covering the whole topic outranks the set it replaced more often than not.
Soft 404s manufacture the same problem without you writing anything at all. If missing pages answer 200 with a friendly not-found message, every mistyped URL, dead link and retired path becomes an indexable page of about thirty words, and a site can accumulate hundreds. Fixing the status code deletes that entire class at once, which is why it is worth checking before you start editing individual pages.
Questions
Why is 150 words the threshold?
It is deliberately low. It is not a target, it is the line below which a page almost certainly cannot have answered anything substantive, in any language and any format. Clearing 150 words does not mean a page is good; falling below it means it is very unlikely to be. The separate 100-word 'very thin' tier flags pages that are effectively empty.
My contact page is flagged as thin. Is that a bug?
Essential and utility pages are meant to be excluded automatically, identified by an AI classifier rather than English URL patterns, so this should be rare. If it is still flagged, the classifier read it as a content page, which is worth investigating, because if an AI reading the full page cannot tell it is a contact page, a crawler probably cannot either.
Does this count text in images or JavaScript-rendered content?
Text inside images is not counted, nor is it read by search engines, so the flag is accurate in that case. JavaScript-rendered content depends on the page: there is a separate JavaScript rendering check that specifically compares the raw HTML against the rendered output, and if a large amount of your text only appears after hydration, that check will tell you.
How many thin pages are too many?
There is no fixed ratio, because the judgement is holistic. As a working rule, if thin pages outnumber substantial ones you have a structural problem that no amount of new content will outrun until the existing pages are dealt with. A handful of thin pages on a site with fifty good ones is not what gets sites rejected.