Agencia de SEO para Adobe Commerce Cloud

Adobe Commerce Cloud (antes Magento Commerce Cloud) es el nivel PaaS administrado de Adobe Commerce. El SEO difiere del de Magento de código abierto o de Adobe Commerce autoalojado en tres aspectos concretos: (1) restricciones de infraestructura: Cloud usa Fastly como CDN administrada y capa de caché de página completa, por lo que el comportamiento de los canónicos y de los encabezados Vary lo determina Fastly VCL, no Apache/Nginx; (2) programación de indexadores: Cloud ejecuta los indexadores con un cron fijo, así que las ventanas de purga de caché y reindexación afectan el contenido que ven los rastreadores; (3) cadencia de despliegue: el modelo de dos entornos de Cloud (staging, producción) y el flujo de integración vía Git condicionan cómo llegan los tickets de SEO. Diseñamos el SEO para ajustarse al entorno operativo de Cloud en lugar de pelear contra él.

1Digital® Agency tiene 15 años en Adobe Commerce / Magento: construimos, optimizamos y migramos en la plataforma desde 2012. Contamos con la confianza de más de 400 marcas y una calificación de 4.9/5 en más de 100 reseñas verificadas. Nuestro equipo cubre SEO, ingeniería de temas (Hyvä y Luma), desarrollo de módulos backend, arquitectura de catálogos B2B, ajuste de indexadores, ajustes de Fastly VCL y migraciones seguras para el SEO hacia y desde la plataforma.

Fastly funciona como CDN y como FPC en Adobe Commerce Cloud. Dos riesgos para el SEO: (1) las páginas en caché pueden servir etiquetas canónicas desactualizadas si el canónico de una página cambia después de llenar la caché; las purgas deben conectarse a eventos que afectan al canónico (mover una categoría, cambiar la clave de URL, reescribir el slug); (2) los encabezados Vary deben incluir solo las dimensiones que realmente cambian el contenido indexable, nunca cookies de sesión de usuario, o fragmentarás la caché y servirás a los rastreadores HTML por sesión. Auditamos el VCL, ajustamos las reglas de purga y verificamos que el HTML en caché coincida con lo que ve Googlebot mediante la Inspección de URL de Search Console.

Los indexadores de Magento (catalog_product_price, catalog_product_attribute, catalog_url, etc.) llenan las tablas planas y las tablas de reescritura de URL que impulsan el renderizado de PDP y categorías. Consecuencias para el SEO: (1) el indexador catalog_url es responsable de la consistencia de las reescrituras de URL: un indexador estancado puede dejar productos nuevos con URL tipo SKU en lugar de slugs amigables; (2) las cadenas de reescritura de URL se acumulan con el tiempo, así que cada cambio de nombre agrega un salto 301 y con el tiempo afecta el presupuesto de rastreo; (3) las ventanas de cron de los indexadores determinan cuándo aparecen en los sitemaps las categorías recién creadas. Programamos los indexadores para alinearlos con las ventanas de actividad de los rastreadores y depuramos las reescrituras de URL obsoletas cada trimestre.

Los productos configurables son el SKU padre; los productos simples son los SKU de las variantes. El comportamiento predeterminado de Magento crea una PDP padre indexable, con las variantes accesibles mediante menús desplegables y no como URL independientes, lo cual suele ser correcto para el SEO. Importan dos configuraciones: (1) "Use Default Value" para el manejo de canónicos por variante determina si las URL de variantes (cuando se habilitan explícitamente) apuntan con canónico al padre; deberían, salvo que las variantes sean realmente productos distintos por intención; (2) el esquema Product debe emitirse en el padre configurable con rangos de Offer (priceRange) o entradas Offer por variante dentro de un solo Product, no como Productos duplicados. Estandarizamos el esquema Product + arreglo de Offer a nivel de padre y deshabilitamos por defecto la indexación de URL de variantes.

