Thin Pages Get Deprioritized by Google: Diagnose, Merge, or Remove

Google quietly stops crawling and indexing your thinnest pages with no penalty notice. Here is how to find them and decide whether to expand, merge, or remove each one.

Fastest fix: Google won’t email you “your page is too thin.” It silently lowers processing priority for low-value pages. Run an inventory of every page under ~500 words, then for each one decide expand, merge (with a 301), or remove (410 or noindex). Adding filler to inflate word count does nothing — Google’s quality systems judge value, not length.

The deprioritization runs through four stages, none of which triggers a Search Console notification:

  1. Crawl frequency drops → the URL stops being re-crawled for weeks or months
  2. Ranking weight is discounted → even when indexed, the page never reaches the top 50
  3. Pattern-wide judgment → all URLs matching a pattern (e.g., /articles/auto-generated-*) get deprioritized together
  4. Eventually deindexed → dropped from “Indexed” after a few months

One thing changed since this topic was last common knowledge. Google’s old standalone “Helpful Content System” no longer exists as a separate, periodic update. In the March 2024 core update Google folded it into the core ranking algorithm, so the “is this site mostly helpful?” judgment is now a continuous, site-wide signal. As Google states it: if a site is found to have a relatively high amount of unhelpful content, even its genuinely helpful pages may perform worse. That is why the fix is rarely “add words” — it is raise real information density or actively clean up.

Symptoms

  • Pages under 100-300 words show a < 30% indexing rate
  • Indexed thin pages get demoted over time (rank drops, then traffic drops)
  • The Crawl Stats report (Settings > Crawling > Crawl stats) shows declining monthly hits on these URL paths
  • Many same-pattern URLs sit in the Page indexing report under “Crawled - currently not indexed” or “Discovered - currently not indexed”

Quick verdict

Google doesn’t need to flag thin pages explicitly. It just deprioritizes them — fewer crawls, lower ranking, eventually deindexing. The fix is to merge, expand, or remove. Re-submitting a page via Request Indexing changes nothing unless the page content itself changed first.

Which bucket are you in

Six patterns cause this. Three of them now map directly onto Google’s named spam policy, scaled content abuse (introduced March 2024), which targets pages “generated for the primary purpose of manipulating search rankings and not helping users.”

#PatternWhat it looks likeGoogle’s framing
1SEO page with no depthDefinition restatement + platitudesUnhelpful / low-value
2Mass AI pages, no unique angle50 articles, same structure, no fact-checkScaled content abuse
3Programmatic permutations/best-X-for-{city}/ × 1000, 90% identicalScaled content abuse
4Auto category/tag/archive pages/tag/seo with 1-3 posts, just H1 + cardsThin / duplicate
5Citations or quotes onlyReposts, roundups, “30 quotes about X”Scraping / no added value
6Content-empty pagesThank-you pages, empty search resultsSoft 404 / thin

1. SEO-generated pages with no content depth

Most common. You see a keyword has volume, write an article — but it’s all definition restatement and platitudes:

"What is X"
"Benefits of X"
"How to use X"
"X considerations"

Each section is 50 words of definition rephrase with zero unique information.

2. AI-generated pages with no unique angle

AI generates 50 articles at once, each 800 words, but all in the same style, same structure, no human fact-check, no firsthand experience. This is exactly what Google’s scaled content abuse policy describes: “using generative AI tools or other similar tools to generate many pages without adding value for users.” The policy applies regardless of how the pages were produced — the test is value to the reader, not the tool used.

3. Programmatic SEO output where pages are near-identical

/best-X-for-{city}/   → 1000 cities = 1000 pages
/{verb}-{noun}-prompts/ → 100×100 combos = 10000 pages

Each page differs only in the variable; the rest of the text is roughly 90% the same. Google flags this as template-thin. Programmatic SEO is allowed — but only when each page carries genuinely unique data (think flight prices or live inventory), not boilerplate with one swapped noun.

4. Auto-generated category / tag / archive pages

/tag/seo has 1-3 articles and the template is just an H1 plus a card list. These rarely deserve indexing on a small site.

5. Content that is only citations or quotes

Reposts, roundups, “30 quotes about X” — no original commentary. This maps to Google’s scraping policy when there is no added value.

6. Content-empty pages

Signup success pages, thank-you pages, empty search results, out-of-stock product pages — all return 200 but the body is nearly empty. These often surface as Soft 404 in Search Console.

Shortest path to fix

Step 1: Inventory all pages under 500 words

// scripts/find-thin-pages.mjs
import fg from "fast-glob";
import fs from "node:fs";
import matter from "gray-matter";

const thin = [];
for (const f of fg.sync("src/content/**/*.{md,mdx}")) {
  const { content } = matter(fs.readFileSync(f, "utf8"));
  const text = content.replace(/```[\s\S]+?```/g, "").replace(/!\[.*?\]\(.+?\)/g, "");
  const words = text.split(/\s+/).filter(Boolean).length;
  if (words < 500) thin.push({ file: f, words });
}
thin.sort((a, b) => a.words - b.words);
console.log(thin.map(x => `${x.words}\t${x.file}`).join("\n"));

Output is sorted by word count ascending — thinnest first. Cross-check each path against the Page indexing report (filter for “Crawled - currently not indexed”) to confirm which thin pages Google has actually declined to index.

Step 2: For each thin page, decide expand, merge, or remove

Ask three questions per thin page:

  1. Does the corresponding query actually get searches? (Check Keyword Planner, or look at the page’s impressions in the Search Console Performance report — zero impressions over 90 days is a strong remove signal.)
  2. Do I have unique information I can add? (Firsthand experience, original screenshots, data.)
  3. Is there an adjacent sibling page that could merge?

