Diagnostic SEO : identifier pages sans texte et hiérarchie Hn vide

Table des matières :

1. Pourquoi les pages sans texte et les Hn vides sont des bombes SEO à retardement
2. Définir “page sans texte” et “hiérarchie Hn vide” (et ce que les robots comprennent vraiment)
3. Diagnostiquer à l’échelle : crawl, extraction et seuils qui tiennent la route
4. Les pièges modernes : JS, AJAX, templates e‑commerce et “texte” invisible
5. Corriger sans détruire le design : contenu, sémantique, accessibilité et données structurées
6. Industrialiser le contrôle : tests SEO en CI/CD, monitoring et priorisation business

Pourquoi les pages sans texte et les Hn vides sont des bombes SEO à retardement

Un diagnostic SEO sérieux finit toujours par tomber sur deux horreurs récurrentes : des pages sans texte (ou quasi) et une hiérarchie Hn vide (pas de H1/H2… ou des titres “visuels” faits en <div> parce que “ça marche pareil”). Techniquement, ces pages peuvent charger vite, être “jolies”, et même vendre… jusqu’au jour où Google décide qu’elles n’ont rien d’intéressant à indexer. Et là, surprise : vos catégories e‑commerce se font doubler par un comparateur moche, mais avec du contenu.

Le problème n’est pas “Google aime le texte” au sens scolaire. Le problème, c’est que sans contenu principal identifiable et sans structure sémantique, vous rendez l’interprétation du sujet plus coûteuse (pour le crawler), plus incertaine (pour l’algorithme) et moins robuste (pour les systèmes de compréhension d’intention). Dans un contexte 2026 où la recherche est de plus en plus “assistée” (résumés, réponses directes, systèmes de retrieval sémantique), une page vide de signaux textuels devient littéralement un trou noir.

Et ne vous racontez pas d’histoires : “mais on a une belle UI, des filtres, des cartes produit”. Oui, et un utilisateur humain voit tout ça. Un bot, lui, voit un DOM, des ressources, un rendu, puis tente d’extraire du Main Content. Les Search Quality Rater Guidelines de Google sont brutales sur ce point : “The MC is the part of the page that helps the page achieve its purpose.” (Google, Search Quality Rater Guidelines, PDF officiel). Si votre “MC” est une grille de produits sans contexte, vous jouez au SEO en mode difficile.

Deux effets collatéraux sont souvent sous‑estimés :

• CTR et snippet : sans Hn et sans texte descriptif, vous laissez Google “inventer” un extrait à partir d’éléments secondaires (menu, libellés de filtres, micro‑textes), ce qui produit des snippets peu vendeurs et parfois hors sujet.
• Maillage interne et consolidation thématique : un texte d’intro de catégorie (bien structuré) est un endroit naturel pour lier des sous‑catégories et des guides. Sans lui, vous finissez avec un maillage “technique” (breadcrumbs + menus) mais pauvre en contexte.

Mini‑scénario très concret (et très fréquent) : une boutique de sport avec une catégorie “Chaussures de randonnée”. La page contient 48 produits, un filtre “pointure”, un carrousel “Top ventes”… et un titre en <div>. Visuellement, tout va bien. Mais côté moteur : pas de H1, 15 mots utiles, aucune phrase qui précise “homme/femme”, “terrain”, “imperméable”, “semelle Vibram”, etc. Face à un concurrent qui a 120 mots d’introduction + 3 sections H2 (choisir sa pointure, usages, entretien), l’écart de compréhension est immédiat — et donc l’écart de visibilité aussi.

Définir “page sans texte” et “hiérarchie Hn vide” (et ce que les robots comprennent vraiment)

Une page sans texte n’est pas forcément une page à 0 mot. C’est une page dont le texte utile (visible, spécifique, non répétitif, non boilerplate) est insuffisant pour porter le sujet. En audit, on parle souvent de seuils (ex. < 80–150 mots uniques pour une catégorie, < 30 mots pour une landing), mais la métrique brute est trompeuse : si 120 mots viennent du footer “Mentions légales / CGV / Livraison”, vous avez surtout 120 mots de bruit.

Pour être plus précis en diagnostic, on peut distinguer 4 familles de “texte” :

