Skip to main content
← Recursos
SEO9 min de lectura

La mayoría de tiendas Shopify pierden revenue por SEO técnico que no pueden ver.

Canonical Tags en Shopify: lo que la plataforma resuelve sola y dónde se rompe

Shopify resuelve bien los canonicals por defecto, hasta que los links internos, los productos en múltiples colecciones o el schema inyectado por apps empiezan a fragmentar el link equity en silencio. Los tres patrones de falla que vemos en casi toda auditoría, y cómo cerrarlos.

Actualizado 21 de mayo de 2026

Trabajamos típicamente con tiendas Shopify y Shopify Plus con $500k+ en revenue anual.

Samuel Noriega
Por

Publicado

CompartirXLinkedIn

Shopify hace un trabajo razonable gestionando los canonical tags por defecto. La mayoría de los merchants nunca los tocan. La mayoría tampoco se entera cuando dejan de funcionar bien. La lógica automática de la plataforma cubre los casos comunes lo suficientemente bien como para que los problemas de canonicals permanezcan invisibles, hasta que aparecen en un reporte de Google Search Console lleno de avisos del tipo "Duplicada, Google eligió un canonical distinto al declarado", o como una meseta de rankings que ningún esfuerzo de contenido logra mover.

Entender dónde terminan los defaults de Shopify y dónde empiezan las fallas no es opcional para tiendas que operan a escala.

Cómo asigna Shopify los canonicals por defecto

Cada tema construido sobre el framework Liquid oficial de Shopify imprime un canonical tag usando el objeto global canonical_url. Ese objeto resuelve a la URL limpia de la página, sin parámetros, sin importar cómo llegó el visitante. La documentación de Liquid de Shopify lo describe como "la URL por defecto de la página con todos los parámetros eliminados".

En la práctica, esto significa que las páginas de producto siempre canonicalizan al formato /products/[handle]. Si un visitante llega al producto vía una colección, la URL en el navegador queda como /collections/oferta-verano/products/sneaker-azul, pero el canonical en el <head> sigue apuntando a /products/sneaker-azul. Esa parte Shopify la resuelve bien.

Los parámetros de variantes se manejan igual. Cuando un cliente selecciona talla o color, el JavaScript añade ?variant=12345678 a la URL del navegador. El canonical lo ignora por completo y sigue apuntando a la raíz limpia. Ese comportamiento es correcto: las variantes no son páginas separadas, y el canonical evita que Google interprete cada combinación de parámetros como contenido único.

Hasta aquí, todo bien. Los problemas aparecen en tres puntos específicos.

El canonical tag es una señal, no una regla. Google lo trata como una recomendación fuerte, pero puede ignorarlo (y de hecho lo hace) cuando se acumulan señales contradictorias. Una de las más fuertes es un patrón de links internos que apuntan a una URL distinta a la declarada como canonical.

Los temas de Shopify, incluyendo el oficial Dawn, generan los links a producto desde las páginas de colección usando el filtro Liquid product.url | within: collection. Ese filtro produce la URL alcance-de-colección: /collections/oferta-verano/products/sneaker-azul. Cada tarjeta de producto en cada página de colección está linkeando a una URL no canónica. El canonical dice "confía en /products/sneaker-azul", pero el grafo interno de links del sitio dice "este producto vive en /collections/oferta-verano/products/sneaker-azul".

Google pondera las dos señales. Cuando un producto vive en cinco colecciones, tiene cinco URLs internas distintas compitiendo con el canonical. El link equity se fragmenta entre esas variaciones. El canonical pierde peso como señal precisamente porque la arquitectura del sitio apunta en otra dirección. Arreglarlo implica editar el template de colección en los archivos Liquid del tema para quitar el filtro within: collection, de modo que los links de producto resuelvan al path limpio /products/.

Falla 2: productos en múltiples colecciones

Un producto que aparece en más de una colección agrava el problema anterior, pero introduce uno adicional y más específico: dilución de link equity.

Cada colección a la que pertenece un producto genera su propia URL rastreable. Un producto en tres colecciones crea tres URLs adicionales más allá de la canónica. Los buscadores las descubren todas vía links internos, crawl del sitemap, y backlinks externos que pueden caer en URLs alcance-de-colección (algo especialmente común cuando se comparten URLs de colección filtradas en campañas de email o ads). Hemos auditado tiendas donde un solo producto estrella tenía más de diez URLs rastreables generadas únicamente por su pertenencia a colecciones.

El canonical apunta todas esas URLs a /products/sneaker-azul. En teoría, Google consolida el link equity. En la práctica, no siempre lo hace, especialmente cuando esas URLs no canónicas han acumulado backlinks externos o cuando el patrón de crawl sugiere que son el destino más enlazado.

El resultado es que la página que Google realmente rankea puede no ser la que tiene la autoridad consolidada más fuerte. Los rankings sufren. El tráfico se concentra en la variante equivocada. La solución combina arreglar los links internos (como arriba) y auditar qué backlinks externos apuntan a URLs alcance-de-colección, para decidir si se justifica meter 301s hacia la ruta canónica.

Falla 3: apps que introducen structured data en conflicto

Esta se discute menos pero aparece en casi toda auditoría que hacemos sobre tiendas con cuatro o más apps activas.

