Architecture web et CMS : ce qui décide vraiment du SEO

Un site qui stagne malgré des liens corrects a rarement un problème de liens. Il a un problème de plomberie : la page qu'on pousse est à cinq clics de la home, elle reçoit deux liens internes venus d'un menu déroulant présent partout, et le CMS a émis trois variantes d'URL qui se partagent son historique. On achète du signal externe pour le verser dans un seau percé, puis on conclut que le netlinking ne marche pas.

Le CMS ne classe rien, son graphe d'URL classe

La question « quel CMS est le meilleur pour le SEO » n'a pas de réponse utile, et c'est la seule chose intéressante à en dire. WordPress, Shopify, Astro, Webflow, un headless maison : tous sont capables de produire une architecture propre et tous produisent une architecture sale par défaut. La différence entre deux sites sous le même CMS est plus grande que la différence entre deux CMS.

Ce qui se décide vraiment au moment du choix, ce sont deux choses très concrètes. D'abord, quelles URLs le système émet sans qu'on lui demande : archives d'auteur, archives de tags, pages de pièces jointes, paginations infinies, combinaisons de filtres à facettes, variantes de tri. Ensuite, quel effort il faut fournir pour les faire taire. Sur WordPress, c'est trois réglages et un plugin. Sur un e-commerce à facettes, c'est un chantier de plusieurs jours avec l'équipe technique. Sur un headless, le piège s'inverse : le système n'émet presque rien de parasite, mais le maillage interne devient entièrement manuel, et on se retrouve avec des pages parfaitement propres que personne ne lie.

La position à tenir face à un client qui hésite : le CMS se choisit sur qui édite, à quelle fréquence, avec quelle compétence technique disponible et quel budget de maintenance. Le SEO n'entre dans cette décision que sous forme de coût de nettoyage. La vraie décision SEO se prend juste après, et elle est indépendante de l'outil : quelle taxonomie, quelle profondeur maximale, quelles URLs on refuse d'émettre.

Ce que 2026 a réellement changé

Deux évolutions rendent l'architecture plus déterminante qu'elle ne l'était il y a cinq ans, et aucune des deux n'est un facteur de classement au sens classique.

La première tient au rythme des mises à jour. Le core update de décembre 2025 a mis environ dix-huit jours à se déployer, celui du 27 mars 2026 environ douze à quatorze jours selon le suivi de Search Engine Land. Ce déploiement continu s'accompagne d'une pression sur l'allocation de crawl : Google réserve son budget aux URLs qui bougent et qui méritent d'être indexées. Un site qui dépense son quota sur des combinaisons de facettes et des archives paginées fait attendre ses pages neuves. Sur un e-commerce ou un média à forte cadence, ce délai se compte en semaines, et il est invisible dans les rapports de positions : la page n'est simplement pas encore dans l'index.

La seconde évolution est la montée des réponses génératives. Ahrefs relève une couverture des AI Overviews passant de 34,5 % des requêtes en décembre 2025 à 48 % en mars 2026. Leur mise à jour du 28 mai 2026 chiffre à 58 % la baisse du taux de clic organique en position 1 sur les requêtes concernées, en comparant décembre 2023 à décembre 2025. Le jeu de données de Seer Interactive, sur 3 119 requêtes informationnelles suivies de juin 2024 à septembre 2025, va dans le même sens avec un CTR organique tombé de 1,76 % à 0,61 % sur les requêtes à AI Overview.

La conséquence architecturale est directe : être premier ne suffit plus à être cité. Une page citable est une page autoportante, dont la hiérarchie de titres correspond à des questions réelles, dont le contenu ne dépend pas d'un carrousel chargé en JavaScript, et qui se situe dans un ensemble cohérent plutôt que seule au milieu d'une taxonomie floue. Les indicateurs de performance perçue jouent ici un rôle de plafond plutôt que de levier : ils ne font pas gagner de positions, mais un INP dégradé au delà de 200 ms sur mobile pénalise l'expérience réelle, et c'est précisément ce que les empilements de plugins produisent sur les CMS grand public.

Auditer l'architecture avant d'acheter un lien

C'est le point où l'architecture cesse d'être un sujet technique pour devenir un sujet de budget. Un lien externe entre sur une page précise. Ce que cette page en redistribue vers le reste du site dépend entièrement du graphe interne. Acheter un lien vers une page profonde, faiblement maillée et concurrencée par sa propre variante canonique, c'est payer pour un signal qui s'arrête à la porte.

La séquence d'audit tient en quelques passes, avant tout arbitrage budgétaire :

1. Crawler le site et sortir la profondeur de clic réelle de chaque page cible depuis la home, en ignorant les liens de menu global. La règle des trois clics n'est pas une superstition, c'est un proxy fiable de la fréquence de passage.
2. Compter les liens internes contextuels entrants, uniquement ceux placés dans le corps de texte. En dessous de cinq, la page n'est pas considérée comme importante par le site lui même, et aucun lien externe ne corrigera ce message.
3. Vérifier l'indexabilité de bout en bout : canonical cohérente, pas de chaîne de redirection, pas de variante avec ou sans slash final qui coexiste.
4. Regarder le nombre de liens sortants de la page réceptrice. Une page qui pointe vers cent quatre-vingts URLs ne transmet rien de significatif à aucune.
5. Seulement ensuite, arbitrer la cible et le budget.

