Etiqueta canonical: cómo evitar el contenido duplicado

Una etiqueta canonical, escrita como link rel="canonical", es un elemento HTML en la sección head de una página. Indica a los buscadores qué versión de la URL es la preferida cuando el mismo contenido, o uno muy parecido, es accesible desde varias direcciones. Ahí está el núcleo del contenido duplicado: cuando Google encuentra varias URL casi idénticas, una de ellas tiene que convertirse en la versión indexada y posicionada. La canonical es tu propuesta de cuál debe ser. Para webs B2B en Europa, desde tiendas online con navegación por filtros hasta sitios multilingües en Next.js, una canonicalización correcta es una de las medidas de SEO técnico más eficaces y, a la vez, de las que más a menudo se implementan mal. Este artículo explica cómo funciona, las buenas prácticas, los errores típicos y la medición, con referencias concretas a los requisitos de Austria y de la región DACH (Alemania, Austria y Suiza) y a los crawlers de IA.

Por qué las etiquetas canonical son decisivas para el rastreo y la indexación

El contenido duplicado no es un fenómeno marginal, sino lo normal en la web. Gary Illyes, de Google, citó en un evento de Search Central la estimación de que alrededor del 60 % de internet es contenido duplicado (internacional, 2022). La definición de duplicado es amplia y va desde copias exactas hasta páginas temáticamente muy similares. Para tu propia web, esto significa que una sola página de producto o de servicio existe a menudo, a nivel técnico, en una docena de variantes de URL sin que nadie las haya creado a propósito.

Lo primero es una buena noticia que sorprende a muchos responsables. Google no penaliza el contenido duplicado. En una aclaración oficial se dice literalmente que no existe una penalización por contenido duplicado y que el contenido duplicado no es motivo para tomar medidas, mientras la intención no sea engañosa o manipuladora (internacional, 2008). El verdadero problema no es, por tanto, una penalización, sino la pérdida de control. Sin una señal clara, Google elige por su cuenta una versión representativa del clúster de páginas duplicadas. Esa elección puede no coincidir con la deseada, reparte las señales de ranking entre varias URL y consume presupuesto de rastreo en variantes que nunca deberían posicionar.

Un análisis a gran escala demuestra que en la práctica dominan los problemas técnicos de URL. En el Site Audit de Ahrefs sobre más de un millón de dominios, los problemas de redirecciones 3XX fueron, con un 95,2 %, el problema de SEO técnico más frecuente de todos (internacional, 2023). Las redirecciones y las canonicals están entrelazadas, y ambas influyen en qué URL acaba en el índice. Quien trabaja bien aquí gana rankings y eficiencia de rastreo, algo que pesa cada vez más en la era de los crawlers de IA adicionales.

Cómo elige Google la URL canónica: una indicación, no una orden

El punto conceptual más importante: la etiqueta canonical es una propuesta, no una instrucción. Google lo formula con claridad en su documentación. Puedes indicar tu preferencia, pero Google puede elegir otra página como canónica por distintos motivos, porque señalar una preferencia canónica es una indicación, no una regla (internacional, 2024). No es un fallo del sistema, sino algo diseñado así a propósito. Google combina varias señales y decide qué URL de un clúster es la más útil y completa para quien busca.

Según Google, en esta selección intervienen varios factores: si una página se sirve por HTTP o HTTPS, las redirecciones, la presencia de la URL en un sitemap y las indicaciones rel-canonical (internacional, 2024). Lo decisivo es que estas señales no pesan lo mismo. Google ordena los métodos según su influencia y los describe así: una redirección es una señal fuerte de que el destino debe convertirse en canónico, la indicación rel-canonical es una señal fuerte para la URL indicada y el sitemap es solo una señal débil (internacional, 2024).

De ahí se deriva una regla práctica central: las señales no deben contradecirse. Si tu canonical apunta a la URL A, pero el enlazado interno lleva sistemáticamente a la URL B, B figura en el sitemap y existen variantes HTTPS, Google evalúa el conjunto de estas indicaciones. Una canonical aislada, aunque sea correcta, no se impone de forma fiable frente a muchas señales contrarias. Por eso la coherencia en todos los canales importa más que la canonical por sí sola.

Buena práctica: la canonical autorreferencial como estándar

La buena práctica establecida es la canonical autorreferencial. Cada página indexable apunta con rel="canonical" a su propia URL canónica. Las canonicals en general están muy extendidas en la web: según el Web Almanac 2024, el 65 % de las páginas móviles y el 69 % de las de escritorio usan rel-canonical (internacional, 2024). La autorreferencia elimina la ambigüedad antes de que surja, porque define sin lugar a dudas la versión limpia de destino para las variantes de parámetros, de tracking o de protocolo.

