Définir la tâche en échec avant les réglages
Notez ce qui échoue : résoudre un nom, ouvrir une page précise ou retrouver une page dans un moteur. Ce sont des tâches séparées. DNS renvoie des registres associés à des noms. HTTP décrit un échange avec un serveur web. L’indexation décrit ce qu’un moteur a traité et conservé. Une observation réussie à une couche ne prouve pas la suivante. Commencez par la tâche exacte et un exemple reproductible, plutôt que de changer DNS, robots et redirections simultanément.
Enregistrez nom concerné, URL complète, heure et source de l’observation. Gardez jetons privés et données de compte hors des outils publics. Notez appareil et réseau pour un problème dans le navigateur, version du site après un déploiement. Cherchez un petit ensemble comparable. Sans ce relevé, un ancien rapport d’indexation, une réponse DNS en cache et une erreur actuelle peuvent sembler un seul événement alors qu’ils répondent à différentes questions. Préservez le contexte propre à chaque source de preuve.
| Couche | Question | Ne prouve pas |
|---|---|---|
| DNS | Nom et type de registre | Service HTTP ou indexation |
| HTTP | Réponse finale et déclarations | Page indexée par le moteur |
| Rapport moteur | Observation enregistrée ou en direct | Tous les trajets visiteurs fonctionnent |
Séparer le nom demandé de l’URL de page
La question DNS porte sur un nom tel qu’example.com ou www.example.com, sans https:// ni chemin de page. Ces noms peuvent avoir des registres différents et ne sont pas interchangeables. La question HTTP comprend protocole, hôte et chemin et peut rediriger ailleurs. Une page d’accueil fonctionnelle ne prouve pas qu’un chemin profond existe. Écrivez nom DNS et URL complète sur des lignes distinctes pour fournir la bonne entrée à chaque outil et conserver la question originale pendant les comparaisons.
Utilisez la recherche DNS avec un des sept types acceptés, puis le vérificateur d’indexation pour une URL publique compatible. Aucun ne lit une page de compte authentifiée. DNS utilise un résolveur Google récursif fixe ; HTTP part du serveur Savvy Toolkit. Ils ne reproduisent pas tous les réseaux locaux. Changer le résolveur de votre appareil est une opération distincte et ne doit pas être une première réaction seulement pour faire coïncider deux observations. Préservez les réglages existants avant de considérer cette modification.
Choisir le registre qui répond à la tâche
Pour les adresses, examinez A pour IPv4 et AAAA pour IPv6 séparément. L’absence dans l’un ne prouve pas l’absence dans l’autre. Pour le courrier, MX est pertinent sans tester une boîte aux lettres. TXT peut contenir plusieurs textes indépendants et n’est pas une validation générale. NS et SOA répondent à d’autres questions de zone. L’outil montre les données reçues sans certifier toute la configuration du domaine ni découvrir ses sous-domaines et les services qui en dépendent.
Gardez code et lignes de réponse ensemble. NOERROR sans réponse du type choisi diffère de NXDOMAIN ; SERVFAIL ne signifie pas nom absent. Un échec fournisseur n’offre pas de réponse DNS valide à interpréter. Des lignes d’alias peuvent apparaître, donc comparez nom et type de chaque ligne. Un résultat tronqué n’est pas un inventaire complet. Types numériques, valeurs et limites constituent les preuves ; les remplacer par un simple libellé de succès peut changer le sens et masquer une information utile au diagnostic.
Employer le TTL comme observation du cache
Le TTL est affiché en secondes. Une valeur hypothétique de 300 secondes vaut cinq minutes, sans fixer une échéance mondiale de changement. Un résolveur récursif peut renvoyer une réponse en cache avec TTL restant tandis qu’un autre voit d’autres données. L’heure indique quand l’observation a eu lieu, pas quand la configuration autoritative a changé. Gardez l’ancien registre prévu et le nouveau pour comparer avec une cible claire. Une seule réponse ou une heure récente ne prouve pas une propagation complète.
Répétez le même nom et le même type lors d’une comparaison. Examinez séparément la configuration autoritative du fournisseur responsable avec l’accès existant du propriétaire. Ne supprimez pas des registres et ne changez pas plusieurs résolveurs parce qu’une réponse diffère. Savvy Toolkit ne surveille pas l’achèvement mondial et ne garde pas d’historique. Documenter un résolveur, une question et une heure est utile ; l’affirmer comme ce que voient tous les visiteurs dépasse les preuves. Gardez les anciennes observations pour préserver leur contexte.
Vérifier HTTP sans faire de DNS un verdict
Une réponse d’adresse peut coexister avec un chemin web absent. Dans un cas fictif, DNS renvoie A pour l’hôte tandis que la page demandée répond HTTP 404. Le nom a été résolu, sans créer la page. Dans un autre, aucune réponse AAAA n’arrive mais le navigateur atteint le site par IPv4. Ce ne sont pas des tests en direct d’example.com. Ils montrent pourquoi un registre vide d’un type et une page échouée ne doivent pas devenir une panne universelle.
Le contrôle HTTP doit utiliser l’URL publique exacte. Comparez URL finale, statut et heure avec l’observation du navigateur. Une redirection peut changer d’hôte ou chemin, dont les déclarations deviennent pertinentes. Savvy Toolkit suit des redirections limitées sans montrer chaque étape ; il n’exécute pas JavaScript et ne s’authentifie pas. L’échec depuis son serveur peut avoir une cause différente de celui du navigateur. Préservez les perspectives sans attribuer une cause trop tôt. Alignez d’abord entrées, versions et heures pour une comparaison valable.
Distinguer statut et contenu utile
Une réponse 200 indique ce statut de succès reçu par la requête. Elle peut encore livrer une erreur ou une coquille vide. Examinez le contenu pour la tâche, pas seulement le code. Savvy Toolkit ne note pas le contenu et ne détecte pas tous les soft 404. Son inspection HTML dépend de taille, type et encodage. Une déclaration non trouvée après inspection incomplète n’est pas preuve de son absence totale. L’avertissement doit accompagner les champs obtenus dans chaque relevé et comparaison.
Après une modification, comparez le déploiement prévu avec la page livrée et une vue rendue pertinente. Alignez hôte et chemin finaux. Une réponse ancienne ou une redirection vers une autre version peut expliquer un écart sans changer DNS. Le propriétaire peut examiner les journaux des vraies requêtes avec son accès existant. N’affirmez pas que Savvy Toolkit est Googlebot ou que sa récupération prouve le traitement du vrai robot. Chaque source a un périmètre qui doit rester près du résultat pendant le diagnostic et le partage.
Séparer accès et directives d’indexation
Le vérificateur rapporte des déclarations d’en-tête et HTML observées et une décision limitée de robots.txt. Il ne se connecte pas à l’index. Un noindex visible peut être volontaire en revue privée. Disallow contrôle l’accès et ne prouve pas le retrait des résultats ; un robot bloqué ne lit pas le noindex de la page. Définissez d’abord le comportement public ou privé voulu puis examinez les déclarations. Retirer des restrictions pour améliorer un rapport peut exposer des pages avant leur approbation.
L’interprétation inconnue doit rester inconnue. Le parseur de préfixes littéraux n’évalue pas entièrement jokers, chemins échappés et tous les groupes. Le robots de l’origine finale peut être inaccessible ou incompatible. Des canoniques observés indiquent une préférence pour les doublons ; l’outil ne vérifie pas la cible ou le choix du moteur. Pointer ailleurs n’est pas automatiquement une erreur. Comparez avec le vrai plan de duplication et conservez les signaux ambigus pour l’inspection du propriétaire responsable du site.
Consulter séparément état indexé et preuve actuelle
Pour un site possédé, utilisez les outils vérifiés du moteur pour l’information disponible. L’Inspection d’URL Google distingue information indexée et test en direct. La page peut changer après l’observation indexée ; alignez donc heures et adresses exactes. Savvy Toolkit apporte des preuves techniques publiques, pas ces rapports connectés. Une recherche site: ou un extrait en cache est encore une autre observation, sans remplacer précisément le rapport vérifié disponible pour l’URL. Préservez le type de rapport en comparant plusieurs résultats.
Une récupération publique apparemment correcte ne garantit ni exploration, ni choix, ni conservation par le moteur. Soumission et indexation sont également distinctes. Examinez tâche, liens contextuels découvrables et contenu original utile avec les signaux techniques, sans faire du nombre de mots un objectif de classement. La longueur de ce guide suit le brief du projet. Il ne promet ni indexation ni trafic et ne justifie pas des pages répétées sans réponse utile. Préservez la distinction entre publication d’une page et acceptation par un moteur.
Résoudre les écarts avec une variable changée
Construisez un relevé avec question, entrée, source, heure, résultat et limite. Répétez une question inchangée avant de modifier les réglages. Changez ensuite seulement le paramètre responsable par l’accès habituel du propriétaire, en gardant ancienne valeur et moyen de retour. Comparez nouveau registre, déploiement, redirection ou directive avec l’effet attendu. Tout changer ensemble rend la cause difficile à retrouver et peut interrompre des services hors de la tâche échouée. Chaque décision doit suivre la preuve qui justifie vraiment la modification spécifique.
Gardez les brouillons privés pendant le contrôle des réglages publics dans un environnement approuvé. Un exemple local de métadonnées correct n’est ni déploiement public ni preuve de propriété du domaine. Avant publication ultérieure, le propriétaire doit vérifier vraies réponses hébergées et comportement attendu de robots, canoniques et sitemap. Les outils ne déploient pas et ne modifient pas le site. Cette démarche produit observations reproductibles et prochaine action limitée, pas un badge vert pour toutes les couches. Notez les revues encore nécessaires sur l’hébergement réel.
Conserver un petit dossier de preuves
Pour DNS, gardez nom, type, résolveur, heure, code, lignes utiles et troncature. Pour HTTP, URL envoyée et finale, heure, statut, déclarations et limites. Pour un rapport moteur, URL exacte, type de rapport et heure sous accès du propriétaire. N’incluez pas mots de passe, liens de session ou registres confidentiels dans une demande publique de correction. Ces relevés séparés permettent à une autre personne de suivre la question sans confondre résultat actuel et ancien. Le contexte rend les observations comparables et réutilisables.
Terminez par la prochaine question sans réponse. Un écart de registres concerne le responsable DNS ; un chemin final incorrect, le routage ou déploiement ; un canonique choisi par le moteur, son rapport vérifié et le plan du site. Les outils aident à recueillir des preuves publiques limitées pour ces tâches. Ils ne remplacent pas l’accès au système responsable et ne prouvent pas l’exclusion de toutes les pannes. Gardez la limite avec le résultat partagé afin que l’action suivante respecte le périmètre vérifié.