Avec Magento/Adobe Commerce, nous identifions d’abord la couche qui sert le storefront public.
Nous partons de Content → Design → Configuration
Dans le bon store view, nous vérifions Search Engine Robots, puis la réponse /robots.txt sur le domaine réel.
Default Robots est une autre couche
Default Robots définit les directives d’indexation des pages ; ce n’est pas le fichier de contrôle du crawl.
Ecommerce demande des tests d’URL réelles
Recherche interne, panier, compte et facettes varient selon la boutique. Nous évitons les blocklists génériques et utilisons le guide des paramètres.
Cloud change le contexte de déploiement
Dans Adobe Commerce Cloud, nous contrôlons séparation des environnements, sitemap et politique d’indexation entre staging et production.
PWA/headless peut déplacer l’ownership
Si un frontend PWA/headless ou CDN sert le domaine public, cette couche peut posséder /robots.txt. Nous vérifions Cloud, PWA/headless et le fichier live avec le checker.
Adobe Commerce Cloud change le diagnostic
Sur Cloud, robots.txt peut être généré à la demande depuis la configuration, sans fichier physique dans le dépôt. Sitemaps et filesystem ont aussi leurs propres contraintes. Si la réponse live est incorrecte, nous déterminons d’abord si Commerce, Fastly/CDN, PWA ou frontend headless possède le host public.
Production, staging et integration ne doivent pas partager aveuglément la même politique d’indexation. Nous vérifions robots.txt, sitemap, hostname et état d’indexation pour chaque environnement.
Headless et multi-store exigent un audit par host
La documentation Adobe récente distingue storefront natif et solutions alternatives. Une PWA peut avoir des routes cart, account, search et filtres différentes de Magento classique. Nous mappons les URL du frontend réel et configurons la couche qui sert la réponse publique. Avec plusieurs websites/store views, nous répétons l’audit par hostname.
Nous testons les vrais types d’URL ecommerce
La validation ne s’arrête pas à la syntaxe. Nous testons produit, catégorie, recherche interne, filtres, panier, compte et au moins une URL avec paramètres. Puis nous vérifions quelle couche a servi /robots.txt et si canonical/noindex restent cohérents avec la politique de crawl. Un blocage générique ne doit pas économiser du crawl au prix de pages commerciales importantes.