Comment auditer un site Wix avec Screaming Frog : configuration exacte et analyse

Lancer Screaming Frog sur un site Wix avec la configuration par défaut donne des résultats trompeurs : des éléments manquants qui existent pourtant bien sur le site, des balises qui semblent absentes alors qu’elles sont injectées après coup. La cause tient à la façon dont Wix sert ses pages, un point que les tutoriels génériques sur Screaming Frog ne traitent jamais parce qu’ils ne s’adressent à aucun CMS en particulier. Ce guide complète notre page pilier sur l’audit SEO Wix côté outillage technique.

Pourquoi la configuration par défaut échoue sur Wix

Wix sert ses pages selon un pipeline en deux temps : un rendu côté serveur (SSR) qui produit un premier HTML, suivi d’une hydratation JavaScript côté client qui complète et active certains éléments (filtres de galerie, blocs d’applications tierces, contenus dynamiques). Googlebot gère bien cette combinaison, documentée comme spécifique à l’écosystème Wix. Screaming Frog, en mode texte seul (par défaut), ne voit que le premier temps : le HTML issu du SSR, sans l’hydratation qui suit.

Concrètement, un crawl lancé sans ajustement peut signaler comme absents des éléments qui existent bel et bien sur le site une fois chargé dans un navigateur, faussant le diagnostic de contenu dupliqué, de balises manquantes ou de maillage interne sur les blocs injectés après le rendu initial.

La configuration exacte à appliquer

1. Basculer le mode de rendu sur JavaScriptConfiguration puis Spider puis onglet Rendering, sélectionnez JavaScript plutôt que Text Only. Screaming Frog exécute alors le JavaScript de la page avant d’en analyser le DOM final, capturant ce que Googlebot voit réellement après hydratation.
2. Régler la vitesse de crawl sur 1 à 2 URL par secondeUn crawl trop rapide sur un hébergement mutualisé (le cas de la majorité des sites Wix) peut déclencher des ralentissements ou des réponses incomplètes, faussant les temps de chargement mesurés.
3. Exclure les paramètres propres à WixConfiguration puis Include/Exclude, filtrez les paramètres d’URL générés par la plateforme (identifiants de session, paramètres de recherche interne de galerie) pour ne pas multiplier artificiellement le nombre de pages crawlées avec des variantes de la même URL.
4. Vérifier le user-agent utiliséConfiguration puis User-Agent, optez pour Googlebot Smartphone : l’indexation mobile-first s’applique aussi aux sites Wix, et certains blocs affichés en desktop peuvent être masqués (pas supprimés) en version mobile selon la configuration de l’éditeur.

Le cas particulier du robots.txt Wix

Contrairement à un site auto-hébergé où le robots.txt se modifie librement, Wix génère ce fichier automatiquement avec des règles fixes pour certains chemins techniques de la plateforme, et n’autorise qu’une personnalisation partielle (ajout de règles complémentaires, pas remplacement total du fichier), plus limitée encore sur l’éditeur Classic que sur Wix Studio. Un audit qui interprète un blocage robots.txt sur ces chemins système comme une anomalie à corriger perd du temps sur un comportement natif et non modifiable de la plateforme.

Avant de signaler un blocage robots.txt comme un défaut dans votre rapport d’audit, vérifiez s’il touche un chemin technique généré par Wix (souvent reconnaissable à un préfixe système) ou une page de contenu réelle : seul le second cas mérite une action corrective.

Quoi analyser une fois le crawl terminé

Trois onglets concentrent l’essentiel du diagnostic sur un site Wix : Page Titles pour les doublons de balise title (fréquents sur les pages de galerie produit générées automatiquement), Response Codes filtré sur les erreurs 4xx et 5xx pour les liens cassés, et Canonicals pour vérifier que chaque variante de page (filtres, tri) pointe bien vers l’URL de référence plutôt que de se disperser en plusieurs versions indexables.

L’onglet Crawl Depth mérite une attention particulière sur les sites e-commerce Wix Stores au catalogue conséquent : au-delà de plusieurs centaines de produits, la profondeur de clic grimpe vite si l’arborescence de collections n’a pas été pensée pour la limiter, un point que notre article sur les 30 points techniques à contrôler sur Wix détaille dans le détail de la correction, pas seulement du diagnostic.

Ce que Screaming Frog ne peut pas voir sur Wix

Même correctement configuré, un crawl reste aveugle à certains signaux propres à la plateforme : le statut réel d’indexation (seul Search Console le confirme), les erreurs de Core Web Vitals mesurées en conditions réelles par les internautes (données terrain, absentes d’un crawl qui mesure en conditions de laboratoire), et les restrictions liées au plan Wix souscrit, un point que notre article sur l’audit rapide par un consultant SEO Wix aborde sous l’angle de l’accès aux données plutôt que du crawl technique (un domaine gratuit .wixsite.com n’expose pas les mêmes fonctionnalités SEO qu’un plan Premium avec domaine connecté).

Questions fréquentes

Un bon crawl commence par comprendre ce qu’on crawle

Screaming Frog reste un outil généraliste, pensé pour s’adapter à n’importe quel site. Sur Wix, cette généralité a un coût si elle n’est pas corrigée en amont : sans le mode de rendu adapté et sans savoir distinguer les limitations de la plateforme des vraies anomalies, l’audit produit une liste de faux positifs aussi longue que la liste des vrais problèmes.