WordPress SEO : Stopper l’index bloat — Règles noindex qui préservent les liens internes

Ce qu’est vraiment l’index bloat (et pourquoi WordPress le facilite)

L’index bloat n’est pas « Google indexe trop » de manière abstraite. C’est un déséquilibre mesurable :

• URLs que Google peut explorer (découvertes via liens internes, sitemaps, liens externes, paramètres)
• URLs que Google choisit d’indexer (gardées dans l’index et éligibles au classement)
• URLs que vous aviez prévues (votre ensemble canonique : pages sur lesquelles vous voulez que les utilisateurs atterrissent)

WordPress facilite la bloat parce qu’il génère par défaut des pages « utiles » : archives de tags, archives par date, archives d’auteurs, pages de pièces jointes, archives paginées, pages de résultats internes, et parfois plusieurs variantes d’URL pour un même contenu via des paramètres ou des codes de tracking.

Le piège : beaucoup de ces pages peuvent encore être utiles pour la navigation et le regroupement thématique à l’intérieur du site. Vous voulez que Google comprenne cette structure. Vous ne voulez simplement pas que Google indexe les variantes de faible valeur.

État cible : Google peut explorer suffisamment pour comprendre le site, mais indexe un ensemble restreint d’URLs canoniques représentant vos meilleures pages.

Opérationnellement, traitez l’index bloat comme n’importe quel autre problème de production : définissez l’état souhaité, mesurez l’écart, puis appliquez des changements avec des garde-fous. Le SEO, c’est juste du SRE pour le contenu.

Faits et contexte : comment on en est arrivé là

Un peu de contexte historique aide car les conseils SEO WordPress ont tendance à fossiliser. Voici quelques faits concrets qui restent pertinents :

1. Robots.txt a démarré en 1994 comme convention volontaire ; ce n’a jamais été un mécanisme de « contrôle d’accès ». C’est un panneau poli, pas une serrure.
2. Le meta robots « noindex » prédate les outils SEO modernes et reste la manière la plus propre de dire « vous pouvez explorer ceci, mais ne l’indexez pas ».
3. Les balises canonical sont devenues grand public en 2009 pour réduire le chaos du contenu dupliqué. Ce sont des suggestions, pas des garanties, mais elles restent cruciales.
4. Les discussions sur le crawl budget de Google ont fleuri dans les années 2010, mais l’enseignement pratique est plus ancien : ne gaspillez pas le temps du crawler sur des ordures.
5. Les pages de pièces jointes WordPress sont un piège SEO depuis des années car chaque média peut devenir une page fine avec une valeur proche de zéro.
6. Les archives de tags ont été inventées pour la navigation et la découverte, pas pour être la 40e page porte d’entrée qui classe pour le même mot-clé.
7. La navigation facettée a explosé avec l’e‑commerce, entraînant une explosion d’URL paramétrées ; les « filtres » WordPress et les plugins recréent ce désordre.
8. « Crawled — currently not indexed » n’est pas une punition ; c’est Google qui est sélectif. Votre travail est de faciliter la sélection.
9. Google moderne peut découvrir des URLs sans sitemaps via les liens et les flux ; les sitemaps sont des indications, pas une dépendance de découverte.

Une citation à garder près de vous :

« L’espérance n’est pas une stratégie. » — Gene Kranz

Il ne s’agit pas d’être malin. Il s’agit d’être explicite.

Règles de base : noindex, canonical, robots et équité des liens

Noindex concerne l’indexation, pas l’exploration

noindex signifie : « N’incluez pas cette page dans les résultats de recherche. » Il n’arrête pas automatiquement l’exploration. Google peut encore l’explorer périodiquement pour réévaluer les signaux, les liens et les directives.

Disallow concerne l’exploration, pas l’indexation (surtout)

Disallow dans robots.txt signifie : « N’explorez pas. » Mais si une URL est découverte via des liens externes, Google peut toujours indexer l’URL sans contenu (le fameux « indexed, though blocked by robots.txt »). C’est ainsi que vous obtenez des entrées fantômes qui ne consolident jamais correctement les signaux.

Canonical consolide les doublons—quand il est crédible

Une balise canonical propose l’URL « principale ». Elle fonctionne mieux lorsque :

• Le contenu est substantiellement identique.
• Les liens internes renforcent la canonical.
• La cible canonique est accessible et indexable.

Les liens internes peuvent pointer vers des pages noindex—mais faites-le avec intention