Para implementarla correctamente se aplican algunas reglas fijas:

• Usar URL absolutas: la canonical debe contener la dirección completa con protocolo y dominio, es decir, https://www.beispiel.at/seite, no solo /seite. Las indicaciones relativas se interpretan, pero aumentan el riesgo de errores.
• Una sola canonical por página: varias canonicals contradictorias en el head hacen que Google las ignore o decida de forma imprevisible.
• Apuntar a una página indexable con código 200: el destino de la canonical debe ser accesible, devolver el código de estado 200 y no estar en noindex.
• Escritura coherente de las URL: elige para todo el proyecto una variante de protocolo (HTTPS), de host (con o sin www) y de barra final, y refléjala en la canonical, las redirecciones, el sitemap y el enlazado interno.
• Usar la cabecera HTTP solo de forma puntual: para archivos que no son HTML, como los PDF, la canonical puede definirse mediante la cabecera HTTP. En la práctica es poco habitual, solo el 1 % de las páginas móviles usa la cabecera HTTP (internacional, 2024), y nunca debería hacerse en paralelo a una canonical HTML contradictoria.

Conviene saber que la mayoría de las páginas sirven su canonical de forma coherente tanto en el HTML en bruto como en el renderizado. Según el Web Almanac, menos del 1 % de las páginas tenía un elemento canonical solo en el HTML en bruto, pero no en el renderizado (internacional, 2024). Ese es el estado ideal: una canonical estable que vale independientemente del renderizado.

Canonical, redirección 301, noindex o robots.txt: la matriz de decisión

La canonical es solo una de cuatro herramientas contra los problemas de URL, y confundirlas es una de las fuentes de error más habituales. La elección depende de si los usuarios deben poder seguir accediendo a la variante y de si la página puede aparecer en el índice.

• Redirección 301: la opción correcta cuando una URL se traslada de forma permanente y nadie debe volver a abrir la dirección antigua. Según Google, la redirección es la señal de canonicalización más fuerte y la que consolida las señales de ranking de forma más fiable. Ejemplo: el paso de http a https o de la versión sin www a la versión con www.
• rel-canonical: la opción correcta cuando ambas URL deben seguir accesibles, por ejemplo porque los filtros o los parámetros de tracking tienen que funcionar para los usuarios, pero solo una versión debe posicionar. El contenido sigue visible en ambas direcciones y el ranking se concentra en la canónica.
• noindex: la opción correcta cuando una página debe ser accesible, pero en ningún caso aparecer en el índice, como las páginas de resultados de la búsqueda interna o las páginas de agradecimiento. A diferencia de la canonical, noindex no consolida señales: simplemente saca la página del índice.
• robots.txt: la herramienta para controlar el rastreo, no la indexación. Una URL bloqueada por robots.txt puede indexarse igualmente si está enlazada. Importante: Google no puede rastrear una página bloqueada por robots.txt, así que tampoco puede leer su canonical. Por eso, la canonical y el bloqueo por robots.txt se excluyen mutuamente.

Como regla práctica: si la variante debe desaparecer, usas 301. Si debe quedarse pero no posicionar, usas la canonical. Si debe ser accesible pero invisible en el índice, usas noindex.

Fuentes habituales de contenido duplicado en B2B y e-commerce

En la práctica, el contenido duplicado casi siempre tiene un origen técnico, no editorial. Las fuentes más habituales en el entorno empresarial:

• Parámetros de URL y tracking: añadidos como ?utm_source=, ?ref= o los ID de sesión generan una URL nueva con contenido idéntico para cada campaña. Una canonical autorreferencial hacia la versión sin parámetros lo resuelve.
• Navegación por filtros y facetada: combinando color, talla, precio y orden, las tiendas online generan muchísimas URL con un contenido prácticamente igual. Aquí hace falta una estrategia consciente sobre qué páginas de filtro son indexables y cuáles apuntan con canonical a la categoría.
• Protocolo y host: http frente a https y www frente a sin www generan hasta cuatro variantes técnicas de la misma página. Deben consolidarse en una sola variante con una redirección 301, no solo con una canonical.
• Barra final y mayúsculas/minúsculas: /seite y /seite/, así como /Seite y /seite, suelen ser para el servidor URL distintas con el mismo contenido. Una normalización para todo el proyecto lo evita.
• Paginación y versiones para imprimir: los listados por páginas o las URL de impresión separadas son fuentes clásicas de duplicados que necesitan reglas de canonical claras.