1. Texte de navigation (boilerplate) : menu, footer, breadcrumbs, filtres, libellés de boutons. Souvent majoritaire… et rarement différenciant.
2. Texte d’inventaire : titres de produits dans une grille, prix, variantes. Utile pour l’utilisateur, mais sémantiquement pauvre si non contextualisé (et très redondant à grande échelle).
3. Texte éditorial : introduction de catégorie, guide d’achat, FAQ, conseils, contraintes (livraison, retours) quand elles sont spécifiques à la page.
4. Texte de preuve : avis clients, Q/R, garanties, disponibilité magasin. Ça peut aider, mais attention : si c’est le seul texte, le sujet devient “flou” (avis sur quoi ? pour quel usage ?).

La hiérarchie Hn vide, c’est l’absence (ou l’inutilité) des balises <h1>…<h6> pour structurer le contenu. Le HTML ne laisse pas beaucoup de place à l’interprétation : “The h1 element represents a section heading.” (WHATWG HTML Living Standard, section headings : documentation officielle). Si vous remplacez les headings par des <span class="title">, vous supprimez un signal structurel que les moteurs, les lecteurs d’écran et même vos outils internes (extracteurs, scrapers, IA) utilisent.

Côté SEO pur, Google l’énonce sans poésie : “Use meaningful headings to indicate important topics, and help create a hierarchical structure for your content.” (Google Search Central, SEO Starter Guide). Traduction technique : les headings aident à construire une arborescence de concepts, ce qui facilite l’extraction de passages pertinents, le snippetting, et la compréhension sémantique globale. Côté accessibilité, WCAG 2.2 est encore plus directe : “Headings and labels describe topic or purpose.” (W3C, WCAG 2.2 – SC 2.4.6). Oui, un diagnostic SEO peut (et devrait) aussi éviter de produire un site inutilisable au clavier.

Ce que les robots “comprennent” (ou plutôt, ce qu’ils exploitent) dépend des signaux disponibles :

• Une page avec H1 descriptif + 2–3 H2 donne une structure exploitable pour associer des passages à des requêtes (ex. “chaussures randonnée imperméables”, “semelle crantée”, “entretien cuir”).
• Une page avec Hn absents force l’algorithme à inférer la structure via des heuristiques (styles CSS, position dans le DOM, patterns), ce qui augmente les erreurs.
• Une page avec des Hn “fonctionnels” (ex. “Filtrer”, “Trier”, “Ajouter au panier”) pollue la hiérarchie : vous donnez des titres à des contrôles, pas à du contenu.

Checklist rapide “Hn vides” (souvent révélatrice en 30 secondes) :

• Aucune balise <h1> ou <h1> vide (ou rempli par un logo).
• Un H1 identique sur tout le site (“Boutique”, “Produits”, “Catalogue”).
• Des sauts illogiques (H3 sans H2) sur des templates censés être “propres”.
• Des H2/H3 utilisés pour des éléments de navigation (filtres, onglets, accordéons purement UI).

Diagnostiquer à l’échelle : crawl, extraction et seuils qui tiennent la route

Un diagnostic SEO “pages sans texte + Hn vides” ne se fait pas à la main, sauf si votre site a 12 URLs et que vous aimez souffrir. Il se fait par crawl (Screaming Frog, Sitebulb, OnCrawl, un crawler maison) + enrichissement via données d’usage (GSC, analytics, logs). Si vous n’avez même pas une idée du volume d’URLs réelles, commencez par régler ce point (voir : Comment compter les URL d’un site internet sans utiliser les résultats de recherche Google).

Sur le crawl, deux métriques minimales sont utiles :

• Word count “visible” (après suppression du boilerplate). Attention : beaucoup d’outils comptent le texte de navigation, ce qui flatte artificiellement.
• Headings : présence/absence de <h1>, nombre de <h2>, structure (un H3 sans H2, etc.), et surtout headings non pertinents (“Accueil”, “Menu”, “Filtrer”, “Trier”).

Pour objectiver, vous pouvez définir des règles simples :

• Page indexable (200) + canonique sur elle‑même + word count utile < 80 ⇒ “risque de thin content”.
• Page indexable + 0 <h1> ⇒ “structure sémantique cassée”.
• Page indexable + <h1> présent mais identique sur 500 URLs (ex. “Boutique”) ⇒ “heading inutile”.

Pour éviter les seuils “au doigt mouillé”, une table de repères (à adapter à votre secteur et à l’intention) peut aider à cadrer le diagnostic :