Noindex ne « tue » pas un lien. Mais cela change la valeur de cette URL comme destination. Le modèle adapté est généralement :

• Lieez vers des pages indexables quand c’est possible (articles, catégories principales que vous voulez voir classer).
• Appliquez noindex aux collections de faible valeur tout en les laissant exister pour les utilisateurs.
• Ne vous obsessionnez pas sur le « link juice » comme s’il s’agissait d’un fluide qu’on renverse. Pensez en termes de chemins d’exploration et de cibles canoniques.

Blague #1 : Le budget de crawl, c’est comme votre calendrier de réunions—si vous acceptez toutes les invitations, vous serez occupé et n’accomplirez rien.

L’« ensemble indexable » est une décision produit, pas un réglage de plugin

Avant de toucher aux règles, notez ce qui doit être indexable :

• Tous les articles ? Toutes les pages ? Seulement les produits ?
• Archives de catégories : oui/non (souvent oui, mais seulement celles avec une réelle intention éditoriale).
• Archives de tags : généralement non, sauf si vous traitez les tags comme des hubs organisés.
• Archives d’auteurs/dates : presque toujours non pour les blogs à auteur unique ou les petites rédactions.
• Résultats de recherche : non.
• Pagination : cela dépend, mais généralement indexer la page 1, noindex pages 2+ (ou canonicaliser prudemment).

Playbook de diagnostic rapide : trouver rapidement le vrai goulot

Quand une équipe SEO dit « index bloat », cela peut signifier trois défaillances opérationnelles différentes. Vérifiez-les dans cet ordre.

Premièrement : est-ce un problème de découverte, de duplication ou de qualité ?

• Problème de découverte : les URLs importantes ne sont pas trouvées/explorées. Symptômes : pages clés manquantes, sitemap ignoré, maillage interne faible.
• Problème de duplication : trop de variantes d’URL pour le même contenu. Symptômes : paramètres, chemins multiples, canonicals incohérents.
• Problème de qualité : Google voit beaucoup de pages fines. Symptômes : « Crawled — currently not indexed », « Duplicate without user-selected canonical ».

Deuxièmement : validez les directives et leurs conflits

Trouvez les contradictions comme :

• Pages noindex incluses dans le sitemap XML
• Disallow bloquant des pages que vous voulez indexer
• Canonical pointant vers une URL qui fait 301, 404 ou est noindexée
• noindex combiné avec nofollow partout (une excellente façon de rendre Google aveugle)

Troisièmement : vérifiez la charge du crawler (logs), pas vos impressions

Les logs d’accès serveur vous diront sur quoi Googlebot passe du temps : pages de tags, recherche, pièces jointes, ou paramètres infinis. Corrigez les points chauds en priorité.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute réellement lorsque je diagnostique l’index bloat WordPress en production. Chacune inclut : commande, sortie d’exemple, ce que ça signifie, et la décision suivante.

Task 1: Count unique URL patterns Googlebot is hitting (top offenders)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$0 ~ /Googlebot/ {print $7}' | sed 's/\?.*$//' | awk -F/ '{print "/"$2"/"}' | sort | uniq -c | sort -nr | head
  18231 /tag/
  12044 /wp-content/
   9312 /page/
   7441 /category/
   5220 /?s=
   4109 /author/

Ce que cela signifie : Googlebot passe beaucoup de temps sur les archives de tags, la pagination, la recherche, les auteurs, et même les ressources statiques.

Décision : Priorisez les directives pour /tag/, /?s= et les archives d’auteurs. Vérifiez aussi que les ressources statiques ne sont pas liées comme des pages explorables (elles ne doivent pas figurer dans les sitemaps).

Task 2: Identify parameter-heavy crawling (possible faceted/filter bloat)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$0 ~ /Googlebot/ {print $7}' | grep -E '\?.+=' | sed 's/.*?/?/' | cut -d'&' -f1 | sort | uniq -c | sort -nr | head
   6421 ?replytocom=
   3220 ?utm_source=
   1411 ?amp=
   1207 ?orderby=
    988 ?filter=

Ce que cela signifie : Des paramètres comme replytocom et les UTM créent des URL alternatives. Ce sont des accélérateurs classiques de l’index bloat.

Décision : Normalisez avec une gestion canonical, des règles de paramètres (là où possible), et envisagez de rediriger ou de supprimer certains paramètres au niveau de la bordure si c’est sûr.

Task 3: Check sitemap URLs vs indexable directives (sample with curl)

