Canonicalización SEO: cómo decide Google qué URL debe ser la principal

Durante años se explicó la canonical como una simple etiqueta HTML, y este tema se entendió de una forma mucho más simple: tú declarabas una URL como principal y, «en principio», esa debía ser la versión dominante.

El problema es que incluso entonces ya se veía que no siempre funcionaba así, ya que había casos en los que Google respetaba esa preferencia y otros en los que terminaba eligiendo una URL distinta.

Con el tiempo se ha visto más claro que este tema no se resuelve mirando una sola línea de código dentro del <head>. Lo que realmente entra en juego es un proceso de canonicalización, es decir, un conjunto de señales que Google cruza para decidir qué URL debe representar un contenido cuando existen varias versiones similares, duplicadas o competidoras.

Qué factores entran dentro del proceso de canonicalización

Cuando varias URLs pueden representar el mismo contenido, o una versión muy parecida, Google no se queda solo con lo que declara una etiqueta canonical. Lo que hace es valorar el conjunto. Por eso, más que preguntarse si una página “lleva canonical”, hoy tiene más sentido preguntarse si todo el sitio está enviando la misma señal sobre qué URL debe consolidar el valor principal.

  • Cómo está implementada la canonical: no basta con que exista. Tiene que estar bien declarada, aparecer una sola vez, estar dentro del <head> o bien resolverse por cabecera HTTP si hablamos de archivos no HTML, y apuntar a una URL válida, indexable y coherente. Aquí fallan bastantes webs por plantillas copiadas, plugins que imprimen una canonical por defecto o implementaciones donde JavaScript la reescribe y complica la señal.
  • Las redirecciones: cuando una versión ya no debería seguir viva, la redirección suele ser la señal más clara. Si una URL debe desaparecer y consolidarse en otra, dejar ambas activas en 200 mientras además intentas resolverlo con canonical suele generar más ruido que claridad.
  • El enlazado interno: si una página declara una canonical hacia una URL, pero los enlaces internos importantes empujan otra versión distinta, la web está mandando un mensaje contradictorio. Esto pasa mucho con menús, breadcrumbs, módulos de productos relacionados, filtros o enlaces antiguos que siguen apuntando a rutas que ya no deberían reforzarse.
  • El sitemap: ayuda a reforzar la versión que consideras principal, pero no rescata una canonicalización incoherente por sí solo. Si en sitemap envías una URL y en la etiqueta canonical o en el enlazado interno empujas otra, la señal deja de ser limpia.
  • La consistencia exacta de la URL elegida: no es solo una cuestión de contenido, también de formato. HTTP o HTTPS, www o no-www, slash final, mayúsculas o minúsculas, parámetros innecesarios o rutas alternativas. Si una misma página puede resolverse de varias formas y el sitio no refuerza siempre la misma versión, empiezan los problemas de consolidación.
  • Parámetros, filtros y ordenaciones: aquí se genera muchísimo ruido en ecommerce y proyectos grandes. Parámetros de tracking, sesiones, filtros combinables, ordenaciones o URLs temporales pueden crear rutas alternativas que no deberían competir entre sí. Si además se enlazan internamente o siguen respondiendo en 200, la señal se ensucia todavía más.
  • La paginación: una serie paginada no debería resolverse canonizando todo hacia la primera página. Si existe una secuencia real, cada URL paginada debe tratarse como una página separada dentro de la serie y tener su propia canonical. Canonizar page/2, page/3 o equivalentes hacia la primera suele ser una simplificación mala del problema.
  • Idiomas, países y hreflang: en proyectos internacionales esto pesa más de lo que parece. Si usas hreflang, la canonical debe ser coherente con ese idioma o, como mínimo, con la mejor versión equivalente posible. Uno de los errores más comunes es mezclar señales entre idiomas y acabar canonizando una versión en un idioma hacia otra que no corresponde.
  • La similitud real entre las páginas implicadas: no todo lo que gira alrededor del mismo tema debe consolidarse con canonical. Hay casos donde alguien intenta canonizar una categoría hacia un artículo destacado, una landing hacia una ficha o páginas solo “parecidas” entre sí. Si la relación no es lo bastante estrecha, la señal pierde sentido y puede ser ignorada.
  • Las contradicciones entre capas del sitio: aquí es donde suele romperse de verdad la canonicalización. Una canonical apuntando a una URL, el sitemap a otra, enlaces internos reforzando una tercera, versiones secundarias vivas en 200, parámetros activos, migraciones a medias o plugins duplicando etiquetas. En ese punto ya no estamos ante una etiqueta mal puesta, sino ante una canonicalización confusa.

Lo que realmente importa es que todas las capas del sitio refuercen la misma versión y no se contradigan entre ellas, y corroborar si todo el sitio está enviando la misma señal sobre qué URL debe consolidar el valor principal..

Casos donde se está implementando mal la etiqueta canonical

