TSEPCONTROL BÊTA GRATUITE
Menu

Où voulez-vous aller ?

TS01Accès et indexation

Cette URL renvoie-t-elle la page attendue ?

Repérez une réponse incorrecte ou un contenu inattendu. Sachez quoi corriger, puis vérifiez le résultat avec les mêmes critères.

Vérifier une URL
Dans l’app
Lecture HTTP + confirmation
À fournir
URL publique et page attendue
À prévoir
Deux lectures et votre confirmation
Vérifier une URL

Comprendre

Un code 200. Mais quelle page ?

Un « 200 OK » peut cacher la mauvaise page. TS01 vérifie séparément la réponse HTTP et le contenu attendu pour une URL publique de référence.

Exemple fictifLa bonne adresse. Le mauvais contenu.
Réponse HTTP200 OK
Contenu reçu
« Connectez-vous pour continuer »

La page d’un atelier photo répond. Mais l’atelier attendu n’apparaît pas.

Selon Google

Un code 2xx permet à Google de traiter le contenu reçu ; il ne garantit pas son indexation. Une page d’erreur servie en 200 peut être considérée comme une soft 404.

Vérifier

La réponse reçue. La page attendue.

Dans TSEP Control

L’app récupère la réponse, suit les redirections autorisées et présente la destination, le code HTTP et le texte lisible. Après votre confirmation, elle relit la page pour la comparer à l’attente enregistrée.

Votre contribution

Confirmez l’usage public de référence, la destination voulue et un texte distinctif de la bonne page. Une mauvaise réponse ne devient jamais automatiquement votre référence.

Avec vos outils

Dans les outils réseau du navigateur ou avec une requête GET, relevez la destination finale, le code HTTP et le contenu reçu. Comparez-les à la page attendue, sans vous fier au code 200 seul.

Les preuves à conserver

Intention, trace GET complète et corps conservé ; justifications par règle A01–A02.

Ce que ce résultat couvre

Une URL, la réponse reçue au moment du test et l’attente déclarée. Ce résultat ne couvre ni tout le site, ni le rendu JavaScript, ni l’indexation effective.

Agir

Le bon contenu. À la bonne adresse.

Rétablissez la réponse HTTP ou le contenu attendu, selon l’écart indiqué.

Recontrôler

Même adresse. Nouvelle lecture.

Après correction, relancez le contrôle depuis son résultat. Les critères restent identiques ; les résultats précédents, leurs dates et leurs preuves sont conservés. Si votre attente change, préparez un nouveau contrôle.

Les repères du contrôle

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
Rétablissez la réponse HTTP ou le contenu attendu, selon l’écart indiqué.
NT · Non établi
La réponse est incomplète, l’attente manque ou le format reçu n’est pas pris en charge. Ce n’est pas une erreur SEO démontrée : complétez l’attente ou relancez la lecture.
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ées2 règles

Méthode et critères du contrôle

Méthode
Envoyer une requête GET, suivre les redirections et relever le code final.

Critères attendus
Chaque GET atteint une réponse finale 200 pour la ressource attendue ; horodatage et chaîne conservés.

Non-applicabilité
Aucune page publique canonique dans le périmètre déclaré.

Règles détaillées

TS01-A01 · GET final en 200

Mode prévu par le protocole : automatique. La disponibilité dans l’app est indiquée sur la fiche du contrôle.

Périmètre
Chaque page publique désignée canonique, dans le contexte de requête déclaré.

Preuves
Intention par URL ; commande et version de l’outil ; trace GET datée, URL et codes de tous les sauts, en-têtes finaux et indicateurs de troncature.

Méthode
Exécuter un GET sans cache conditionnel ; enregistrer chaque saut et la réponse finale. Déclarer agent, en-têtes, cookies/authentification, réseau, heure et bornes de temps, taille et redirections.

Critères attendus
Une réponse finale complète est observée en 200. Un 204, 206, 4xx ou 5xx final observé contredit cet attendu ; HEAD seul ou 304 sans représentation ne suffit pas.

Quand le résultat reste indéterminé
Délai, DNS/TLS, chaîne interrompue, borne atteinte, capture incomplète, requête HEAD seule ou 304 sans corps conservé : inconclusive, sans défaut SEO déduit.

Non-applicabilité
Aucune exemption atomique quand le contrôle s’applique.

Hypothèses
La requête et ses bornes sont déclarées avant l’essai ; le 200 est une exigence TSEP pour cette population.

Limites
Ni disponibilité permanente ni réponse réelle de Googlebot. Une chaîne observée ne valide pas TS02.

TS01-A02 · Ressource finale attendue

Mode prévu par le protocole : automatique. La disponibilité dans l’app est indiquée sur la fiche du contrôle.

Périmètre
Chaque réponse finale dont le contenu peut être comparé à l’intention.

