Si votre boutique Magento passe par Cloudflare, c’est le moment de vérifier votre configuration. Mais posons tout de suite la vraie question : avez-vous réellement besoin de Cloudflare pour filtrer vos bots ?

Ce que Cloudflare va changer, en bref

Cloudflare proposait jusqu’ici une case unique « bloquer les bots IA », qui regroupait sans distinction l’entraînement de modèles et le crawling de recherche. Cloudflare a annoncé le remplacement de cette case par des contrôles plus granulaires — mais les sites ayant déjà activé l’ancien blocage global verront, à partir du 15 septembre 2026, Googlebot et les autres crawlers multi-usages bloqués avec le reste (source : blog officiel Cloudflare, 1er juillet 2026). Sur une boutique e-commerce, ça touche l’indexation de tout le catalogue produit — pas seulement quelques pages.

Ce changement ne concerne, par nature, que les boutiques qui utilisent Cloudflare comme couche de filtrage devant leur infrastructure. Et c’est là que la question devient intéressante : toutes les boutiques Magento n’en ont pas besoin.

Cloudflare n’est pas la seule façon de filtrer les bots

Cloudflare est une solution pratique, mais ce n’est pas la seule architecture possible pour se protéger du trafic indésirable — scraping agressif, bots malveillants, tentatives d’intrusion — tout en laissant passer sans ambiguïté les moteurs de recherche légitimes. Une infrastructure Magento bien pensée peut assurer ce filtrage directement au niveau du serveur, sans dépendre d’une couche tierce et de ses décisions de configuration.

Un point mérite d’être clarifié, car il change beaucoup la donne financière : ce que la plupart des sites utilisent sur Cloudflare (Bot Fight Mode en gratuit, Super Bot Fight Mode sur les formules Pro à 20 $/mois ou Business à 200 $/mois) reste un filtrage relativement basique — un interrupteur qui challenge les bots détectés, sans règles fines par endpoint ni score de risque par requête. Le vrai filtrage granulaire, avec scoring de bot et règles personnalisées, correspond au produit « Bot Management », qui est réservé aux contrats Enterprise — sans palier intermédiaire en libre-service (source : documentation officielle Cloudflare, developers.cloudflare.com/bots/). Ces contrats Enterprise démarrent généralement autour de plusieurs milliers de dollars par mois, négociés au cas par cas. Autrement dit, un filtrage de bots réellement fin sur Cloudflare n’est pas à la portée d’un simple upgrade de formule à 20 ou 200 $ : c’est un saut budgétaire nettement plus important.

Ce qu’implique un filtrage HAProxy bien conçu

Sans entrer dans le détail des règles — chaque infrastructure a ses propres contraintes et ce n’est pas quelque chose qui se généralise dans un article de blog — voici les grands principes d’une architecture de filtrage efficace au niveau du reverse proxy :

• Distinguer les bots par leur comportement réel, pas seulement par leur nom déclaré — un attaquant peut se faire passer pour Googlebot, tandis qu’un vrai Googlebot a des plages d’IP vérifiables.
• Cibler les sources de trafic abusif identifiées (plages d’hébergeurs cloud utilisées pour du scraping massif, bots connus) sans jamais toucher aux crawlers légitimes des moteurs de recherche.
• Faire évoluer les règles en continu — les sources de trafic indésirable changent, une configuration figée devient obsolète en quelques mois.
• Garder une visibilité complète via les logs, pour vérifier objectivement ce qui est bloqué et ce qui passe, plutôt que de faire confiance à une case à cocher opaque.

C’est un travail de configuration fine et de suivi dans le temps — pas un réglage qu’on fait une fois et qu’on oublie. C’est exactement le type d’accompagnement qu’on assure sur les infrastructures Magento qu’on gère : un filtrage efficace, sans dépendre d’un acteur tiers et de ses choix de politique produit.

Le paramétrage Magento qui complète l’architecture serveur

Le filtrage réseau ne suffit pas seul : la structure de vos URLs et vos directives d’exploration comptent tout autant pour un bon référencement. Sur les boutiques équipées de modules de navigation par filtres et de SEO avancé — Amasty Layered Navigation et Mageworx SEO Ultimate en tête — plusieurs points méritent une attention régulière :

Alors, faut-il utiliser Cloudflare sur toutes les boutiques Magento ?