Type de page	Objectif principal	Texte utile minimal (ordre de grandeur)	Hn attendus (minimum)	Erreurs typiques
Catégorie e‑commerce	Guider le choix + lister	80–150 mots	1×H1 + 2×H2	grille seule, H1 générique, texte en image
Produit	Décrire + rassurer + specs	150–300 mots (hors avis)	1×H1 + H2 “Détails”, “Livraison”…	contenu dupliqué fournisseur, accordéons non rendus
Landing locale (service + ville)	Convaincre + capter intent locale	250+ mots	1×H1 + H2 (preuves, zone, FAQ)	hero + formulaire, aucune zone desservie
Facette (filtres indexables)	Capter une intention précise	80–120 mots (si indexée)	H1 spécifique	indexation massive “par accident”
Page éditoriale	Informer	variable (souvent 800+)	H1 + H2 structurants	headings incohérents, blocs “contenu” sans titres

Le meilleur moyen de ne pas se mentir, c’est d’extraire le texte de la zone <main> (quand elle existe) et de comparer à une extraction globale. Exemple en Python (simplifié) pour mesurer un ratio “texte utile” et détecter les pages quasi vides :

import re
import requests
from bs4 import BeautifulSoup

def words(text):
    return re.findall(r"[\w’'-]+", text.lower())

def audit_url(url):
    html = requests.get(url, timeout=20, headers={"User-Agent": "SEO-Audit"}).text
    soup = BeautifulSoup(html, "lxml")

    main = soup.find("main") or soup.body
    text = " ".join(main.stripped_strings)

    # heuristique : supprimer des patterns de boilerplate fréquents
    text = re.sub(r"\b(cgv|mentions légales|politique de confidentialité)\b.*", "", text, flags=re.I)

    wc = len(words(text))
    h1 = len(soup.select("h1"))
    hn = sum(len(soup.select(f"h{i}")) for i in range(1,7))
    return {"url": url, "word_count": wc, "h1": h1, "hn_total": hn}

Ce n’est pas parfait (rien ne l’est), mais ça force déjà une vérité : si votre page “Catégorie / Chaussures” sort à 12 mots dans <main>, vous avez un problème. Pour une approche plus rigoureuse, utilisez un extracteur de contenu (Readability, trafilatura) et stockez les résultats dans un entrepôt pour prioriser.

• Croiser avec GSC : une page “thin” qui n’a aucune impression n’est pas prioritaire ; une page “thin” qui fait 50 000 impressions/mois avec un CTR bas est un candidat évident.
• Croiser avec les logs : si Googlebot crawl des milliers d’URL à faible texte (facettes, pages de tri), vous consommez du budget de crawl pour des pages à faible valeur. Le diagnostic n’est plus “contenu”, il devient aussi “allocation de ressources”.

Les pièges modernes : JS, AJAX, templates e‑commerce et “texte” invisible

Le cas classique en 2026 : SPA/SSR hybride, composants React/Vue, et le contenu “arrive” après API call. Le crawler télécharge un HTML squelettique, exécute du JavaScript (parfois), mais vous ne contrôlez ni le budget de rendu ni les délais. Résultat : vos pages sont “sans texte” pour une partie des bots, ou indexées avec un contenu incomplet. Et ça, c’est avant même de parler des variations par localisation, consentement cookies, ou personnalisation.

Si vous avez des pages catalogue construites façon “infinite scroll + filtres + cartes”, vous êtes pile dans le débat détaillé ici : L’AJAX en e‑commerce : oui ou non ?. En SEO, l’AJAX n’est pas “interdit”, mais il impose une discipline : URLs stables, contenu accessible sans interaction, pagination ou équivalent, et rendu initial contenant le minimum sémantique. Sinon, vous offrez à Google une expérience… disons… “spartiate”.

Autre piège : le texte invisible ou non extractible. Exemples fréquents :

• Texte injecté dans un canvas, ou dans une image (bonjour les bannières “Catégorie” en JPG).
• Headings visuels créés via CSS (un <div class="h1">), donc sémantiquement inexistants.
• Headings présents mais masqués (display:none) pour “SEO”. Oui, on voit venir l’idée. C’est rarement une bonne stratégie, et ça casse souvent l’accessibilité.

Ajoutez à ça trois situations très concrètes (et très fréquentes en prod) :