cr0x@server:~$ curl -sS -I https://example.com/post-sitemap.xml | head
HTTP/2 200
content-type: application/xml; charset=UTF-8
cache-control: max-age=300, must-revalidate

Ce que cela signifie : Le sitemap est accessible. Maintenant, confirmez qu’il ne contient que des URLs indexables.

Décision : Récupérez quelques URLs du sitemap et vérifiez qu’elles ne sont pas noindex et qu’elles retournent 200 avec la canonical correcte.

Task 4: Validate a page’s robots meta and canonical (headers + HTML grep)

cr0x@server:~$ curl -sS -D- https://example.com/tag/widgets/ | sed -n '1,25p'
HTTP/2 200
content-type: text/html; charset=UTF-8

cr0x@server:~$ curl -sS https://example.com/tag/widgets/ | grep -iE 'robots|canonical' | head
<meta name="robots" content="noindex,follow">
<link rel="canonical" href="https://example.com/tag/widgets/" />

Ce que cela signifie : La page de tag est réglée en noindex,follow. C’est souvent correct si les tags ne doivent pas être classés mais servent à la navigation.

Décision : Conservez le follow pour que les liens internes restent découvrables. Assurez-vous que les pages de tags ne figurent pas dans les sitemaps.

Task 5: Confirm robots.txt isn’t blocking something you want indexed

cr0x@server:~$ curl -sS https://example.com/robots.txt
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-json/
Disallow: /tag/
Sitemap: https://example.com/sitemap_index.xml

Ce que cela signifie : /tag/ est interdit, ce qui empêche l’exploration et peut laisser les URLs de tags indexées sans contenu si elles sont découvertes ailleurs.

Décision : Préférez autoriser l’exploration + noindex pour les archives de tags, sauf si vous avez une bonne raison de bloquer l’exploration. Supprimez Disallow: /tag/ et gérez via les meta robots.

Task 6: Find attachment pages returning 200 (thin content candidates)

cr0x@server:~$ wp --path=/var/www/html --allow-root post list --post_type=attachment --post_status=inherit --fields=ID,post_title,post_date --format=table | head
+------+------------------------+------------+
| ID   | post_title             | post_date  |
+------+------------------------+------------+
| 4123 | datasheet-widget-01    | 2023-05-10 |
| 4124 | widget-diagram         | 2023-05-10 |
+------+------------------------+------------+

Ce que cela signifie : Des pièces jointes existent et ont probablement des pages de pièces jointes sauf si le thème ou un plugin les désactive/redirige.

Décision : Redirigez les pages de pièces jointes vers le fichier média ou le post parent, et/ou appliquez noindex aux pièces jointes sur tout le site.

Task 7: List public post types and taxonomies (what can generate archives)

cr0x@server:~$ wp --path=/var/www/html --allow-root eval 'print_r(get_post_types(["public"=>true]));'
Array
(
    [post] => post
    [page] => page
    [attachment] => attachment
    [product] => product
)

cr0x@server:~$ wp --path=/var/www/html --allow-root eval 'print_r(get_taxonomies(["public"=>true]));'
Array
(
    [category] => category
    [post_tag] => post_tag
    [product_cat] => product_cat
    [product_tag] => product_tag
)

Ce que cela signifie : Vous avez des taxonomies qui peuvent générer des archives : post_tag, product_tag, etc.

Décision : Décidez quelles archives de taxonomie doivent être indexables. La plupart des sites n’ont besoin qu’un sous-ensemble (souvent les catégories/product_cat).

Task 8: Detect near-duplicate URL versions (http/https, www/non-www)

cr0x@server:~$ curl -sS -I http://example.com/ | head -n 5
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

cr0x@server:~$ curl -sS -I https://www.example.com/ | head -n 5
HTTP/2 301
location: https://example.com/

Ce que cela signifie : Des redirections sont en place. Bien. La duplication ici est contrôlée.

Décision : Confirmez que toutes les variantes convergent vers un seul hôte et schéma canoniques partout, y compris dans les sitemaps et les balises canonical.

Task 9: Check for trailing slash inconsistencies (duplicate paths)

cr0x@server:~$ curl -sS -I https://example.com/category/widgets | head -n 6
HTTP/2 301
location: https://example.com/category/widgets/

Ce que cela signifie : WordPress normalise vers la version avec slash final via redirection.

Décision : Assurez-vous que les balises canonical utilisent toujours la version normalisée pour éviter le bruit « duplicate, Google chose different canonical ».