Non, sûrement pas de façon systématique. Cloudflare est un bon outil pour certains contextes — notamment quand on veut une mise en place rapide sans expertise serveur poussée en interne — mais ce n’est pas une nécessité universelle. Il existe d’autres moyens tout aussi efficaces pour filtrer le trafic indésirable, avec l’avantage de rester entièrement maîtrisés par vous, sans dépendre des choix de configuration d’un tiers qui peuvent, comme le 15 septembre le montre, changer avec des conséquences inattendues sur votre référencement.

Le bon choix dépend de votre contexte : taille de l’infrastructure, ressources techniques disponibles, niveau de menace réel sur votre boutique. Ce qui compte, dans tous les cas, c’est que la décision soit prise consciemment — pas héritée d’une configuration mise en place il y a longtemps et jamais revue depuis.

FAQ

Comment savoir si ma boutique utilise Cloudflare ?

Le plus simple : vérifier les serveurs DNS de votre domaine, ou regarder si les en-têtes de réponse HTTP de votre site mentionnent Cloudflare. Si c’est le cas, vérifiez dans le dashboard Cloudflare la configuration de gestion des bots avant le 15 septembre 2026.

Migrer de Cloudflare vers un filtrage HAProxy, c’est un gros chantier ?

Ça dépend entièrement de l’infrastructure existante et du niveau de filtrage actuellement en place côté Cloudflare. Ce n’est pas une réponse générique — chaque cas nécessite un audit préalable pour évaluer l’effort réel et la meilleure trajectoire de migration.

Sans Cloudflare, ma boutique est-elle plus vulnérable ?

Pas nécessairement — tout dépend de la qualité de la configuration mise en place au niveau serveur. Une architecture de filtrage bien conçue et activement maintenue peut offrir un niveau de protection tout à fait comparable, avec l’avantage d’un contrôle total sur les règles appliquées.

L’article Cloudflare va bloquer Googlebot avec les bots IA si vous ne faites pas ça avant le 15 septembre est apparu en premier sur eBusiness360.

Voici comment comprendre ces métriques, identifier les causes sur Magento, et mettre en place les leviers qui font vraiment bouger l’aiguille.

Les trois métriques Core Web Vitals en 2026

Google mesure trois aspects distincts de l’expérience utilisateur. Chacun a un seuil « bon », « à améliorer » et « mauvais » :

LCP — le plus impactant pour Magento

Le LCP mesure le temps avant que le plus grand élément visible de votre page soit affiché. Sur une boutique Magento, c’est souvent l’image principale d’un produit, le banner de la homepage ou le logo. Un mauvais LCP est presque toujours lié à l’une de ces causes :

• Images non optimisées — des photos produit de 3 Mo servies sans compression ni conversion WebP
• Absence de Varnish ou cache full-page — PHP doit générer la page à chaque requête, ajoutant 1 à 3 secondes
• Ressources bloquantes — des fichiers CSS ou JS chargés en synchrone qui retardent l’affichage
• Serveur trop lent — un TTFB supérieur à 800ms plombe mécaniquement le LCP

Le levier numéro un : activer Varnish et convertir les images en WebP. Ces deux actions seules peuvent diviser votre LCP par deux sur la plupart des boutiques Magento.

INP — la métrique que Magento rate souvent

L’INP remplace le FID depuis mars 2024. Il mesure la réactivité de votre page aux interactions utilisateur — un clic sur un bouton « Ajouter au panier », une saisie dans le champ de recherche, un filtre de catégorie. Si votre page met plus de 200ms à réagir après une interaction, votre INP est dégradé.

Sur Magento, les coupables habituels sont les bibliothèques JavaScript volumineuses chargées sur toutes les pages, les extensions tierces qui ajoutent des scripts lourds, et le JavaScript de tracking (Google Analytics, pixels publicitaires) mal configuré. Le thème joue un rôle crucial : Breeze et Hyvä sont nativement bien meilleurs que les thèmes classiques basés sur RequireJS sur cette métrique.

CLS — l’ennemi des images sans dimensions

Le CLS mesure les décalages visuels pendant le chargement — ces moments frustrants où vous allez cliquer sur un lien et la page bouge au dernier moment. Sur Magento, la cause la plus fréquente est simple : des images HTML sans attributs width et height explicites.

Sans ces dimensions, le navigateur ne réserve pas d’espace pour l’image avant qu’elle soit chargée. Quand l’image arrive, elle pousse le contenu existant vers le bas — c’est exactement ce que mesure le CLS. La correction est simple : s’assurer que toutes les images générées par Magento incluent leurs dimensions dans le HTML.

Breeze et Hyvä — pourquoi ils changent la donne