Sobre todo en catálogos B2B extensos, estas variantes suman rápidamente miles de URL. Sin una estrategia de canonicals, Google se ve obligado a tomar sus propias decisiones y se gasta presupuesto de rastreo que estaría mejor invertido en las páginas de contenido reales.

Errores frecuentes con las canonicals y cómo evitarlos

Los errores con las canonicals son traicioneros porque rara vez se ven de inmediato: van desplazando la indexación a lo largo de semanas. Las trampas más importantes:

• Señales contradictorias entre HTML, cabecera HTTP y DOM renderizado: si el HTML en bruto, la cabecera HTTP y el resultado renderizado con JavaScript indican canonicals distintas, surge un conflicto. Según el Web Almanac 2024, la canonical de la cabecera HTTP y la del HTML renderizado se contradecían en el 0,8 % de las páginas, y el renderizado modificó la canonical en el 1,9 % de las páginas de escritorio y en el 2,1 % de las móviles (internacional, 2024). Parece poco, pero en sitios grandes afecta a muchas URL.
• Canonical hacia una página noindex, una redirección o una página 4xx: el destino debe ser una página accesible e indexable con código 200. Si la canonical apunta a una URL redirigida o bloqueada, envía una señal imposible de resolver.
• Cadenas de canonicals: la página A canonicaliza a B, y B a C. Estas cadenas debilitan la señal y deberían sustituirse por una indicación directa al destino final.
• Canonicals entre dominios incorrectas: una canonical puede apuntar a otro dominio, por ejemplo en la sindicación de contenidos. Es poderoso y peligroso a la vez: una canonical entre dominios puesta por error, por ejemplo desde una configuración de staging copiada, puede expulsar del índice toda la web en producción. Usa las canonicals entre dominios solo de forma consciente y con moderación.
• Canonical hacia URL con parámetros en lugar de la versión limpia: a menudo la canonical apunta por error a la URL abierta en ese momento, con parámetros incluidos, en lugar de a la URL base canónica.

La buena noticia: la corrección técnica suele poder comprobarse. Según el Web Almanac, el 98 % de las páginas con un elemento canonical detectado supera la prueba de Lighthouse de rel-canonical válido (internacional, 2024). La sintaxis formal es correcta casi siempre; los conflictos de contenido y los errores de destino siguen siendo el verdadero reto.

SEO para JavaScript y renderizado: cómo configurar bien las canonicals en Next.js y SPA

En los frontends modernos, sobre todo en Next.js y en las Single Page Applications, aparece una fuente de error adicional: la canonical se define con JavaScript solo en el navegador. Los crawlers que no renderizan, o que lo hacen con retraso, no ven ninguna canonical o ven una incorrecta. Como el renderizado puede modificar la canonical de forma medible, la canonical servida desde el servidor es la vía segura.

En concreto, para Next.js:

• Usar la Metadata API en el servidor: define la canonical mediante la propiedad alternates.canonical de la Metadata API o mediante elementos head renderizados en el servidor, para que la canonical ya esté en el HTML en bruto y no aparezca solo después del renderizado.
• Una lógica de canonical inequívoca por ruta: las rutas dinámicas deben derivar su URL canónica de parámetros estables, no de la petición concreta con su query string.
• Alinear el HTML en bruto y el renderizado: evita que el código del lado del cliente sobrescriba después la canonical definida en el servidor. Justo esa ruptura genera los conflictos causados por el renderizado.
• Vigilar las canonicals por cabecera HTTP en el edge/CDN: si las canonicals se definen por cabecera en el borde de la CDN, comprueba que no choquen con la canonical HTML.

El objetivo es siempre el mismo: un crawler debe ver la canonical definitiva sin tener que ejecutar JavaScript. El renderizado en servidor o la generación estática cumplen este requisito de forma fiable.

Paginación, hreflang y la interacción de las señales

Dos casos especiales merecen atención, porque en ellos persisten ideas erróneas muy arraigadas.

Primero, la paginación. Google hace años que no usa rel="prev" ni rel="next" para la indexación. La solución correcta hoy es una canonical autorreferencial en cada página de una serie paginada. Es decir, la página 2 apunta a la página 2, no a la página 1. Si haces que todas las páginas siguientes apunten a la página 1 mediante canonical, te arriesgas a que los productos o artículos enlazados solo desde ellas ni siquiera se descubran.

Segundo, la interacción entre canonical y hreflang. Ambos deben mantenerse claramente separados. Cada versión de idioma recibe una canonical autorreferencial, es decir, la página de-AT apunta a sí misma y la página de-DE, a sí misma. Después, hreflang conecta entre sí estas versiones equivalentes. Un error frecuente y grave es hacer que la variante de-AT apunte con canonical a la variante de-DE. Eso saca en la práctica la versión austriaca del índice e invalida toda la construcción de hreflang. Regla para recordar: la canonical siempre apunta a sí misma dentro de la misma versión de idioma; hreflang conecta los idiomas.