Cet ordre inverse la pratique courante, qui consiste à choisir la page en fonction du mot clé puis à acheter. Dans les faits, corriger le maillage interne autour d'une page avant d'y envoyer trois liens change davantage le résultat que de monter en gamme sur l'autorité du domaine source. C'est la partie du travail qu'aucune plateforme ne fait à votre place, que vous passiez par un catalogue en libre service ou par un accompagnement complet sur la campagne.

La contrainte vaut aussi côté hôte. Sur les 53 médias que nous opérons en propre, l'arborescence est bornée par construction : tout article est à deux clics de la home via sa rubrique, et reçoit des liens contextuels depuis les articles voisins. Ce n'est pas une coquetterie éditoriale. Un article publié à quatre clics de la home met des semaines à être crawlé, et pendant ces semaines le lien qu'il porte ne vaut rien pour l'acheteur.

Les défauts qu'on retrouve en audit

Les mêmes cinq problèmes reviennent, quel que soit le CMS, et aucun n'apparaît dans un rapport d'outil sous une étiquette alarmante.

Les facettes indexables

Un e-commerce avec quatre filtres combinables génère mécaniquement des dizaines de milliers d'URLs, dont presque aucune n'a de demande de recherche propre. Le réflexe de tout ouvrir « au cas où » a été rentable vers 2016. En 2026, il consomme le budget de crawl qui devrait servir aux nouvelles fiches produit. La bonne pratique est de sélectionner à la main les cinq à quinze combinaisons qui correspondent à une intention réelle, de les traiter comme des pages à part entière avec un contenu propre, et de fermer le reste.

Le sitemap pris pour un maillage

Déclarer une URL dans le sitemap indique son existence, pas son importance. Une page orpheline listée dans un sitemap peut rester des mois sans visite de crawler. Quand un client affirme que ses pages sont « soumises à Google », la question suivante est toujours la même : combien de liens en corps de texte pointent vers elles depuis le site.

Le menu comme unique système de liens

Un lien présent sur toutes les pages ne hiérarchise rien, puisqu'il ne distingue aucune page des autres. Le maillage qui porte un signal est celui qui varie : liens contextuels dans les articles, blocs de recommandation calculés sur la proximité sémantique réelle et non sur la date de publication.

Les migrations sans plan de redirection un pour un

Le cas classique : refonte de CMS, changement de structure d'URL, redirection en masse de toute l'ancienne arborescence vers la home ou vers la catégorie parente. Le trafic ne revient pas, et le diagnostic arrive six mois plus tard. Le plan doit être écrit URL par URL avant le lancement, avec une vérification que les règles ne se masquent pas entre elles.

Les contenus de tiers hébergés dans un sous dossier

Depuis le durcissement de la politique sur l'abus de réputation de site en août 2025, héberger du contenu partenaire sans rapport avec le sujet du site dans un sous répertoire est devenu un pari risqué. Si le contenu ne relève pas du domaine éditorial du site, il n'a rien à y faire.

Ce qu'on ferait sur un site à refaire

La séquence est toujours la même, et elle commence loin de l'outil. On fixe d'abord la taxonomie, fermée, avec un nombre de rubriques qu'on peut compter sur ses doigts et une profondeur maximale de trois niveaux. Une taxonomie qui grossit à mesure que le contenu arrive produit invariablement des rubriques à deux articles et des pages listes vides.

On applique ensuite la règle d'une URL par intention de recherche. Deux pages qui répondent à la même question ne se complètent pas, elles se concurrencent, et le CMS n'a aucun moyen de le savoir à votre place. Puis on construit le maillage comme un livrable à part entière, avec un objectif chiffré de liens contextuels entrants par page importante, vérifié après publication et pas seulement planifié.

Sur la partie technique, deux garde fous suffisent à couvrir la majorité des dégâts : un budget de performance mesuré sur mobile, en surveillant en particulier la réactivité aux interactions plutôt que le seul temps de chargement, et une revue trimestrielle des URLs émises pour repérer ce que les nouveaux plugins ou modules ont ajouté sans prévenir. Les seuils publiés par Google servent ici de plancher, pas d'objectif.

Le netlinking arrive en dernier, et c'est volontaire. Une campagne lancée sur une architecture saine produit un résultat lisible : on sait quelle page a reçu quoi, et on peut attribuer le mouvement. Lancée sur une architecture confuse, elle produit un budget dépensé et un débat sans fin sur la qualité des liens. Nos tarifs sont publics précisément pour que cet arbitrage se fasse sur des chiffres, avant l'achat plutôt qu'après.