Les thèmes Magento classiques (Luma, Porto, et la plupart des thèmes marketplace) héritent d’une architecture JavaScript basée sur RequireJS qui charge des dizaines de modules même quand ils ne sont pas nécessaires sur la page courante. C’est structurellement lourd et difficile à optimiser sans réécrire le thème.

Breeze est un frontend alternatif qui remplace la couche JS de Magento par une implémentation légère, sans RequireJS. Il est compatible avec les thèmes existants (Porto, Argento…) et s’installe sans refonte complète. Hyvä va plus loin en remplaçant entièrement le frontend par une stack Alpine.js + Tailwind CSS — scores PageSpeed spectaculaires, mais migration plus lourde.

Pour une boutique qui cherche à améliorer ses Core Web Vitals sans refonte complète, Breeze est souvent le meilleur rapport effort/résultat.

Comment mesurer et suivre vos scores

L’outil de référence est PageSpeed Insights (pagespeed.web.dev). Il affiche deux types de données : les données de terrain (CrUX — mesures réelles sur vos vrais visiteurs sur 28 jours) et les données lab (mesure simulée sur la requête du moment). Google utilise les données terrain pour le ranking — c’est donc ces chiffres qui comptent pour le SEO.

Mesurez systématiquement trois pages : votre homepage, une page catégorie et une fiche produit. Les problèmes ne sont pas toujours les mêmes selon le type de page. Et mesurez toujours en mobile — c’est la version que Google utilise en priorité (mobile-first indexing).

FAQ

Un bon score PageSpeed améliore-t-il directement le classement Google ?

C’est un signal parmi d’autres — Google a confirmé que les Core Web Vitals sont un facteur de classement, mais un facteur de départage entre des pages de pertinence similaire. Un contenu très pertinent avec un mauvais score peut encore se classer au-dessus d’un contenu médiocre avec un excellent score. En revanche, à pertinence égale, les Core Web Vitals font la différence — et ils impactent directement le taux de rebond et la conversion, indépendamment du SEO.

Mon score est bon en desktop mais mauvais en mobile — lequel corriger en priorité ?

Le mobile, sans hésitation. Google indexe et classe les sites selon leur version mobile depuis 2019 (mobile-first indexing). Le score desktop est utile pour diagnostiquer, mais c’est le mobile qui compte pour le SEO et qui représente plus de 60% du trafic e-commerce en France.

L’article Core Web Vitals sur Magento 2 : guide pour passer au vert en 2026 est apparu en premier sur eBusiness360.

Voici les dix erreurs que l’on retrouve le plus souvent lors de nos audits SEO techniques sur des boutiques Magento 2.

1. Les URL canoniques mal configurées

Magento génère souvent plusieurs URL pour accéder à un même produit : via sa catégorie, via une autre catégorie, via une recherche… Pour Google, ce sont des pages différentes qui se font concurrence. La balise canonical indique à Google quelle est la « vraie » URL à indexer.

Le problème : par défaut, Magento ajoute des canonicals, mais ils peuvent pointer vers des URL incorrectes selon la configuration des catégories. Le correctif : vérifier dans Stores → Configuration → Catalog → Search Engine Optimization que les options « Use Canonical Link Meta Tag for Categories » et « …for Products » sont bien activées, et auditer les canonicals générés avec un outil comme Screaming Frog.

2. Le duplicate content lié aux store views

Si votre boutique a plusieurs store views (par exemple une version française et une version anglaise sur le même domaine), Magento peut exposer le même contenu sur des URL différentes. Google pénalise ce type de duplication.

Le correctif : s’assurer que chaque store view dispose de sa propre balise hreflang correctement configurée, et que les canonicals de chaque store view pointent bien vers leur propre URL et non vers le store view par défaut.

3. Le fichier robots.txt trop restrictif

Magento génère un robots.txt par défaut qui bloque un certain nombre de chemins. Le problème survient quand ce fichier est mal configuré : soit trop permissif (Google indexe des pages techniques sans intérêt), soit trop restrictif (Google ne peut plus accéder à des pages importantes).

Ce qu’on voit souvent : des boutiques qui bloquent accidentellement des URLs de catégories ou de produits suite à une mauvaise règle dans robots.txt. Le correctif : vérifier le contenu du fichier via votre-domaine.fr/robots.txt et tester les URL importantes dans Google Search Console → Inspection d’URL.

4. La pagination non gérée correctement

