La etiqueta canonical que mentía · Serpion 007

El periódico provincial digital llevaba más de una década online. No era un medio grande, pero tampoco era pequeño: información municipal, deportes locales, agenda cultural, sucesos. Una redacción activa, varias publicaciones al día y una plataforma editorial desarrollada a medida por una agencia de la zona allá por 2011. El sistema funcionaba. Nadie lo tocaba si no hacía falta. Y precisamente por eso, nadie lo miraba.

El aviso llegó de forma indirecta. El responsable de contenidos notó que algunos artículos de las secciones de cultura y agenda dejaban de aparecer en Google dos o tres días después de publicarse, justo cuando más tráfico deberían atraer. No era una caída general. El resto del sitio funcionaba con normalidad. Pero esas páginas concretas parecían desvanecerse. La etiqueta canonical existía en el HTML de cada artículo, eso estaba claro. El problema era que nadie sabía a dónde apuntaba realmente.

Aquí había ruido, pero no era ruido cualquiera. Si las páginas tenían canonical implementado y el contenido era original, Google no debería tratarlas como copias de nada. Algo en esa instrucción estaba torcido, pero antes de asumir lo más obvio, necesitaba ver los datos.

Lo que la etiqueta canonical decía y lo que Google estaba leyendo

Lo primero fue cuantificar el problema. Abrí el informe de cobertura en Google Search Console y filtré por el estado de duplicados. El resultado: 53 URLs afectadas, concentradas casi en su totalidad en las secciones de cultura, agenda y ocio. La sección de deportes, noticias de municipio y sucesos no mostraba ningún estado similar. Eso me decía algo importante desde el principio: no era un problema global del sitio. Era algo específico de esas secciones.

Antes de ir al código, quise descartar la hipótesis más inmediata. El periódico tenía una versión imprimible de cada artículo, accesible desde un parámetro en la URL del tipo ?formato=impresion. Si el rastreador de Google hubiera llegado a esas variantes y las hubiera tomado como versiones alternativas del mismo contenido, podría haber generado los duplicados que veía en Search Console. Era una hipótesis técnicamente sólida para un medio de esa antigüedad.

Revisé los logs del servidor durante los últimos 45 días filtrando las visitas de Googlebot a URLs con ese parámetro. El bot había accedido a algunas de ellas, sí, pero en proporciones muy bajas y únicamente en las secciones de deportes y sucesos, que eran exactamente las secciones que no tenían el problema. Las URLs afectadas de cultura y agenda no mostraban visitas de Googlebot con ese parámetro. La hipótesis se caía. El origen no iba por ahí.

El problema no estaba en lo que Google encontraba al rastrear. Estaba en la instrucción que el sitio le daba después de entrar.

Lancé entonces un rastreo con Screaming Frog limitado a las 53 URLs en estado de duplicado. Exporté los valores del campo canonical de cada una y los comparé con sus propias URLs. Lo que salió en la hoja de cálculo me hizo detenerme un momento.

Muestra extraída del rastreo — URLs afectadas vs. canonical declarado

URL rastreada:
  /cultura/exposicion-fotografica-convento-agosto-2024

Canonical en el HTML:
  /agenda/feria-medieval-septiembre-2024

---

URL rastreada:
  /agenda/mercado-artesania-plaza-mayor

Canonical en el HTML:
  /cultura/ciclo-teatro-otono-programa

---

URL rastreada:
  /cultura/concierto-banda-municipal-parque

Canonical en el HTML:
  /agenda/verbena-barrio-norte-horarios

Los canonicals no apuntaban a variantes de las mismas URLs. Apuntaban a artículos completamente distintos dentro del propio sitio, sin ninguna relación temática entre sí. Una exposición fotográfica señalando a una feria medieval. Un mercado de artesanía apuntando a un ciclo de teatro. Desde el punto de vista de Google, cada uno de esos artículos le estaba diciendo: «no me indexes a mí, indexa este otro». Y Google, obediente, hacía exactamente eso.

Por qué la etiqueta canonical apuntaba a artículos que no tenían nada que ver

Con esa evidencia sobre la mesa, la pregunta dejaba de ser «¿hay un problema de etiqueta canonical?» y pasaba a ser «¿quién o qué está escribiendo esos valores?». La plataforma editorial generaba los canonicals de forma automática a través de un módulo de plantilla. Nadie los introducía a mano. Lo que significaba que el error no era puntual: era sistemático y estaba reproduciendo ese mismo fallo en cada artículo nuevo publicado en esas secciones.

Que una etiqueta exista en el HTML no garantiza que su valor sea correcto. Esa diferencia, que parece obvia, es exactamente la que hace que este tipo de error pase desapercibido durante meses.

Los datos del rastreo confirmaban el patrón con suficiente claridad como para pasar al siguiente nivel: inspeccionar cómo la plataforma construía esos valores internamente.

El módulo que llevaba meses escribiendo mal su propia instrucción

Accedí al panel de administración de la plataforma editorial con el equipo técnico del periódico. El sistema de gestión de contenidos había sido desarrollado a medida y llevaba funcionando desde 2011 con actualizaciones parciales a lo largo de los años. El módulo responsable de generar el bloque <head> de cada artículo incluía una función específica para construir el campo canonical.

Esa función no tomaba la URL del artículo que se estaba renderizando. Consultaba una tabla de configuración interna donde cada sección del sitio tenía asignada una URL de referencia para el canonical. La lógica original pretendía generar automáticamente el valor del canonical a partir de una tabla de configuración interna. Sin embargo, la implementación nunca llegó a utilizar la URL del propio artículo como canonical, sino una URL de referencia almacenada para cada sección. Era un planteamiento incorrecto desde el origen, aunque permaneció oculto mientras la configuración interna siguió siendo coherente.