La etiqueta canonical suele estar mal implementada cuando intenta reflejar en el <head> una realidad que el resto del sitio no está reforzando. Es decir, cuando la metaetiqueta apunta hacia una URL concreta, pero las demás señales que influyen en el proceso de canonicalización empujan en otra dirección.

En esos casos, el problema no suele ser la falta de etiqueta, sino la contradicción entre capas: canonical, enlazado interno, sitemap, redirecciones, parámetros, paginación, versiones técnicas o arquitectura general del sitio. Algunos errores bastante habituales son estos:

Un caso bastante típico donde la canonical no arregla nada

Un ejemplo muy común es una migración donde la canonical apunta a la versión HTTPS, pero el sitemap sigue enviando HTTP, parte del enlazado interno continúa reforzando la versión antigua, y además conviven www y no-www en respuesta 200. En ese escenario no hay una señal dominante clara: hay varias compitiendo entre sí. La etiqueta canonical no corrige por sí sola ese desorden, solo añade una preferencia más dentro de un sistema que sigue mandando mensajes mezclados.

Algunos errores bastante habituales son estos:

  • Usar la canonical para corregir señales que el propio sitio contradice

    Este es probablemente el error más común. La página declara una canonical hacia una URL, pero los enlaces internos importantes apuntan a otra, el sitemap refuerza una tercera y, además, siguen existiendo versiones equivalentes respondiendo en 200. En ese escenario la canonical no cierra nada: simplemente intenta compensar una incoherencia estructural con una sola línea de código.

  • Canonizar una URL cuando en realidad lo que tocaba era una 301

    Si una versión ya no debería existir, lo lógico no es mantenerla viva y ponerle una canonical hacia otra, sino redirigirla correctamente. Esto pasa mucho en migraciones, cambios de slugs, fusiones de categorías o versiones antiguas de fichas de producto. Mantener ambas URLs activas y esperar que la canonical resuelva sola la consolidación suele ser una forma blanda de no cerrar bien el problema.

  • Usar la canonical para tapar un caos de parámetros, filtros y ordenaciones

    En ecommerce y sitios grandes esto se ve constantemente. Parámetros de tracking, filtros combinables, ordenaciones, búsquedas internas o URLs temporales empiezan a generar versiones alternativas de una misma página. Si esas URLs además se enlazan, aparecen en módulos internos o siguen indexables, la canonical deja de ser una ayuda y pasa a ser un parche. El problema real no es la etiqueta: es que el sistema sigue creando rutas que compiten entre sí.

  • Canonizar páginas que no son lo bastante equivalentes

    No todo lo que trata el mismo tema debería unificarse con canonical. Aquí entra el típico caso de canonizar una categoría hacia otra, una landing hacia una ficha concreta o una página informativa hacia otra comercial solo porque “interesa más posicionar esa”. Si la similitud real entre ambas no es suficientemente estrecha, la canonical pierde sentido técnico y puede ser ignorada.

  • Resolver mal la paginación

    Durante años se difundió bastante la idea de canonizar toda una serie paginada hacia la primera página. A día de hoy ese enfoque no es el bueno. Si existe una secuencia real, cada página paginada forma parte de la colección y debe tener su propia canonical. Tratar /page/2/, /page/3/ y siguientes como si fueran un duplicado bruto de la primera suele simplificar mal el problema.

    Y aquí además conviene limpiar otra herencia antigua: seguir apoyándose en referencias a rel="next" y rel="prev" como si eso resolviera por sí solo la paginación ya no tiene demasiado recorrido. Lo importante hoy es revisar bien la serie, su enlazado y la canonicalización de cada URL.

  • Mezclar canonical e idiomas de forma incoherente

    En proyectos internacionales también se mete bastante la pata. Por ejemplo, cuando una versión en español canoniza hacia una versión en inglés, o cuando las canonicals no respetan la lógica del hreflang y acaban cruzando países o idiomas que no tocan. Aquí la señal deja de ser limpia porque se mezclan dos capas distintas: la versión canónica y la relación entre variantes lingüísticas o regionales.

  • Dejar conviviendo versiones técnicas que deberían estar resueltas

    HTTP y HTTPS, www y no-www, URLs con y sin slash final, rutas duplicadas por mayúsculas, versiones antiguas accesibles o parámetros que alteran la misma página sin necesidad real. Todo eso genera ruido. Si luego intentas arreglarlo con una canonical sin haber cerrado antes esas variantes técnicas, la señal llega débil y tarde. Primero hay que decidir qué versión debe existir de verdad y después reforzarla en todas las capas.

  • Confiar en una canonical autorreferenciada por defecto como si aportara algo por sí sola

    Muchas webs imprimen una canonical autorreferenciada en la URL actual por pura configuración del CMS o del plugin SEO. Eso no es necesariamente un problema, pero tampoco conviene atribuirle más valor del que tiene. Si no hay duplicidad relevante, ni conflicto de señales, ni una estrategia clara que esté cerrando el círculo, esa canonical existe más por inercia que por utilidad real.

  • Intentar canonicalizar con mecanismos que no sirven para eso

    Bloquear en robots.txt, meter noindex como sustituto o tirar de herramientas de retirada temporal no resuelve una canonicalización. Son atajos que suelen aparecer cuando no se ha afrontado la pregunta de fondo: qué URL debe consolidar valor, cuáles sobran y cómo debe reforzarse esa decisión desde el conjunto del sitio.

  • Dar por buena una implementación “correcta” sobre el papel cuando el conjunto no lo es

    Este caso se ve mucho en WordPress, themes complejos y tiendas con plantillas heredadas. Sobre el papel todo parece bien: la canonical existe, el plugin la imprime y no hay errores visibles. Pero luego las taxonomías, los módulos internos, los breadcrumbs, los filtros, los paginados o ciertas plantillas del tema empujan otra versión distinta. Y ahí es donde una canonical aparentemente correcta pasa a ser irrelevante en la práctica.

