Too Many Thin Pages Are Dragging Down a Content Site

Q: Will cutting pages hurt my traffic?

Cutting *thin, near-zero-impression* pages almost never costs meaningful traffic, because they weren't getting any. The risk is cutting wrong — always check 90-day impressions before removing, and merge (301 to a relevant page) anything that has even small traffic or backlinks instead of deleting it.

Q: 410 or 404 for removed pages?

Use **410** when the content is gone for good — Google tends to drop it a little faster (a couple of days, per Mueller). Use **404** if the URL might return under the same slug. If your static host can't emit 410, a 404 is fine; it's just slower to clear.

Q: Should I noindex thin pages or just delete them?

`noindex` if the page still serves a purpose on-site (internal navigation, a tag hub, a utility page) but shouldn't compete in search. Delete (410) if it has no purpose at all. Don't noindex a page you actually want to rank — fix or merge it instead.

Q: Why is one specific page stuck in "Crawled - currently not indexed" even though it's good?

This status is frequently a *site-wide* quality verdict, not a judgment on that single URL. Google deprioritizes pages from properties whose average quality is low. Pruning the thin pile and adding internal links from strong pages does more than editing the stuck page alone.

500+ pages and Google indexes few. Audit by word count + impressions, tag each page expand / merge / noindex / 410, and cut the weakest 20-40% to lift site-wide quality.

Published: May 19, 2026 Updated: Jun 21, 2026 Author: AI Productivity Guide Team 🌐 查看中文版本

Fastest fix: export every URL with its word count and 90-day impressions, sort ascending, and tag each page below ~500 words and near-zero impressions as expand, merge, noindex, or 410. Then actually cut the weakest 20-40%. The cut is the fix: Google scores quality at the site level, so pruning weak pages raises the bar for everything that remains. Don’t try to expand your way out of it.

You publish 500+ pages. In Google Search Console, the Pages report (Indexing -> Pages) shows a growing “Crawled - currently not indexed” bucket. A content audit reveals many pages under 300 words. Traffic concentrates in your top 10% of articles; the remaining 90% generate near-zero impressions. The homepage looks rich, but Google treats the property as low quality because the average page is thin.

This matters more in 2026 than it used to. Since around April 2026, Google has been deindexing low-value URLs at a higher rate as it trims an index growing faster than the supply of genuinely useful content (Search Engine Journal and multiple SEO trackers reported the spike; Google’s John Mueller called it routine “some sites go up, some go down” housekeeping). Thin, templated, and AI-pipeline pages are the first to get dropped. And per Mueller’s long-standing guidance, “Crawled - currently not indexed” is often a site-wide quality signal, not a per-page bug — so fixing one page rarely moves it; raising the site average does.

Common causes

Ordered by hit rate, highest first.

1. Programmatic SEO pages with little unique substance

You generated 200 “Best X for Y” pages by combining lists. Each is templated and sparse. Google sees the template, not unique value.

How to spot it: clusters of pages with the same URL pattern and word counts bunched in the 200-400 range. Programmatic shape.

2. AI-generated articles that all follow the same template

Same problem from a different source: AI-pipeline articles hit the minimum-acceptable bar without exceeding it. Each one technically “answers” the query but adds nothing a human searcher couldn’t already find.

How to spot it: AI batches cluster around the same word count (500-800), same heading structure, same example patterns. This is exactly the content type Google has been deindexing fastest in 2026.

3. Old short posts from a different content era

Pre-2020 posts (300-500 words) that were normal then and are thin now. Standards rose; the old content didn’t.

How to spot it: publishedAt before ~2020 and word count < 600. Era mismatch.

4. Auto-generated tag / archive pages

(See Too many tags create thin archive pages.) These often slip into the thin-page count.

How to spot it: tag pages listing < 5 articles; date- or author-archive pages with auto-generated content only.

5. “List of links” pages with no editorial content

