SEO en Magento 2: configuración y trampas del catálogo

Magento 2 no falla en SEO por defecto: falla porque expone de fábrica cada combinación de filtro, cada ruta de categoría y cada store view como una URL indexable distinta. Un catálogo mediano con ocho atributos filtrables puede generar cientos de miles de URLs técnicamente válidas y, en la práctica, duplicadas entre sí. Configurar el SEO de Magento 2 es decidir, en un puñado de ajustes concretos, qué parte de ese catálogo se abre a Google y cuál se cierra antes de que el rastreo se disperse.

Esta guía se centra en lo específico de Magento y Adobe Commerce: navegación por capas, ruta de categoría en la URL del producto, crecimiento de la tabla de reescrituras, ajustes de canonical y varios idiomas mediante store views. Shopify resuelve varias de estas cuestiones de forma opinada; PrestaShop tiene sus propias trampas. Magento da control total sobre cada pieza y, con él, la responsabilidad total: un ajuste mal entendido se convierte en miles de páginas que no debieron indexarse nunca.

Navegación por capas: el problema de las URLs infinitas

La navegación por capas es una razón habitual para elegir Magento y, sin ajustes, la primera fuente de URLs basura del sitio. Cada filtro que un visitante activa —color, talla, marca, rango de precio— añade parámetros a la URL de la categoría, y si el tema no controla esos enlaces, cada combinación queda rastreable en el HTML. Google no necesita un sitemap para descubrirlas: le basta seguir los enlaces de la propia página.

El problema no es solo el volumen. Cada una de esas URLs muestra casi siempre un subconjunto de los mismos productos que ya aparecen en la categoría base, con título y meta descripción prácticamente idénticos: contenido duplicado a escala, generado por tu propio catálogo, que compite por presupuesto de rastreo con las páginas que sí quieres posicionar.

No basta con bloquear estas URLs en robots.txt: si además dependes de un canonical hacia la categoría base, el bloqueo gana, porque Google no puede leer una etiqueta en una página que tiene prohibido descargar. Elige un mecanismo, no los dos peleando entre sí. En la mayoría de catálogos funciona mejor permitir el rastreo, apoyarse en el canonical para las combinaciones con más de un filtro activo, y reservar el bloqueo por patrón solo para los parámetros de ordenación.

• Cada atributo marcado como 'usar en navegación por capas' multiplica las combinaciones posibles con los demás atributos activos en esa categoría.
• Ordenación y paginación (product_list_order, product_list_dir, p=2, p=3) se combinan con cada filtro y multiplican otra vez el total.
• Los IDs de opción en la URL no son estables frente a reordenaciones del atributo, así que una misma combinación lógica puede acabar generando más de una URL con el tiempo.

La categoría en la URL del producto: qué implica cada opción

El ajuste 'Use Categories Path for Product URLs' decide si la URL de un producto es plana (/producto.html) o incluye la ruta de categoría (/categoria/subcategoria/producto.html). Parece cosmético, pero es una de las decisiones más costosas de revertir en un catálogo Magento ya en producción.

El motivo es la relación de muchos a muchos entre productos y categorías, nativa en Magento: un mismo producto puede vivir en varias categorías a la vez, algo habitual cuando un artículo está en 'Ofertas', en su categoría propia y en una colección de temporada. Con la ruta activada, cada asignación adicional genera una URL adicional para el mismo producto. Sin el canonical de producto activo, tienes varias URLs indexables sirviendo la misma ficha, y Google decide cuál mostrar, casi siempre peor que la elección que habrías hecho tú.

Hay un segundo efecto, menos visible pero más costoso: reorganizar el árbol —renombrar una categoría, mover una subcategoría, cambiar la url_key de un padre— obliga a regenerar la URL de cada producto que cuelga de ella. En un catálogo grande eso son decenas de miles de filas nuevas y, si el redireccionamiento automático no está bien configurado, un lote de URLs antiguas devolviendo 404.

• Si tus productos casi siempre viven en una sola categoría natural, la ruta de categoría aporta contexto semántico real.
• Si tu catálogo reutiliza productos entre muchas categorías promocionales y de temporada, la ruta multiplica duplicados más rápido de lo que aporta contexto.
• Si tu árbol de categorías todavía está cambiando, retrasa esta decisión: revertirla después de indexar miles de productos es una migración de URLs completa, no un cambio de configuración.

