El contenido duplicado del impostor · Serpion 016

La web de una aseguradora local. Nada alarmante a primera vista: estructura razonablemente ordenada, páginas de servicios bien diferenciadas, textos trabajados con criterio. Habían invertido tiempo en el contenido y se notaba. Pero el rendimiento orgánico llevaba meses plano. No una caída. No un accidente. Solo estancamiento silencioso, del tipo que no activa ninguna alerta pero que tampoco avanza.

Lo primero que llama la atención cuando revisas algo así no es el error en sí, sino la sensación de que los números no suman. Las páginas existían, Google las visitaba, los textos no eran malos. Y sin embargo, Search Console mostraba señales de contenido duplicado que nadie había detectado ni documentado. Había URLs en estados extraños, grupos de páginas con comportamientos inconsistentes, y una especie de ruido de fondo que alguien en algún momento había decidido ignorar.

Demasiadas URLs apuntando al mismo sitio sin que ninguna tomara el control. Eso no me cuadraba. Si el contenido era sólido y el sitio llevaba años activo, algo tenía que estar interfiriendo antes de que las señales llegaran donde debían.

El rastro del contenido duplicado en una web sin señales claras

Empecé por donde suelo: los datos de cobertura en Google Search Console. El informe de páginas indexadas no era catastrófico en números absolutos, pero tenía una distribución rara. Alrededor de veinte URLs aparecían bajo el estado "Duplicate without user-selected canonical". No en páginas secundarias ni en secciones menores, sino en las áreas de servicios, justo donde estaban los textos más trabajados del sitio.

La primera hipótesis que barajé fue thin content. Algunas de esas páginas parecían cortas visualmente, y era tentador pensar que Google las estaba agrupando por falta de sustancia. Revisé el recuento de palabras en los documentos afectados: ninguno bajaba de 290 palabras, varios superaban las 400. Pero el número de palabras no permitía confirmar ni descartar por sí solo una situación de thin content. Sin embargo, los primeros indicios apuntaban a otro problema: varias URLs estaban ofreciendo exactamente el mismo contenido. La investigación tenía que continuar por ahí.

Lo que sí seguía en pie era el patrón: grupos de páginas con el mismo comportamiento, todas afectadas en las mismas secciones, ninguna con una señal canónica clara que le dijera a Google cuál debía priorizar. Esto no era ruido aleatorio. Era un patrón con una causa detrás.

Ahí lancé un rastreo completo con Screaming Frog. Lo que apareció confirmó la sospecha: el informe de contenido duplicado mostraba hashes idénticos en grupos de tres a cinco URLs distintas. El mismo hash. El mismo contenido exacto. Rutas diferentes. Google estaba leyendo el mismo texto desde varias direcciones y sin instrucción alguna sobre cuál era la buena.

https://www.ejemplo-seguro.es/seguros/hogar/
https://www.ejemplo-seguro.es/seguros/hogar/?ref=menu
https://www.ejemplo-seguro.es/seguros/hogar/?origen=banner
https://www.ejemplo-seguro.es/hogar/contratacion/

Cuatro URLs. El mismo contenido. Cuatro caminos que conducían al mismo texto sin que el sitio indicara cuál debía ser la versión principal. Google tenía que tomar esa decisión por su cuenta.

Las URLs donde el contenido duplicado se volvía invisible para el rastreador

El patrón se repetía en cinco grupos de páginas, todos relacionados con servicios: hogar, automóvil, vida, salud y decesos. En cada grupo, entre tres y cinco URLs servían contenido con hash idéntico sin ninguna etiqueta canónica declarada. No había instrucción de ningún tipo. El rastreador llegaba, leía el contenido y Google tenía que decidir por su cuenta qué versión debía tratar como referencia, al no encontrar una preferencia canónica declarada por el sitio.

En ausencia de una señal canónica declarada, Google agrupaba las versiones duplicadas y elegía por su cuenta cuál debía considerar principal. El problema era que esa elección no tenía por qué coincidir con la URL que el negocio quería posicionar. Las señales que el sitio enviaba no estaban suficientemente alineadas para orientar esa decisión.

Google no estaba fallando. Estaba obedeciendo. Cuando el sitio no declara una preferencia, el sistema toma la suya propia. Y esa decisión autónoma no siempre coincide con la que el proyecto necesita.

En Search Console aparecían dos situaciones distintas. Algunas URLs figuraban como "Duplicate without user-selected canonical": Google había identificado el contenido duplicado y seleccionado otra versión como canónica. Otras aparecían como "Rastreada: actualmente sin indexar", un estado que indicaba que Google había visitado esas páginas, pero no las había incorporado al índice. Aunque podían coexistir dentro del mismo escenario, cada estado requería interpretar su causa por separado.

Grupo de URLs (ejemplo — seguro de hogar):

URL A: /seguros/hogar/               → URL seleccionada por Google
URL B: /seguros/hogar/?ref=menu      → duplicada
URL C: /seguros/hogar/?origen=banner → duplicada
URL D: /hogar/contratacion/          → duplicada

Canonical declarada por el sitio: ninguna
Hash de contenido: d3f82a19c... (idéntico en las 4)

Hasta aquí la investigación había confirmado el síntoma con bastante detalle. Pero todavía no tenía claro de dónde salían estas variaciones de URL ni por qué el sistema las generaba. Ahí estaba la pregunta que todavía quedaba abierta.