Task 10: Find “thin” archives by counting posts per term

cr0x@server:~$ wp --path=/var/www/html --allow-root term list post_tag --fields=term_id,name,count --format=csv | awk -F',' 'NR>1 && $3+0<3 {print}' | head
102,blue-widgets,1
141,widget-ideas,2
177,old-campaign,1

Ce que cela signifie : Beaucoup de tags ont 1–2 articles. Indexer ces pages d’archives est généralement inutile et augmente la bloat.

Décision : Réglez les archives de tags en noindex,follow, ou sélectionnez un petit sous-ensemble de « tags hub » à indexer et noindexez le reste (avancé).

Task 11: Confirm internal search pages exist and are indexable (they shouldn’t be)

cr0x@server:~$ curl -sS -I "https://example.com/?s=widgets" | head -n 12
HTTP/2 200
content-type: text/html; charset=UTF-8

cr0x@server:~$ curl -sS "https://example.com/?s=widgets" | grep -i 'robots' | head
<meta name="robots" content="noindex,follow">

Ce que cela signifie : Les résultats de recherche sont correctement réglés en noindex. S’ils ne l’étaient pas, vous auriez des pages infinies de faible qualité.

Décision : Conservez noindex,follow. Évitez aussi de lier vers les résultats internes de recherche dans les templates.

Task 12: Spot pagination bloat (page/2, page/3…)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$0 ~ /Googlebot/ {print $7}' | grep -E '/page/[0-9]+/' | sed 's/[0-9]\+/\{n\}/' | sort | uniq -c | sort -nr | head
   8022 /category/{n}/
   2210 /tag/{n}/

Ce que cela signifie : Googlebot explore profondément la pagination, surtout des pages de catégories. Cela peut être normal, mais c’est souvent du gaspillage si les pages paginées offrent peu de valeur unique.

Décision : En général : conservez la page 1 indexable, appliquez noindex,follow aux pages 2+ de la pagination. Assurez-vous que les liens de pagination sont explorables pour que Google puisse atteindre des articles plus anciens si nécessaire.

Task 13: Check response codes for suspicious URL families (404/soft 404)

cr0x@server:~$ zcat -f /var/log/nginx/access.log* | awk '$9 ~ /404|410/ {print $7}' | head
/tag/obsolete/
/category/typoo/
/wp-content/uploads/2019/ghost.png

Ce que cela signifie : Archives cassées et médias manquants peuvent créer du gaspillage d’exploration et du bruit d’index.

Décision : Corrigez les liens internes, redirigez si nécessaire, et renvoyez 410 pour les ensembles d’URLs vraiment supprimés quand c’est approprié.

Task 14: Confirm you’re not shipping “noindex” on pages you want ranking

cr0x@server:~$ curl -sS https://example.com/important-landing-page/ | grep -i 'meta name="robots"' -n
24:<meta name="robots" content="noindex,nofollow">

Ce que cela signifie : Quelqu’un (réglage de plugin, bascule d’environnement, ou template) a noindexé une page commerciale. C’est urgent.

Décision : Supprimez le noindex immédiatement, purge des caches, resoumettez pour indexation, et auditez l’origine du réglage pour éviter une récidive.

Règles noindex qui ne tuent pas les liens internes (la liste pratique)

Voici l’ensemble de règles que je déploie le plus souvent sur WordPress. Elles sont orientées vers les sites éditoriaux et de marketing de contenu, mais la logique s’applique largement. Pour l’e‑commerce, vous conserverez plus d’archives de taxonomie indexables, mais vous noindexerez toujours les variantes inutiles.

1) Résultats de recherche internes : noindex, follow

Faire : noindex,follow sur /?s=query et sur tout chemin de recherche « joli » que vous utilisez.

Pourquoi : Les résultats de recherche sont infinis, instables et souvent fins. Ils sont aussi trivially spammés par des permutations de requêtes.

Conserver les liens internes : follow permet à Google de toujours parcourir vers de vraies publications depuis ces pages si elles sont explorées.

2) Archives de tags : par défaut noindex, follow

Faire : noindex des archives de tags sauf si vous les curez activement.

Pourquoi : Les tags sont généralement désordonnés. Les gens créent « blue-widget », « blue-widgets », « bluewidget », puis les laissent tous avec un seul article chacun.

Exception : Si vous avez un vocabulaire contrôlé et que chaque tag est une vraie page hub avec un texte d’introduction unique et une curation significative, indexez-la. La plupart des équipes ne le font pas.

