Conținut subțire (thin content): cum îl diagnostichezi și cum îl repari

„Thin content" e unul dintre acele diagnostice care sună vag până în ziua în care îl primești tu. Noi l-am primit: un domeniu cu peste 800 de pagini publicate, un blog cu articole lungi, mai multe aplicații web — și verdictul Google la aplicația AdSense a fost „low value content". Articolul acesta descrie metoda concretă prin care am măsurat problema, criteriile prin care am decis ce rămâne în index și pașii de reparare. Totul e reproductibil pe orice site, cu unelte gratuite.

Ce înseamnă de fapt „subțire"

Conținutul subțire nu înseamnă „scurt". O pagină de contact scurtă e perfect legitimă. Subțire înseamnă pagină care nu ar supraviețui unei evaluări manuale: dacă un om s-ar uita 20 de secunde la ea, ar conchide că nu oferă nimic ce nu există deja în alte mii de pagini identice — pe site-ul tău sau pe alte site-uri. Cele trei forme pe care le-am avut chiar noi:

Cataloage generate din șablon: sute de pagini construite dintr-un JSON, identice structural, cu 80–100 de cuvinte unice fiecare. Individual, fiecare pare OK. La scară, sunt zgomot.
Pagini-aplicație goale pentru crawler: aplicații JavaScript (jocuri, tools) al căror HTML e un <div id="app"></div> și un script. Utilizatorul vede un produs întreg; crawlerul vede o pagină albă.
Conținut preluat: descrieri importate dintr-un API public sau dintr-o bază de date deschisă. Textul există deja, cuvânt cu cuvânt, pe zeci de alte site-uri.

Diagnosticul: măsoară, nu ghici

Primul pas care ne-a schimbat perspectiva a fost să măsurăm ce vede crawlerul, nu ce vedem noi în browser. Un one-liner suficient pentru un audit inițial:

curl -sL https://site.ro/pagina | \
  sed -e 's/<script[^>]*>.*<\/script>//g' \
      -e 's/<[^>]*>/ /g' | wc -w

Rulează-l pe un eșantion din fiecare tip de pagină de pe site. La noi, rezultatele au fost brutale: articolele de blog aveau 2.000–2.500 de cuvinte, paginile generate ~90, iar paginile de jocuri — între 1 și 4 cuvinte. Nu aveam idee că paginile de jocuri sunt efectiv invizibile pentru crawler până nu am măsurat.

Apoi calculează raportul: câte pagini indexabile ai în fiecare găleată? Formula noastră de sănătate:

Dacă paginile pe care le-ai apăra într-o evaluare manuală sunt sub jumătate din paginile indexabile, ai o problemă de thin content — indiferent cât de bune sunt cele bune.

La noi raportul era 14 pagini apărabile la ~800 subțiri. Nicio calitate individuală nu compensează un asemenea raport.

Repararea: trei unelte, în ordinea corectă

1. Noindex — oprirea hemoragiei

Pentru cataloagele generate, soluția imediată nu e să scrii 800 de pagini de conținut — e să scoți din index ce nu poți apăra azi:

<meta name="robots" content="noindex, follow">

„Follow" păstrează fluxul de linkuri intern. Concomitent, scoate paginile noindexate din sitemap.xml — un sitemap care listează pagini noindexate transmite semnale contradictorii. Sitemap-ul nostru a scăzut de la 400+ de URL-uri la 9. Pare o înfrângere; e de fapt o declarație: „astea sunt paginile mele, pe fiecare o pot apăra".

Important: dacă generezi paginile dintr-un script (cazul nostru), pune noindex-ul în generator, nu în fișierele generate — altfel dispare la următorul build. Și adaugă un test automat care verifică prezența lui.

2. Text real pentru paginile-aplicație

Pentru aplicațiile JavaScript, soluția nu e noindex — sunt produsele tale, vrei să fie găsite. Soluția e conținut HTML static alături de aplicație. La hub-ul nostru de jocuri am adăugat o secțiune statică sub aplicație: ce este fiecare joc, cum se joacă, controale — aproximativ 100–140 de cuvinte per joc, vizibile și pentru utilizatori (cine derulează sub grilă găsește ghidurile). Pagina a trecut de la 4 cuvinte vizibile la peste 650. Pentru paginile individuale de joc, unde layoutul fullscreen nu permite conținut sub canvas, am folosit titluri descriptive, meta descriptions reale și blocuri <noscript> — mai puțin ideal, dar infinit mai bine decât pagina albă.

3. Îmbogățirea — singura reparare adevărată

Noindex-ul cumpără timp; nu produce valoare. Repararea reală e să transformi, treptat, paginile subțiri în pagini apărabile: la un catalog de rețete, asta înseamnă introducere proprie, sfaturi de preparare, variații, întrebări frecvente — 300–500 de cuvinte de experiență reală, nu text umplutură generat. Regula practică: îmbogățești în ordinea traficului potențial (top 20–50 de pagini întâi) și reindexezi pagină cu pagină, pe măsură ce fiecare devine apărabilă. Umplutura generată automat doar ca să crești numărul de cuvinte te aduce înapoi exact la problema de la care ai plecat.

Greșeli care prelungesc agonia

Reaplicarea imediată la review fără schimbări măsurabile. Dacă cifrele de mai sus nu s-au schimbat, verdictul nu se schimbă nici el.
Ștergerea paginilor în loc de noindex. 800 de 404-uri nu sunt o îmbunătățire; sunt altă problemă. Paginile funcționează în continuare pentru utilizatori — doar nu cer să fie indexate.
Ascunderea textului. Text alb pe fundal alb, blocuri invizibile doar pentru crawler — asta nu e reparare, e cloaking, și transformă o problemă de calitate într-una de conformitate.
Obsesia pentru numărul de cuvinte. 300 de cuvinte utile bat 1.500 de cuvinte de umplutură. Măsurătoarea e diagnostic, nu obiectiv.