• CMP / consentement cookies : si une CMP bloque le chargement d’un bundle (ou d’une API) tant que l’utilisateur n’a pas consenti, vous pouvez vous retrouver avec une page “vide” côté rendu initial. Même si Google peut exécuter du JS, vous ne voulez pas que votre contenu dépende d’un état “consent”.
• Personnalisation : contenu différent selon l’utilisateur (géolocalisation, historique) = risque de rendu variable. Exemple : une page “Magasins” qui affiche la zone “Lyon” seulement si l’IP est dans le Rhône. Pour le SEO, mieux vaut un contenu stable et une logique explicite (sélecteur de ville, pages dédiées, texte statique).
• Accordéons et onglets : si les descriptions produits sont présentes uniquement après interaction (ou chargées à la demande), vous créez artificiellement du thin content “vu du bot”.

Pour diagnostiquer correctement sur des pages JS, utilisez un rendu headless (Playwright/Puppeteer) en plus du crawl “HTML brut”. Exemple minimal en Node.js avec Playwright pour récupérer le texte rendu et les Hn :

import { chromium } from 'playwright';

export async function audit(url) {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto(url, { waitUntil: 'networkidle' });

  const wordCount = await page.locator('main').innerText().then(t => t.split(/\s+/).filter(Boolean).length)
    .catch(async () => (await page.innerText('body')).split(/\s+/).filter(Boolean).length);

  const h1 = await page.locator('h1').count();
  const hn = await page.locator('h1,h2,h3,h4,h5,h6').count();

  await browser.close();
  return { url, wordCount, h1, hn };
}

Vous comparez ensuite “HTML brut” vs “rendu” : si les Hn n’existent qu’après JS, vous avez un risque (pas toujours fatal, mais réel). Et si le texte n’existe jamais, vous avez un diagnostic SEO… rapide.

Astuce simple (et souvent révélatrice) : sur un échantillon de pages stratégiques, comparez :

• ce que renvoie la réponse HTML (sans exécuter de JS),
• ce que voit un navigateur après rendu,
• et ce que vous avez réellement envie d’indexer.

Si “ce que vous avez envie d’indexer” n’est présent nulle part dans le HTML initial, le plan de correction sera presque toujours : SSR/prerender ciblé + nettoyage des templates.

Corriger sans détruire le design : contenu, sémantique, accessibilité et données structurées

Première remédiation (la plus rentable) : réparer les templates. Une catégorie e‑commerce doit avoir un <h1> unique et descriptif (“Chaussures de randonnée homme”), puis un texte d’introduction (même 80–150 mots) qui explique l’offre, les critères (matières, usage, tailles), et donne du contexte. Oui, c’est du contenu. Non, ce n’est pas “du blabla” si c’est utile.

Une approche qui passe bien côté UX (et évite l’effet “pavé SEO”) :

• Au‑dessus de la grille : 2–3 phrases très concrètes (promesse + critères de choix).
• Sous la grille : un bloc “Guide” structuré en H2/H3 (critères, FAQ, entretien).
• En complément : un lien vers un guide éditorial si vous en avez un (maillage interne contextualisé).

C’est aussi un excellent endroit pour insérer des liens internes vers des sous‑catégories, cohérents avec votre architecture (voir : Arborescence de site : 6 étapes pour un SEO performant).

Deuxième remédiation : rendre le contenu accessible au premier chargement. Idéalement via SSR (Next/Nuxt), ou au minimum via pre‑render sur les pages stratégiques. Le but n’est pas de “plaire au bot”, c’est de garantir que le contenu est disponible même si un script échoue, si une policy CSP bloque une ressource, ou si un navigateur low‑end rame. Bonus : vous améliorez souvent les Core Web Vitals, ce qui évite d’avoir à “sortir le 100/100 PSI” en bricolant (utile en lecture croisée : Sortir un site 100/100 au Page Speed Insights Desktop de Google).

Troisième remédiation : structurer proprement, pas “juste un H1 pour la forme”. Quelques règles qui évitent 80% des audits humiliants :