3) Archives d’auteurs : noindex pour auteur unique ou petites équipes

Faire : noindex des archives d’auteurs si elles n’apportent pas de valeur unique au-delà de « articles par X ».

Pourquoi : Elles dupliquent des listes d’articles. Elles créent aussi des pages fines pour « Admin » ou des comptes hérités.

Conserver les liens internes : Laissez les liens d’auteur pour les utilisateurs si nécessaire, mais assurez-vous que l’archive est noindexée.

4) Archives par date : noindex presque toujours

Faire : noindex des archives par date (mensuelles/quotidiennes).

Pourquoi : Les dates ne sont pas thématiques. Elles créent une navigation parallèle inutile pour la recherche et produisent des tonnes de pages de faible valeur.

5) Pages de pièces jointes : rediriger ou noindex strictement

Faire : soit :

• 301 rediriger les pages de pièces jointes vers le post parent (préféré quand le parent existe), ou
• Rediriger vers l’URL du fichier média, ou
• Noindexer les pages de pièces jointes sur tout le site.

Pourquoi : Les pages de pièces jointes sont l’équivalent SEO d’un couloir sans portes.

6) Pagination : généralement indexer la page 1, noindex pages 2+

Faire : appliquer noindex,follow sur les archives paginées au-delà de la page 1 (ex. /category/widgets/page/2/).

Pourquoi : Les pages paginées sont souvent « plus de la même liste », et l’index bloat gonfle rapidement. Mais vous voulez toujours qu’elles soient explorées pour découvrir les contenus plus profonds.

Attention : Si la page 2 contient du contenu unique ou si la catégorie est massive et que la page 1 ne peut pas la représenter, vous pouvez autoriser l’indexation. Ce n’est pas courant pour les blogs ; c’est plus courant pour de grands catalogues.

7) URLs paramétrées : canonicalisez et réduisez à la source

Faire :

• Maintenez la canonical pointant vers l’URL propre (sans paramètres de tracking).
• Arrêtez de générer des liens avec des paramètres UTM à l’intérieur de votre propre site.
• Pour des params notoires comme replytocom, désactivez le comportement ou redirigez.

Pourquoi : Les paramètres se multiplient. Google est performant, mais il n’est pas là pour résoudre vos devoirs de maths.

8) Pages de filtres/facettes (pilotées par plugin) : décidez explicitement des « facettes indexables »

Si vous avez WooCommerce ou un plugin de navigation facettée, vous devez décider quelles combinaisons de filtres représentent de vraies pages de destination.

• Facettes indexables : combinaisons à forte intention que vous pouvez maintenir, avec contenu stable et demande.
• Facettes noindex : tout le reste, surtout les permutations multi-filtres qui créent des millions de pages.

Conserver les liens internes : Il est acceptable que les utilisateurs filtrent ; il n’est pas acceptable que Google indexe chaque permutation. Utilisez noindex,follow ou canonical vers une catégorie parent quand c’est approprié.

9) Archives de taxonomie dupliquées entre post types : consolidez

Les configurations WordPress créent parfois plusieurs taxonomies identiques (« topics », « tags », « labels »). Si deux archives se concurrencent pour la même intention, choisissez-en une et noindexez ou redirigez l’autre.

10) Aperçus, staging et pages de requête : bloquez correctement

Faire : Assurez-vous que le staging est bloqué au niveau serveur (auth) et aussi avec robots, et qu’il n’apparaît jamais dans les sitemaps.

Et pour les aperçus comme ?preview=true : canonicalisez vers l’URL publiée et évitez l’indexation. Ces URLs fuient facilement.

Blague #2 : Si vous laissez indexer chaque archive de tag, votre stratégie SERP devient « espérons que l’algorithme nous adopte ». Ce n’est pas un plan ; c’est un appel à l’aide.

Ce que signifie réellement « règles noindex qui ne tuent pas les liens internes »

Cela signifie éviter nofollow par défaut. Le modèle pour les pages de faible valeur est :

• noindex,follow pour les pages qui aident la découverte mais ne doivent pas être classées.
• 301 redirect pour les duplicatas et les familles d’URLs obsolètes.
• Disallow seulement quand l’exploration du contenu est activement nuisible (espaces infinis, zones privées, endpoints lourds), et si vous assumez les effets secondaires sur l’indexation.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise était en plein replatform, mais « en plein replatform » est le jargon corporate pour « tout est en feu, poliment ». Leur blog WordPress était derrière un CDN et une couche de cache, et quelqu’un a remarqué que Googlebot martelait les URLs /?s=. La solution rapide semblait évidente : bloquer la recherche interne dans robots.txt.

