readability
Contingut escàs
Marca pàgines on l'article principal extret té menys de ~150 paraules: el que el helpful-content system de Google rebaixa i els agents d'IA salten completament.
Què comprova aquesta auditoria
Mesura la substància de la pàgina, no el recompte brut de paraules.
MetricSpot extreu l’article principal fent servir un heurístic d’estil Readability:
- Prefereix
<main>o<article>quan són presents. - Treu
nav,header,footer,aside, banners de cookies i chrome conegut (objectius de skip-link, breadcrumbs). - Puntua els blocs restants per densitat de text (caràcters per node) i pes de tag, el mateix enfocament que Readability.
- Compta les paraules dins del bloc supervivent.
Si aquest recompte està per sota de ~150 paraules, la pàgina es marca com a escassa. Això és intencionadament diferent del nombre de paraules de pàgina, que compta tot el que és visible (boilerplate inclòs). Un lloc pot passar el nombre de paraules de pàgina amb 2.000 paraules de nav + footer + sidebar i fallar aquesta comprovació amb 80 paraules d’article real.
Per què importa
Dos sistemes penalitzen el contingut escàs, dur:
El helpful-content system de Google. Des de l’actualització del 2022 (i endurit el 2024–2025), les pàgines jutjades com a proveïdores de “poc valor, baix valor afegit, o no gaire útils d’una altra manera” es rebaixen a nivell de lloc, no només la URL ofensiva. Els ofensors clàssics són els índexs de categoria autogenerats, les pàgines de localització girades des d’una plantilla i les pàgines de producte sense més descripció que títol + preu.
Motors de resposta d’IA. ChatGPT, Perplexity, Claude, AI Overviews de Google i Gemini executen tots un filtre de substància abans de citar. Una pàgina amb 60 paraules de cos és parsejable però no es pot citar, no conté una resposta defensable. La teva URL mai entra al pool de cites.
El contingut escàs també és un problema de conversió. Els visitants que aterren en una pàgina de 70 paraules abandonen; els que aterren en una pàgina de 600 paraules amb profunditat, FAQs i un proper pas clar converteixen.
Com solucionar-ho
No estàs afegint farciment. Estàs afegint substància, contingut que un lector faria una captura de pantalla. Tria els patrons que encaixin amb el tipus de pàgina.
Pàgines de categoria / índex
L’ofensor de contingut escàs per defecte. La solució:
- 2–3 paràgrafs curts de comentari original sobre el llistat: què és la categoria, per a qui és, què mirar.
- Un bloc curt d’FAQ (3 preguntes) tractant les preguntes habituals prèvies a la compra.
- Enllaços interns a les 3–5 subcategories o pàgines pilar més rellevants. Mira estratègia d’enllaçat intern.
Pàgines de producte / SKU
Si la teva descripció són només especificacions:
- Afegeix un paràgraf de “per què el portem” o “millor per a” (50–100 paraules, escrit per un humà).
- Inclou 3–5 ressenyes de clients amb atribució d’autor i valoració. Marca-les amb schema
Review, fan doble funció com a prova social i com a contingut. - Inclou un bloc de “compatible amb” o “es compren sovint amb”, útil per als lectors, útil per als cercadors mapejant relacions d’entitats.
Pàgines de localització / àrea de servei
La trampa de l’spam-de-plantilla. La solució és més dura perquè és feina:
- Cada pàgina necessita almenys un paràgraf de contingut específicament local. No “servim a
”, sinó detalls reals: un punt d’interès, una regulació local, un matís de servei. - Un cas d’estudi local o testimoni si en tens.
- Una H1 única per pàgina (no “Lampista a {Ciutat}”).
Si no pots escriure alguna cosa única per a una ciutat, aquella ciutat no es mereix una pàgina. Consolida en un hub regional.
Stubs de blog i landings
- Comença amb el patró contingut answer-first, la pregunta a l’H1, la resposta a les 50 paraules següents.
- Segueix amb les seccions “per què importa” i “com fer-ho”, el patró profunditat de contingut.
- Acaba amb un bloc d’FAQ (2–3 preguntes) que capturi consultes de cua llarga.
Com MetricSpot extreu el contingut
Si la comprovació es dispara però creus que la pàgina té substància, l’extractor potser l’ha perdut. Causes habituals:
- Cos de l’article dins d’un
<div>sense embolcall semàntic, al costat d’una sidebar molt gran. Readability a vegades tria la sidebar. Embolcalla l’article amb<main>o<article>. - Contingut renderitzat al costat client després de la hidratació. MetricSpot llegeix la resposta del servidor. Prerenderitza o SSR del cos.
- Ús intensiu de
<iframe>o<canvas>, això no és prosa. Si la pàgina és una eina, està bé; la regla no aplicarà a pàgines interactives un cop les marquis ambrole="application"i una descripció breu.
Combina aquesta regla amb nombre de paraules de pàgina i longitud de paràgrafs, juntes et diuen si la pàgina té prou redacció, ben estructurada.
Preguntes freqüents
Quin és el llindar real de recompte de paraules?
Aproximadament 150 paraules de contingut principal extret. El número exacte depèn del tipus de pàgina: una pàgina de producte amb dades estructurades riques (preu, valoracions, disponibilitat, schema) obté més indulgència que una pàgina /sobre-nosaltres sense schema i 80 paraules.
Afegir un bloc d’FAQ arreglarà cada pàgina escassa?
Ajuda però no és una bala d’argent. Una FAQ afegeix substància i captura consultes de cua llarga, però si la resta de la pàgina és genuïnament buida (una categoria embrionària, un placeholder), l’FAQ sola no l’aguantarà. Afegeix una FAQ més almenys un paràgraf original above the fold.
La meva pàgina d’inici és intencionadament curta. M’hauria de preocupar?
Les pàgines d’inici tenen un pass parcial, la comprovació espera que siguin navegacionals, i la majoria d’heurístics d’extracció retornen un recompte baix fins i tot per a pàgines d’inici sanes. La penalització de contingut escàs a la pràctica colpeja les pàgines interiors: índexs de categoria, pàgines de localització i SKUs generats per plantilla. Si la teva pàgina d’inici és l’única pàgina escassa marcada, normalment la pots ignorar.
Fonts
Última actualització 2026-05-11