Vistas todas estas situaciones, por lo tanto, conviene revisar es si todas las señales del proyecto están empujando hacia la misma URL.

«Checklist:» Cómo hacer ingeniería inversa para saber si el proceso de canonicalización es correcto

Si quieres revisar una canonicalización sin autoengañarte, no empieces por el plugin ni por la etiqueta del <head>. Empieza por reconstruir qué señales está recibiendo Google realmente y si todas apuntan a la misma URL o si cada capa del sitio está empujando una versión distinta.

  • Qué URL declara la página como canonical: el primer paso es comprobar qué versión se está declarando como principal y si esa declaración es limpia. Es decir, si hay una sola canonical, si apunta a una URL válida, si esa URL responde correctamente y si no hay rarezas de plantilla, cabeceras HTTP o JavaScript que alteren la señal.
  • Qué URL recibe el enlazado interno importante: aquí no importa solo el menú. También cuentan breadcrumbs, módulos relacionados, listados, filtros, enlaces contextuales y cualquier bloque interno que refuerce una versión concreta. Si la canonical apunta a una URL, pero los enlaces internos importantes empujan otra, ya tienes una contradicción bastante seria.
  • Qué versión se está reforzando en el sitemap: el sitemap no manda por sí solo, pero sí ayuda a reforzar una URL. Si en sitemap estás enviando una versión distinta a la declarada en canonical o distinta a la que más enlaces internos recibe, la señal deja de ser coherente.
  • Qué variantes siguen vivas en respuesta 200: una buena parte de los problemas aparecen porque siguen accesibles URLs que no deberían seguir compitiendo. Aquí conviene revisar versiones con y sin slash, HTTP y HTTPS, www y no-www, parámetros, filtros, ordenaciones, URLs antiguas o rutas generadas por el CMS que continúan respondiendo como si fueran válidas.
  • Qué versión está tomando Google como canónica real: una cosa es la canonical declarada y otra la canónica que Google termina aceptando. Ahí Search Console te da una pista muy valiosa, porque te permite ver si Google está comprando tu señal o si está eligiendo otra URL distinta al detectar contradicciones.
  • Si hay conflictos con parámetros, paginación, idioma, protocolo o facetas: muchas canonicalizaciones aparentemente correctas se rompen por detalles de este tipo. Paginaciones mal tratadas, filtros indexables, versiones multidioma mal relacionadas, HTTP y HTTPS conviviendo, facetas que generan URLs casi duplicadas o plantillas que imprimen señales distintas según el tipo de página.
  • Si la URL elegida encaja de verdad con la arquitectura del sitio: este punto es menos vistoso, pero pesa mucho. A veces una canonical está “bien puesta” y aun así no convence porque intenta consolidar una URL que el propio sitio no trata como principal. Si la arquitectura, el enlazado, la navegación y la lógica del proyecto no respaldan esa elección, la señal queda artificial.

Cuando haces esa ingeniería inversa, ves enseguida si la canonical está cerrando un círculo ya bien resuelto o si simplemente está adornando una arquitectura que sigue diciendo otra cosa.

Cuándo tiene sentido usar canonical de verdad

La canonical no funciona bien como solución aislada, sino como refuerzo final dentro de un proceso de canonicalización coherente. Tiene sentido cuando el resto del sitio ya está empujando la misma URL: enlazado interno, sitemap, arquitectura y versiones activas.

Cuando esas señales van en otra dirección, la canonical sirve de poco. En ese caso no está cerrando una decisión técnica bien resuelta, sino intentando maquillar una incoherencia estructural.

Escrito por:

Óscar Carrillo

Más de 15 años de carrera me han enseñado que el SEO es un ecosistema vivo. Paso cada jornada trabajando para que las empresas alcancen su máximo potencial en Google

Posts relacionados