Robots.txt SEO : les 5 erreurs qui plombent les e-commerces

📌 POINTS À RETENIR

• Le robots.txt contrôle le crawl, pas l'indexation — une confusion qui coûte cher en e-commerce
• Bloquer ses propres pages produits ou son sitemap est une erreur plus fréquente qu'on ne le croit
• Les URL à paramètres et les pages de facettes sont les principales pompes à budget crawl sur les gros catalogues
• Un robots.txt mal rédigé peut passer des mois sans être détecté — jusqu'à ce que le trafic chute

⏱️ Temps de lecture : ~6 min

---

Vous avez déjà vu un site e-commerce perdre 30 % de son trafic organique sans toucher une seule ligne de contenu ? Dans la moitié des audits que je réalise, l'explication est dans un fichier de quatre lignes que personne n'a relu depuis le lancement.

Le robots.txt est-il vraiment si critique pour le SEO ? Oui — à condition de comprendre ce qu'il fait réellement. Il ne décide pas ce que Google indexe, il décide ce que Googlebot peut visiter. Sur un catalogue de 50 000 références, ce détail change tout.

Voici les cinq erreurs que je retrouve systématiquement sur les sites e-commerce, et comment les corriger sans casser quoi que ce soit.

Crawl vs indexation : la confusion qui coûte cher

Avant de parler d'erreurs, posons le cadre. Le robots.txt est un fichier texte placé à la racine de votre domaine (monsite.com/robots.txt). Il indique aux robots d'exploration — Googlebot en tête — quelles URL ils sont autorisés à visiter.

Ce qu'il ne fait pas : empêcher une page d'apparaître dans les résultats Google. Si une page est bloquée par robots.txt mais qu'elle reçoit des liens externes, Google peut quand même la référencer — simplement, il ne l'aura pas lue. Google Search Central le précise explicitement : crawl et indexation sont deux étapes distinctes.

Cette confusion — confondre robots.txt et noindex — est la source de la plupart des erreurs que je liste ci-dessous. Si on comprend que robots.txt = accès au crawleur, tout le reste devient logique.

Si vous voulez comprendre en détail comment ces trois étapes s'articulent (crawl, indexation, ranking), j'ai développé le sujet dans mon article sur les problèmes d'indexation Google et comment les diagnostiquer.

Erreur 1 — Bloquer des pages produits par accident

C'est l'erreur la plus grave, et elle arrive plus souvent qu'on ne le pense. Le cas typique : une agence configure le robots.txt lors du développement pour bloquer tout le site (Disallow: /), et personne ne le modifie avant la mise en production.

Autre variante fréquente : un développeur bloque /products/ pour éviter le crawl des pages de prévisualisation — et oublie que les fiches produit live sont elles aussi sous ce chemin.

⚠️ ERREUR COURANTE : Une règle Disallow: /products/ bloque TOUTES les URL qui commencent par /products/, y compris vos fiches produit en production. La correspondance est préfixielle, pas exacte.

La correction est simple : ouvrir le robots.txt, tester chaque règle Disallow dans l'outil de test de Google Search Console, et comparer avec le crawl Screaming Frog. J'aborde cette étape de vérification dans ma méthode d'audit technique SEO.

Erreur 2 — Omettre les URL à paramètres et les facettes

Sur un e-commerce avec navigation à facettes (filtres par taille, couleur, prix, marque), chaque combinaison de filtres génère une URL distincte. Un catalogue de 10 000 produits peut produire des millions d'URL uniques.

Si ces URL ne sont pas bloquées dans le robots.txt — ou gérées via canoniques — Googlebot les crawle toutes. Il épuise son budget de crawl sur des pages sans valeur SEO, au détriment de vos vraies fiches produit.

💡 ASTUCE : Pour identifier l'ampleur du problème avant de tout bloquer, analysez vos logs serveur. Regardez quelles URL Googlebot visite le plus souvent. Si vous voyez /catalogue?couleur=rouge&taille=M&tri=prix-asc revenir des centaines de fois, le problème est confirmé.

Le pattern Disallow à ajouter pour les paramètres courants :

