Corriger une erreur de crawl ou synchronisation

Un échec de crawl se situe avant, pendant ou après le téléchargement

Avant : URL invalide, destination privée ou quota. Pendant : DNS, TLS, redirection, statut HTTP, challenge ou taille. Après : contenu vide, format inutilisable, extraction ou tâche d’indexation. Identifier la phase évite de relancer toute la base.

Pour un site complet, Wavize affiche les totaux de pages découvertes, traitées et échouées, mais ne conserve pas nécessairement un motif détaillé par URL. Isolez une page représentative pour obtenir un diagnostic reproductible.

Relance raisonnée
Corrigez d’abord la cause, relancez quelques URL prioritaires, puis le site complet. Des relances répétées peuvent consommer quota et masquer l’heure du premier incident.

Tester l’URL comme un visiteur anonyme

Utilisez une fenêtre privée et, si possible, un réseau extérieur.

1. Réponse sans connexion

   La page doit afficher son contenu sans compte, mot de passe, cookie préalable ou jeton signé temporaire.

2. Redirections finies

   Vérifiez l’URL finale, le même domaine et l’absence de boucle HTTP/HTTPS ou www. L’analyse légère d’onboarding limite les redirections et un crawl reste soumis aux contrôles de destination.

3. Texte réellement présent

   Une page vide avant exécution JavaScript, une vidéo seule ou un canvas n’offre pas de contenu exploitable. Ajoutez une version HTML ou texte.

Lire les réponses serveur

Demandez à votre hébergeur les journaux autour de l’heure du test si nécessaire.

• 403 ou challenge

  Le WAF, robots ou une protection anti-bot refuse le serveur. Créez une règle ciblée conforme à votre politique, sans désactiver toute la sécurité.

• 404 ou 410

  Corrigez liens et sitemap, excluez les pages retirées et ne les remplacez pas par des redirections vers l’accueil qui créent du contenu dupliqué.

• 429

  Le serveur limite les requêtes. Espacez le crawl ou ajustez la règle pour Wavize ; ne lancez pas plusieurs sources identiques en parallèle.

• 5xx / TLS / DNS

  Corrigez l’indisponibilité, la chaîne certificat ou la résolution avant relance. Une page qui fonctionne seulement depuis votre bureau peut rester inaccessible publiquement.

Contrôler quota, sélection et statut de tâche

Une source partielle n’est pas toujours une panne.

1. Quota mensuel d’URL

   Comparez pages déjà utilisées et capacité de la formule. Excluez filtres, paramètres et duplications avant de relancer.

2. File et workers

   Un statut queued persistant peut indiquer une file chargée ou un worker arrêté. Notez durée et source avant d’ouvrir un ticket.

3. Échecs concentrés

   Recherchez un motif d’URL commun : langue, sous-domaine, filtre, fichier lourd. L’exclusion par famille peut sauver le crawl utile.

Valider la correction dans les réponses

Un statut réussi doit encore produire une connaissance utile.

1. Page traitée

   La page prioritaire n’est plus échouée ou exclue involontairement.

2. Question factuelle

   Posez une question dont la réponse se trouve explicitement dans le texte téléchargé.

3. Absence de doublon

   L’ancienne URL ou version ne fournit pas une réponse contradictoire après réentraînement.

Informations à joindre au support

N’envoyez pas de clé API ni une page privée.

• Source — Titre, type et URL publique.
• Chronologie — Heure de lancement, durée dans chaque statut et dernière relance.
• Échantillon — Deux ou trois URL représentatives et leurs statuts publics.