TS02Accès et indexation
Cette adresse mène-t-elle directement à la bonne page ?
Repérez les chaînes, les boucles et les mauvaises destinations après une migration ou un changement d’adresse.
Vérifier une redirection- Dans l’app
- Trajet HTTP + plan confirmé
- À fournir
- Adresse de départ et destination
- À prévoir
- Selon le trajet et les délais du plan
Comprendre
La bonne page. Sans détour inutile.
Une redirection qui fonctionne peut encore faire un détour. TS02 compare le trajet réel au plan confirmé : destination, nombre de redirections, codes autorisés et absence de boucle.
- Trajet observé
- 3 redirections
- Trajet attendu
- 1 redirection
Selon Google
Google distingue les redirections permanentes et temporaires. Le contrôle TSEP compare en plus le trajet au plan que vous avez confirmé.
Vérifier
Le trajet réel. Le plan prévu.
Dans TSEP Control
L’app suit chaque redirection de l’adresse de départ choisie et relève les codes HTTP, dans les limites du plan. Depuis une analyse, elle propose les variantes http/https, avec ou sans www et slash final : vous choisissez le départ à tester.
Votre contribution
Confirmez la destination attendue et le trajet autorisé avant la lecture. Par défaut : une redirection permanente 301 ou 308, puis 200. Vérifiez aussi les domaines autorisés et les limites de collecte.
Avec vos outils
Relevez chaque réponse et son en-tête Location avec les outils réseau ou curl. Testez séparément les variantes utiles et comparez le trajet au plan approuvé.
Les preuves à conserver
Le plan approuvé, la chaîne HTTP complète et la destination finale. Chaque départ choisi fait l’objet de son propre test.
Ce que ce résultat couvre
L’adresse testée et son trajet, à la date du test, depuis le client TSEP. Cela ne couvre ni toutes les variantes automatiquement, ni tout le site, ni la pertinence du contenu d’arrivée, ni une visite réelle de Googlebot.
Agir
Un lien direct. Vers la destination.
Faites pointer la règle directement vers la destination finale et mettez à jour les liens internes.
Recontrôler
Même départ. Moins de détours ?
Depuis le résultat, « Recontrôler cette redirection » propose le même départ et les mêmes attentes. Confirmez le nouveau test ; les résultats précédents restent conservés. La comparaison permet de voir, par exemple, le passage de trois redirections à une.
Pour aller plus loin.
Les statuts, les sources et la méthode.
Comprendre les statutsC · NC · NT · NA
La même légende dans les fiches, l’analyse et la démo. Chaque statut dépend des preuves et des règles du contrôle.
- C · Vérifié
- Le critère est satisfait dans le périmètre évalué. Conservez la preuve datée pour la prochaine comparaison.
- NC · À corriger
- Au moins un critère du contrôle n’est pas satisfait : le plan peut avoir été refusé ou le trajet observé peut différer de l’attente confirmée. Consultez le motif avant de corriger.
- NT · Non établi
- Les preuves requises ne permettent pas de conclure, par exemple si la revue n’est pas renseignée ou si la collecte ne permet pas d’établir le trajet. Consultez les limites et le motif du rapport ; un arrêt de collecte ne démontre pas à lui seul une erreur du site.
- NA · Non applicable
- À retenir uniquement si la non-applicabilité est justifiée selon les règles. Une adresse sans redirection peut aussi être conforme à un plan qui attend zéro redirection.
Sources et références1 référence
Méthode et règles détaillées2 règles
Méthode et critères du contrôle
Méthode
Tester les variantes HTTP/HTTPS, hôte, slash et anciennes URL avec le nombre de redirections.
Critères attendus
Chaque variante testée suit la destination et le nombre de sauts autorisés, sans boucle ; intention validée par le responsable.
Non-applicabilité
Aucune redirection ni variante attendue, inventaire à l’appui.
Règles détaillées
TS02-A01 · Plan de redirection approuvé au préalable
Mode prévu par le protocole : manuel. La disponibilité dans l’app est indiquée sur la fiche du contrôle.
Périmètre
Variantes et anciennes URL dont le comportement attendu est déclaré.
Preuves
Plan, contexte, identité déclarée et rôle du responsable, date, décision, motif, assistance et provenance de la revue ; empreinte exacte des critères examinés.
Méthode
Déclarer source, destination finale, statuts de redirection et terminaux admis, nombres minimal et maximal de redirections et contexte. Vérifier la revue fournie du responsable, motivée, datée entre déclaration et capture et liée par empreinte au plan/contexte.
Critères attendus
Le plan applicable est explicitement approuvé par le responsable avant la capture. Un rejet explicite lié au même plan est fail ; une revue absente ou non attribuable reste inconclusive.
Quand le résultat reste indéterminé
Plan absent, invalide ou postérieur ; validation manquante, non liée ou hors période ; mécanisme non couvert. L’outil ne fournit aucune approbation humaine.
Non-applicabilité
Aucune exemption atomique. La non-applicabilité du contrôle exige un inventaire positif distinct ; elle ne découle pas d’une capture absente.
Hypothèses
Le responsable fournit ses critères avant la capture ; un auteur de laboratoire peut fournir une revue synthétique explicitement identifiée. Une empreinte lie les pièces, sans authentifier une personne.
Limites
Une redirection valide ne prouve pas la pertinence sémantique de sa destination. La référence exécutable borne les trajectoires serveur HTTP ; les autres mécanismes restent non établis, sans exemption du contrôle.
TS02-A02 · Trajectoire HTTP conforme au plan
Mode prévu par le protocole : automatique. La disponibilité dans l’app est indiquée sur la fiche du contrôle.
Périmètre
Variantes et anciennes URL dont le comportement attendu est déclaré.
Preuves
Requêtes et réponses HTTP originales pour chaque saut, URL, complétude, client et contexte ; plan antérieur. Une contradiction prouvée survit aux lacunes ultérieures et à l’absence d’approbation A01.
Méthode
Lire chaque échange GET attribuable dans l’ordre, résoudre Location, conserver codes et URL, compter les redirections et vérifier destination/statut terminaux. Comparer au plan fixé avant la capture, sans reconstruire les réponses manquantes. Le profil préalable http-trajectory-headers-v1 peut conclure sur les en-têtes complets après un arrêt attribué à la borne d’octets du collecteur 2 ; le corps reste incomplet et non évalué.
Critères attendus
La chaîne complète respecte destination, statuts et bornes déclarés, sans boucle. Un type interdit, une borne maximale dépassée, une redirection sans Location ou un retour vers une URL déjà parcourue sont fail dès le préfixe complet qui les prouve. Une destination/statut terminal ou un nombre minimal contradictoires sont fail après réponse terminale attribuable.
Quand le résultat reste indéterminé
Chaîne inachevée sans contradiction, limite de collecte atteinte, Location ambiguë, fragment ou syntaxe hors portée, requête conditionnelle/authentifiée, capture incomplète ou mal attribuée. Atteindre une borne de collecte ne prouve pas une boucle ; dépasser une borne d’intention est distinct. Exception bornée : préfixe à la limite exactement attestée avec un octet excédentaire, sans ambiguïté d’en-têtes ou contradiction de framing, sous le nouveau profil explicite uniquement.
Non-applicabilité
Aucune exemption atomique. La non-applicabilité du contrôle exige un inventaire positif distinct ; elle ne découle pas d’une capture absente.
Hypothèses
Le responsable fournit ses critères avant la capture ; un auteur de laboratoire peut fournir une revue synthétique explicitement identifiée. Une empreinte lie les pièces, sans authentifier une personne.
Limites
Une redirection valide ne prouve pas la pertinence sémantique de sa destination. La référence exécutable borne les trajectoires serveur HTTP ; les autres mécanismes restent non établis, sans exemption du contrôle.
Version des règles 0.3.0-draft.6 · Fiche du protocole public · Source versionnée
Passer à la pratique
← Retour aux contrôles