TS03Accès et indexation
Accès et indexationLes pages absentes répondent-elles comme prévu ?
Mettre côte à côte les réponses d’une page existante, d’une page supprimée et d’une adresse inexistante. Cela aide à documenter un code HTTP inattendu avant une correction.
Relever les réponses
- Dans l’app
- Relevé HTTP · sans verdict
- À fournir
- 2 ou 3 URL du même site
- À prévoir
- Lecture et confirmation
À fournir
À prévoirComprendre
La page manque. La réponse compte.
Mettre côte à côte les réponses d’une page existante, d’une page supprimée et d’une adresse inexistante. Cela aide à documenter un code HTTP inattendu avant une correction.
Selon Google
Une page introuvable doit signaler sa situation. Un contenu d’erreur renvoyé avec un statut de succès peut être classé comme soft 404 par Google.
Vérifier
Présente, absente. Quelle réponse ?
Dans TSEP Control
Après votre confirmation : la première réponse HTTP, sa date, les octets reçus et un extrait du contenu lorsqu’il est lisible. Le résumé se copie, les preuves se téléchargent et une nouvelle lecture conserve l’historique.
Votre contribution
Deux ou trois adresses du même site, avec leur situation réelle. La page supprimée est facultative si vous n’avez pas d’exemple. Une suppression avec remplacement relève du parcours TS02.
Avec vos outils
Avec vos outilsOuvrez vos adresses témoins et relevez le code HTTP ainsi que le message affiché. Pour une page sans remplacement, vérifiez qu’une erreur réelle ne se cache pas derrière un code 200.
Ce que ce résultat couvre
Le relevé d’URL réelles est disponible. Le verdict TSEP réel ne l’est pas encore : la règle TS03-A01 actuelle ne qualifie que des matrices fictives .invalid. Le parcours ne classe pas les soft 404 de Google et ne vérifie pas tout le site.
Agir
Une page absente. Un code explicite.
Faites correspondre la réponse serveur à la situation réelle : page existante, supprimée ou inexistante.
Recontrôler
Mêmes URL. Réponses corrigées ?
Reprenez le parcours avec le même périmètre après correction. Datez la nouvelle observation et conservez les preuves précédentes.
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
- Faites correspondre la réponse serveur à la situation réelle : page existante, supprimée ou inexistante.
- NT · Non établi
- Les preuves ou les confirmations ne suffisent pas pour conclure. Complétez ce qui manque ; ce statut ne démontre pas une erreur SEO.
- NA · Non applicable
- Le contrôle ne s’applique pas au périmètre, selon ses règles et une justification conservée. Une absence de preuve ne suffit pas à le déclarer non applicable.
Sources et références2 références
Méthode et règles détaillées1 règle
Méthode et critères du contrôle
Méthode
Avant les captures, lier à configuration le plan d’intention des trois états de route et leurs critères de contenu. Comparer une matrice HTTP GET fournie, sans résolution DNS ni collecte réseau.
Critères attendus
Pass qualifie seulement la matrice complète fournie : 200 et marqueurs attendus pour une route existante ; 404/410 et critères de corps déclarés pour les routes supprimées/inexistantes. Un 2xx pour ces dernières, un autre statut complet, ou une contradiction de marqueur est fail. La classification soft 404 reste hors mesure.
Non-applicabilité
Périmètre ne contenant aucun routage HTTP, justification fournie.
Règles détaillées
TS03-A01 · Réponses HTTP synthétiques comparées à un plan préalable
Mode prévu par le protocole : assisté, avec preuves et déclarations fournies. La disponibilité dans l’app est indiquée sur la fiche du contrôle.
Périmètre
Un plan de route contient au moins un état existant, supprimé et inexistant dans le périmètre synthétique.
Preuves
Le plan et son empreinte, les attentes content, puis pour chaque route la requête GET, la réponse HTTP brute, le statut, la date et le corps complet. Conserver les observations contradictoires et les lacunes séparément.
Méthode
Vérifier le plan antérieur et son empreinte ; comparer chaque GET/response attribuable, complète et liée à une route .invalid aux statuts permis et marqueurs littéraux UTF-8 fixés dans les attentes content.
Critères attendus
Pass exige exactement une réponse complète par route et tous les états requis : 200 pour existante, 404/410 pour supprimée ou inexistante, marqueurs requis présents et interdits absents. Une contradiction complète reste fail malgré doublon, autre capture incomplète ou lacune. Les 206/304, données absentes, ambiguës ou mal attribuées restent inconclusives.
Quand le résultat reste indéterminé
Plan absent/futur/mal lié, état de route manquant, doublon, HTTP incomplet, URL/client non attribuable, statut 206/304, contenu non UTF-8, marqueurs contradictoires dans le plan ou matrice incomplète ; une contradiction attribuable reste fail.
Non-applicabilité
Aucune exemption atomique. NA du contrôle entier exige un inventaire positif, complet, motivé et daté prouvant qu’aucun routage HTTP n’entre dans le périmètre.
Hypothèses
Le plan, les classifications et critères sont fournis et non authentifiés. La revue attachée est un exercice synthétique, pas une approbation indépendante.
Limites
Une capture .invalid ne teste aucun serveur. Les marqueurs sont recherchés littéralement dans le corps décodé, sans DOM, rendu, jugement sémantique ou classification de moteur. C ne porte que sur la matrice déclarée, pas sur un site entier, une disponibilité dans le temps, une indexation ou un ranking.
Version des règles 0.2.0-rc.1 · Fiche du protocole public · Source versionnée
Passer à la pratique
Deux ou trois URL du même site.