Disallow: /*?*

Attention : cette règle bloque toutes les URL avec paramètre. Si certaines ont une valeur SEO (pages de campagne avec UTM mises de côté, pages de résultats de recherche interne), ajustez au cas par cas.

J'ai détaillé le mécanisme exact dans mon article dédié au budget de crawl sur les sites de plus de 100k pages — le problème des facettes y est traité en profondeur.

Erreur 3 — Oublier de déclarer le sitemap

Le robots.txt peut contenir une ligne Sitemap: qui pointe vers votre sitemap XML. Ce n'est pas obligatoire — Google peut trouver votre sitemap autrement — mais c'est une bonne pratique qui facilite le travail de Googlebot.

Ce que je vois souvent : le sitemap est soumis dans la Search Console, mais la ligne Sitemap: n'est pas dans le robots.txt. Résultat, d'autres crawlers (Bing, robots tiers) ne le trouvent pas.

La ligne à ajouter, aussi simple que ça :

Sitemap: https://www.monsite.com/sitemap.xml

Si vous avez plusieurs sitemaps (produits, catégories, articles de blog), déclarez-les tous — ou utilisez un sitemap index.

Erreur 4 — Bloquer les ressources CSS et JavaScript

Celle-ci date un peu, mais elle revient encore sur des sites anciens ou mal migrés. Avant 2015, bloquer les CSS et JS dans le robots.txt était une pratique répandue — pour éviter de « montrer » le design aux concurrents, ou par erreur de configuration.

Depuis, Google rend le site tel qu'un navigateur le verrait. Si Googlebot ne peut pas charger vos feuilles de style et vos scripts, il voit une page dégradée — et peut mal évaluer votre contenu et votre expérience utilisateur.

⚠️ ERREUR COURANTE : Les règles Disallow: /wp-content/themes/ ou Disallow: /assets/css/ bloquent les ressources front-end. Sur un site Next.js ou un Shopify customisé, c'est la même logique — vérifiez que /_next/static/ n'est pas bloqué.

Google Search Central recommande explicitement de ne pas bloquer les ressources nécessaires au rendu. Si vous avez des doutes sur ce que Google voit réellement de votre site, l'outil « Inspecter l'URL » dans la Search Console affiche le rendu Googlebot.

Erreur 5 — Laisser le robots.txt de recette en production

C'est la plus spectaculaire et la plus difficile à défendre en comité de direction.

Le scénario classique : pendant le développement, le site de recette bloque tout le crawl (Disallow: /) pour éviter l'indexation des pages de test. Au moment du go-live, le déploiement copie les fichiers — robots.txt inclus — et personne ne pense à le modifier.

Résultat : le site est en ligne, il reçoit des visites, les équipes fêtent le lancement — et Googlebot est bloqué depuis le premier jour.

Ce genre d'erreur peut passer des semaines sans être détecté, surtout si le site conserve un résidu de trafic direct ou payant. Ce n'est qu'au bout de plusieurs mois, quand les positions s'effondrent, qu'on remonte la cause.

💡 ASTUCE : Intégrez une vérification du robots.txt dans votre checklist de go-live. Une ligne suffit : ouvrir monsite.com/robots.txt et vérifier qu'il n'y a pas de Disallow: / global. Ensuite, tester l'URL de votre page d'accueil dans l'outil de test Search Console.

FAQ — Robots.txt SEO

Le robots.txt empêche-t-il Google d'indexer une page ?

Non. Le robots.txt bloque uniquement le crawl — pas l'indexation. Une page bloquée par robots.txt peut quand même apparaître dans les résultats si Google en connaît l'existence via un lien externe. Pour empêcher l'indexation, il faut utiliser une balise <meta name="robots" content="noindex"> dans le <head> de la page, ou un en-tête HTTP X-Robots-Tag: noindex.

Faut-il ajouter les pages de panier et de compte dans le robots.txt ?

Oui, c'est indispensable sur un e-commerce. Les pages /cart/, /account/, /checkout/, /wishlist/ n'ont aucune valeur SEO et gaspillent le budget de crawl de Googlebot. On les bloque avec des règles Disallow ciblées. Même logique pour les pages de confirmation de commande.

Le robots.txt est-il pris en compte immédiatement par Google ?

Non. Google met en cache le robots.txt jusqu'à 24 heures. Une modification n'est pas appliquée instantanément. Pour forcer une vérification plus rapide, utilisez l'outil de test de robots.txt dans la Google Search Console — il relit le fichier en temps réel.

Peut-on avoir plusieurs fichiers robots.txt sur un site ?

Non, un seul fichier robots.txt est autorisé par domaine, à la racine. Si votre site a des sous-domaines (blog.monsite.com, shop.monsite.com), chaque sous-domaine doit avoir son propre fichier robots.txt à sa racine. Un fichier placé en sous-dossier sera ignoré par les moteurs de recherche.

Conclusion

Le robots.txt est un fichier court, rarement modifié, facile à oublier — et c'est exactement pourquoi il cause autant de dégâts. Sur un site e-commerce avec un catalogue conséquent, une règle mal placée peut bloquer des milliers de pages ou laisser Googlebot s'épuiser sur des URL sans valeur.

Les trois réflexes à avoir :

• Tester le robots.txt à chaque déploiement — pas seulement au lancement
• Bloquer explicitement les pages sans valeur SEO (compte, panier, facettes, paramètres)
• Ne jamais confondre robots.txt (crawl) et noindex (indexation) — ce sont deux leviers distincts

Si vous n'avez pas relu votre robots.txt depuis plus de six mois, c'est le moment. L'outil de test Search Console + un crawl Screaming Frog vous donnent une image complète en moins d'une heure. Pour replacer cette vérification dans une démarche globale, consultez notre méthode d'audit technique SEO.