Audit technique de référence

Phase P2 · Étape A — Comprendre
Durée indicative : 2–4 heures pour un passage léger, 1–2 jours ouvrés pour un passage standard, ou 3–8 jours ouvrés pour un passage approfondi.
Responsable : le responsable SEO technique. Les responsables ingénierie, analytique, contenu et localisation apportent des preuves et acceptent les correctifs dans leurs domaines respectifs.

Un audit technique de référence établit si les moteurs de recherche peuvent atteindre, interpréter et sélectionner les URL que l’entreprise attend d’eux. Son périmètre couvre les contrôles d’exploration, les réponses HTTP, l’indexation, les canoniques, les liens, le rendu, le ciblage international et la livraison sécurisée. Le résultat est un registre priorisé des constats avec des responsables nommés et des tests d’acceptation, et non un score.

Pourquoi cette phase se situe ici

Publier sur un site présentant des problèmes d’exploration ou d’indexation aggrave les dégâts. Les moteurs de recherche découvrent souvent un défaut répété sur de nouvelles URL plus rapidement qu’ils n’évaluent et ne récompensent le contenu. Un modèle canonique défectueux peut rediriger chaque article ailleurs ; une règle robots peut masquer un répertoire ; une navigation rendue côté client peut créer des orphelines pour un client sans JavaScript. Chaque nouvelle page agrandit l’ensemble affecté et rend la réparation plus risquée.

Corrigez d’abord les fondations. L’ordre est explorabilité → indexabilité → qualité du contenu → performance car chaque couche est une porte. L’explorabilité signifie qu’un robot peut découvrir et demander une URL ; l’indexabilité signifie que l’URL accessible est éligible à l’inclusion. Ce n’est qu’ensuite que la qualité du contenu et la performance doivent être évaluées. Une page rapide bloquée par robots.txt ne peut pas rivaliser, et les balises titre n’ont pas d’importance sur des pages inaccessibles.

Cette phase consomme le périmètre, les parcours prioritaires, les marchés et les risques issus de la Découverte et objectifs . La réaliser trop tôt produit une exploration sans contexte commercial. La sauter laisse la recherche et la production cibler des modèles qui ne peuvent pas entrer de manière fiable dans l’index.

Entrées et sorties

Les entrées définissent le site visé, pas seulement ce qu’un robot trouve. Les sorties indiquent au prochain responsable quelles URL sont sûres à tester et lesquelles restent bloquées.

Choisir la profondeur de l’audit

Sélectionnez la profondeur avant l’exploration. Les estimations supposent que l’accès est prêt et excluent la mise en œuvre.

La liste de vérification

Travaillez dans l’ordre. Un échec de porte peut invalider les échantillons ultérieurs, donc enregistrez l’échec et son périmètre avant de continuer.

1. Confirmer que la cible est la production

Quoi faire : vérifier le schéma, l’hôte, le fichier robots, la propriété analytics, la propriété Search Console et l’hôte du sitemap. Pourquoi c’est important : le staging peut sembler propre alors que la production reste défaillante. Comment faire : résoudre l’hôte canonique convenu, comparer les pages prioritaires et les en-têtes de réponse, et enregistrer l’origine de l’exploration. Outil : navigateur, configuration du robot d’exploration, sélecteur Search Console. Fait quand : le registre nomme l’origine de production et la propriété confirmées, sans nom d’hôte de staging dans les seeds ou les exports.

2. Tester robots.txt avant l’exploration

Quoi faire : inspecter le /robots.txt de chaque hôte de production et les sitemaps référencés. Pourquoi c’est important : une règle d’interdiction empêche l’exploration avant que le contenu puisse être évalué. Comment faire : comparer les motifs Disallow avec l’inventaire visé, tester les URL correspondantes et non correspondantes, et distinguer un bloc d’exploration de noindex. Outil : réponse brute et testeur robots. Fait quand : robots retourne 200, les blocages visés ont des raisons, les échantillons indexables sont autorisés, et un blocage non intentionnel déclenche un constat critique.