• Un <main> par page, un seul <h1>, des <h2> pour les sections, puis <h3> si besoin.
• Éviter les headings “fonctionnels” (Filtrer / Trier) dans le flux principal ; ce sont des contrôles UI, pas des sections de contenu.
• Ne pas confondre style et sémantique : si un titre doit ressembler à un H2, utilisez un H2, puis stylez‑le.
• Éviter les headings “marketing” vides : un H2 “Nos engagements” sans aucun texte derrière (juste 3 pictos) n’aide ni le SEO ni l’accessibilité. Ajoutez 2–3 lignes, ou remplacez par une liste descriptive.
• Sur les pages locales (ex. “service + ville”), éviter le piège “une page par commune” sans contenu distinct : si vous ciblez “Lyon”, “Villeurbanne”, “Oullins”, “Vénissieux”, etc., chaque page doit apporter des éléments vérifiables et utiles (zone couverte, modalités d’intervention, contraintes logistiques, preuve locale). Sinon, vous fabriquez de la duplication — et vos Hn seront des coquilles.

Enfin, n’oubliez pas les données structurées quand elles ont du sens (Product, BreadcrumbList, ItemList pour catégories). Ça ne remplace pas le texte ni les headings, mais ça renforce les signaux et l’interopérabilité avec des systèmes IA (voir : Données structurées : clé d’une IA générative efficace en entreprise).

Un point pratique : les données structurées sont d’autant plus efficaces que votre page est déjà “lisible” sans elles. Si votre template est vide et que vous tentez de “compenser” avec du JSON‑LD, vous ne corrigez pas le problème de fond : l’utilisateur (et le moteur) n’a toujours pas de contenu principal clair, structuré et explorable.

Industrialiser le contrôle : tests SEO en CI/CD, monitoring et priorisation business

Le vrai luxe, ce n’est pas de corriger une fois. C’est de ne pas régresser à chaque release. Si vous avez un pipeline CI/CD digne de ce nom, ajoutez des tests automatisés : “toutes les pages de template X doivent avoir 1 H1”, “le <main> doit contenir > N mots”, “pas de Hn vides”, “pas de duplication massive de H1”. Ça se fait avec des tests Playwright, des crawls sur l’environnement de staging, ou une job dédiée sur un snapshot.

Un modèle simple de critères d’acceptation (lisible par dev/PO/SEO) :

• Template “catégorie” : 1 H1 non vide, unique, différent de “Boutique”.
• Template “catégorie” : présence d’un bloc intro dans <main> (même court) + au moins 1 section H2 de contenu (guide/FAQ) si la page est indexable.
• Template “produit” : H1 = nom produit, au moins une section “Description” textuelle accessible sans interaction.
• Tous templates : pas de Hn contenant uniquement “Filtrer”, “Trier”, “Menu”.

Côté observabilité, traitez le SEO comme un système : logs, métriques, alertes. Une hausse de pages 200 sans <h1> après un déploiement, ça doit déclencher un ticket, pas une découverte 3 mois plus tard. Si vos équipes sont déjà outillées, vous pouvez même centraliser la donnée via OpenTelemetry (voir : OpenTelemetry : unifier métriques, traces et logs pour l’observabilité) et compléter par du monitoring RUM pour corréler UX et performance (voir : Real User Monitoring : RUM vs monitoring synthétique). Oui, c’est “DevOps”, mais appliqué au SEO : ça marche étonnamment bien.

Enfin, priorisez avec des critères business, pas avec l’émotion :

1. Pages avec impressions/clics GSC mais CTR faible + contenu mince ⇒ quick wins.
2. Pages qui rankent déjà en top 10 mais stagnent ⇒ renforcer texte + Hn + maillage.
3. Pages de facettes / filtres indexables “par accident” ⇒ décider : enrichir, canonicaliser, ou noindex.

Sur ce dernier point, un rappel utile : si vous multipliez les URL quasi identiques, vous déclenchez des soucis de duplication et de cannibalisation. Votre diagnostic SEO doit donc inclure canonicals et stratégie d’indexation (utile : Définition : contenu dupliqué et URL canoniques).

Si vous voulez une approche “propre” (audit + roadmap + exécution), alignez SEO, technique, UX et sécurité plutôt que de les faire se tirer dessus (référence : Audit de site web : technique, SEO, UX et sécurité pour une roadmap). Et si vous préférez un dispositif de veille/audit continu plutôt qu’un PDF qui dort, regardez un outil orienté pilotage comme Vikings Central — ou contactez directement l’équipe pour un diagnostic SEO “pages sans texte / Hn vides” avec correctifs actionnables.