Preuves
Trace HTTP, corps complet et intention préalable datée avec URL, empreinte de référence et éventuels marqueurs/politique de stabilité ; extraction, valeurs calculées et outil/version. Empreinte après décodage de transfert et de contenu, avant toute transformation. Marqueurs littéraux sensibles à la casse dans chaque segment de texte source HTML décodé : entités résolues, commentaires, script/style, balises et attributs exclus, segments jamais concaténés à travers le balisage. Pour text/plain, corps décodé intégral. Ni normalisation des espaces ni expression régulière. Le profil parsé distinct normalise CRLF/CR source en LF avant expansion des références, sans modifier les critères ; conserve les deux projections, contextes, positions, erreurs rapportées, résultats et outils. Les contextes identiques sont référencés sans suppression de segments ; arbres reconstructibles à partir du corps et des outils exacts.

Méthode
Comparer d’abord l’URL finale à expected_final_url, puis le SHA-256 du corps complet à expected_body_sha256. Fixer références, éventuelle stabilité et marqueurs avant la mesure. La branche de variation sans stabilité utilise le lecteur historique, sauf identity_reader: html-tree-markers-v1 déclaré au préalable : deux hypothèses statiques globales, segments parsés attribués aux octets et critères littéraux. L’empreinte porte toujours sur le corps complet inchangé. Édition draft.6 : les espaces ASCII structurels sous html ou traversant uniquement les fermetures body/html sont exclus avec leurs positions et octets conservés ; voir migration-0.3.0-draft.6. Le profil distinct html-tree-markers-v2 exclut les segments sous noscript de toute comparaison de marqueurs, y compris aux recontrôles. Le profil v1 garde sa sémantique historique. Une intention doit nommer explicitement le profil retenu avant la nouvelle capture. Le profil distinct html-tree-markers-v3 porte sur le texte HTML principal : exclusions attribuées noscript/iframe/sous-arbres étrangers ; un interdit dans ces exclusions empêche pass ; seuls les doublons d’attributs sont admis parmi les erreurs parse5, sans interprétation de directives. Espaces ASCII traversant des fermetures ignorées admis seulement avec reconstruction exacte. Voir migration-0.3.0-draft.7 pour les limites et la migration explicite.

Critères attendus
URL finale différente : fail. À URL identique, empreinte identique : pass. Sinon, representation: stable impose fail. Sinon, sous le lecteur historique, des marqueurs valides donnent fail si un requis manque ou si un interdit apparaît. Pass exige au moins un marqueur requis, tous les requis présents et tous les interdits absents. Interdits seuls absents : inconclusive. Sans marqueurs ni stabilité déclarée : inconclusive. Le statut HTTP ne remplace pas cette comparaison. Sous html-tree-markers-v1, chaque lecture complète compare tous les marqueurs ; deux pass donnent pass, deux fail donnent fail, tout autre couple donne inconclusive. Les priorités URL, empreinte et stabilité restent inchangées.

Quand le résultat reste indéterminé
Capture absente/tronquée, décodage inconnu, référence URL absente/invalide, intention postérieure : inconclusive. À URL identique, empreinte de référence absente/invalide : inconclusive. Si les empreintes diffèrent sans stabilité, marqueurs absents, vides, malformés ou contradictoires, extraction indéterminée, ou interdits seuls tous absents : inconclusive. Une URL différente reste fail même sans empreinte de référence. Pour le profil parsé : divergence des hypothèses, erreur rapportée par parse5, texte étranger non blanc hors exclusions, frames/contextes non qualifiés, intervalles non attribuables, runtime indisponible ou borne dépassée restent inconclusive, sans repli.

Non-applicabilité
Aucune exemption atomique quand le contrôle s’applique.

Hypothèses
Le responsable fixe une représentation de référence avant la collecte ; sa pertinence métier reste sa responsabilité. La comparaison est automatique, la définition de l’intention ne l’est pas. Le profil éventuel et ses critères sont déclarés dans une nouvelle intention avant capture ; aucune sélection ou conversion silencieuse des anciennes intentions.

Limites
Une variation d’empreinte seule ne prouve pas un contenu erroné. L’extraction du texte source ne mesure ni visibilité CSS/DOM, ni similarité sémantique ; titre et texte masqué par CSS peuvent compter. Des marqueurs pertinents et une référence correcte restent la responsabilité du propriétaire. Une mauvaise intention peut valider un mauvais contenu. Ni classification soft 404 du moteur, ni indexation, ni routes non déclarées. Le nouveau profil conserve title/textarea/options/textes masqués, exclut scripts/styles HTML/SVG et templates inactifs ; le contrat précise les refus. Aucun comportement navigateur, validité HTML complète ou nouvelle évaluation Edikka déduit.

Version des règles 0.3.0-draft.7 · Fiche du protocole public · Source versionnée

Passer à la pratique

← Retour aux contrôles

30 lectures disponibles aujourd’hui

Renouvellement :

Votre limite quotidienne : 30 lectures

Comment ça fonctionne

Une lecture consulte votre page et quelques sources publiques. La limite s’applique à votre espace de visiteur ; des protections supplémentaires s’appliquent au réseau partagé et à l’ensemble du service.

Répondre aux questions, consulter vos dossiers et exporter vos résultats ne consomme aucune lecture. Ces étapes restent disponibles lorsque la limite est atteinte.