Un SEO freelance tombe sur une URL bizarre dans Screaming Frog pendant un audit Squarespace. La page est bloquée en robots.txt, personne ne sait d’où elle vient, et le CMS ne permet pas de la supprimer. Panique. John Mueller a répondu directement sur Reddit : ignore-la, ça n’a aucun impact SEO.
Voici pourquoi, et ce que ça dit sur la façon de lire un audit technique.
Ce que Screaming Frog a détecté (et pourquoi ça inquiète)
La situation est classique. Un SEO audite un site Squarespace pour un client. Screaming Frog remonte un lien interne vers une URL de ce type :
https://domaine.com/categories/=59487a4cd1758e7669102174La page est bloquée par robots.txt. Le client ne l’a jamais créée. Et impossible de modifier ou supprimer le lien depuis l’interface Squarespace, car le CMS ne donne pas accès au backend.
La question posée à Mueller sur Reddit était directe : est-ce que ce lien parasite crée un problème SEO ? Est-ce que Google peut suivre ce lien malgré le robots.txt ?
La réponse de Mueller : ne touche à rien
Mueller a répondu sans détour :
« It doesn’t really matter. I’d ignore it. It has no impact on search / SEO at all. Some platforms just have links like that, if there’s nothing behind the link that you want indexed, there’s nothing you need to do. »
Traduction : certaines plateformes génèrent ce type de liens par construction. Si la page derrière ce lien n’a pas vocation à être indexée, il n’y a rien à faire. Et sur une plateforme hébergée, il n’y a souvent rien à faire de toute façon.
Ce n’est pas une réponse évasive. C’est une confirmation que ces URLs font partie de l’architecture interne du CMS, pas d’un bug ou d’une fuite.
Ce que sont vraiment ces URLs Squarespace
Squarespace, comme tout CMS, gère ses contenus via une base de données. Chaque catégorie, chaque page, chaque élément a un identifiant unique dans cette base. L’URL visible par l’utilisateur (/categories/chaussures, par exemple) est une couche cosmétique par-dessus cet identifiant.
La chaîne 59487a4cd1758e7669102174 est précisément cet identifiant interne. Elle ne change jamais, même si le client renomme sa catégorie dix fois. C’est ce qui permet à Squarespace de faire coexister l’URL lisible choisie par l’utilisateur avec la référence stable en base de données.
Un développeur Squarespace le sait. Un auditeur SEO qui arrive de l’extérieur peut le prendre pour une anomalie.
L’astuce ?format=json-pretty
Si tu travailles sur un site Squarespace et que tu veux voir les identifiants de base de données sous-jacents, ajoute ?format=json-pretty à la fin de n’importe quelle URL. Squarespace bascule alors en mode sortie JSON brut. Tu vois toute la structure interne de la page. C’est un outil utilisé par les développeurs Squarespace pour déboguer.
WordPress fait exactement la même chose
Ce n’est pas spécifique à Squarespace. WordPress utilise le même principe, plus discret mais identique :
term_idpour les catégories et les tagspost_idpour les articles, pages, produits et médias
Ces identifiants apparaissent parfois dans le HTML brut généré par WordPress, notamment dans certains attributs de classes ou de liens. Screaming Frog peut les remonter de la même façon. Et tout comme pour Squarespace, il n’y a aucune raison SEO de les modifier ou de les supprimer.
C’est une architecture normale, pas une dette technique.
Ce que ça change pour tes audits SEO
Ce cas soulève un point plus large sur la méthode d’audit. Screaming Frog est un outil puissant, mais il remonte tout ce qu’il trouve, y compris des artefacts qui font partie du fonctionnement normal d’un CMS.
La compétence de l’auditeur, c’est précisément de distinguer ce qui mérite une action de ce qui peut être ignoré. Sur ce sujet, j’ai aussi détaillé pourquoi les tests SEO échouent souvent : agir sur de faux signaux en fait partie.
Quelques repères pratiques pour Squarespace en particulier :
- Configure Screaming Frog pour respecter le robots.txt (
Settings > Spider > Crawl Behaviour > Respect robots.txt) - Ou exclue manuellement les patterns d’URLs internes comme
/categories/=de ton crawl - Avant de signaler une anomalie à un client, vérifie si elle correspond à un comportement documenté du CMS
Sur les plateformes hébergées (Squarespace, Wix, Shopify), la liberté d’édition du backend est limitée par design. Ce n’est pas forcément un problème SEO. C’est un compromis d’architecture.
Ce que ça veut dire pour toi
Si tu audites régulièrement des sites sur des CMS propriétaires, investis du temps pour comprendre leur mécanique interne avant de livrer des recommandations. Un rapport d’audit qui liste des faux positifs fragilise ta crédibilité.
À mon avis, c’est aussi un argument pour documenter tes outils et leur configuration dans ton process d’audit. Screaming Frog configuré pour ignorer le robots.txt remonte plus de données, mais pas forcément de meilleures données. C’est la même logique que pour les pages non indexées que Google explique par la qualité : volume n’égale pas pertinence.
Pour les clients qui s’interrogent sur leur robots.txt et ses effets réels, l’article sur la règle de spécificité dans robots.txt donne un contexte utile sur comment Googlebot interprète ces fichiers.
Si tu veux aller plus loin sur la structuration de tes audits et leur lisibilité pour des clients non-techniques, mon agence AskOptimize travaille précisément sur ce type de problématiques.
FAQ
Les URLs auto-générées par Squarespace nuisent-elles au SEO ?
Non. John Mueller a confirmé que ces URLs n’ont aucun impact sur la visibilité dans la recherche. Elles font partie de l’architecture interne du CMS et n’ont pas besoin d’être supprimées.
Pourquoi Screaming Frog détecte-t-il ces liens si la page est bloquée par robots.txt ?
Screaming Frog peut être configuré pour ignorer ou respecter robots.txt. Quand il ignore ce fichier, il remonte tous les liens présents dans le HTML, y compris ceux qui pointent vers des pages bloquées. Cela ne signifie pas que Google les suivra ou les indexera.
Peut-on supprimer ces liens sur Squarespace ?
Non, et ce n’est pas nécessaire. Ces liens sont générés automatiquement par l’architecture interne de Squarespace. Le CMS ne donne pas accès au backend pour les modifier, et Mueller confirme qu’il n’y a aucune raison SEO de le faire.
WordPress génère-t-il le même type d’identifiants internes ?
Oui. WordPress utilise des term_id pour les catégories et les tags, et des post_id pour les articles et pages. Ces identifiants peuvent apparaître dans le HTML brut et sont visibles dans Screaming Frog, mais ils ne posent aucun problème SEO.
Comment configurer Screaming Frog pour éviter ces faux positifs sur Squarespace ?
Active l’option Respect robots.txt dans Settings > Spider > Crawl Behaviour. Tu peux aussi créer des règles d’exclusion manuelles pour les patterns d’URLs internes spécifiques à Squarespace, comme les chaînes de type /categories/=.