3. Réconcilier les sitemaps avec les URL réelles

Quoi faire : comparer les sitemaps soumis avec l’inventaire canonique et indexable. Pourquoi c’est important : un sitemap doit nommer les URL que le site souhaite voir sélectionnées, pas les redirections, erreurs ou doublons. Comment faire : normaliser les entrées, comparer les comptes par modèle, puis échantillonner les ajouts et omissions dans Sitemaps et indexation . Outil : https://app.amicited.com/reports/google-search/sitemaps-indexing et exports d’exploration. Fait quand : la couverture est d’au moins 95 %, 0 entrée redirige ou génère une erreur, et chaque écart a une raison ou un responsable.

4. Mesurer la distribution des codes de statut

Quoi faire : classer les réponses en 2xx, 3xx, 4xx ou 5xx. Pourquoi c’est important : les erreurs empêchent la récupération et les redirections ajoutent des sauts. Comment faire : suivre et rapporter les redirections, segmenter par modèle, et comparer avec Exploration Bing . Outil : https://app.amicited.com/reports/bing-webmasters/crawl, robot d’exploration et surveillance. Fait quand : les URL indexables retournent 200 ; les erreurs internes, boucles et chaînes sont à zéro ; et les redirections intentionnelles sont documentées.

5. Supprimer les chaînes et boucles de redirection

Quoi faire : tracer les redirections jusqu’à leur réponse finale. Pourquoi c’est important : les sauts ralentissent la découverte ; une boucle n’atteint jamais le contenu. Comment faire : exporter les chemins, mettre à jour les liens internes vers les canoniques finals, et consolider les règles. Outil : rapport de redirections et vérifications d’en-têtes. Fait quand : les liens internes vont directement, les redirections legacy font un seul saut, et aucune boucle ou chaîne ne subsiste.

6. Établir le ratio d’indexation éligible

Quoi faire : comparer l’état de l’index Google avec les URL délibérément éligibles. Pourquoi c’est important : inclure les redirections, filtres, doublons ou pages noindex rend le ratio dénué de sens. Comment faire : construire le dénominateur éligible, inspecter les échantillons prioritaires dans Inspection d’URL , et regrouper les exclusions par modèle. Outil : https://app.amicited.com/reports/google-search/url-inspection, Search Console et inventaire. Fait quand : au moins 90 % sont indexés ou chaque écart a un responsable de cause racine ; en dessous de 80 % est un constat majeur.

7. Vérifier la justesse des canoniques

Quoi faire : comparer les canoniques déclarés, finals et sélectionnés par Google. Un canonique est la version préférée parmi des URL similaires. Pourquoi c’est important : un mauvais canonique consolide les signaux ailleurs que sur la page visée. Comment faire : tester les auto-références des pages uniques, les cross-canoniques délibérés et la cohérence entre HTML, sitemaps, redirections et liens. Outil : rapport canonique et https://app.amicited.com/reports/google-search/url-inspection. Fait quand : 100 % des pages indexables uniques nomment un canonique absolu, 200 et indexable, avec chaque divergence sélectionnée expliquée.

8. Trouver les groupes de doublons et quasi-doublons

Quoi faire : regrouper les URL dont le contenu principal est identique ou sensiblement similaire et qui partagent le même objectif de recherche. Pourquoi c’est important : les doublons divisent les signaux internes et forcent les moteurs de recherche à choisir une version que l’entreprise peut ne pas préférer. Comment faire : comparer les hashs exacts, la similitude textuelle normalisée, les titres, les canoniques, les paramètres et l’objectif du modèle ; puis choisir la consolidation, la différenciation, le noindex ou la suppression. Outil : rapports de doublons du robot, inventaire des pages et Pages Google Search . Fait quand : aucun groupe ne contient plus d’une URL canonique indexable non expliquée servant la même intention, et chaque variante acceptée a un objectif distinct enregistré.