A “Best tools for X” page that is 10 names with one-sentence descriptions. The page doesn’t help — the linked destinations do.

How to spot it: the page is mostly outbound links plus minimal explanation, with no unique value above what the linked pages already provide.

6. Translated stubs without per-language depth

You auto-translated a stub. Now it’s a stub in two languages, doubling the thin-page count.

How to spot it: the ZH version mirrors the EN word count, and both sit below your depth threshold.

Which bucket is each page in?

Before fixing anything, classify. The two axes that matter are demand (does anyone search this, and could you realistically rank) and current depth.

Demand for the topic	Current state	Action
Real volume, you can win	Thin but salvageable	`Expand`
Several near-duplicate angles	3-5 overlapping thin pages	`Merge` into one deep page, 301 the rest
Useful internally, not for search	Tag/archive/utility page	`Noindex`
No demand, no future use	Dead weight	`410` (or 301 to a real successor)

Most thin pages should be merged or removed, not expanded. Expanding everything is how the pile grew in the first place.

Shortest path to fix

Ordered by ROI. Step 1 audits; Step 2 decides per page; Steps 3-6 execute.

Step 1: Export URL + word count + last-modified + impressions

Pull two datasets and join them on URL:

# A) Crawl your own site for URL + word count + last-modified.
#    Use Screaming Frog (Word Count column), Sitebulb, or a
#    custom script over your sitemap.
#
# B) From Google Search Console -> Performance, export the last
#    90 days of impressions/clicks per page (or use the Search
#    Console API / Looker Studio connector for the full set).
#
# Join A + B on URL, then:
#   - sort by word count ascending
#   - flag word count < 500 AND 90-day impressions ~ 0

You’ll typically find 20-40% of articles below 500 words with no impressions. That’s the thin pile. Cross-check it against the “Crawled - currently not indexed” export in the Pages report — heavy overlap confirms a quality problem, not a crawl-budget one.

Step 2: Tag each page expand / merge / noindex / 410

Use the decision table above. Be honest: if a topic has no search demand and you wouldn’t link to it from a strong page, it’s a merge or a 410, not an expand.

Step 3: For “expand” — do real depth work, not word-count padding

- Look at the top 3-5 results currently ranking for the query;
  add what they cover that you don't, plus something they lack
  (original data, a real example, firsthand testing, expert take)
- Add 3-5 concrete, specific examples (not generic)
- Add a "common pitfalls" section
- Add an FAQ with 4-6 real questions a stuck user would search
- Re-screenshot any UI that has changed
- Add internal links from a strong, topically related page
  (this is what actually pushes a stuck page into the index)
- Re-check length: a genuine answer is usually 1,200-2,000+ words

Filler to hit a word count is not a fix. Google’s systems are tuned to detect padding, and adding fluff to a thin page can leave it thin and bloated.

Step 4: For “merge” — combine 3-5 thin pages into one deep guide

1. Pick the merge target: the strongest URL of the group becomes
   the consolidated home (best existing rankings / backlinks).
2. Fold the best 1-2 sections from each thin page into the target.
3. 301-redirect the other URLs to the target.
4. Confirm the target clears your depth bar after merging.

Five thin pages become one deep page, and the site-wide average rises. Critical: only 301 to a genuinely relevant target. A 301 to an unrelated page (or to the homepage) is treated by Google as a soft 404, which is as bad as or worse than leaving the URL gone.

Step 5: For “noindex” or “410” — execute deliberately

For pages you keep on the site but want out of search (utility, tag, thin-but-internal), use a noindex directive. Google drops a noindex page within 1-7 days of recrawling it:

<!-- noindex: page stays accessible on-site, drops out of search -->
<meta name="robots" content="noindex" />

For permanent removal, the cleanest signal is HTTP 410 Gone. Google tends to drop 410 URLs a little faster than plain 404s (Mueller has described it as a small time advantage, on the order of a couple of days) because a 404 stays in the recrawl queue (retried at ~24h, 7d, 30d, 90d) in case it returns, whereas 410 says “don’t come back.” Either way Google must recrawl the URL to see the status, so neither is instant.