Ils ont ajouté Disallow: /?s= et sont rentrés chez eux contents. Pendant environ une semaine, tout avait l’air d’aller—le volume de crawl a chuté et les tableaux de bord se sont calmés. Puis le trafic organique a commencé à décliner, lentement mais sûrement, comme un disque de stockage qui lâche tous les vendredis.

La mauvaise hypothèse : « Si on interdit l’exploration, ça ne s’indexera pas. » En réalité, c’était pire. Google avait déjà découvert des milliers d’URLs de recherche via des liens internes et des référents externes. Avec l’exploration bloquée, il ne pouvait plus les refetcher pour voir un directive noindex ou une canonical, et ne pouvait pas consolider les signaux proprement.

Search Console a commencé à afficher un mélange moche de « Indexed, though blocked by robots.txt » et de confusion canonique. L’ensemble indexé est devenu pollué d’entrées uniquement-URL et d’extraits de faible qualité. Pendant ce temps, certains posts réels étaient moins explorés parce que Googlebot découvrait toujours des ordures, juste avec moins de capacité d’évaluer.

La correction a été ennuyeuse et précise : retirer le disallow, appliquer noindex,follow aux pages de recherche, et arrêter de lier aux URLs de recherche dans la navigation. Le crawl a augmenté brièvement, puis s’est normalisé. L’index s’est nettoyé sur les semaines suivantes. La leçon : n’utilisez pas robots.txt comme un balai ; c’est plutôt un panneau « ne pas entrer » que les gens peuvent toujours noter sur un morceau de papier.

Mini-récit 2 : L’optimisation qui a échoué

Une équipe marketing d’entreprise a décidé de « simplifier le SEO » en mettant noindex,nofollow sur toutes les pages de tags, catégories et auteurs. L’idée : seuls les articles doivent classer, tout le reste est du bruit.

Ça a fonctionné—en partie. L’index bloat a chuté. Mais la découverte des anciens articles aussi. Le site avait des années de contenu et la navigation interne principale était basée sur les catégories. Les catégories étaient le tissu conjonctif qui menait les crawlers et les utilisateurs vers les archives profondes.

Avec nofollow partout sur ces pages, le graphe d’exploration s’est amincit. Google a commencé à traiter des parties du site comme des îles isolées. Un tas d’articles long-tail a perdu des impressions parce qu’ils n’étaient plus atteints aussi fréquemment, et le contexte des ancres internes s’est affaibli.

Ils ont annulé la portion nofollow, en laissant noindex,follow sur les archives de faible valeur. Pour les catégories clés qui servaient de vraies pages d’atterrissage, ils les ont rendues indexables et ont ajouté de courtes introductions éditoriales. Le résultat n’était pas spectaculaire, mais il était stable : moins d’URLs inutiles indexées, et le maillage interne a retrouvé sa fonction.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Un éditeur gérait WordPress à grande échelle avec plusieurs types de post personnalisés et une rotation de plugins. Leur équipe SEO voulait noindexer agressivement pour réduire le « Crawled — currently not indexed ». L’équipe SRE a répondu : « D’accord, mais on le fait via le change control. » Tout le monde a grogné, comme la tradition le veut.

Ils ont maintenu un document d’inventaire simple : quels types d’URL existent, lesquels sont indexables, lesquels sont noindex, lesquels sont redirigés, et lesquels sont bloqués. Pas une feuille de calcul magistrale—juste une carte vivante. Chaque changement proposé devait nommer la famille d’URLs et les résultats attendus dans les logs et Search Console.

Ils faisaient aussi des échantillonnages hebdomadaires des logs : principaux chemins Googlebot, principaux 404, et principaux URLs paramétrés. Quand une mise à jour de plugin a soudain introduit des variantes ?amp=1 et a commencé à les lier en interne, cela a été détecté en quelques jours, pas en plusieurs mois.

Cette pratique ennuyeuse a évité un gros bazar. Ils n’avaient pas besoin d’exploits héroïques. Ils avaient besoin d’une boucle de rétroaction : déployer, observer, ajuster. C’est la même discipline que pour des régressions de performance de stockage—mesurez avant et après, et ne faites pas confiance à « ça devrait aller ».

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: “Indexed, though blocked by robots.txt” grows