9. Trouver les orphelines et mesurer la profondeur des liens

Quoi faire : croiser les URL du robot avec les sitemaps, analytics, Search Console, exports CMS et backlinks pour trouver les pages sans lien interne explorable. Mesurer le chemin de clic le plus court depuis la page d’accueil. Pourquoi c’est important : une orpheline peut apparaître dans un sitemap tout en recevant peu de contexte interne ou d’autorité ; une profondeur excessive rend la découverte fragile. Comment faire : comparer les sources, inspecter les motifs de répertoires dans Vue Répertoire , et tracer la navigation, le fil d’Ariane, les hubs et les liens contextuels. Outil : https://app.amicited.com/reports/directory et une exploration multi-sources. Fait quand : le nombre d’orphelines visées est nul, les pages prioritaires sont à moins de trois clics de la page d’accueil, les autres pages indexables visées sont à moins de cinq clics, et chaque exception a une voie de découverte délibérée.

10. Comparer le HTML rendu et non-JavaScript

Quoi faire : comparer la réponse initiale du serveur avec la page après exécution du JavaScript. Pourquoi c’est important : un navigateur peut afficher du contenu et des liens qu’un client sans JavaScript ne reçoit jamais. Comment faire : récupérer des pages représentatives avec les scripts désactivés, inspecter le HTML brut, puis comparer les titres, le texte principal, les liens, le canonique, les directives robots, les données structurées et le statut après rendu. Outil : robot en mode HTML et rendu, plus les outils de développement du navigateur. Fait quand : la réponse initiale contient le contenu principal, le canonique, les directives d’index et la navigation explorable nécessaire pour découvrir les pages prioritaires ; toute dépendance exclusivement JavaScript est explicitement acceptée et testée sur tous les modèles.

11. Valider hreflang le cas échéant

Quoi faire : vérifier les annotations qui connectent les équivalents linguistiques ou régionaux. Pourquoi c’est important : des groupes incomplets ou conflictuels peuvent amener les moteurs de recherche à ignorer le ciblage et à afficher la mauvaise version du marché. Comment faire : tester les codes langue-région valides, les URL canoniques absolues, les auto-références, les liens de retour réciproques, x-default là où il a un véritable rôle de repli, et l’indexabilité de chaque cible. Outil : rapport hreflang du robot et échantillons d’URL. Fait quand : les codes invalides, les auto-références manquantes, les retours manquants, les cibles non canoniques, les redirections et les erreurs sont tous à zéro. Si le site n’a pas d’équivalents localisés, mentionnez « non applicable » plutôt que d’inventer des annotations.

12. Tester la pagination et les chemins d’exploration

Quoi faire : vérifier que les séquences de catégories ou d’archives multi-pages exposent des liens explorables et des URL uniques utiles. Pourquoi c’est important : le défilement infini ou le chargement par bouton peuvent masquer les éléments plus profonds, tandis que la canonisation de chaque page vers la page un peut retirer des articles distincts de la découverte. Comment faire : désactiver JavaScript, suivre les liens suivants et numérotés, inspecter le statut, les directives canoniques et robots, et tester la dernière page et les paramètres hors limites. Outil : exploration sans rendu et navigateur. Fait quand : chaque élément visé est accessible via des liens ancrés, chaque page utile s’auto-canonise, les numéros de page invalides retournent une erreur appropriée plutôt qu’un 200 mou, et aucune séquence ne crée un espace d’URL illimité.

13. Vérifier la parité mobile

