Les critères techniques d’une architecture de site silo qui boostent le SEO

Un client m'a envoyé un jour un audit très propre. Maillage interne noté 8/10. Structure "logique". Trois semaines plus tard, Search Console affichait un taux de pages indexées catastrophique sur la moitié de son catalogue. Le problème ne venait pas du maillage. Il venait d'un détail que personne n'avait regardé : les liens entre ses catégories passaient tous par la page d'accueil, et son fil d'Ariane envoyait 40 % du jus vers des URL à paramètres que Google traitait comme des doublons. Sur le papier, c'était un silo. Techniquement, c'était un gruyère.

C'est la différence que je veux qu'on regarde ensemble : un silo n'est pas un schéma sur une diapo, c'est un ensemble de critères techniques vérifiables. Si vous ne pouvez pas les mesurer, vous n'avez pas une architecture, vous avez une intention.

Les critères techniques d'une architecture de site silo : ce qui se vérifie vraiment

Vous avez sûrement lu la définition classique : une page pilier qui vise la requête large, des pages satellites qui couvrent les sous-sujets, des liens verticaux entre elles. C'est vrai. Et c'est insuffisant, parce que cette définition décrit une intention éditoriale, pas une architecture technique. N'importe qui peut dessiner ça sur un tableau blanc en dix minutes.

Ce qui va faire la différence, ce sont des seuils qu'on peut contrôler dans un crawler ou dans les logs serveur.

La profondeur de clics, pas la profondeur "logique"

Règle que j'applique depuis un moment sur mes propres projets : aucune page satellite ne doit se trouver à plus de 3 clics de la page d'accueil. Pas "3 niveaux dans mon arborescence mentale" — 3 clics réels, comptés par un robot. J'ai vu des sites où une fiche produit était "au 2e niveau" dans l'organigramme du propriétaire et au 7e clic dans un crawl. Vous devinez qui a raison.

Pourquoi cette limite ? Parce que chaque clic supplémentaire dilue la transmission de popularité et rend le budget de crawl moins prévisible. Au-delà de 4 clics, on entre dans la zone où une page n'est plus visitée régulièrement par le robot, et où une nouvelle page peut mettre des semaines à être découverte.

La densité de liens internes par page

Franchement, ce critère, personne n'en parle et c'est une erreur. Une page qui contient 200 liens internes n'aide personne : le poids se disperse sur trop de cibles. Je vise personnellement entre 30 et 80 liens internes par page selon le type (une page pilier peut monter plus haut, une fiche produit doit rester bien plus basse).

Le corollaire, c'est que le nombre de satellites par silo a une limite pratique. Un silo à 60 pages satellites finit par diluer l'attention. La plupart des silos que j'ai posés tiennent entre 8 et 25 satellites.

La structure d'URL comme signal du silo

Un silo cohérent se lit dans l'URL. Pas besoin d'y mettre quinze mots-clés — juste une hiérarchie stable. Quelque chose comme /rubrique/sous-rubrique/page/, appliqué partout, sans exception. Les URL qui mélangent les niveaux (une page en /nom-du-produit à la racine et sa voisine en /rubrique/categorie/nom-du-produit) cassent la lecture que fait Googlebot de votre hiérarchie.

Deux pièges fréquents : les tags WordPress qui génèrent des URL en doublon des catégories, et les paramètres de tri qui créent autant de versions d'une même liste. Les deux se règlent avec une politique canonical claire — mais il faut la décider, pas la subir.

Silo physique ou silo virtuel : laquelle choisir selon votre configuration ?

C'est la question à laquelle je vois le plus de réponses bancales. La vraie différence est simple : dans un silo physique, la structure d'URL et le fil d'Ariane matérialisent la thématique. Dans un silo virtuel, l'URL ne dit rien, mais les liens contextuels créent la hiérarchie.

Le silo physique est plus robuste parce qu'il est compréhensible par un robot qui ne suit pas forcément tous les liens. Le silo virtuel est plus souple, mais il repose entièrement sur le maillage — si vous le ratez, il ne reste rien.