Esta separación es especialmente relevante en la región DACH, porque de-AT, de-DE y de-CH suelen ser muy parecidas en contenido. Justo entonces la tentación de agruparlas mediante canonical es grande, y eso destruye la visibilidad regional.

Monitorización, validación y medición

Las canonicals no son estáticas: hay que vigilarlas de forma continua. Las herramientas clave:

• Google Search Console, inspección de URLs: muestra para cada URL la canonical elegida por Google junto a la declarada por el usuario. Si ambas difieren, es la primera señal de alarma.
• Informe de indexación de GSC: el estado «Duplicada: Google ha elegido una versión canónica diferente a la del usuario» muestra sistemáticamente dónde divergen tu indicación y la decisión de Google. Es el informe más importante para evaluar la calidad de las canonicals.
• Auditorías del sitio con Screaming Frog o Ahrefs: los crawlers detectan de forma exhaustiva cadenas de canonicals, canonicals hacia destinos noindex o redirigidos, canonicals ausentes y conflictos entre HTML en bruto y renderizado. Teniendo en cuenta que los problemas de redirecciones 3XX aparecen en el 95,2 % de los dominios (internacional, 2023), la revisión conjunta de redirecciones y canonicals debe formar parte de toda auditoría.
• Lighthouse: comprueba la validez formal del rel-canonical por página y sirve para un control rápido de una plantilla concreta.
• Comparación del renderizado: compara de forma específica el HTML en bruto y el renderizado para localizar conflictos de canonical causados por JavaScript que los crawlers estáticos pasan por alto.

Al evaluar, ten en cuenta que una diferencia entre la canonical deseada y la elegida no es necesariamente un error. A veces Google ha encontrado una versión objetivamente mejor. Hay que actuar cuando Google prefiere una variante más débil o incorrecta, por ejemplo una URL con parámetros en lugar de la página limpia.

Las canonicals en la era de los crawlers de IA y el GEO

La lógica de la canonicalización gana importancia con los crawlers de IA. Su volumen crece a gran velocidad: según un análisis de Cloudflare, la cuota de GPTBot, de OpenAI, pasó entre mayo de 2024 y mayo de 2025 del 2,2 % al 7,7 % de las solicitudes de crawlers de IA y de búsqueda, con un aumento de las solicitudes del 305 % (internacional, 2025). Entre los crawlers puramente de IA, su cuota creció en el mismo periodo del 5 al 30 %. Esta carga de rastreo adicional recae justo sobre las variantes de URL que unas canonicals limpias deberían contener.

Según un análisis de Vercel y MERJ, ninguno de los grandes crawlers de IA, entre ellos GPTBot, ClaudeBot y PerplexityBot, ejecuta JavaScript (internacional, 2024). Las excepciones son Gemini, que usa la infraestructura de Googlebot, y AppleBot. Para el resto de crawlers de IA, la exigencia de una canonical coherente, presente en el HTML en bruto servido desde el servidor, cuenta por tanto el doble. Una canonical definida solo en el cliente, que para Googlebot todavía funciona dando un rodeo, se pierde con un crawler de IA que no renderiza. Así, las señales coherentes y ancladas en el código fuente son un asunto de ranking y también de Generative Engine Optimization.

En la práctica, esto significa que quien sirve sus canonicals desde el servidor, sin contradicciones y de forma coherente en el HTML, el sitemap, los enlaces internos y las redirecciones, optimiza de una vez para la búsqueda clásica y para los sistemas de respuesta con IA. Ambos sistemas premian la misma disciplina técnica.

Más información y conclusión

La etiqueta canonical es una herramienta precisa, pero que se presta a malentendidos. Es una señal fuerte, aunque no vinculante, que solo funciona de forma fiable junto con redirecciones coherentes, un sitemap limpio y un enlazado interno consistente. Los siguientes pasos más eficaces para webs B2B: establecer como estándar una canonical autorreferencial en cada página indexable, consolidar las variantes de protocolo y de host con 301, separar estrictamente canonical y hreflang, renderizar en el servidor en Next.js y SPA, y revisar con regularidad el informe de GSC sobre canonicals divergentes. Como los crawlers de IA aumentan la carga de URL y a menudo no renderizan JavaScript, toda estrategia de canonicals coherente y anclada en el código fuente aporta hoy el doble a la visibilidad.