Decision:

  • Q1 yes + Q2 yes → expand
  • Q1 yes + Q3 yes → merge
  • Q1 no → remove

Step 3: Expand — add concrete content

Each item below moves the page up one tier in information density:

1. Add 1 original screenshot
2. Add 1 numerical comparison table
3. Add 1 real code / command snippet
4. Add 1 FAQ section (at least 3 questions)
5. Add 1 first-person observation ("We tested Y in March 2026 and got Z")

Target 800-1500 words with rich formatting. Before that, study the pages already ranking for the query and cover what they cover plus something they don’t — Google judges thinness relative to competing results, not against an absolute word count.

Step 4: Merge — combine 3-5 into one in-depth article

# Old URL list
echo "/articles/seo-tip-1
/articles/seo-tip-2
/articles/seo-tip-3" > to-merge.txt

# Merge into /articles/seo-complete-guide
# 301 all old URLs to the new one
// firebase.json
{
  "hosting": {
    "redirects": [
      { "source": "/articles/seo-tip-1", "destination": "/articles/seo-complete-guide", "type": 301 },
      { "source": "/articles/seo-tip-2", "destination": "/articles/seo-complete-guide", "type": 301 }
    ]
  }
}

The new article fuses the essence of the old ones plus new angles and data. The 301 passes the old pages’ signals to the master, so you concentrate authority rather than lose it.

Step 5: Remove — noindex or 410

For thin pages with no future use, keep them reachable but out of the index:

<!-- Stay accessible but not indexed -->
<meta name="robots" content="noindex,follow" />

Or delete the page entirely and return 410 Gone:

res.status(410).send("This page has been permanently removed.");

A 410 tells Google “this URL is gone on purpose and won’t return” more clearly than a 404. In practice 410 URLs drop from the index faster — often 1-2 weeks versus 2-4 weeks for 404 — and they leave the crawl queue sooner, freeing crawl budget. Note the nuance from Google’s John Mueller: Googlebot may keep re-checking removed URLs for a long time regardless of 404 vs 410, and that periodic re-check is harmless. Pick 410 when you are certain the page is gone for good; otherwise either works.

Step 6: Remove processed URLs from the sitemap

// scripts/clean-sitemap.mjs
import fs from "node:fs";

const sitemap = fs.readFileSync("public/sitemap.xml", "utf8");
const toRemove = fs.readFileSync("noindex-list.txt", "utf8").trim().split("\n");

let cleaned = sitemap;
for (const url of toRemove) {
  const re = new RegExp(`<url>\\s*<loc>${url}</loc>[\\s\\S]*?</url>`, "g");
  cleaned = cleaned.replace(re, "");
}
fs.writeFileSync("public/sitemap.xml", cleaned);

Leaving merged or removed URLs in the sitemap sends Google mixed signals (you’re telling it to crawl a page you 301’d away). Keep the sitemap to live, canonical, indexable URLs only.

How to confirm it’s fixed

  1. Run the URL Inspection tool on a fixed page, then click Test Live URL to confirm it renders and reports “URL is available to Google.”
  2. Click Request Indexing on the live test, then Validate Fix on the affected group in the Page indexing report.
  3. Track the URL path’s impressions in the Performance report over the next 4-8 weeks. Re-crawl and re-evaluation are not instant — expect roughly 4-8 weeks before indexing rates and rankings move.

When this is not on you

A small number of thin pages (contact, privacy, about) are fine. Google knows not every page should be 2000 words. The problem starts when thin pages exceed about 20% of the site — because the helpful-content signal is now site-wide, a large share of low-value URLs can drag down your good pages too.

Easy to misdiagnose

  • Adding filler to inflate word count: filler isn’t depth, and Google’s systems judge value over length.
  • Treating noindex as a penalty: noindex is a deliberate “do not index this” instruction, not a punishment.
  • Thinking merging loses authority: merge + 301 concentrates authority on the master page.
  • Expecting rankings to recover the day you delete: re-evaluation typically takes 4-8 weeks.

Prevention

  • Minimum bar before publishing: >= 500 words + at least 1 image + at least 2 internal links + at least 1 specific number
  • Don’t chase keyword counts with auto-generated permutations
  • AI drafts must be human fact-checked and injected with firsthand experience (this is the line between an acceptable AI-assisted page and scaled content abuse)
  • Quarterly content audit: find and process the thinnest 20%
  • CI blocks thin posts: a post under 300 words fails the build, which forces real writing

FAQ

Q: What counts as “thin” exactly? A: Google publishes no word-count threshold. Under ~500 words is usually thin, but a 2000-word article with no unique value is also thin. Google measures thinness relative to the pages already ranking for the query, not against a fixed number.

Q: Is the “Helpful Content System” still a thing I can recover from? A: There’s no separate system to recover from anymore. Since the March 2024 core update, that judgment lives inside the core ranking algorithm and runs continuously and site-wide. Recovery means genuinely improving (or removing) the low-value share of your site, then waiting for the next re-evaluation cycle.

Q: Will deleting thin pages help the rest of the site? A: Often yes — it frees crawl budget and lifts the site-wide quality signal. Roughly 4-8 weeks later, your good pages’ indexing rates and rankings tend to improve.

Q: Are all auto-generated pages bad? A: No. If each programmatic page genuinely carries unique data, context, or user value (not template fill-in), it’s fine — flight search results are the classic example. The moment the only difference between pages is a swapped variable, you’re in scaled content abuse territory.

Tags: #SEO #Google #Search Console #Indexing #Troubleshooting #Thin page