- Delete the MDX file.
- Return a real 410 for that path (see the static-host note below),
  OR 301 it to a relevant successor — never to the homepage.
- Don't block the URL in robots.txt instead: blocked + previously
  indexed often shows up as a soft 404.

Static-host caveat (Firebase / Vercel / Netlify): plain static hosting can’t emit a real 410. Firebase Hosting redirects only support 301 and 302 — there is no 410 type. As of June 2026 your realistic options are: (a) serve a custom error page (Firebase returns 404, not 410 — still fine for removal, just slower than 410); (b) front the path with a Cloud Function / Cloud Run / edge function that sets 410; or (c) drop the page, let it 404, and add a temporary entry in Search Console’s Removals tool (Indexing -> Removals) to hide it within ~24h. The Removals tool is temporary (about 6 months) and must be paired with a permanent 404/410/noindex.

Step 6: Re-audit in 4-8 weeks

In Search Console -> Pages and -> Performance, watch for:
  - "Crawled - currently not indexed" count trending down
  - Total indexed pages drops (expected — you cut) BUT
  - Average position of the remaining articles improves
  - Impressions/clicks on survivors hold or rise

If those moved the right way, the cut worked. If “Crawled - currently not indexed” didn’t budge, you either cut the wrong pages or didn’t cut deep enough — the site average is still too low.

How to confirm it’s fixed

The thin pile no longer appears in the “Crawled - currently not indexed” export.
site:yourdomain.com (or the Pages report’s “Indexed” count) dropped, but average position and total clicks on the kept pages held or rose — that’s the signal the prune helped rather than hurt.
For 410’d / removed URLs: curl -I https://yoursite.com/old-url/ returns 410 (or 404), and the URL Inspection tool shows “URL is not on Google” with no soft-404 warning.

Prevention

Set a real publish bar: depth and uniqueness, not just a word-count floor. A 1,500-word page that restates the top results is still thin.
Put a quarterly content audit on the team calendar — thin pages accumulate silently between launches.
Give programmatic and AI-pipeline pages genuine per-page substance (original data, real examples), or don’t ship them; these are the first deindexed in 2026.
Never 301 dead pages to the homepage. Either 410/404 them or 301 to a topical successor.
Don’t pad to hit length. Padding is detectable and doesn’t lift quality.

FAQ

Will cutting pages hurt my traffic? Cutting thin, near-zero-impression pages almost never costs meaningful traffic, because they weren’t getting any. The risk is cutting wrong — always check 90-day impressions before removing, and merge (301 to a relevant page) anything that has even small traffic or backlinks instead of deleting it.

410 or 404 for removed pages? Use 410 when the content is gone for good — Google tends to drop it a little faster (a couple of days, per Mueller). Use 404 if the URL might return under the same slug. If your static host can’t emit 410, a 404 is fine; it’s just slower to clear.

Should I noindex thin pages or just delete them? noindex if the page still serves a purpose on-site (internal navigation, a tag hub, a utility page) but shouldn’t compete in search. Delete (410) if it has no purpose at all. Don’t noindex a page you actually want to rank — fix or merge it instead.

Why is one specific page stuck in “Crawled - currently not indexed” even though it’s good? This status is frequently a site-wide quality verdict, not a judgment on that single URL. Google deprioritizes pages from properties whose average quality is low. Pruning the thin pile and adding internal links from strong pages does more than editing the stuck page alone.

Is it really thin pages dragging the rest down, or just normal indexing lag? If new pages index fine and only old/templated ones are excluded, it’s quality. If everything indexes slowly, it may be crawl budget or a genuinely new site — see When an indexing delay is normal before you start cutting.

Tags: #Content ops #Site quality #Site audit #Troubleshooting #Thin page