Quoi faire : comparer la livraison mobile et desktop pour le contenu, les liens, les métadonnées, les directives, les données structurées et le statut de réponse. Pourquoi c’est important : Google évalue principalement la représentation mobile ; cacher du contenu ou des liens significatifs uniquement sur mobile modifie ce qu’il peut comprendre. Comment faire : explorer avec des agents utilisateur desktop et smartphone et comparer les modèles représentatifs, pas seulement les captures d’écran visuelles. Outil : explorations jumelées, inspection d’URL mobile et mode responsive du navigateur. Fait quand : tout le contenu indexable et les liens explorables nécessaires à la signification et à la découverte sont équivalents, avec zéro blocage mobile uniquement, différence canonique ou réponse d’erreur.

14. Imposer HTTPS et supprimer le contenu mixte

Quoi faire : vérifier la livraison sécurisée, les redirections d’hôte, les certificats, le schéma canonique, les URL internes et les ressources chargées via HTTP. Le contenu mixte signifie qu’une page HTTPS demande une ressource non sécurisée. Pourquoi c’est important : les requêtes non sécurisées peuvent être bloquées, exposent les utilisateurs et créent des signaux d’URL incohérents. Comment faire : explorer toutes les variantes HTTP, inspecter la couverture des certificats et les erreurs de sécurité du navigateur, et rechercher les demandes de ressources rendues. Outil : robot, panneau de sécurité du navigateur et configuration serveur. Fait quand : chaque page HTTP redirige en une fois vers son URL HTTPS correspondante, tous les canoniques et liens internes utilisent HTTPS, les certificats sont valides pour chaque hôte actif, et les demandes de contenu mixte actif ou passif sont à zéro.

Outils dans AmICited

Utilisez les rapports produit comme preuves dans la liste de vérification, pas comme un remplacement de l’exploration.

• Sitemaps et indexation sur https://app.amicited.com/reports/google-search/sitemaps-indexing montre l’état des sitemaps soumis, les avertissements, les erreurs et les actions d’indexation.
• Inspection d’URL sur https://app.amicited.com/reports/google-search/url-inspection donne le verdict live de Google pour les URL échantillonnées et le canonique sélectionné.
• Exploration Bing sur https://app.amicited.com/reports/bing-webmasters/crawl expose l’activité du robot Bing et les problèmes au niveau des URL.
• Pages Google Search sur https://app.amicited.com/reports/pages aide à sélectionner les pages de destination à forte valeur et sépare les pages avec visibilité des pages absentes des données de recherche.
• Vue Répertoire sur https://app.amicited.com/reports/directory révèle les motifs au niveau des sections et prend en charge les investigations de profondeur et d’orphelines.
• Santé des données sur https://app.amicited.com/features/data-health/ enregistre si les preuves connectées sont suffisamment complètes pour soutenir des décisions confiantes.

Règles de décision

Les seuils créent des constats ; ils ne remplacent pas le jugement. Segmentez par modèle et importance commerciale : dix échecs dans une catégorie de paiement peuvent peser plus qu’un millier de balises d’archive cassées.

Priorisez avec impact × effort × confiance. Notez l’impact de 1 à 5 en fonction des URL éligibles affectées et des parcours commerciaux. Notez l’effort de 1 à 5 comme facteur de facilité, où 5 signifie un petit changement réversible et 1 un grand programme risqué ; enregistrez également l’estimation honnête en heures ou jours. Notez la confiance à 0,5 pour une hypothèse plausible, 0,75 pour des preuves répétées, ou 1,0 pour une cause racine reproduite. Le produit donne une aide au classement, pas une précision fallacieuse.

Appliquez la dérogation de dépendance : un correctif qui débloque d’autres travaux prime sur un score plus élevé qui ne le fait pas. Supprimer un blocage robots avant le lancement passe avant de polir les balises titre indexées. Au même niveau de dépendance, traitez les causes à l’échelle du modèle avant les symptômes.

Livrable : le registre priorisé des constats

Transmettez un registre partagé unique, pas un export de robot. Utilisez une ligne par cause racine et joignez les échantillons d’URL séparément.

Le registre est complet lorsque les constats critiques et majeurs ont des responsables et des estimations, les bloqueurs ont une séquence, les hypothèses sont étiquetées et la décision de publication est explicite.

