Définir la question et le périmètre
Un rapport technique utile sert à décider : observation, contradiction avec l’objectif, responsable et preuve de correction. Précisez hôte, environnement, date de collecte, source des URL, méthode d’exploration et de rendu, limites d’accès. Six URL ne couvrent pas un site entier ; indiquez modèles, appareils et espaces authentifiés non examinés.
Ces exemples originaux fonctionnent sur votre ordinateur. Les chemins avant et après coexistent pour répéter le test sans modifier un site en production. Ils illustrent HTTP, directives HTML et transmission des tâches ; ils ne simulent ni Googlebot, ni rendu JavaScript, ni mesures terrain, ni indexation. Les canonical relatifs rendent le laboratoire portable ; suivez la documentation pour la production.
Conserver des preuves reproductibles
Conservez URL exacte, méthode, chaîne de réponses, en-têtes pertinents et extrait source. Ajoutez heure UTC et référence de trace ou capture pour les observations réelles. Si le rendu diffère de la réponse initiale, gardez les deux avec les réglages de l’outil. Séparez constat, explication et recommandation ; non testé ne signifie pas réussi.
La commande de vérification fournit les six paires de réponses en JSON. Comparez avec evidence.json du ZIP. Dates serveur et ports temporaires sont omis pour stabiliser la trace : il s’agit d’un cas reproductible, pas d’une mesure client datée. Les commandes fixes n’explorent pas de domaines arbitraires.
Séparer objectif, portée et confiance
Trois priorités élevées contredisent un objectif explicite de livraison ou d’indexation. Deux moyennes demandent une correction ciblée de modèle ou de contenu. Le témoin ne change pas. Pour un vrai site, examinez population touchée, parcours critiques, confiance, risque et effort avant de séquencer les tâches. Six lignes ne mesurent pas la prévalence globale.
Attribuez un responsable et une date de revue à chaque constat. Un grand nombre d’avertissements ne prime pas automatiquement sur une panne prouvée d’un parcours critique. Clarifiez l’objectif avant de modifier noindex, redirections ou canonical. Ne retirez pas une exclusion voulue pour améliorer un score.
| ID | Observation | Priorité | Responsable |
|---|---|---|---|
| A01 | La page publique contient noindex | Élevée | Développeur web |
| A02 | Robots empêche la lecture de l’exclusion | Élevée | Responsable de plateforme |
| A03 | La redirection permanente aboutit à une erreur | Élevée | Développeur du routage |
| A04 | Canonical désigne un contenu sans rapport | Moyenne | Responsable SEO et développeur |
| A05 | La page absente renvoie un succès | Moyenne | Développeur web |
| A06 | Le témoin fonctionnel ne nécessite pas de correction spéculative | Aucun changement | Relecteur de l’audit |
Six constats à transmettre au développeur
A01 · La page publique contient noindex
Observation: GET /launch renvoie 200 et une balise meta robots noindex. L’objectif est une page publique éligible à la recherche.
Enjeu: La directive contredit cet objectif. Sa présence est confirmée, pas sa lecture par Google.
Action proposée: Retirer la directive involontaire du modèle public. Vérifier également les en-têtes et le HTML rendu.
Responsable: Développeur web
Critère de validation: /fixed/launch renvoie 200 sans noindex. Retester le déploiement réel et utiliser séparément une inspection d’URL autorisée.
A02 · Robots empêche la lecture de l’exclusion
Observation: robots.txt bloque /blocked/ tandis que /blocked/page contient noindex. L’objectif est l’exclusion de la recherche, pas la restriction d’accès.
Enjeu: Un robot respectueux des règles ne peut lire la directive. Robots ne remplace pas l’authentification.
Action proposée: Autoriser l’exploration de la page en conservant noindex. Protéger les contenus privés par authentification.
Responsable: Responsable de plateforme
Critère de validation: /fixed/blocked/page est hors du préfixe bloqué et conserve noindex. Vérifier les règles réelles et l’indexation ultérieure séparément.
A03 · La redirection permanente aboutit à une erreur
Observation: /old-guide renvoie 301 vers /missing-guide, qui renvoie 404. /guide est supposé être un remplacement pertinent.
Enjeu: Le chemin ne livre pas le contenu voulu. Une redirection ne prouve pas le bon fonctionnement de sa destination.
Action proposée: Rediriger directement vers le remplacement pertinent et actualiser les liens internes. Ne pas envoyer toutes les pages supprimées à l’accueil.
Responsable: Développeur du routage
Critère de validation: /fixed/old-guide produit une seule 301 puis /guide en 200 avec le contenu attendu. Vérifier toute la chaîne après déploiement.
A04 · Canonical désigne un contenu sans rapport
Observation: /variant déclare /other-topic comme canonical alors que son contenu duplique /guide.
Enjeu: La préférence contredit la relation entre contenus. Elle ne révèle pas le canonical choisi par Google.
Action proposée: Confirmer l’équivalence puis aligner canonical, liens internes et sitemap sur /guide. Garder distincts les contenus aux fonctions différentes.
Responsable: Responsable SEO et développeur
Critère de validation: /fixed/variant déclare /guide et la destination répond correctement. Contrôler séparément le choix de Google dès que possible.
A05 · La page absente renvoie un succès
Observation: /gone répond 200 avec un titre Not found. Aucun remplacement adapté n’est prévu.
Enjeu: Contenu d’erreur et statut de succès sont incohérents : candidat soft 404, pas classification Google observée.
Action proposée: Renvoyer le statut approprié de ressource absente et retirer les liens internes obsolètes. Conserver une page d’erreur utile.
Responsable: Développeur web
Critère de validation: /fixed/gone renvoie 404 avec le contenu d’erreur. Une observation Search Console ultérieure constitue une preuve distincte.
A06 · Le témoin fonctionnel ne nécessite pas de correction spéculative
Observation: /guide renvoie 200, se déclare canonical et n’est pas bloqué par ces règles robots. Cette réponse ne contient pas noindex.
Enjeu: Ces tests locaux réussissent. Ils ne prouvent ni qualité, rendu, découverte, indexation, ni classement.
Action proposée: Documenter le témoin valide. Explorer d’autres signaux seulement si une question précise le justifie.
Responsable: Relecteur de l’audit
Critère de validation: Les réponses avant et après restent identiques. Conserver cette preuve sans inventer un défaut pour augmenter le compteur.
Clore un constat par un nouveau contrôle
Un ticket réalisé ne constitue pas une preuve de clôture. Répétez la requête en production, contrôlez des URL comparables et consignez nouvelle date et réponse. Préservez l’ancien état. Distinguez validation technique et observation ultérieure du moteur ; une directive corrigée ne garantit ni indexation ni trafic.
Utiliser le rapport et le registre
Le CSV rempli présente les six décisions ; le fichier vierge ne contient que les en-têtes. Ajoutez URL réelles, environnement, heure UTC, références, portée, confiance, responsable, échéance, statut et nouveau test. Le HTML est autonome et imprimable. Cette page ne sauvegarde aucun audit de compte et n’analyse pas un domaine saisi.
Commencez la synthèse par le périmètre et les décisions attendues, puis présentez priorités, preuves, dépendances et plan de clôture. Signalez les contrôles reportés. Ne présentez pas cet exercice comme un audit client et n’inventez pas les mesures manquantes. Rendu, internationalisation, données structurées, accessibilité et performance peuvent demander des analyses supplémentaires.
Distinguer technique et performance
Éligibilité technique et performance observée répondent à des questions distinctes. Utilisez le rapport de positions pour les exports datés de requêtes/pages et l’audit de backlinks pour les liens sources. Une page fonctionnelle peut rester non indexée. Une variation de clics ne prouve ni défaut canonical ni effet d’un achat de liens.
Rapport de positionnement SEO : comparer la visibilité et comprendre les moyennes
Réaliser un audit de backlinks : preuves, priorités et modèle de suivi