Cuando el impostor tiene tu misma cara

La causa estaba en cómo el CMS del sitio gestionaba las rutas internas. La plantilla de servicios generaba múltiples versiones de cada URL según el punto de entrada del usuario: si llegabas desde el menú principal, desde un banner interno o desde un enlace de otra sección, el sistema añadía parámetros a la URL sin limpiarlos ni redirigirlos hacia la versión canónica. Además, una reorganización interna del árbol de contenido había dejado activa una ruta de URL antigua junto a la nueva, y ambas servían el mismo documento sin que ninguna de las dos tuviera prioridad declarada. La ruta heredada no era un error de configuración evidente: respondía con estado 200, tenía contenido y el sistema la trataba como cualquier otra página activa.

El resultado era exactamente lo que mostraba Screaming Frog: contenido duplicado distribuido en cinco grupos, cada uno con su propio conjunto de URLs activas. No era intención de nadie. Era la consecuencia lógica de una plantilla que no gestionaba los parámetros de seguimiento y de una migración de rutas que se había hecho a medias.

Una URL duplicada no siempre es un error intencionado. A veces es el rastro de algo que se hizo bien en su momento, pero que nadie actualizó cuando el contexto cambió.

El impacto SEO era concreto: las señales que debían apuntar a /seguros/hogar/ estaban repartidas entre varias versiones. Google tenía que decidir cuál representaba mejor ese contenido, y podía elegir una URL distinta de la que el negocio quería posicionar. El rastreador gastaba visitas en todas ellas. Los enlaces internos que apuntaban a versiones distintas no convergían. Y el resultado era una pérdida de control sobre qué URL aparecía en los resultados de búsqueda.

Esto no era un problema de contenido pobre. Era un problema de identidad: el mismo texto vivía en demasiados sitios a la vez, y ninguno de esos sitios era reconocible como el principal porque el propio sitio no había tomado esa decisión.

Limpiar el mapa antes de que Google lo aprenda de nuevo

El plan de acción tenía que resolver tres cosas a la vez: indicar a Google cuál era la URL canónica de cada grupo, eliminar el acceso a las variantes que no debían existir y limpiar los rastros de las rutas antiguas que habían quedado activas sin intención.

Primero el canonical, luego el corte limpio

La primera opción que valoré fue añadir etiquetas noindex a las URLs duplicadas. Es una corrección rápida: le dices a Google que no indexe esas versiones y asunto resuelto en apariencia. Pero hay un problema con ese enfoque: el noindex excluye la página del índice, pero no impide que el rastreador siga visitándola. Las URLs seguirían existiendo, seguirían recibiendo visitas del bot, y el rastreador seguiría distribuyendo tiempo entre versiones que no aportaban nada. Eso era exactamente lo que ya estaba pasando. Cambiar el estado sin limpiar las rutas no resolvía el problema de fondo.

Lo que sí tenía sentido era ir en orden: primero, identificar la URL principal de cada grupo e implementar la etiqueta canónica en las versiones duplicadas que debían seguir siendo accesibles. Segundo, implementar redirecciones 301 desde las variantes de parámetro y las rutas antiguas que ya no debían funcionar como destinos independientes. Tercero, corregir en el panel de configuración interna la forma en que la plantilla generaba los parámetros de seguimiento, para que las nuevas visitas no volvieran a crear variantes sin controlar.

El riesgo de ejecutar esto mal era real. Si las redirecciones 301 apuntaban a la URL equivocada dentro de un grupo, toda la señal acumulada por las variantes iba al destino incorrecto. Había que tener claro cuál era la URL principal antes de tocar nada, y eso requería revisar el enlazado interno del sitio para identificar cuál de las versiones recibía más referencias internas y cuál era la que el sitio debía proyectar hacia fuera.

Con ese mapa claro, la ejecución fue metódica: canonical en las páginas duplicadas que debían seguir siendo accesibles, 301 desde las variantes con parámetros y las rutas antiguas hacia sus respectivas URLs principales, corrección de la configuración del sistema y revisión del sitemap XML para eliminar las URLs duplicadas que seguían declaradas como válidas. Cualquier URL duplicada que siguiera apareciendo en el sitemap enviaba una señal incoherente con la intención de consolidar el contenido en una única versión. El sitemap debía reflejar las URLs principales elegidas para cada grupo.

Dos semanas después del primer bloque de cambios, Search Console empezaba a actualizar los estados. Las URLs duplicadas que debían seguir siendo accesibles comenzaron a pasar de "Duplicate without user-selected canonical" a "Página alternativa con etiqueta canónica adecuada", mientras que las variantes a las que se habían aplicado redirecciones 301 empezaron a figurar como páginas con redirección. Progresivamente, algunas de las URLs principales volvieron al estado indexado con la señal correcta. No fue un cambio instantáneo —Google necesita tiempo para rerastrear y reevaluar—, pero la dirección era la correcta desde los primeros datos.

Cuando una web lleva meses enviando señales contradictorias, la corrección no produce resultados en días. El rastreador tiene que volver, leer la nueva instrucción, procesarla y actualizar su modelo del sitio. Acelerar ese proceso dependía en parte de mantener el sitemap limpio y de reforzar el enlazado interno hacia las URLs canónicas para que el bot tuviera motivos claros para priorizarlas.