Amir Mousavi

Liste de vérification

Liste de vérification d’architecture SEO

Mis à jour le · Par Amir Mousavi

L’architecture SEO est la structure qui aide les moteurs de recherche et les systèmes IA à comprendre quelles pages existent, ce que chaque page répond et comment les pages se relient. Une architecture utile donne à chaque URL importante une intention claire, une identité canonique et un chemin de maillage interne.

Architecture de l’information

  • Regrouper les sujets en grappes : une page pilier avec des pages de soutien. Le pilier répond à la question large, chaque page de soutien à une question précise. Construisez la grappe avant d’écrire : plaquer une structure sur un ensemble d’articles existants oblige généralement à en fusionner ou en supprimer plusieurs.

    Comment vérifier : Listez chaque grappe avec son pilier et ses URL de soutien.

    Réussi quand : Chaque page indexable appartient à une grappe, et chaque grappe a un seul pilier.

  • Donner à chaque page une intention de recherche unique et distincte. Deux pages visant la même intention ne doublent pas vos chances : elles divisent les signaux et laissent le moteur choisir, souvent la plus faible. Si vous ne pouvez pas dire en une phrase ce qui les distingue pour un lecteur, elles n’en font qu’une.

    Comment vérifier : Dans la Search Console, ventilez vos requêtes principales par page.

    Réussi quand : Aucune requête importante ne voit deux de vos pages s’y relayer.

  • Garder des URL lisibles, stables et peu profondes. Une URL est un identifiant durable : fixez le modèle avant de publier plutôt que de migrer plus tard, car chaque changement coûte une redirection et une part d’autorité. La profondeur compte moins que la capacité du chemin à décrire le contenu.

    Comment vérifier : Lisez le modèle d’URL de chaque gabarit.

    Réussi quand : Les URL décrivent le contenu en mots, ne portent ni date ni identifiant appelés à changer, et le modèle est écrit.

  • Éviter les pages minces ou en double qui se concurrencent pour la même requête. « Mince » se juge à la réponse apportée, pas au nombre de mots. Le test utile : cette page apporte-t-elle quelque chose que les trois premiers résultats ne donnent pas déjà ? Sinon, la fusionner vaut mieux que la publier.

    Comment vérifier : Comparez chaque page candidate aux trois premiers résultats de sa requête.

    Réussi quand : Chaque page apporte quelque chose que ces résultats n’ont pas ; les autres sont fusionnées ou retirées.

Maillage interne

  • Utiliser un texte d’ancrage descriptif et axé sur les mots-clés. L’ancre annonce ce qui attend le lecteur et le robot à l’autre bout. Variez-la naturellement entre les liens vers une même page : répéter partout la même chaîne exacte relève de la manipulation, pas de l’éditorial.

    Comment vérifier : Exportez les textes d’ancre internes d’une exploration.

    Réussi quand : Aucune ancre « cliquez ici » ou « en savoir plus », et les liens vers une même page emploient des formulations variées et descriptives.

  • S’assurer que les pages importantes sont accessibles en quelques clics. La profondeur de clic depuis l’accueil approxime l’importance qu’un site accorde à une page. Auditez régulièrement les pages orphelines : elles s’accumulent discrètement à chaque refonte de la navigation.

    Comment vérifier : Vérifiez la profondeur d’exploration et le rapport des pages orphelines dans un robot d’exploration alimenté par le sitemap.

    Réussi quand : Les pages importantes sont à environ trois clics de l’accueil, et aucune URL du sitemap n’est orpheline.

Gabarits et métadonnées

  • Définir des modèles de titre et de méta-description par gabarit. Les modèles assurent la cohérence d’un grand site sans rédiger chaque balise à la main. Rappel : la méta-description n’est pas un facteur de classement et est souvent réécrite dans les résultats — elle gagne des clics, pas des positions.

    Comment vérifier : Explorez le site et exportez titres et descriptions par gabarit.

    Réussi quand : Chaque gabarit suit son modèle documenté, sans doublon ni espace réservé oublié.

  • Maintenir un seul H1 clair par page avec un ordre de titres logique. Ne sautez pas de niveau pour obtenir une taille de police : c’est le rôle du CSS. Une hiérarchie propre est aussi ce qui permet à un assistant d’extraire un passage précis plutôt que la page entière.

    Comment vérifier : Exportez les H1 et la structure des titres d’une exploration.

    Réussi quand : Un seul H1 par page, et aucun niveau de titre sauté.

  • Ajouter des données structurées adaptées à chaque type de page. Le balisage doit décrire ce que la page montre visiblement — un schéma qui contredit la page expose à une action manuelle qui retire l’admissibilité aux résultats enrichis ; ce n’est pas un raccourci. Choisissez le type selon le contenu au lieu de tous les ajouter.

    Comment vérifier : Testez une URL par gabarit dans le test des résultats enrichis et le Schema Markup Validator.

    Réussi quand : Aucune erreur, et chaque propriété balisée est visible sur la page.

