Sites, vérification et configuration du crawl
Vérifiez les paramètres de crawl et la vérification du site avant de lancer une exécution qui servira de référence.
Crawl borné
Preuves traçables
Vérification comparable
Conserver chaque propriété auditée dans son propre contexte
Un site appartient à un workspace et conserve URL de base, mode d’autorisation, état de vérification, réglages, calendriers et historique. Séparez les hôtes dont la propriété ou le cycle de livraison demande une enquête distincte.
- Les offres actuelles autorisent par défaut 3, 5, 10 ou 50 sites Site Audit actifs par organisation.
- La vue Sites associe chaque propriété à son dernier run conservé; les dates de crawl peuvent donc différer d’une ligne à l’autre.
- Un site bloqué ne peut pas être crawlé; un site non vérifié reste limité au sondage public.
Confirmer site et run avant de lire un rapport
Le site détermine la propriété autorisée; le run détermine l’observation enregistrée. Changer de run modifie le contexte des vues liées au crawl, sans modifier les preuves historiques.
Un réglage peut évoluer ensuite. Le run conserve néanmoins la politique appliquée, le plafond demandé, l’estimation, les compteurs et les horodatages nécessaires pour expliquer ce qui s’est réellement passé.
Le setup expose chaque décision de portée
La vérification prouve le contrôle côté serveur
Trois méthodes sont prises en charge: balise meta CMS, fichier HTML à la racine ou enregistrement DNS TXT. Le challenge est lié au site et à la méthode et expire après sept jours. Un état dans l’interface ne peut pas marquer seul le site comme vérifié.
Un échec enregistre son heure, un code et un message borné. Vérifiez protocole, hôte, HTML déployé, propagation DNS, méthode et expiration avant de conclure que la propriété ne peut pas être confirmée.
Le Quick check réduit volontairement la portée
Il admet au plus 100 URL, une profondeur de deux, aucun rendu, une concurrence de deux, au moins une seconde entre les requêtes et des lots de 25. Il respecte toujours robots.txt et sert de sondage public, pas d’audit complet.
Définir la frontière de preuve avant le départ
| Réglage | Conséquence |
|---|---|
| URL de base | Fixe le point de départ, le protocole et l’hôte. |
| Plafond d’URL | Borne pages admises, volume de preuve et coût potentiel. |
| Profondeur | Borne la distance de découverte depuis le départ. |
| Chemins inclus | Détermine les zones internes admissibles après normalisation. |
| Chemins exclus | Retire explicitement des zones de l’ensemble crawlable. |
| Robots | Détermine comment les interdictions affectent la collecte. |
| Rendu | Détermine quelles pages obtiennent une observation rendue. |
Les plafonds de plan et de workspace restent fermes
Un crawl complet ne dépasse jamais 5 000 URL. Les valeurs actuelles par défaut sont 500, 1 000, 2 500 ou 5 000 pages par crawl et 3, 5, 10 ou 50 sites selon le plan. Une configuration effective du control plane peut remplacer ces valeurs et prévaut dans le produit.
Les URL découvertes au-delà du plafond admis restent une information de couverture. Elles ne sont ni des pages échouées ni des éléments que l’on peut ajouter silencieusement au dénominateur crawlé.
Le rendu change la preuve et l’estimation
En mode eligible, l’estimation réserve actuellement du rendu pour 25 % du plafond; en mode required, pour toutes les pages admises. Le règlement terminal utilise les unités réellement auditées et rendues, puis libère la réserve inutilisée lorsque l’état du run le permet.
Le rendu peut modifier métadonnées, liens, ressources, données structurées et constats. Conservez la même politique pour comparer deux runs et n’attribuez pas de preuve navigateur à un crawl où le rendu était désactivé.
Séparer estimation, réservation et règlement
Le serveur estime avant l’admission, réserve le solde au départ et règle les unités réelles à la fin. Une estimation n’est donc ni une facture finale ni la preuve que le worker a exécuté le crawl.
Le ledger du run distingue réservation, travail audité, unités rendues, règlement et éventuelle libération. Utilisez cet historique terminal lorsque vous devez expliquer un coût au lieu de vous fier au seul écran de départ.
Lancer avec un contexte vérifiable
Une requête enregistrée ne prouve pas le travail du worker
requested, reserved, dispatch_pending, queued, crawling, analyzing et completed décrivent des phases différentes. Lisez état, compteurs et publication plutôt que le seul succès de l’appel de départ.
Une fois le rapport disponible, examinez la couverture et les statistiques du crawl avant d'interpréter le score de santé.
La rétention conserve les tendances, pas tous les détails à vie
Détail complet jusqu’à 30 jours et pour les dix derniers runs terminaux; compaction annoncée jusqu’à 183 jours; une ancre mensuelle admissible jusqu’à 365 jours; suppression ensuite, sauf protection du dernier run terminal du site. Cinq épingles par site peuvent retarder la compaction mais pas la limite annuelle.
Archiver déclenche une voie de suppression distincte
Après sept jours de grâce, les données d’un site archivé passent directement à la suppression, quel que soit leur âge. Vérifiez calendriers, comparaisons, exports et besoins de preuve avant l’archivage. Les éléments de facturation suivent leur propre rétention.