La tabla de URL rewrites: por qué crece sin control

Magento no guarda una URL por entidad: guarda una fila de reescritura por entidad y store view, y una fila adicional por cada categoría en la que un producto está asignado, si la ruta de categoría está activa, en cada store view. Un catálogo con 5.000 productos, tres store views y una media de dos categorías por producto no tiene 5.000 filas relevantes: tiene un múltiplo de eso, y cada reorganización añade más sin retirar automáticamente las que ya no sirven.

Cuando mueves un producto de categoría, Magento no borra la URL antigua sin más: si la redirección permanente está activada —y debería estarlo, para no perder el enlazado externo que ya apunta ahí—, la fila antigua se convierte en un 301 hacia la nueva. Esto es correcto y deseable. El problema aparece cuando el proceso se repite varias veces sobre el mismo producto sin que nadie revise el resultado: acabas con cadenas de redirección, donde cada salto adicional diluye ligeramente la señal y ralentiza el rastreo.

Las importaciones masivas son la otra fuente habitual de bloat. Un CSV de categorías ejecutado con el modo equivocado puede dejar asignaciones huérfanas, filas autogeneradas que ya no corresponden a ninguna combinación real, o duplicados con el mismo request_path apuntando a entidades distintas, algo que aparece cuando la importación se ejecuta en varias tandas sin reindexar entre medias.

La corrección no es borrar filas al azar: es reindexar tras cada reorganización grande, aplanar las cadenas de más de un salto a un único redireccionamiento, y tratar toda importación de categorías como una operación que necesita verificación posterior, no solo ejecución.

• El indexador de reescrituras de URL tarda visiblemente más que hace unos meses en un catálogo que no ha crecido tanto.
• Aparecen en Search Console URLs 404 de productos que sabes que siguen activos: señal de una redirección rota o de una cadena demasiado larga.
• Al exportar la tabla encuentras más de una fila activa para el mismo request_path.

Canonical: qué activar en categorías y en productos

Magento separa el canonical de categorías del canonical de productos en dos ajustes independientes, y es habitual que un sitio tenga uno activo y el otro no, simplemente porque nadie revisó el segundo después de configurar el primero.

Con el canonical de categorías activo, cualquier variante filtrada, ordenada o paginada de una categoría declara como canonical la URL base de esa categoría, la página uno sin filtros. Esto no reduce el rastreo —Google sigue visitando esas URLs mientras existan enlaces internos hacia ellas—, pero evita que se indexen como páginas independientes que compiten por las mismas consultas que la categoría principal.

Con el canonical de productos activo, y sobre todo si la ruta de categoría está en la URL, cada producto debería declarar una única URL canónica aunque sea accesible desde varias categorías distintas. No te fíes solo del nombre del ajuste: la lógica de qué URL exacta se marca como canónica ha cambiado entre versiones de Magento, y algunos temas personalizados sobrescriben el bloque que la renderiza sin que nadie lo note durante meses. La forma fiable de comprobarlo es rastrear tu propio sitio, entrar en fichas de producto accedidas desde categorías distintas, y confirmar que el rel canonical del código fuente es siempre la misma URL, no la ruta por la que acabas de entrar.

• Las páginas con filtros declaran canonical hacia la categoría base; las páginas paginadas, en cambio, deberían apuntar a sí mismas, como recomienda Google.
• Un mismo producto, visitado desde dos categorías distintas, declara exactamente la misma URL canónica en ambos casos.
• El canonical no cambia según parámetros de sesión o de store switcher.
• Ningún override de tema ha eliminado silenciosamente la etiqueta al personalizar el head del documento.

Store views multilenguaje: URLs, dominios y hreflang

Magento organiza el multilenguaje mediante website, store y store view, y esa jerarquía condiciona directamente cómo se ven tus URLs y qué tienes que construir a mano para que la señal de idioma llegue a Google correctamente, porque el núcleo de Magento no la genera solo.

La primera decisión es si el idioma vive en la URL o en el dominio. Activando 'Add Store Code to Urls' obtienes rutas como /es/producto.html y /en/producto.html bajo el mismo dominio, sencillo de desplegar, pero hay que revisar que ningún enlace interno se genere sin el código de store view, porque eso crea la misma página accesible con y sin prefijo. La alternativa es asignar un dominio o subdominio distinto como base URL de cada store view, lo que da URLs más limpias por idioma pero traslada la complejidad al servidor web y al DNS, con certificados y configuración de caché por dominio.