Los temas de Shopify incluyen schema JSON-LD básico de producto por defecto. Cuando los merchants instalan apps de SEO, de reviews, o de product feeds, esas apps frecuentemente inyectan sus propios bloques de structured data en las mismas páginas. El resultado son dos o más bloques de schema Product en una sola URL, a veces con @id distintos, precios diferentes, o señales de disponibilidad que no coinciden.

Esto no es lo mismo que contenido duplicado en el sentido tradicional. Los conflictos de structured data son un problema aparte. Cuando el crawler de Google encuentra dos bloques Product en una página con referencias @id distintas, tiene que decidir cuál creer. En muchos casos rechaza ambos, y la tienda pierde elegibilidad para rich results por completo. El conflicto también puede encadenarse: una app de reviews que inyecta un bloque aggregateRating atado a la URL alcance-de-colección genera una situación donde el identificador del structured data no coincide con la URL canónica declarada, lo cual es a su vez una señal blanda que Google usa al evaluar la autoridad del canonical.

El proceso de auditoría aquí es directo. Pasa cada URL de producto por el Rich Results Test de Google. Si la herramienta detecta más de un bloque Product, investiga qué app está inyectando el duplicado y configura la app para deferir al markup que ya emite el tema, o desactiva la salida de schema de esa app.

Cómo auditar la salud de tus canonicals

Dos herramientas cubren bien este trabajo.

El modo de auditoría de canonicals de Screaming Frog crawlea el sitio y devuelve un reporte mostrando los canonicals declarados, los seguidos, y cualquier mismatch entre ambos. Configúralo para renderizar JavaScript (porque algunas apps inyectan el canonical vía JS y no en el HTML del servidor) y corre el crawl contra la URL de producción completa. Filtra el output por páginas donde las columnas "Canonical" y "Self Referencing Canonical" difieren. Cualquier URL de producto donde el canonical resuelve a un path alcance-de-colección es una falla confirmada.

Ahrefs Site Audit hace una verificación similar pero añade una dimensión particularmente útil: cruza los canonicals con el grafo de crawl, así puedes ver cuáles URLs no canónicas han acumulado backlinks. Eso identifica si necesitas una estrategia de redirects encima del fix de links internos.

Ambas herramientas surfacean el patrón "Alternate page with proper canonical tag" que reporta Google Search Console. Si esa cuenta está creciendo en tu reporte de Coverage de GSC, las tres fallas de arriba son las culpables más probables.

Un hallazgo real de una auditoría de Shugert

Corrimos una auditoría técnica para una marca DTC de apparel en EE. UU. operando en Shopify Plus. Su tienda tenía 340 productos activos, cada uno organizado en un promedio de cuatro colecciones (drops estacionales, colecciones por categoría, colecciones de sale, y una colección rotativa de "novedades"). Eso significa que el crawler descubrió más de 1,300 URLs de producto alcance-de-colección además de las 340 canónicas.

Los links internos desde colecciones usaban el filtro within: collection. La tienda tenía dos apps de SEO instaladas en paralelo: una inyectaba schema de producto desde el tema, y una segunda app de reviews añadía su propio bloque Product con un aggregateRating anidado. El @id del bloque de la app de reviews referenciaba la URL alcance-de-colección, no la canónica.

GSC mostraba 1,200+ URLs en estado "Alternate page with proper canonical tag". Los rich results habían caído aproximadamente seis meses antes, lo cual coincidía con la instalación de la app de reviews. El fix involucró tres pasos: corregir el filtro de links internos en el template de colección, desactivar el output de schema standalone de la app de reviews preservando su display visible en página, y resubmitir el sitemap actualizado. Google recrawleó y consolidó a lo largo de ocho semanas.

Los canonical tags no son una feature de "configura y olvida"

El comportamiento por defecto de Shopify es un punto de partida, no una garantía. Los temas generan canonicals correctos en la instalación. Después un developer edita el template de colección, una app se instala sin una auditoría de structured data, o un merchant añade un producto a doce colecciones porque el equipo de merchandising quería más cross-sells. Cada una de esas acciones puede degradar la salud de los canonicals en silencio.

Este es el tipo de deuda técnica compuesta que aparece como una meseta de tráfico orgánico meses después de la decisión que la causó. La plataforma no te va a avisar. Google no te va a avisar. Lo encuentras en los datos.

Para un marco más amplio sobre cómo gestionar SEO técnico en Shopify, el Shopify Technical SEO Playbook cubre la estrategia de canonicals junto con crawl budget, gestión de redirects y decisiones de arquitectura de sitio que alimentan el performance de rankings en el tiempo.

Shugert lleva auditando y migrando tiendas Shopify desde 2015. Después de 30+ migraciones y cientos de auditorías técnicas, las fallas de canonicals siguen siendo uno de los problemas más sistemáticamente subestimados que encontramos en tiendas que por lo demás están bien optimizadas. Si tu tienda ha crecido a través de múltiples instalaciones de apps y expansiones de colecciones sin una revisión técnica estructurada, la capa de canonicals es el lugar correcto para empezar.

CompartirXLinkedIn

Sigue leyendo

Recursos relacionados

En esta página