Critère	Silo physique (URL)	Silo virtuel (liens)
Structure d'URL	Hiérarchique et stable	Plate, non informative
Dépendance au maillage	Faible	Totale
Résistance au refonte	Bonne (l'URL porte le sens)	Faible (une suppression de lien casse le silo)
Souplesse éditoriale	Limitée (changer d'URL = rediriger)	Élevée
Application typique	E-commerce, catalogue structuré	Blog multithématique, site éditorial

Mon avis, et je le défends : si vous débutez, partez sur du physique. Les erreurs de silo virtuel sont silencieuses et vous ne vous en apercevez qu'au moment où vous perdez du trafic. Le physique pardonne plus.

Comment gérer les liens transverses entre silos ?

La règle que j'applique : un lien entre deux silos passe par les pages piliers, jamais directement entre satellites de thèmes différents. Sinon vous recréez un plat de spaghettis où chaque page pointe vers n'importe quoi, et le robot ne distingue plus les regroupements thématiques.

L'exception que je tolère : un lien contextualisé dans le corps du texte, quand il sert vraiment le lecteur. Une fois par page, deux grand maximum. Au-delà, le silo se dissout.

Maillage interne, fil d'Ariane et redirections : les critères qu'on oublie

Trois briques techniques font partie du silo et sont presque toujours traitées à part, comme si elles n'avaient aucun rapport. Erreur.

Le fil d'Ariane

Il doit refléter la hiérarchie réelle, pas un chemin de navigation. Beaucoup de CMS génèrent un fil d'Ariane basé sur l'historique de clics de l'utilisateur, ce qui produit des variantes différentes selon le parcours. Résultat : la même page reçoit des dizaines de liens internes avec des chemins distincts. À corriger en configurant le fil d'Ariane sur la hiérarchie de contenu, pas sur la navigation.

Les redirections 301 lors d'une refonte

Un silo refondu sans plan de redirection 301 complet détruit sa propre cohérence. Quand je change l'URL d'une page pilier, je redirige en 301 non seulement l'ancienne URL, mais aussi toutes les variantes générées par les filtres ou les paginations. C'est fastidieux. C'est aussi ce qui distingue une refonte propre d'une perte de trafic.

Canonical et nofollow

Les balises canonical servent à pointer les versions dupliquées vers la version de référence — attention, dans un silo, la canonical ne doit jamais traverser les silos. Une page satellite pointe vers la page pilier de son silo, pas vers un équivalent ailleurs.

Pour le nofollow : à réserver aux liens publicitaires, aux liens de commentaires non modérés, et éventuellement aux liens vers des pages utilitaires (mentions, CGV) qui n'ont pas leur place dans la hiérarchie thématique. Pas plus.

Comment valider techniquement qu'un silo est bien interprété ?

Le schéma sur le tableau blanc ne prouve rien. Trois vérifications me suffisent pour savoir si un silo tient ou pas.

1. Crawl complet du site avec un outil type Screaming Frog ou équivalent. Objectif : vérifier que chaque page satellite reçoit un lien depuis sa page pilier, et que la profondeur de clics ne dépasse pas le seuil fixé.
2. Logs serveur sur 30 jours. On y lit quelles pages le robot visite réellement, à quelle fréquence, et dans quel ordre. Une page du silo jamais visitée est un signal d'alerte immédiat.
3. Search Console : section "Liens", onglet "Liens internes". On compare la distribution des liens internes avec la hiérarchie prévue. Si une page pilier reçoit moins de liens que prévu, c'est que le maillage réel ne correspond pas à l'intention.

Et un quatrième critère moins évident : la couverture d'indexation par silo. Si Google indexe 90 % des pages d'un silo et 40 % de l'autre, l'architecture est déséquilibrée. Ça se corrige souvent en un après-midi, mais il faut le mesurer.

Que faire d'un contenu qui relève de deux silos ?

Cas classique et frustrant. Une page qui parle à la fois de "référencement technique" et de "performance web", par exemple. Deux options honnêtes.

Soit vous choisissez le silo dominant et vous créez les liens contextuels vers l'autre — un ou deux maximum, en corps de texte. Soit vous dupliquez le contenu en deux versions distinctes, chacune taillée pour son public, avec une canonical qui ne pointe pas vers l'autre. Le copier-coller avec canonical croisée est le pire des deux mondes : Google en ignorera une, et vous aurez perdu les deux angles.

Les erreurs qui coûtent le plus sur une architecture silo

Une liste, tirée de ce que j'ai vu et de ce que j'ai fait.

• Créer un silo avec une seule page. Un silo à un satellite n'est pas un silo, c'est une page avec une catégorie vide.
• Oublier les pages orphelines. Elles existent, elles traînent, et elles brouillent la lecture globale. À lier ou à supprimer, sans état d'âme.
• Multiplier les tags WordPress. Un blog bien construit a souvent 4 à 6 catégories et beaucoup moins de tags. Si chaque article porte 8 tags, vous avez construit un silo virtuel incontrôlable.
• Laisser le fil d'Ariane générer des chemins variables selon le parcours utilisateur. C'est un classique, et ça se règle en configuration.
• Confondre profondeur logique et profondeur de clics. Le robot compte les clics, pas vos intentions.

Ce que je remarque sur les projets où le silo fonctionne vraiment, c'est rarement une question de sophistication. C'est une question de discipline. Les seuils sont tenus, la structure d'URL ne bouge pas, le maillage est vérifié une fois par trimestre. Rien de brillant. Juste de la constance.

Et c'est peut-être ça, la vérité un peu ingrate de l'architecture silo : la plupart des sites qui échouent n'ont pas un mauvais design. Ils ont juste arrêté de mesurer au bout de deux mois, quand la structure tenait encore à peu près — jusqu'à ce qu'une nouvelle catégorie, un nouveau tag, une refonte d'URL grignotent silencieusement ce qui avait été posé. Si vous ne relisez pas vos logs de crawl ce trimestre, vous ne saurez pas si votre silo tient toujours. Et c'est précisément le moment où il commence à céder.