Les pages de catégories paginées (/category.html?p=2, ?p=3…) peuvent poser problème si elles sont toutes indexables sans directive particulière. Google peut diluer le « jus SEO » d’une catégorie sur 20 pages au lieu de le concentrer sur la page principale.

Le correctif : ajouter une balise canonical sur les pages paginées qui pointe vers la page 1, ou utiliser la directive rel="next" / rel="prev" si votre version de Magento la supporte encore. Vérifier aussi que les paramètres de tri et de filtre (?product_list_order=price) ne génèrent pas des milliers d’URL distinctes indexées.

5. Les images sans attribut alt

Magento permet de renseigner un attribut alt pour chaque image produit, mais il n’est pas obligatoire. Résultat : des catalogues entiers avec des centaines d’images sans description textuelle. Google ne peut pas « voir » une image — il lit l’attribut alt pour comprendre ce qu’elle représente.

Le correctif : renseigner systématiquement le champ « Image Alt Text » dans la fiche produit Magento. Sur un catalogue volumineux, un script d’import ou une mise à jour en masse via le back-office peut accélérer le travail.

6. Les redirections en chaîne

Magento crée automatiquement des redirections 301 à chaque modification d’URL (renommage de produit, déplacement de catégorie…). Au fil du temps, ces redirections s’accumulent et forment des chaînes : A redirige vers B, qui redirige vers C, qui redirige vers D. Google suit ces chaînes, mais elles lui coûtent des ressources et diluent légèrement le signal SEO.

Le correctif : auditer régulièrement les URL Rewrites dans Marketing → SEO and Search → URL Rewrites, supprimer les doublons obsolètes, et s’assurer que toutes les redirections pointent directement vers la destination finale.

7. Le sitemap XML non soumis ou mal configuré

Magento génère un sitemap.xml automatiquement si vous le configurez — mais beaucoup de boutiques l’ont activé sans jamais le soumettre à Google Search Console, ou avec des paramètres qui incluent des URL inutiles (pages de compte client, pages de panier…).

Le correctif : configurer le sitemap dans Marketing → SEO and Search → Site Map, vérifier les URL incluses, générer le fichier, et le soumettre dans Google Search Console → Sitemaps. Prévoir une génération automatique planifiée.

8. Les balises title et meta description génériques

Par défaut, Magento construit les balises title à partir du nom du produit et du nom du site. C’est fonctionnel, mais pas optimisé : toutes les pages ont des titles au même format, souvent trop courts ou trop génériques pour se démarquer dans les résultats de recherche.

Le correctif : personnaliser le format des titles via Stores → Configuration → Catalog → Search Engine Optimization, et renseigner manuellement les meta descriptions sur les pages stratégiques (homepage, catégories principales, best-sellers).

9. La vitesse de chargement négligée

Google intègre la vitesse de chargement dans son algorithme depuis 2021, et les Core Web Vitals sont désormais un signal de classement officiel. Une boutique Magento sans cache full-page Varnish, sans Redis, et avec des images non optimisées peut facilement afficher des scores PageSpeed catastrophiques.

Le correctif : activer le cache full-page Magento (Varnish en production), compresser et convertir les images en WebP, activer la minification JS/CSS dans Stores → Configuration → Advanced → Developer, et mesurer régulièrement avec PageSpeed Insights.

10. Le contenu produit dupliqué avec les fournisseurs

Si vous utilisez les descriptions produits fournies par vos fournisseurs telles quelles, vous partagez exactement le même contenu que des dizaines — parfois des centaines — d’autres boutiques qui vendent les mêmes produits. Google ne sait plus quelle boutique mérite d’être mise en avant.

Le correctif : réécrire au moins les descriptions des produits les plus importants en termes de chiffre d’affaires. Même une réécriture partielle (titre original + quelques phrases supplémentaires) suffit à différencier votre contenu. C’est un travail de fond, mais son impact sur le long terme est significatif.

Par où commencer ?

Si vous découvrez plusieurs de ces problèmes sur votre boutique, ne cherchez pas à tout corriger en même temps. La priorité va aux erreurs à impact fort : les canonicals, le duplicate content et la vitesse de chargement sont les trois leviers qui ont le retour sur investissement le plus rapide.

Un audit SEO technique complet permet d’identifier exactement quelles erreurs sont présentes sur votre boutique, dans quelle proportion, et dans quel ordre les traiter selon votre trafic actuel.

L’article SEO Magento 2 : les 10 erreurs techniques qui plombent votre référencement est apparu en premier sur eBusiness360.