Qué es una URL canónica y por qué puede afectar a Google

Una URL canónica es la dirección que Google elige como representante cuando varias direcciones de tu web enseñan el mismo contenido. Tú puedes decirle cuál prefieres con una etiqueta en el código, pero esa etiqueta es una recomendación: la decisión final la toma Google, y en su documentación lo dice con todas las letras.

Eso, para un negocio pequeño, tiene una consecuencia práctica: no basta con poner la etiqueta y darla por buena. Aquí está qué es exactamente, cómo elige Google, las tres formas de declarar tu preferencia por orden de fuerza, lo que no hay que hacer y cómo lo tenemos montado en esta web, con la comprobación que hicimos hoy sobre sus 55 direcciones.

Qué es una URL canónica, según Google

Google define el proceso y el resultado en la misma frase. En Qué es la canonicalización de URLs, actualizada el 11 de septiembre de 2026:

La canonicalización es el proceso de seleccionar la URL representativa de determinado contenido (canónica). Por lo tanto, una URL canónica es la URL de una página que Google ha elegido como la más representativa de un conjunto de páginas duplicadas.

Fíjate en el verbo: Google ha elegido. La canónica no es la etiqueta que escribes, es la URL que el buscador acaba considerando la buena. La etiqueta es solo una de las señales que usa para decidirlo.

Y tiene dos efectos que se notan:

• Es la que se muestra. «Los resultados de la Búsqueda de Google suelen redirigir a páginas canónicas, a menos que un duplicado se adapte mejor a la búsqueda del usuario.»
• Es la que se juzga. «Google utiliza la página canónica como fuente principal para evaluar el contenido y la calidad.» Si el buscador ha elegido como representante una versión pobre de tu página, esa es la que evalúa.

Hay además un efecto sobre el rastreo: la canónica «será la página que se rastreará con mayor frecuencia; las versiones duplicadas no se rastrean tan a menudo para reducir la carga del rastreo de sitios».

De dónde salen las URLs duplicadas en una web pequeña

Antes de nada, quítate un miedo de encima. Google lo dice literalmente: «Es normal que en un sitio haya contenido duplicado, lo cual no infringe las políticas de spam de Google». Tener duplicados no es una falta; es una situación que hay que resolver.

Su documentación agrupa las causas en cinco familias: variantes regionales, variantes de dispositivo, variantes de protocolos —«las versiones HTTP y HTTPS de un sitio»—, funciones del sitio como ordenar y filtrar, y variantes accidentales, «cuando los rastreadores pueden acceder por error a la versión demo de un sitio».

En una web de pyme española, en la práctica, las que aparecen casi siempre son cuatro:

1. El dominio con y sin www, o con y sin https, sirviendo los dos lo mismo con respuesta 200.
2. Los parámetros de campaña. Cada enlace con utm_source o con un identificador de anuncio es, técnicamente, una URL distinta que devuelve la misma página.
3. La barra final. /contacto y /contacto/ pueden ser dos direcciones para el mismo contenido si el servidor no unifica una de las dos.
4. La página de servicio duplicada a mano porque hacía falta una versión «para Google» y otra «para el anuncio».

El precio de dejarlo así no es una penalización: es dispersión. Google lo describe como algo que «puede empeorar la experiencia de usuario» y que puede «hacer que sea más difícil controlar el rendimiento de tu contenido en los resultados de búsqueda». Traducido: los enlaces que recibes se reparten entre versiones y tus informes cuentan la misma página dos veces.

Ojo con no confundir esto con otro problema que se parece pero es distinto. Dos URLs diferentes peleando por la misma búsqueda no es un caso de canonicalización, es una decisión de arquitectura de contenidos, y se resuelve fusionando o diferenciando, no con una etiqueta. Eso está contado en cómo se conectan las keywords informacionales y comerciales.

Cómo elige Google y por qué puede no hacerte caso

El proceso tiene dos pasos. Primero agrupa: «Si Google encuentra varias páginas que parecen ser iguales o cuyo contenido principal es muy similar, las agrupa». Después elige dentro del grupo la que «sea objetivamente la más completa y útil para los usuarios de la Búsqueda».

Los factores que pesan, según la misma página, son cuatro: «si la página se sirve a través de HTTP o HTTPS, las redirecciones, la presencia de la URL en un sitemap y las anotaciones link rel="canonical"».

Y a continuación viene la frase que conviene tener escrita en la pared antes de discutir con nadie sobre canonicals:

Puedes indicar a Google qué página consideras que es la canónica con las técnicas que se describen en este artículo, pero es posible que Google elija otra por diversos motivos. Es decir, indicar una preferencia canónica es una sugerencia, no una regla.

Por eso el orden correcto de trabajo es al revés de como suele hacerse: primero se arregla la causa del duplicado, y la etiqueta viene después a confirmar la decisión. Una etiqueta que contradice al resto de señales del sitio no gana la discusión, solo la ensucia.

Google también avisa de algo que ahorra trabajo: «Es probable que tu sitio funcione bien sin especificar una preferencia canónica», porque si no dices nada, el buscador elegirá por su cuenta. Declararla sirve cuando quieres decidir tú, no como trámite obligatorio.

Las tres formas de declarar tu preferencia, por orden de fuerza

La guía Cómo especificar una URL canónica con rel="canonical" y otros métodos, actualizada el 15 de julio de 2026, las ordena de mayor a menor influencia:

1. Redirecciones. De ellas dice Google que «son una señal clara de que el destino de la redirección debe ser canónico». Es el método más fuerte y el único que además retira la URL vieja de la circulación. Google reserva su uso para eso: «Utiliza este método solo cuando quieras retirar páginas duplicadas».
2. La anotación canónica en el HTML. De las anotaciones link rel="canonical" dice Google que «son una señal clara de que la URL especificada debería convertirse en canónica». Es la opción cuando las dos URLs tienen que seguir existiendo.
3. La inclusión en el sitemap. Google la describe como algo que «es una señal con poca influencia que ayuda a que las URLs incluidas en un sitemap se conviertan en canónicas». Por sí sola no resuelve nada: «Google debe determinar las páginas duplicadas asociadas a las páginas canónicas que se declaran en el sitemap».

Y un detalle que casi nunca se aprovecha: las señales suman. «Ten en cuenta que estos métodos pueden acumularse y, por tanto, son más eficaces si se combinan.»

Sobre el tipo de redirección hay una distinción que decide el resultado. En Las redirecciones y la Búsqueda de Google, actualizada el 5 de mayo de 2026, están las dos mitades: las permanentes «muestran el nuevo destino de una redirección en los resultados de búsqueda», mientras que en las temporales «el flujo de procesamiento de indexación no la utiliza como una señal de que la página de destino debería ser la canónica». Una redirección temporal mueve al visitante pero no consolida nada. Si querías consolidar y pusiste una temporal, no has hecho la mitad del trabajo: has hecho otra cosa.

Existe un cuarto método para los archivos que no son HTML. Un PDF no tiene <head> donde poner la etiqueta, así que Google admite una cabecera de respuesta Link: <...>; rel="canonical". Sirve para decir que el PDF descargable de tu catálogo es una variante de la página web que lo explica. Google recomienda no usar el elemento HTML y la cabecera a la vez: «hacerlo resulta más propenso a errores».

La canónica que se apunta a sí misma

Es la práctica que más rendimiento da por lo poco que cuesta. Google la recomienda explícitamente: «Incluye un enlace rel="canonical" en la propia página canónica (también conocida como "canónica que hace referencia a sí misma")».

Qué resuelve, en concreto: cuando alguien llega a tu página con ?utm_source=newsletter pegado al final, esa dirección declara desde dentro que la buena es la limpia. No hace falta prever cada parámetro que se te pueda ocurrir a ti o a un tercero; basta con que cada página diga cuál es su propia dirección.

Dos requisitos que se incumplen a menudo:

• URL absoluta, no relativa. «Usa rutas absolutas en vez de relativas con el elemento link rel="canonical". Aunque Google admite rutas relativas, pueden provocar problemas a largo plazo (por ejemplo, si permites accidentalmente que se rastree tu sitio de prueba).»
• Dentro de la cabecera del documento. «El elemento link element rel="canonical" solo se acepta si aparece en la sección <head> del HTML, por lo que debes asegurarte de que al menos la sección <head> sea código HTML válido.» Una etiqueta que acaba en el cuerpo de la página no existe.

Lo que no hay que hacer

Las prácticas desaconsejadas están en la misma guía de Google, y las tres primeras son responsables de la mayoría de los líos que hemos visto en auditorías:

• No uses robots.txt para marcar canónicas. «Google puede seguir indexando URLs que estén bloqueadas en robots.txt sin su contenido.» Bloquear no es elegir: es impedir que Google vea la etiqueta que habías puesto dentro.
• No uses noindex para resolver un duplicado. «No recomendamos usar noindex para impedir que se seleccione una página canónica de un solo sitio, ya que la bloqueará por completo de la Búsqueda. Es preferible usar anotaciones link rel="canonical".» La diferencia importa: la canónica agrupa señales, el noindex las tira.
• No des dos preferencias distintas. «No marques como canónicas URLs diferentes que lleven a una misma página con varias técnicas. Por ejemplo, no indiques una URL en un sitemap y otra de la misma página mediante rel="canonical".»
• No uses fragmentos, porque «Google generalmente no admite fragmentos de URL». Un #seccion no identifica una página distinta.
• No la retoques con JavaScript. «La mejor forma de hacerlo es especificar la URL canónica en el código fuente HTML y asegurarse de que JavaScript no cambie el elemento de enlace canónico.»
• No la uses para el contenido sindicado. Si otro medio republica tus artículos, Google desaconseja resolverlo con la etiqueta «ya que las páginas suelen ser muy diferentes»; recomienda que sea el partner quien bloquee la indexación.

Un apunte más, por si tu web va por HTTPS y aun así aparece la versión antigua: Google prefiere HTTPS por defecto, pero esa preferencia se cae si «la página HTTPS tiene un certificado SSL no válido», si redirige a los usuarios a una página HTTP o si su propia etiqueta canónica apunta a la versión HTTP.

Cómo lo tenemos montado en esta web

Este apartado es el nuestro, con los números medidos hoy, 17 de septiembre de 2026, sobre el HTML que sirve la web en producción. No es una estimación ni un ejemplo de manual.

La comprobación completa. Descargamos el sitemap y pedimos una a una sus 55 direcciones: las 55 responden 200, las 55 declaran exactamente una etiqueta canónica, todas absolutas y con https y www, y en las 55 la canónica declarada coincide con la URL que figura en el sitemap. Ninguna de esas 55 lleva noindex. Es decir, las dos señales del sitio —etiqueta y sitemap— dicen lo mismo en todas las páginas publicadas, que es justamente la acumulación que Google describe como más eficaz.

La normalización del host, antes de la etiqueta. El dominio sin www y la versión sin cifrar responden con una redirección permanente 308 a la dirección buena; la ruta antigua del producto también. Esa corrección la hicimos el 8 de septiembre de 2026 y está contada, con lo que la motivó, en los problemas de indexación más frecuentes. Lo relevante aquí es el orden: la etiqueta canónica ya apuntaba al www antes de esa corrección y no bastaba, porque era una sugerencia frente a un sitio entero alcanzable por dos caminos con respuesta 200.

El caso del parámetro, medido. Tenemos una ruta corta, /demo, que lleva a la página de contacto con un parámetro para saber de dónde viene la visita. Hoy responde con un 307 temporal —deliberadamente, porque puede cambiar— y el destino, con el parámetro pegado, devuelve 200 y declara como canónica la dirección limpia de contacto, sin parámetro. Las dos piezas hacen lo suyo: la redirección temporal no consolida nada, y la canónica que se apunta a sí misma evita que la variante con parámetro se convierta en una segunda URL de la página de contacto.

Un detalle de implementación que puede despistar. En el código de cada página la canónica está escrita como ruta relativa y el framework la resuelve contra la dirección base del sitio. Lo comprobamos en el HTML servido porque el código fuente no basta para saberlo: lo que llega al navegador es la URL absoluta completa, que es lo que Google pide. Si auditas una web hecha con un framework moderno, mira el HTML final y no el archivo de configuración.

Lo que no está bien del todo, dicho aquí. Escribiendo este artículo encontramos una incoherencia propia: la página del equipo editorial responde 200, es indexable y declara su canónica, pero no está en el sitemap, mientras que la del autor sí. No rompe nada —el sitemap es la señal débil de las tres— pero contradice el criterio que acabamos de defender de que las dos señales digan lo mismo. Queda apuntada para corregir. Distinto es el caso de las páginas legales: llevan noindex a propósito y están fuera del sitemap también a propósito. Ahí no hay duplicado que resolver, hay una exclusión decidida, y por eso el noindex no contradice nada de lo anterior.

Qué hacer si Google elige una canónica distinta a la tuya

Pasa, y la propia documentación tiene una página para ello: Solucionar problemas de canonicalización, actualizada el 11 de septiembre de 2026. El orden que propone es este:

1. Mira qué página considera Google que es la canónica, con la herramienta de inspección de URLs de Search Console. Y después haz la pregunta incómoda que plantea Google: «Piensa si la URL canónica que ha seleccionado Google tiene más sentido que la que prefieres para los usuarios procedentes de la Búsqueda de Google». A veces el buscador tiene razón.
2. Busca el fallo técnico. Los que Google enumera: anotaciones incorrectas puestas por un CMS o un complemento, servidores mal configurados que devuelven el contenido de un dominio al pedir otro, y un caso que conviene conocer porque no es raro en webs desatendidas: un ataque que inserta «una redirección 3xx HTTP o que inserta una anotación link rel="canonical" que lleva a otro dominio».
3. Comprueba si las páginas son de verdad distintas. Si Google las ha agrupado, es que se parecen. La salida no es insistir con la etiqueta, es diferenciar el contenido o quedarse con una sola.

Y un plazo concreto, que es el dato más útil de esa página para gestionar expectativas: «incluso después de corregir los problemas de contenido, es posible que Google mantenga las páginas agrupadas como duplicadas durante un máximo de dos semanas». Además, «las páginas se dividirán más rápido si la diferencia entre el contenido nuevo y las otras páginas agrupadas es clara y significativa». Un retoque cosmético alarga la espera; un cambio real la acorta.

Si lo que te ocurre es que la página no aparece de ninguna forma, y no que aparece la versión equivocada, el diagnóstico no es este: está en problemas de indexación más frecuentes y cómo detectarlos, donde también figuran los nombres oficiales que usa el informe de Search Console para los duplicados.

Lista de comprobación

Lo que revisamos nosotros en la parte de canonicalización de una auditoría SEO, y que puedes repasar tú mismo en una tarde:

• El sitio es alcanzable por una sola combinación de protocolo y dominio; el resto redirige de forma permanente.
• Cada página declara una sola etiqueta canónica, absoluta, dentro del <head>.
• Esa etiqueta apunta a sí misma en las páginas buenas.
• La URL de la etiqueta y la del sitemap son la misma cadena de texto, carácter por carácter.
• Las variantes con parámetros de campaña devuelven 200 y declaran la dirección limpia.
• Ninguna canónica apunta a una URL que redirige, que da 404 o que lleva noindex.
• No hay noindex ni bloqueo en robots.txt usados para resolver duplicados.
• Los enlaces internos apuntan a la URL canónica, no a la variante: Google lo pide expresamente —«Cuando crees enlaces en tu sitio, enlaza a la URL canónica en lugar de a la duplicada»— y está desarrollado en enlazado interno.
• Si hay PDFs publicados que repiten contenido de la web, se han resuelto con la cabecera HTTP y no con nada más.

Nada de esta lista requiere una herramienta de pago. Requiere abrir el código fuente de cada página y leer una línea.

Fuentes consultadas

• Google Search Central, Qué es la canonicalización de URLs, última actualización del 11 de septiembre de 2026, consultada el 17 de septiembre de 2026. Definición, causas del duplicado, criterio de elección, la canónica como sugerencia y su papel en la evaluación del contenido.
• Google Search Central, Cómo especificar una URL canónica con rel="canonical" y otros métodos, última actualización del 15 de julio de 2026, consultada el 17 de septiembre de 2026. Orden de fuerza de los métodos, acumulación de señales, prácticas recomendadas y desaconsejadas, rutas absolutas, cabecera HTTP y preferencia por HTTPS.
• Google Search Central, Solucionar problemas de canonicalización, última actualización del 11 de septiembre de 2026, consultada el 17 de septiembre de 2026. Pasos de diagnóstico, problemas habituales y el plazo de hasta dos semanas para deshacer una agrupación.
• Google Search Central, Las redirecciones y la Búsqueda de Google, última actualización del 5 de mayo de 2026, consultada el 17 de septiembre de 2026. Efecto de las redirecciones permanentes y temporales sobre la elección de la canónica.
• PotencIA Soluciones, medición propia del 17 de septiembre de 2026 con curl sobre el HTML servido en producción: las 55 URLs del sitemap con su código de respuesta, su etiqueta canónica y su etiqueta de robots; los códigos de las redirecciones de host, de protocolo y de rutas antiguas; y la variante con parámetro de la página de contacto. Código del sitio revisado el mismo día.