Pages de services et de localisation

  • Créer des pages distinctes et substantielles — pas des ébauches quasi identiques. Générer une page par ville à partir d’un gabarit en changeant le nom est le schéma classique de la page satellite, explicitement contraire aux consignes de Google. Si une page de localisation n’a rien de spécifique à dire, elle ne devrait pas exister.

    Comment vérifier : Lisez deux pages de localisation ou de service côte à côte en masquant le nom du lieu ou du service.

    Réussi quand : On reconnaît encore chaque page à son contenu.

  • Inclure des signaux locaux pertinents et exacts. Nom, adresse et téléphone doivent correspondre exactement à la fiche d’établissement et à toutes les autres inscriptions. Des coordonnées incohérentes entre sources sont une cause fréquente et parfaitement évitable de faible visibilité locale.

    Comment vérifier : Comparez le nom, l’adresse et le téléphone du site à la fiche d’établissement et aux principaux annuaires.

    Réussi quand : Ils concordent au caractère près.

Fondations techniques

  • Confirmer la gestion des balises canoniques, du hreflang et de la pagination. Les échecs courants sont silencieux : une canonique pointant vers une URL désormais redirigée envoie au moteur une contradiction qu’il résout en ignorant la balise, et des paires hreflang sans balises de retour sont écartées d’office. Côté pagination, Google a confirmé en 2019 ne plus utiliser rel=next/prev — faites de chaque page d’une série sa propre canonique, reliée par de simples liens explorables, sans canoniser la page deux vers la page un.

    Comment vérifier : Examinez les balises canoniques et hreflang dans une exploration, et passez quelques pages à l’outil d’inspection d’URL de la Search Console.

    Réussi quand : Les canoniques pointent vers des pages en 200, les paires hreflang sont réciproques, et la canonique choisie par Google correspond à la vôtre.

  • Décider quelles URL à facettes et à paramètres méritent d’exister. Filtres, tris et paramètres de suivi peuvent multiplier une page en milliers de variantes explorables — l’échec d’architecture le plus fréquent passé une certaine taille de site. Donnez aux rares combinaisons de facettes à réelle demande de recherche des URL propres et indexables, puis canonisez ou passez en noindex le reste, en gardant en tête que robots.txt bloque l’exploration, pas l’indexation — il gère le budget d’exploration, il ne déduplique pas.

    Comment vérifier : Explorez en suivant les paramètres et comparez le nombre d’URL explorées au nombre de pages voulues.

    Réussi quand : Seules les URL de facettes retenues sont indexables ; les autres sont canonisées ou en noindex.

  • Garder le sitemap exact et explorable. Un sitemap listant des URL redirigées, en noindex ou mortes apprend au moteur à s’en méfier, et un lastmod estampillé à chaque build plutôt qu’à chaque vrai changement finit ignoré pour la même raison. Ne listez que des URL canoniques et indexables, et ne changez lastmod que lorsque le contenu change.

    Comment vérifier : Explorez les URL du sitemap et comparez les valeurs lastmod aux vraies modifications de contenu.

    Réussi quand : Chaque URL renvoie 200, est indexable et sa propre canonique, et lastmod ne change que si le contenu change.

  • Surveiller la couverture d’indexation et corriger les pages orphelines. Une pile croissante d’URL « Explorée, actuellement non indexée » est un jugement du moteur sur la qualité, pas un bogue à signaler. Les orphelines méritent ici une attention particulière : une page que seul le sitemap fait découvrir ne porte aucun signal interne d’importance — elle est explorée, puis discrètement abandonnée.

    Comment vérifier : Chaque mois, examinez le rapport Indexation des pages avec la liste des orphelines de l’exploration.

    Réussi quand : « Explorée, actuellement non indexée » est stable ou en baisse, et il ne reste aucune URL orpheline dans le sitemap.

  • Conserver les journaux du serveur au moins quatre-vingt-dix jours et classer les requêtes selon les agents utilisateurs documentés des robots d’exploration IA. Les assistants IA récupèrent les pages sans exécuter les balises d’analytique : les journaux du serveur sont donc la seule trace qu’un moteur de réponses a lu le site — et quatre-vingt-dix jours d’historique suffisent pour distinguer une tendance du bruit.

    Comment vérifier : Vérifiez la durée de conservation des journaux, et lancez une requête groupée par agent utilisateur de robot IA.

    Réussi quand : Au moins quatre-vingt-dix jours de journaux sont conservés, et la requête renvoie le nombre de requêtes par robot.