La navegación por capas genera parámetros de URL (?color=blue&size=M) por defecto, la mayoría de los cuales no deberían indexarse. Patrones de SEO: (1) la etiqueta canónica en las URL filtradas apunta de vuelta a la categoría sin filtrar para evitar la canibalización por contenido duplicado; (2) las URL de filtros de "categoría de destino" incluidas selectivamente en una lista blanca (p. ej., /shoes/men o /shoes/blue-running) se promueven a páginas de categoría indexables con su propio meta, contenido y esquema; (3) se aplica robots.txt o meta-robots noindex,follow a las facetas no promovidas. En los catálogos B2B, la navegación por facetas suele necesitar un comportamiento que tenga en cuenta el grupo de clientes: los filtros visibles cambian por grupo, así que la estrategia de canónicos debe respetar el contexto del grupo.

Adobe Commerce B2B (nivel de licencia aparte) introduce catálogos específicos por cliente, catálogos compartidos, jerarquías de empresas, flujos de cotización y precios negociables. Estrategia de SEO: (1) el SEO del catálogo público cubre la superficie de marketing: categorías, productos principales y contenido; (2) el portal autenticado de compradores lleva noindex,nofollow para que Google no intente indexar páginas restringidas; (3) los catálogos compartidos (un catálogo por segmento de empresa) requieren fijar el canónico al catálogo público para evitar problemas de producto duplicado; (4) las URL de listas de requisición y de borradores de cotización siempre llevan noindex. Diseñamos el límite entre lo indexable y lo restringido y emitimos el meta-robots adecuado por ruta.

Adobe Commerce admite headless mediante las API REST y GraphQL, a menudo combinadas con Next.js, PWA Studio o Vue Storefront en el front end. La responsabilidad del SEO pasa del tema Luma/Hyvä al repositorio del front end headless. Seguimos el mismo manual de nuestro programa de SEO para comercio headless: estrategia de renderizado con SSR primero, orquestación del sitemap en el origen del front end, inyección de esquema a nivel de layout, despliegue de llms.txt y verificación de HTML equivalente al del rastreador. Los límites de tasa de la API de Adobe Commerce Cloud importan: almacenamos en caché las respuestas de GraphQL en el borde y regulamos el ritmo de los trabajos de generación del sitemap para mantenernos dentro de los límites del plan.

Sí. Hyvä es el stack de temas moderno basado en Tailwind/Alpine; Luma es el stack heredado de Knockout/RequireJS. Las diferencias de SEO son sobre todo de rendimiento: Hyvä normalmente entrega Core Web Vitals en verde desde el inicio (LCP por debajo de 2.5 s, INP por debajo de 200 ms, CLS por debajo de 0.1), mientras que Luma necesita optimización agresiva (empaquetado de RequireJS, aplazamiento de bindings de Knockout, extracción de la ruta crítica de CSS). Ambos pueden posicionarse; Hyvä lo hace más barato. Auditamos la salida del tema, el JS diferido y el CSS que bloquea el renderizado sin importar el stack, y entregamos un plan de mejora de CWV por plantilla.

Fase 1: auditoría técnica que cubre Fastly VCL, salud del calendario de indexadores, profundidad de las cadenas de reescritura de URL, topología de canónicos y hreflang, completitud del esquema Product, manejo de productos configurables, indexación de navegación por facetas y Core Web Vitals por plantilla. Fase 2: trabajo correctivo: ajuste de VCL, alineación del calendario de indexadores, reconstrucción del grafo de esquema, reglas de navegación por facetas y correcciones de CWV a nivel de tema (Hyvä o Luma). Fase 3: mapeo de palabras clave a categorías, briefs de contenido, optimización para motores de IA (llms.txt, PDP ricas en entidades) y seguimiento de citaciones. Las marcas que cambian de plataforma suelen combinar esto con una evaluación de migración de Magento a Shopify Plus; si Cloud es el hogar correcto, lo ajustamos para él.