Checklist final

Măsoară cuvintele vizibile pentru crawler pe fiecare tip de pagină.
Împarte paginile indexabile în „apărabile" și „neapărabile".
Noindex + scoatere din sitemap pentru tot ce e neapărabil azi.
Conținut static real pentru paginile-aplicație.
Îmbogățește în ordinea traficului potențial; reindexează treptat.
Automatizează: generatorul pune noindex, un test verifică, sitemap-ul se construiește din lista de pagini apărabile.

Dacă treci printr-un refuz similar și vrei o a doua opinie pe cifre, scrie-ne la contact@hashcoreai.com.

"Thin content" is one of those diagnoses that sounds vague until the day you receive it. We did: a domain with over 800 published pages, a blog with long articles, several web apps — and Google's verdict on our AdSense application was "low value content." This article describes the concrete method we used to measure the problem, the criteria for deciding what stays in the index, and the repair steps. Everything is reproducible on any site, with free tools.

What "thin" actually means

Thin content doesn't mean "short." A short contact page is perfectly legitimate. Thin means a page that wouldn't survive a manual review: if a human looked at it for 20 seconds, they'd conclude it offers nothing that doesn't already exist on thousands of identical pages — on your site or on others. The three forms we had ourselves:

Template-generated catalogues: hundreds of pages built from a JSON file, structurally identical, with 80–100 unique words each. Individually, each looks fine. At scale, they're noise.
App pages that are empty for crawlers: JavaScript applications (games, tools) whose HTML is a <div id="app"></div> and a script. The user sees a whole product; the crawler sees a blank page.
Imported content: descriptions pulled from a public API or an open database. The text already exists, word for word, on dozens of other sites.

Diagnosis: measure, don't guess

The first step that changed our perspective was measuring what the crawler sees, not what we see in the browser. A one-liner is enough for an initial audit:

curl -sL https://site.com/page | \
  sed -e 's/<script[^>]*>.*<\/script>//g' \
      -e 's/<[^>]*>/ /g' | wc -w

Run it on a sample of every page type on your site. Our results were brutal: blog articles had 2,000–2,500 words, generated pages ~90, and the game pages — between 1 and 4 words. We had no idea the game pages were effectively invisible to crawlers until we measured.

Then compute the ratio: how many indexable pages sit in each bucket? Our health formula:

If the pages you'd defend in a manual review are fewer than half of your indexable pages, you have a thin content problem — no matter how good the good ones are.

Our ratio was 14 defensible pages to ~800 thin ones. No amount of individual quality compensates for a ratio like that.

The repair: three tools, in the right order

1. Noindex — stop the bleeding

For generated catalogues, the immediate fix isn't writing 800 pages of content — it's removing from the index what you can't defend today:

<meta name="robots" content="noindex, follow">

"Follow" preserves internal link flow. At the same time, remove noindexed pages from sitemap.xml — a sitemap listing noindexed pages sends contradictory signals. Our sitemap went from 400+ URLs to 9. It looks like a defeat; it's actually a statement: "these are my pages, and I can defend every one."

Important: if you generate pages from a script (our case), put the noindex in the generator, not the generated files — otherwise it vanishes on the next build. And add an automated test that checks it's there.

2. Real text for app pages

For JavaScript applications, the fix isn't noindex — they're your products, you want them found. The fix is static HTML content alongside the app. On our games hub we added a static section below the app: what each game is, how to play it, controls — roughly 100–140 words per game, visible to users too (scroll past the grid and you find the guides). The page went from 4 visible words to over 650. For individual game pages, where the fullscreen layout doesn't allow content below the canvas, we used descriptive titles, real meta descriptions and <noscript> blocks — less ideal, but infinitely better than a blank page.

3. Enrichment — the only true repair

Noindex buys time; it doesn't produce value. The real repair is gradually turning thin pages into defensible ones: for a recipe catalogue, that means an original introduction, preparation tips, variations, FAQs — 300–500 words of real experience, not generated filler. The practical rule: enrich in order of traffic potential (top 20–50 pages first) and reindex page by page as each becomes defensible. Auto-generated filler added just to raise the word count brings you right back to the problem you started with.

Mistakes that prolong the agony

Reapplying for review immediately with no measurable changes. If the numbers above haven't changed, the verdict won't either.
Deleting pages instead of noindexing. 800 404s aren't an improvement; they're a different problem. The pages keep working for users — they just don't ask to be indexed.
Hiding text. White text on white backgrounds, blocks visible only to crawlers — that's not repair, it's cloaking, and it turns a quality problem into a compliance one.
Word-count obsession. 300 useful words beat 1,500 words of filler. The measurement is a diagnostic, not a target.

Final checklist

Measure crawler-visible words for every page type.
Split indexable pages into "defensible" and "not defensible."
Noindex + sitemap removal for everything not defensible today.
Real static content for app pages.
Enrich in order of traffic potential; reindex gradually.
Automate it: the generator emits noindex, a test verifies it, the sitemap is built from the defensible list.

If you're going through a similar rejection and want a second opinion on your numbers, write to us at contact@hashcoreai.com.

Conținut subțire (thin content): cum îl diagnostichezi și cum îl repari înainte de următorul review

Thin Content: How to Diagnose It and Fix It Before Your Next Review