Ce qui peut mal tourner

Un rapport de 200 éléments sur lequel personne ne peut agir

Les exports de robots confondent observations et décisions. Regroupez les URL répétées sous le modèle ou la règle qui les cause, fournissez un échantillon représentatif et attribuez un seul responsable. Deux cents URL cassées produites par un composant de navigation sont un constat de cause racine unique avec un périmètre mesurable, pas deux cents tâches.

Signaler les symptômes au lieu des causes

« Page non indexée » est un symptôme. La cause peut être un canonique non intentionnel, un modèle orphelin, des variantes de paramètres pauvres, une erreur mobile ou un lien exclusivement JavaScript. Un constat n’est pas prêt pour la priorisation tant qu’il n’identifie pas la cause maîtrisable ou n’étiquette pas clairement le prochain test diagnostique.

Auditer le staging par accident

Le staging peut avoir des règles robots, une authentification, des données, des modèles, des feature flags et un comportement d’hôte différents. Enregistrez l’origine de production et la propriété Search Console en haut de chaque export. Si une exploration doit être exécutée contre le staging pour l’assurance de version, étiquetez-la comme une comparaison séparée et ne fusionnez jamais ses métriques dans la référence de production.

Évitez également de compter les exclusions délibérées comme des pertes, de traiter l’inclusion dans un sitemap comme une preuve d’indexation, de tester uniquement la page d’accueil, ou de prioriser par le seul nombre d’URL. Définissez l’ensemble éligible, segmentez par modèle et conservez les preuves d’acceptation.

Phase suivante

La phase suivante, Accessibilité IA et préparation des agents , a besoin d’un échantillon techniquement stable. Transmettez l’inventaire des URL indexables visées, des URL représentatives propres pour chaque modèle prioritaire, des comparaisons HTML brut et rendu, des preuves robots et de réponse, les décisions canoniques, les exclusions connues et le registre des constats ouverts.

N’affirmez pas que le site est « techniquement sain ». Indiquez quels modèles ont passé les portes d’exploration et d’index, lesquels restent bloqués et si la publication peut procéder. Le prochain responsable accepte lorsqu’il peut tester les agents utilisateur spécifiques à l’IA et l’extraction sans redécouvrir des défauts d’exploration de recherche non résolus.

FAQ

À quelle fréquence devons-nous répéter un audit technique de référence ?

Exécutez-le avant une migration, une refonte, un changement de domaine ou un grand programme de publication, puis répétez les vérifications affectées après le lancement. Surveillez en continu et répétez un passage standard lorsque les modèles, la navigation, le rendu ou les règles canoniques changent.

Quel ratio d’indexation un site sain devrait-il avoir ?

Pour les URL délibérément éligibles, 90 % ou plus est l’attente de départ, 80–90 % nécessite une explication, et en dessous de 80 % est un constat. Excluez les redirections, les doublons, les filtres et les pages noindex intentionnelles du dénominateur.

Pouvons-nous publier du contenu pendant que les correctifs techniques sont en cours ?

Uniquement lorsque les nouvelles URL sont explorables, indexables, canonisées, liées en interne et non affectées par le défaut. Si la découverte ou la sélection est bloquée, suspendez ; les nouvelles URL ne font qu’élargir le nettoyage.

Avons-nous besoin d’un robot d’exploration si Search Console est connectée ?

Oui. Search Console rapporte ce que Google a observé ; un robot d’exploration teste le site actuel et révèle les liens, les réponses, la profondeur, les canoniques et les doublons. Aucun ne remplace l’autre.

Qui est responsable des correctifs découverts lors de l’audit ?

Le responsable SEO est propriétaire du registre et des critères d’acceptation. L’ingénierie est généralement responsable des correctifs serveur, de rendu, de redirection, de canonique et HTTPS ; les équipes contenu peuvent être responsables des doublons et des liens. Chaque élément nécessite une personne nommée.