Cause racine : Vous avez désactivé l’exploration d’URLs qui sont découvrables via des liens, donc Google indexe l’URL sans pouvoir évaluer le contenu ou les directives.

Correction : Supprimez le disallow pour cette famille d’URLs et utilisez noindex dans la page. Pour les espaces vraiment infinis, envisagez de bloquer, retirer les liens internes et renvoyer 404/410 si approprié.

2) Symptom: Important pages show “Duplicate without user-selected canonical”

Cause racine : Plusieurs variantes d’URL existent (paramètres, trailing slash, http/https, www/non-www, pagination), et les canonicals sont incohérents ou peu crédibles.

Correction : Normalisez avec des redirections, assurez-vous que les balises canonical pointent vers l’URL finale 200, et arrêtez de lier en interne vers des variantes non canoniques.

3) Symptom: Tag pages outrank posts (and conversions tank)

Cause racine : Les tags sont indexés, fins, et correspondent accidentellement à des requêtes larges. Google choisit la page de tag comme « meilleure » parce que le reste est dilué ou dupliqué.

Correction : Noindexez les archives de tags par défaut ; ne laissez indexables que des hubs sélectionnés. Renforcez les liens internes vers la page de destination souhaitée.

4) Symptom: Lots of “Crawled — currently not indexed” for archives and pagination

Cause racine : Google les crawle mais ne voit pas assez de valeur unique, ou voit des signaux de duplication.

Correction : Noindexez les archives de faible valeur et la pagination profonde ; ajoutez des canonical quand la duplication est le problème principal ; réduisez le nombre d’URLs inutiles découvrables.

5) Symptom: Sudden deindexing after a plugin update

Cause racine : Le plugin SEO ou le thème a modifié le meta robots globalement, ou a activé un drapeau « décourager les moteurs de recherche ».

Correction : Auditez le meta robots sur les templates clés, verrouillez la configuration via des vérifications d’environnement, et ajoutez un test de monitoring qui curl quelques pages critiques pour vérifier index,follow.

6) Symptom: Attachment pages are indexed with weird snippets

Cause racine : Les pages de pièces jointes sont fines et parfois auto-générées sans contexte ; elles peuvent être liées depuis la recherche d’images ou des listings médias internes.

Correction : Redirigez les pages de pièces jointes vers les posts parents ou les fichiers médias ; noindex en solution de secours.

7) Symptom: Crawl rate is high but rankings don’t improve

Cause racine : L’effort de crawl est dépensé sur des ensembles d’URLs de faible valeur : paramètres, pages de tags, recherche interne et archives fines.

Correction : Réduisez la découvrabilité des ordures et resserrez l’ensemble indexable. Ensuite, améliorez les pages qui restent indexables.

Listes de contrôle / plan étape par étape

Étape 1 : Définissez votre ensemble indexable (consignez-le)

• Indexable : articles, pages, produits, catégories/collections sélectionnées.
• Noindex : recherche interne, archives de tags, archives par date, la plupart des archives d’auteurs, pages de pièces jointes, pages paginées 2+ (généralement).
• Rediriger : duplicatas (http→https, www→non-www), pages de pièces jointes (préféré), ensembles d’URLs obsolètes.
• Bloquer l’exploration : admin, login, endpoints API lourds que vous ne voulez jamais voir explorés.

Étape 2 : Alignez les sitemaps avec cet ensemble

• Seules les URLs indexables doivent figurer dans les sitemaps XML.
• Retirez les types d’URLs noindexés des sitemaps via les réglages du plugin.
• Confirmez que les URLs du sitemap retournent 200 et sont canoniques.

Étape 3 : Corrigez d’abord les plus grands multiplicateurs de bloat

• Pages de recherche interne : assurez-vous de noindex,follow.
• Tags : réglez en noindex,follow sauf si curation.
• Pièces jointes : rediriger ou noindex.
• Paramètres : arrêtez de les générer en interne ; canonicalisez ; envisagez la normalisation en bordure pour les params connus.
• Pagination : noindex pages 2+ (généralement).

Étape 4 : Validez via les logs et des vérifications ponctuelles

• Échantillonnez les requêtes Googlebot chaque semaine et suivez les principales familles d’URLs.
• Curl une poignée de pages représentatives et confirmez les meta robots + canonical.
• Surveillez les nouvelles familles d’URLs après les mises à jour de plugins/thèmes.

Étape 5 : Ajoutez des garde-fous (monitoring)

