Comment pallier l’absence d’analyse de logs serveur sur Wix pour auditer le budget de crawl

Wix ne donne pas accès aux logs serveur, ce qui prive d’une analyse de crawl classique. La réponse habituelle, passer par une offre Cloudflare Enterprise, est surdimensionnée pour la quasi-totalité des sites Wix. Il existe plus simple : le rapport Statistiques d’exploration de la Search Console est un résumé de logs que Google vous fournit gratuitement. Bien lu, il répond aux questions qui comptent.

Ce que les logs apportent, et pourquoi Wix vous les refuse

Un fichier de logs enregistre chaque requête reçue par le serveur, dont chaque passage de Googlebot : quelle URL, à quelle heure, avec quel code de réponse et quel temps de traitement. Croisé sur plusieurs semaines, cela donne la fréquence de crawl page par page, la liste des URL que Google explore sans qu’elles soient dans le sitemap, et la part du budget dépensée sur des erreurs.

Wix n’expose pas ces logs : la plateforme gère l’infrastructure, vous n’avez pas la main dessus. Une couche Cloudflare sur les forfaits supérieurs permet techniquement d’extraire les requêtes par agent utilisateur, mais c’est un investissement lourd, justifié seulement au-delà de plusieurs milliers d’URL. Pour un site vitrine, une boutique de taille moyenne, un site local, ce n’est pas la bonne réponse.

Le rapport Statistiques d’exploration, votre résumé de logs

Dans la Search Console, ouvrez Paramètres, puis Statistiques sur l’exploration. Ce rapport agrège, sur 90 jours, l’activité réelle de Googlebot sur votre site. Il n’est pas détaillé URL par URL comme de vrais logs, mais il répond aux trois questions qui déterminent la santé d’un budget de crawl.

Lire les codes de réponse

Le rapport ventile les requêtes par code HTTP. Visé : plus de 90 % de réponses 200, moins de 5 % de 3xx, moins de 5 % de 4xx, une part infime de 5xx. Une proportion élevée de 404 signifie que Googlebot passe son temps sur des URL mortes, souvent d’anciennes pages Wix Stores ou Bookings supprimées sans redirection. Un pic de 5xx pointe un problème côté plateforme à surveiller.

Lire le temps de réponse

Le rapport donne le temps de réponse moyen. Au-delà de 600 millisecondes, Googlebot réduit son rythme d’exploration ; en dessous de 300, il explore librement. Sur Wix, vous ne pilotez pas ce temps, il dépend de l’infrastructure : c’est un constat à intégrer, pas un levier. S’il est élevé en permanence, cela explique un crawl lent et donc une découverte lente de vos nouvelles pages.

Lire l’objectif d’exploration

Chaque requête est classée « découverte » ou « actualisation ». Une part écrasante d’actualisation sur des pages qui ne changent jamais est du gaspillage. Une part de découverte proche de zéro alors que vous publiez régulièrement signale que Google ne trouve pas vos nouveautés : problème de maillage interne ou de sitemap.

Compléter avec le rapport Pages et un écart sitemap

Deux contrôles complètent le tableau. Le rapport d’indexation des pages liste les raisons de non-indexation : « explorée non indexée », « détectée non indexée », « page en double », « soft 404 ». Chaque catégorie volumineuse est un poste de gaspillage de crawl identifié.

Ensuite, comparez le nombre d’URL de votre sitemap Wix au nombre d’URL indexées et au nombre d’URL explorées. Un écart important entre explorées et indexées indique que Googlebot dépense de l’énergie sur des pages qu’il ne retient pas. Des URL explorées qui ne figurent nulle part dans votre sitemap sont soit des pages orphelines, soit des URL parasites, paramètres ou pages de test, à traiter. Cette lecture croisée prolonge la démarche de notre guide de l’indexation et du SEO technique sur Wix, et prépare les corrections détaillées dans l’article sur l’optimisation du budget de crawl via robots.txt, sitemap et noindex.

Ce que ce montage ne verra jamais

Soyons honnêtes sur les angles morts. Vous n’aurez pas la fréquence de crawl d’une URL précise, seulement des moyennes. Vous ne verrez pas les autres robots, légitimes ou non, ni les appels de ressources qui échouent en profondeur du rendu. Vous ne pourrez pas dater au jour près le dernier passage de Google sur une page donnée, sauf à l’inspecter une par une.

En pratique, ces limites comptent peu en dessous de quelques milliers d’URL, ce qui couvre la grande majorité des sites Wix. Au-delà, et seulement là, l’extraction via Cloudflare devient un investissement défendable.

Auditer le crawl sur Wix sans logs

1. Ouvrir Statistiques sur l’explorationSearch Console, Paramètres, Statistiques sur l’exploration : la base de l’audit, sur 90 jours.
2. Vérifier la répartition des codesPlus de 90 % de 200, part de 4xx sous 5 % ; une masse de 404 = anciennes pages Stores ou Bookings sans redirection.
3. Noter le temps de réponse moyenAu-dessus de 600 ms, le crawl ralentit ; sur Wix c’est un constat d’infrastructure, pas un réglage.
4. Analyser l’objectif d’explorationTrop d’actualisation sur des pages figées, ou trop peu de découverte malgré des publications : maillage ou sitemap à revoir.
5. Croiser avec le rapport PagesLister les raisons de non-indexation volumineuses, chacune étant un poste de gaspillage.
6. Mesurer l’écart sitemap / explorées / indexéesUn grand écart explorées contre indexées, ou des URL explorées hors sitemap, signalent le gaspillage à corriger.

Un audit de crawl sans une seule ligne de log

L’absence de logs sur Wix n’empêche pas d’auditer un budget de crawl. Le rapport Statistiques d’exploration, lu sur trois axes, codes de réponse, temps de réponse, objectif d’exploration, complété du rapport Pages et d’un écart sitemap, répond aux vraies questions : Google perd-il du temps sur des erreurs, explore-t-il assez vite, trouve-t-il vos nouveautés. C’est suffisant sous quelques milliers d’URL, et c’est gratuit.