En Magento/Adobe Commerce empezamos por identificar qué capa sirve el storefront público.
Revisamos Content → Design → Configuration
En la configuración correspondiente buscamos Search Engine Robots y verificamos después /robots.txt en el dominio real.
Default Robots no es el archivo robots.txt
Default Robots controla directivas de indexación de páginas; las reglas de crawling de robots.txt son otra capa. No mezclamos ambos conceptos.
Ecommerce necesita pruebas con URLs reales
Carrito, cuenta, búsqueda y navegación facetada pueden generar rutas muy distintas entre tiendas. No pegamos un blocklist genérico. Para parámetros usamos la guía de facetas.
Cloud cambia el contexto
En Adobe Commerce Cloud revisamos controles por entorno, sitemap y separación entre staging y producción.
PWA y headless pueden mover el ownership
Si un frontend PWA/headless o CDN sirve el host público, ese sistema puede ser quien realmente genere robots.txt. Un ajuste en Commerce Admin solo sirve si controla la respuesta pública.
Nuestro checklist incluye Content, Design, Configuration, Search Engine Robots, Default Robots, Cloud, sitemap, PWA/headless y verificación con el checker.
Adobe Commerce Cloud añade restricciones concretas
En Cloud, robots.txt puede generarse bajo demanda desde configuración y no depender de un archivo físico del repositorio. Sitemap y filesystem también tienen requisitos propios. Por eso, cuando la respuesta pública es incorrecta, primero determinamos si la controla Commerce, Fastly/CDN, PWA o el frontend headless antes de crear otro archivo.
Los entornos también se tratan por separado: producción debe tener la política de indexación prevista, mientras integration o staging no deberían heredarla accidentalmente. Verificamos robots.txt, sitemap, hostname y el estado de indexación de cada entorno.
Headless cambia las reglas de ownership
La documentación reciente de Adobe diferencia recomendaciones para storefront nativo y arquitecturas alternativas. En una PWA, las rutas de cart, account, filtros y search pueden no coincidir con Magento clásico. Mapeamos las URLs reales del frontend y configuramos la capa que sirve el host público. En instalaciones multi-store repetimos la auditoría por hostname y store view en lugar de asumir una política única.
