Cinco conflictos de canonical que decide Google

Una etiqueta canonical es una indicación, no una norma. Así lo dice la propia página de canonicalización de Google, que elige la URL canónica por su cuenta a partir de redirecciones, inclusión en el sitemap, preferencia por HTTPS y clústeres de hreflang, además de tu etiqueta. Cuando esas señales se contradicen, tu etiqueta pierde. Estos son los cinco conflictos que lo provocan.

¿La etiqueta canonical es una orden o una indicación?

Una indicación. La página What is canonicalization de Google dice literalmente que indicar una preferencia canónica es una indicación, no una norma. Google agrupa las páginas que lee como duplicadas y marca la que considera más completa y útil para quien busca. Tu etiqueta es una entrada más de esa decisión, y ocupa un lugar concreto en un orden publicado.

Dos recomendaciones conviene tenerlas a mano antes de entrar en los conflictos. No uses robots.txt para canonicalizar, porque Google puede indexar igualmente una URL bloqueada, eso sí, sin su contenido. Y no declares URL canónicas distintas para la misma página usando técnicas distintas.

¿Puede un canonical apuntar a una página con noindex, bloqueada o redirigida?

Puede, y cada variante debilita la etiqueta. Google desaconseja usar noindex para elegir el canónico dentro de un mismo sitio, porque eso bloquea la página por completo en la Búsqueda, y señala rel=canonical como la solución preferida. Apuntar a una URL bloqueada en robots.txt es peor todavía: la documentación de noindex es explícita en que un rastreador que no puede descargar una página nunca llega a ver ninguna regla en ella.

Las redirecciones son el caso sutil, porque están por encima de las etiquetas canonical en el propio orden de Google. La documentación desarrolla un solo escenario: una página HTTPS que redirige a los usuarios a HTTP o a través de HTTP, o que lleva un canonical a la versión HTTP, aparece como señal contradictoria, y las redirecciones de HTTPS a HTTP hacen que Google prefiera HTTP con mucha fuerza. Más allá de ese caso la documentación no detalla qué pasa cuando un canonical apunta a una URL que redirige, así que comprueba el destino tú mismo con nuestro comprobador de redirecciones y apunta la etiqueta a la URL que responde 200.

¿Qué pasa si el sitemap y el canonical no coinciden?

Este lo nombra Google sin rodeos en sus recomendaciones: no indiques una URL en el sitemap y otra distinta para la misma página con rel=canonical. La inclusión en el sitemap es la señal más débil de las dos, así que suele ganar la etiqueta, pero cada URL que envías se propone como canónica y Google todavía tiene que decidir cuáles son duplicadas. La solución es aburrida: genera el sitemap desde la misma fuente que escribe las etiquetas canonical y revisa el archivo con nuestro validador de sitemaps. Qué debe entrar en él lo explica nuestra guía de buenas prácticas de sitemaps.

¿Puede rel=canonical entrar en conflicto con hreflang?

A menudo, y es el conflicto que más daño hace en los sitios multilingües. La instrucción de Google es indicar una página canónica en el mismo idioma, o en el mejor idioma sustituto posible si no existe una en ese idioma. Si el canonical de tu página en español apunta a la inglesa, le has pedido a Google que descarte la española.

Dos detalles más de esas mismas páginas. Una anotación rel=canonical con atributos hreflang, lang, media o type no se usa para canonicalizar, para eso está rel=alternate. Y pertenecer al clúster es en sí una señal: el ejemplo de Google son una página de-de y otra de-ch que se referencian mutuamente y resultan preferidas como canónicas frente a una de-at que queda fuera del clúster. Los errores de anotación que rompen esos clústeres los cubre nuestra guía de hreflang.

¿Hace falta un canonical autorreferencial?

Google lo recomienda. Sus buenas prácticas piden incluir un enlace rel=canonical en la propia página canónica, lo que se conoce como canonical autorreferencial.

El daño de verdad llega con las plantillas que construyen la etiqueta a partir de la URL solicitada. Alguien entra con un parámetro de seguimiento y la etiqueta pasa a apuntar a esa variante con parámetros, de modo que cada clic en un anuncio declara su propio canónico. El ejemplo que usa Google de URL que preferirías no ver en resultados es una ficha de producto con un parámetro gclid. Dos requisitos más de la misma página: usa URL absolutas en lugar de relativas y no apuntes nunca un canonical a un fragmento de URL, porque Google normalmente no admite fragmentos.

¿Funciona el canonical fuera del head o con JavaScript?

Fuera del head no. Google indica que el elemento link rel=canonical solo se acepta si aparece en la sección <head> del HTML, y añade que al menos esa sección debe ser HTML válido. Ahí está la trampa: una etiqueta sin cerrar empuja tu canonical al body, donde no cuenta para nada.

JavaScript está admitido, pero desaconsejado. La página de fundamentos de SEO para JavaScript dice que la Búsqueda de Google recoge el canonical inyectado al renderizar. La página de canonicalización, en cambio, te pide que fijes la URL en el HTML de origen y te asegures de que JavaScript no la cambie por otra. Si no puedes ponerla en el origen, déjala fuera del todo y ponla solo con JavaScript. En cualquier caso, publica una sola: Google avisa de que varias etiquetas rel=canonical o etiquetas en conflicto pueden dar resultados inesperados.

¿Cómo saber qué canónico eligió Google?

La herramienta de inspección de URL de Search Console muestra el canónico elegido por Google junto al que tú declaraste. La página de resolución de problemas añade algo que conviene saber antes de rehacer plantillas: incluso después de arreglar el contenido, Google puede mantener las páginas en un clúster de duplicados hasta dos semanas, y salen antes cuanto más clara y significativa es la diferencia. Nada de esto sirve si el rastreador no llega a la página, y eso son cinco minutos revisando tu robots.txt.