Recherche IA et agents

Google le dit clairement : apparaître dans les AI Overviews ou le mode IA ne demande aucune optimisation particulière, aucun schéma supplémentaire et aucun fichier texte pour l’IA. Rien ci-dessous n’est donc une astuce de classement. Ce sont les habitudes de structure qui rendent une page facile à citer correctement pour tout système qui extrait des passages — et pour les agents qui récupèrent de plus en plus des pages pour le compte de quelqu’un.

  • Écrire des sections qui répondent seules à leur titre. Les moteurs de réponse citent des passages, pas des pages. Une section dont les deux premières phrases répondent à son titre peut être reprise telle quelle ; une section qui s’appuie sur « comme mentionné plus haut » ne le peut pas. Formuler les titres comme la question que poserait un lecteur rend la correspondance explicite.

    Comment vérifier : Lisez isolément trois sections d’une page clé, en partant de chaque titre.

    Réussi quand : Chacune répond à son titre dans ses deux premières phrases, sans avoir besoin du reste de la page.

  • Nommer l’organisation et les personnes derrière elle de la même façon partout. Les moteurs assemblent une entité à partir de nombreuses mentions. Employez un seul nom et une seule description, ajoutez un balisage Organization ou Person avec des liens sameAs vers les profils que vous contrôlez, et gardez les mêmes faits dans le pied de page, la page À propos et ces profils.

    Comment vérifier : Comparez le nom et la description sur le site, dans son JSON-LD et sur chaque profil vers lequel pointent les liens sameAs.

    Réussi quand : Ils concordent, et chaque URL sameAs mène à un profil que vous contrôlez.

  • Si vous offrez une version Markdown pour les agents, gardez-la hors de l’index. Certains agents récupèrent une page pour la lire, et une version Markdown propre — à une URL .md ou sur Accept: text/markdown — leur épargne la navigation et les scripts. Rien ne l’exige : traitez-la comme une commodité, marquez-la noindex, annoncez-la comme alternative, laissez-la hors du sitemap et générez-la à partir de la page pour qu’elle ne dérive jamais.

    Comment vérifier : Demandez l’URL .md d’une page, puis la page elle-même avec Accept: text/markdown, et lisez les en-têtes de réponse.

    Réussi quand : Les deux renvoient le Markdown avec X-Robots-Tag: noindex, la version négociée envoie aussi Vary: Accept, et aucune des deux URL n’est dans le sitemap.

  • Vérifier l’accès des robots IA à chaque couche, pas seulement dans le robots.txt. Un robots.txt qui autorise un robot ne dit rien du CDN ou du pare-feu placé devant le site, qui peut refuser la même requête. Les trois couches de l’accès des robots IA expliquent comment vérifier chacune.

    Comment vérifier : Comparez le robots.txt aux réglages de robots du CDN ou du pare-feu, puis consultez les événements de sécurité pour les requêtes de robots vérifiés.

    Réussi quand : Aucune couche ne refuse un robot qu’une autre autorise, sauf si la politique écrite le prévoit.

Pour savoir où l’automatisation peut accélérer les briefs, les métadonnées et le maillage interne, consultez l’article connexe ci-dessous.

Sources

Les affirmations factuelles de cette page ont été vérifiées auprès de ces sources primaires le 10 octobre 2026 :

À lire aussi