El problema apareció cuando, hacía aproximadamente dieciséis meses, el equipo creó dos nuevas subsecciones —cultura y agenda— separando lo que antes era una única sección llamada «ocio y cultura». Al añadir esas subsecciones en el panel, alguien insertó las entradas en la tabla de configuración con los IDs de sección intercambiados. Cultura apuntaba a la URL de referencia de agenda, y agenda apuntaba a la de cultura.

Tabla de configuración interna — estado durante el período afectado

| ID sección | Nombre sección | URL canonical de referencia asignada        |
|------------|----------------|---------------------------------------------|
| 14         | cultura        | /agenda/feria-medieval-septiembre-2024      |  ← incorrecto
| 15         | agenda         | /cultura/ciclo-teatro-otono-programa        |  ← incorrecto

Pero había un segundo nivel de daño. La URL de referencia no era fija. El módulo la actualizaba automáticamente cada vez que se publicaba un artículo nuevo en esa sección, apuntando al último artículo publicado como referencia. Eso significaba que el canonical de todos los artículos de cultura apuntaba al artículo más reciente de agenda, y viceversa. Y ese valor cambiaba con cada publicación, de modo que en cada nueva pasada de rastreo, Google se encontraba con una instrucción distinta para las mismas URLs, acumulando confusión en el índice con el tiempo.

El resultado era una cadena de señales contradictorias que se renovaba sola. Cada artículo nuevo que entraba en esas secciones no solo estaba mal declarado: también actualizaba el destino incorrecto al que apuntaban todos los artículos anteriores. Google recibía instrucciones distintas cada vez que volvía a rastrear las mismas páginas. No estaba ante contenido duplicado real. Estaba ante un sitio que le pedía, de forma constante y equivocada, que redistribuyera la prioridad de indexación entre artículos sin ninguna relación entre sí.

Las páginas de cultura y agenda no estaban perdiendo visibilidad porque su contenido fuera débil. Estaban perdiendo visibilidad porque el sitio les ordenaba a Google que mirara a otro lado.

Reescribir la instrucción sin desestabilizar lo que sí funcionaba

El alcance del problema estaba claro: la tabla de configuración tenía los IDs cruzados, el módulo actualizaba el valor dinámicamente con cada publicación, y 53 artículos ya tenían canonicals erróneos registrados en el índice de Google. La corrección tenía que actuar en dos frentes: la fuente del error y las páginas ya afectadas.

Cuánto tocar y por dónde empezar sin abrir otro frente

La tentación inicial del equipo técnico era intervenir directamente en la lógica del módulo y cambiar el comportamiento completo de la función: en lugar de consultar la tabla de referencia, que el canonical de cada artículo apuntara a su propia URL. Era la solución más limpia a largo plazo y técnicamente la más correcta. El problema era el riesgo de ejecución: ese módulo afectaba al <head> de todos los artículos del sitio, no solo de las secciones con el error. Un fallo en el despliegue podía introducir canonicals vacíos o mal formados en cientos de páginas que en ese momento estaban indexadas correctamente.

Hacer ese cambio de golpe, en un sitio con publicación diaria y sin entorno de preproducción documentado, era asumir un riesgo desproporcionado al problema que se quería resolver.

Así que la decisión fue otra: corregir primero los valores de la tabla de configuración para que cada sección apuntara a su propia URL de portada, y además desactivar el comportamiento dinámico que sobreescribía ese valor con cada nueva publicación. Ese segundo ajuste era imprescindible: sin él, el módulo seguiría actualizando la referencia con el último artículo publicado, aunque ahora dentro de la sección correcta. El resultado no sería un canonical autorreferente —cada artículo apuntando a sí mismo— sino un canonical estable que señalaba a la portada de su sección.

No era la solución ideal, pero sí era coherente y predecible. Google recibiría una instrucción consistente en lugar de una que cambiaba con cada publicación. La refactorización completa del módulo, para que cada artículo generara su propio canonical autorreferente, quedaba para la segunda fase.

Esa segunda fase era importante, pero no urgente. Detener el daño activo era lo primero.

Una vez aplicadas las dos correcciones —los IDs de la tabla y la desactivación del comportamiento dinámico— todos los artículos nuevos publicados en cultura y agenda empezaron a generar la etiqueta canonical apuntando de forma estable a la portada de su propia sección. No era un canonical autorreferente, pero era consistente y correcto: Google dejaba de recibir una instrucción diferente en cada visita y empezaba a leer una señal que no se movía.

Para la supervisión continua, se configuró un rastreo programado semanal con Screaming Frog sobre los últimos 30 artículos publicados en cada sección, verificando que el valor del canonical coincidía con la URL de portada asignada a esa sección. Cualquier desviación respecto a ese valor esperado activaría una alerta antes de que el problema pudiera volver a acumularse. La comprobación de autorreferencia —que cada artículo apuntara a su propia URL— quedaba pendiente para después de la segunda fase, una vez refactorizado el módulo. Supervisar algo distinto a lo que el sistema estaba produciendo habría generado falsas alarmas en cada rastreo.

Cuatro semanas después de la corrección, el estado «Duplicada, Google ha elegido una versión canónica diferente a la del usuario» había desaparecido en 48 de las 53 URLs. Las cinco restantes correspondían a artículos publicados durante el período de mayor frecuencia de actualización dinámica, que Google tardaba más en re-rastrear. Sin intervención adicional, ese número siguió bajando solo en las semanas siguientes.

Una corrección que no tiene supervisión posterior es una corrección que puede volver a romperse en silencio. Eso no cambia aunque el origen del error quede resuelto.