La segunda decisión, y la que más se pasa por alto, es el hreflang. Magento no emite etiquetas hreflang de fábrica en ninguna versión reciente del núcleo: es una idea extendida que sí lo hace, y no es cierto. Si quieres que Google entienda que la ficha en español y la ficha en inglés de un mismo producto son versiones alternativas entre sí, alguien tiene que añadir esas etiquetas mediante una plantilla personalizada o un módulo pequeño que recorra los store views activos de esa entidad. Esto solo funciona si el producto está realmente asignado al store view de destino: si un artículo existe en español pero nunca se asignó al website en inglés, no hay URL equivalente a la que enlazar, y una referencia hreflang rota es peor que no tener hreflang en absoluto, porque le dice a Google que existe una alternativa que en realidad no carga.

Conviene además que cada store view que representa un mercado distinto tenga su propia categoría raíz. Reutilizar la misma raíz de categorías entre store views que deberían mostrar catálogos distintos produce el mismo problema de fondo que la navegación por capas: contenido duplicado, solo que esta vez a nivel de estructura de categorías completa.

• Decide código de store view en la URL frente a dominio propio antes de indexar contenido, no después.
• Implementa hreflang de forma explícita; no asumas que Magento lo hace.
• Genera y envía un sitemap independiente por store view; Magento lo permite de forma nativa en la configuración de Site Map.
• Asigna una categoría raíz propia a cada store view que represente un catálogo o mercado distinto.
• Verifica que el canonical no colapsa accidentalmente las versiones en distintos idiomas hacia una sola URL.

Otros focos de indexación que Magento crea solo

Más allá del catálogo y la navegación por capas, Magento genera por sí mismo otras familias de URLs que conviene revisar. Las páginas de resultados de búsqueda interna (catalogsearch/result/index) son rastreables y, salvo que se configuren explícitamente como noindex, terminan indexadas como páginas de contenido casi vacío para miles de consultas internas de usuarios: exactamente el tipo de página fina que perjudica la percepción de calidad de todo el dominio.

Los parámetros del selector de tienda (___store, ___from_store) que Magento añade cuando un visitante cambia manualmente de store view generan una variante con parámetro de una URL que, sin ese parámetro, es exactamente la misma página. Si un enlace interno o un widget arrastra ese parámetro de forma persistente, acabas con una segunda versión indexable de cada página del sitio, distinguible solo por una cadena de consulta.

El robots.txt que trae Magento de fábrica ya bloquea algunos de estos patrones, pero está pensado como punto de partida, no como configuración final: cada catálogo genera sus propias combinaciones problemáticas según qué atributos son filtrables y qué extensiones de terceros añaden parámetros propios. El informe de indexación de páginas de Search Console, en el motivo 'Duplicada: Google eligió una URL canónica distinta de la indicada por el usuario', es el sitio más fiable para ver qué combinaciones está indexando realmente Google frente a las que tú crees haber resuelto con la configuración.

Rutina de mantenimiento para un catálogo Magento limpio

Nada de lo anterior es una configuración que se hace una vez y se olvida, porque el catálogo sigue cambiando después del lanzamiento. Tras cualquier reorganización grande de categorías o importación masiva, conviene reindexar y comprobar manualmente que la tabla de reescrituras no dejó duplicados ni cadenas de redirección de más de un salto para las URLs que cambiaron.

De forma periódica, no solo tras un cambio puntual, tiene sentido rastrear el propio sitio con una herramienta externa y comparar las URLs canónicas declaradas contra las que Search Console reporta como indexadas, prestando atención especial al crecimiento del grupo de duplicados con canonical distinto al declarado, que suele ser la primera señal de que la navegación por capas o los store views están generando más variantes de las previstas.

Por último, trata el ajuste de ruta de categoría en la URL del producto como una decisión bloqueada una vez tomada: revertirla después de indexar el catálogo no es cambiar una casilla, es planificar una migración completa de URLs con su correspondiente mapa de redirecciones, y merece el mismo cuidado que un cambio de dominio.