Site Audit
Commencez par la configuration du site et du crawl afin que l'audit couvre le périmètre que vous souhaitez examiner.
Crawl borné
Preuves traçables
Vérification comparable
Utiliser Site Audit comme une boucle de preuve
Choisir la vue qui possède la question
| Vue | Question principale |
|---|---|
| Sites | Quelle propriété, quelle autorisation et quel dernier run sont concernés ? |
| Overview | Où le run sélectionné mérite-t-il une enquête ? |
| Issues | Quelles règles touchent quelles URL ou ressources ? |
| Pages | Quel ensemble d’URL répond aux filtres techniques ? |
| Statistics | Dans quels segments les faits se concentrent-ils ? |
| Structured Data | Quel balisage a été conservé et évalué ? |
| Performance | Quelles mesures terrain, labo ou crawl existent réellement ? |
| Internal Links | Quelles relations source-cible expliquent le motif ? |
| Compare | Qu’est-ce qui a changé entre deux runs admissibles ? |
| Crawls | La collecte et la publication ont-elles abouti ? |
| Automation | Quand tenter une nouvelle collecte et quand alerter ? |
| Settings | Quel contrat de preuve gouverne les prochains crawls ? |
Le site et le run forment un contexte commun
Le site fixe la frontière de propriété. Le run sélectionné fixe la date et les preuves enregistrées dans les vues liées au crawl. Lancer un nouveau crawl ne réécrit pas les anciens résultats.
Les réglages du site peuvent changer après le crawl. Le run garde sa propre politique, son plafond demandé, son estimation, ses compteurs et ses horodatages afin que l’équipe puisse reconstruire les conditions exactes de l’observation.
Un Quick check ne remplace pas un crawl vérifié
Le crawl complet exige une vérification confirmée côté serveur. Le Quick check public est limité à 100 URL et deux niveaux, respecte robots.txt, désactive le rendu et utilise une faible concurrence. Sa couverture doit toujours être présentée comme restreinte.
La vérification prouve le contrôle de l’hôte enregistré au moyen d’un challenge actuel. Elle n’autorise pas automatiquement chaque sous-domaine, zone connectée, ressource tierce ou environnement associé.
Lire la portée et la couverture avant le score
Un périmètre plus étroit, des pages bloquées ou des fetchs manquants peuvent faire monter un score tout en réduisant les preuves. Une absence de score ne vaut pas zéro. Sous 70 % de couverture, les preuves sont insuffisantes; de 70 à moins de 85 %, le résultat reste provisoire.
Une collecte terminée peut encore être en traitement
Après le crawl primaire, Crawl Foundry publie graphe de liens, projections de constats, synthèses, métriques, agrégats, Health Score, signaux AI Readiness et alertes. Tant que ce traitement secondaire n’est pas terminé, le rapport peut rester en état Processing.
Health oriente l’enquête sans prédire le ranking
Le score condense des règles de crawlabilité, indexabilité, contenu, métadonnées, architecture de liens, données structurées, internationalisation, performance, ressources et sécurité. Il ne mesure ni probabilité de ranking ni valeur commerciale.
Le résultat conserve aussi version du score, éligibilité, portée, couverture, confiance, exactitude et troncature. Deux points ne forment une tendance que lorsque ces bases restent réellement comparables.
Passer de l’orientation à la preuve propriétaire
Overview et Statistics montrent un motif. Issues explique la règle, Pages délimite l’ensemble d’URL, Internal Links conserve les relations et le dossier URL réunit les faits de page. La décision éditoriale ou technique reste humaine.
Utilisez les problèmes, pages et liens pour passer du résumé de l'audit aux URL et relations derrière un constat.
Les limites font partie de la preuve
Tables, snapshots, exemples, comparaisons et exports sont bornés. Gardez pagination, comptage exact ou minimal, omissions et troncature visibles. Un échantillon affiché ne représente pas silencieusement tout le site.
Utilisez le total affiché, l’indicateur d’exactitude, la page suivante, le filtre enregistré ou l’export adapté à la question. Une liste chargée à l’écran n’est pas une affirmation sur toutes les URL.
Utiliser l’historique et l’automatisation pour observer de façon répétable
Compare s’appuie sur deux runs publiés, terminés ou partiels, et peut conserver les changements d’URL, de métadonnées, de constats, de liens, de ressources, de segments et d’arborescence. Les règles de correspondance restent explicites pour un recrawl, une migration ou un passage autorisé de staging à production.
Automation peut planifier des runs quotidiens, hebdomadaires ou mensuels et évaluer les règles d’alerte actives par rapport à un run précédent comparable. Une échéance, un run admis, une alerte créée, un e-mail mis en file et un e-mail livré sont cinq faits distincts.
Pour un examen régulier, configurez la surveillance et les alertes autour des données qu'une personne est chargée de vérifier.
L’historique perd progressivement son détail
Les dix runs terminaux les plus récents et tous ceux de 30 jours ou moins gardent le détail. Jusqu’à 183 jours, les anciens runs sont compactés après préavis de sept jours. Jusqu’à 365 jours, une ancre admissible par mois subsiste. Au-delà, même un run épinglé est supprimé, sauf le run terminal le plus récent d’un site inactif.
Fermer le travail avec une preuve comparable
Un ticket ou un déploiement ne prouve pas le résultat SEO. Recrawlez une portée équivalente, vérifiez collecte et publication, puis contrôlez les constats résolus, persistants et nouvellement créés.