• Automatisez des vérifications du meta robots sur 10–20 pages clés.
• Alertez sur des pics d’exploration paramétrée ou de 404.
• Conservez un « inventaire des directives SEO » à côté des docs d’infrastructure.

FAQ

Dois-je noindexer les pages de catégories ?

Généralement non. Les catégories représentent souvent de vrais thèmes et peuvent être de bonnes pages d’atterrissage. Indexez les catégories que vous êtes prêt à soigner ; noindexez uniquement si elles sont fines et redondantes.

Est-ce que noindex,follow est toujours valide, ou Google l’ignore ?

C’est valide. La nuance est que Google peut traiter nofollow comme une indication dans certains contextes, mais noindex reste la directive adaptée pour « ne pas indexer cette page ».

Qu’est-ce qui est mieux : noindex ou canonical pour les duplicatas ?

Si la page est une vraie variante dupliquée qui ne doit pas exister comme destination, privilégiez les redirections et la canonicalisation. Utilisez noindex pour les pages ayant un usage utilisateur mais qui ne doivent pas classer (résultats de recherche, certaines archives).

Noindexer les pages de tags va-t‑il nuire au maillage interne ?

Si vous utilisez noindex,follow, les chemins d’exploration sont conservés. Le vrai risque est de mettre nofollow partout ou de bloquer l’exploration dans robots.txt.

Dois-je disallow les archives de tags dans robots.txt pour économiser le crawl budget ?

Rarement. Disallow empêche l’exploration, ce qui peut créer des artefacts « indexés mais bloqués » si les URLs de tags sont découvertes ailleurs. Laissez-les être explorées et noindexez-les à la place.

Combien de temps faut-il pour que l’index bloat diminue après les changements ?

Prévoyez des semaines, pas des jours. Google doit recrawler les pages pour voir les directives, et le nettoyage de l’index n’est pas instantané. Vos logs refléteront les changements de comportement plus tôt que l’index.

Dois-je retirer les URLs noindexées des sitemaps ?

Oui. Les sitemaps sont une liste de « veuillez indexer ceci ». Inclure des URLs noindexées envoie des signaux conflictuels et gaspille de l’attention.

Pour la pagination—devrais-je canonicaliser page 2+ vers la page 1 ?

Faites attention. Canonicaliser la page 2 vers la page 1 peut masquer des éléments profonds et confondre Google sur la distinction des listes. Un modèle plus sûr est souvent noindex,follow sur les pages 2+ tout en conservant des liens de pagination propres.

Puis-je simplement supprimer les pages de tags ?

Vous pouvez arrêter de les lier et de les générer, mais les URLs existantes peuvent persister à l’extérieur. Noindex et/ou 301 redirections sont plus propres que de faire semblant qu’elles n’ont jamais existé.

Bloquer /wp-json/ aide-t‑il ?

Parfois. Pour de nombreux sites, il est acceptable de disallow si cela crée du bruit d’exploration, mais soyez prudent : certaines fonctionnalités front-end et plugins en dépendent. Testez avant de fermer la porte.

Conclusion : prochaines étapes qui fonctionnent vraiment

Cessez de traiter l’index bloat comme une malédiction SEO mystique. C’est juste une surface d’URL incontrôlée. WordPress générera des pages jusqu’à la fin des temps ; votre travail est de décider lesquelles comptent.

Faites ceci ensuite, dans l’ordre :

1. Inventoriez les familles d’URLs (articles, pages, catégories, tags, auteurs, dates, pièces jointes, recherche, paramètres, pagination).
2. Définissez les défauts : recherche, tags, date, pièces jointes → noindex,follow (ou rediriger les pièces jointes). Conservez les catégories indexables uniquement si ce sont de vrais hubs.
3. Éliminez les contradictions : retirez les URLs noindexées des sitemaps ; supprimez les disallows robots.txt qui créent des problèmes « indexés mais bloqués ».
4. Surveillez les logs chaque semaine jusqu’à ce que le mix d’exploration semble sain (moins de paramètres, moins de pages de tags, moins de paginations profondes).
5. Ajoutez des garde-fous pour qu’une mise à jour de plugin ne puisse plus noindexer silencieusement vos meilleures pages.

Si vous faites cela, vous obtiendrez un empreinte d’index plus petite et plus propre et un site plus facile à comprendre pour les crawlers. C’est tout le jeu : rendez la structure souhaitée évidente, et cessez d’offrir à Google un buffet de restes.