Short answer: "thin" gets used as a feeling. In THINN it's a number. A page is thin when its server HTML carries under 800 characters of visible text once scripts, styles and tags are stripped. THINN checks up to 30 URLs, usually one per template, and gives each one a verdict, an owner (Marketing or Dev), a priority and a fix.
Usage is in THINN: how it works. This is the reasoning behind the number.
What you paste in
URLs, up to 30 per run. Pick one or two per template, not 30 of the same: category hubs, tag pages, location pages, filtered listings, the long tail of a CMS. THINN is a template-level check, so it pays to sample templates, not articles.
The checks, in order
THINN follows redirects, reads the final page, and stops at the first failure:
- Couldn't prove (P0, Dev): the final status isn't 200, or the fetch failed.
- Thin body (P0, Marketing): under 800 characters of visible text. Fix: expand the unique value on the template (purpose, proof, FAQs), and don't ship near-empty hubs.
- Multiple H1s (P1, Dev): more than one
h1. One per template, and demote the extras to H2. - Hub noindex (P1, Dev): the page says noindex. Confirm that's intended. If the hub should rank, remove the noindex and strengthen it.
- Missing or weak title or H1 (P1, Marketing): no title, or no H1. Add a clear title and a single H1 that match intent.
- Looks OK (P2): no thin-hub ticket from this sample.
The order is deliberate. A thin page with two H1s is a content problem first. Fixing its headings won't make it worth indexing.
Why 800 characters
800 characters is a low bar: a few short paragraphs. THINN isn't saying 801 characters is good. It says that below this, the template almost certainly has nothing of its own to say. The count includes all visible text in the HTML, so navigation and footer text add to it. That's why a hub with a big menu can pass THINN and still be empty where it matters. Treat a pass as "not obviously thin", never as "good".
Edge cases
- Client-side rendered pages. THINN reads the HTML the server sends, before any JavaScript runs. A page that builds its content in the browser can read as thin here. That's a useful warning on its own: you're relying on Google's rendering step to see the content.
- Redirects are followed. THINN judges the page you land on and records that it moved.
- Non-HTML responses have no text to measure and will read as thin. Don't feed it PDFs.
Worked example
https://samplebrand.test/kits/ (category hub)
https://samplebrand.test/tags/teal (tag page)
https://samplebrand.test/stores/north-street (location page)
Live: row 1 200, 6,400 chars, 1 x h1, indexable
Live: row 2 200, 310 chars, 1 x h1, indexable
Live: row 3 200, 2,100 chars, 2 x h1, indexableVERDICT: OK, THIN (P0 Marketing), MULTI_H1 (P1 Dev)
The tag template is the thin one: a heading and a list of links. Either give tags a real purpose and some copy, or noindex the template and take it out of the sitemap. Then prove the noindex can be read with VEXA. The location template has a stray second H1, which is a one-line template fix.
The money angle
Thin templates multiply. One weak tag template on a large CMS can produce thousands of URLs, each one asking Google to crawl and judge it. That's the pattern behind many thin-content manual actions, and behind sites where every new page seems to start from a lower bar.
Fixing it is cheap at template level and expensive page by page. If a manual action is already in play, start with how to check for a Google penalty, then see Google penalty recovery.