Corregir contenido duplicado en WordPress: canónica, barra final y www sin canibalización

octubre 30, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 6

¿Te fue útil?

Algunos sitios WordPress no tienen un problema de SEO. Tienen una crisis de identidad de URL.

Si tu contenido es accesible como cuatro URLs diferentes (HTTP/HTTPS × www/non-www, además de la barra final opcional), Google no “elige la mejor” como la gente espera. Prueba, se cubre y a veces divide señales. Mientras tanto, tus propias páginas compiten entre sí como compañeros de trabajo que “colaboran” creando hojas de cálculo paralelas.

Por qué ocurre el lío de URLs duplicadas en WordPress

El contenido duplicado en WordPress no suele ser “alguien copió mi entrada”. Es tu propio sitio generando múltiples URLs válidas que muestran los mismos bytes. Desde una perspectiva de fiabilidad, eso no es solo “SEO”. Es enrutamiento inconsistente e identidad inconsistente. Los sistemas odian eso.

Qué significa realmente “contenido duplicado” aquí

Los motores de búsqueda no indexan “páginas”. Indexan URLs. Si el mismo contenido aparece en varias URLs, obtienes:

Dilución de señales: backlinks y enlaces internos repartidos entre variantes.
Inflación de index: presupuesto de rastreo consumido en duplicados en lugar de contenido nuevo.
Canibalización: páginas similares (o duplicadas) intercambian posiciones en los rankings, especialmente en términos principales.
Infierno de depuración: no puedes saber cuál URL es “la” URL porque el propio sitio no actúa como si lo supiera.

Los sospechosos habituales: protocolo, host, barra y plugins “útiles”

Patrones comunes de URLs duplicadas en WordPress:

HTTP vs HTTPS (a menudo por una migración parcial o redirección de borde mal configurada).
www vs non-www (no se fuerza un host canónico).
Barra final vs sin barra (el servidor y los ajustes de enlaces permanentes de WordPress no están de acuerdo).
Archivos index: / vs /index.php vs /index.html restantes.
Cadenas de consulta: parámetros UTM, ordenación, paginación, IDs de sesión, IDs de clics publicitarios.
Archivos de archivo: archivos de autor, por fecha, etiquetas que replican extractos o contenido completo de entradas.
Páginas de adjuntos: URLs de medios de WordPress que reflejan la imagen pero crean páginas delgadas.

La canonicalización no es un “ajuste de SEO”. Es un contrato de enrutamiento. Decide cuál debe ser la canónica, aplícalo en el borde y haz que WordPress genere enlaces internos coherentes. Haz esas tres cosas y el resto se vuelve aburrido, que es exactamente la meta.

Datos interesantes y contexto histórico (por qué se repite)

Los servidores web tempranos trataban “/dir” y “/dir/” de forma distinta porque uno parecía un archivo y el otro un directorio. Ese legado todavía se filtra en pilas modernas.
El elemento canonical de Google apareció en 2009 tras años de sitios luchando con URLs duplicadas por parámetros de seguimiento y sindicación.
WWW no es obligatorio; es una convención de nombre de host. Pero los CDN y las prácticas de ámbito de cookies en los 2000 hicieron que “www” fuera una elección operativa popular.
Los permalinks de WordPress cambiaron las reglas al permitir “URLs bonitas”, pero también facilitaron servir la misma entrada desde varias rutas cuando las reglas de reescritura se desincronizan.
La barra final se volvió casi una religión en parte porque el manejo de directorios de Apache (y luego el comportamiento de redirección canónica de WordPress) creó patrones predecibles que los SEOs estandarizaron.
Las migraciones HTTP→HTTPS históricamente causaron duplicación masiva porque se añadió TLS pero se olvidó forzar la redirección y actualizar enlaces internos, dejando ambos protocolos activos durante meses.
“Duplicate, Google chose different canonical” en Search Console es una versión moderna de una historia antigua: si no eliges una URL única, Google lo hará. A veces elegirá la que odias.
Las etiquetas canonical son sugerencias, no mandatos—funcionan mejor cuando las respaldan redirecciones consistentes y enlaces internos.
Los CDN introdujeron un nuevo modo de fallo: puedes tener redirecciones perfectas en el origen, pero el borde cachea la variante equivocada o evita la lógica de redirección por “rendimiento”.

Guía rápida de diagnóstico (comprueba esto primero)

Si estás de guardia por “SEO cayó” o “Google indexando URLs raras”, no deambules por el administrador de WordPress haciendo clic. Trátalo como triaje de incidentes: identifica la política canónica, prueba su aplicación y luego limpia los residuos (sitemaps, enlaces internos, caches).

Comprueba qué hace la página de inicio en sus variantes.
- Prueba: http vs https, www vs non-www, con barra vs sin barra.
- Objetivo: cada variante no canónica debería 301 hacia una URL canónica en un solo salto.
Comprueba la URL de una entrada representativa y la de una categoría/etiqueta representativa.
- Las entradas suelen comportarse; los archivos a menudo no.
- Busca respuestas 200 en múltiples variantes o cadenas de redirección.
Revisa las etiquetas canonical y cabeceras en la URL canónica.
- Objetivo: <link rel="canonical" ...> coincide con la URL final tras redirecciones.
- Sin contradicciones: no canonical que apunte a host/protocolo/barra no canónicos.
Comprueba que los enlaces internos sean coherentes.
- Si tu HTML enlaza a URLs no canónicas, estás votando contra ti mismo.
Revisa sitemaps y feeds.
- Las URLs del sitemap deben ser canónicas. Si tu sitemap lista URLs no canónicas, estás enviando duplicados a propósito.
Verifica el comportamiento en la capa de borde (CDN/WAF/load balancer).
- Asegúrate de que las redirecciones ocurran antes del cacheo, y que la clave de caché no divida por host/protocolo inesperadamente.

Idea parafraseada de Werner Vogels: Todo falla, todo el tiempo; diseña asumiendo fallos. La canonicalización es exactamente eso—supón que alguien accederá a la URL equivocada y haz que el sistema se corrija solo.

Etiquetas canonical vs redirecciones vs enlaces internos (quién gana)

Oirás “solo añade una etiqueta canonical”. Eso es como decir “solo añade monitorización” mientras la base de datos está en llamas. Las etiquetas canonical importan, pero no imponen. La imposición son las redirecciones y los enlaces coherentes.

Redirecciones: el agente de tráfico

Una redirección 301 dice: “esta URL no es la correcta; ve aquí”. Los motores generalmente consolidan señales a través de 301 con el tiempo. También evita que los usuarios marquen variantes basura como favoritos.

Preferencia operativa: la normalización de host/protocolo/barra debe ocurrir en el borde (nginx/Apache/CDN), antes de que WordPress ejecute PHP. Es más rápido, más barato y menos frágil.

Etiquetas canonical: la papeleta de votación

El elemento link canonical es una pista embebida en el HTML. Ayuda cuando no puedes redirigir (por ejemplo, variaciones por parámetros que quieres mantener accesibles). También ayuda a los motores a consolidar duplicados que aún existen.

Regla: las etiquetas canonical deben coincidir con la URL final redirigida. Si canonicalizas a una URL que a su vez redirige, estás enviando señales mixtas.

Enlaces internos: la cultura de la empresa

Los enlaces internos son lo que tu sistema “cree”. Si tu menú, migas de pan y enlaces inline apuntan a variantes mezcladas, seguirás generando rutas de rastreo hacia duplicados aunque existan redirecciones. Quieres enlaces internos limpios para que los rastreadores gasten su tiempo en páginas reales.

¿Cuál importa más?

Para host/protocolo/barra: redirecciones primero, luego consistencia de enlaces internos, luego etiquetas canonical. Las etiquetas canonical son valiosas, pero son las menos autoritativas de las tres.

Chiste #1: La canonicalización es como las convenciones de nombres—todos acuerdan que importan, hasta que tienen que renombrar algo.

Elige tu política de “una URL verdadera”

No puedes arreglar duplicaciones hasta que decidas cómo es lo “correcto”. Elige una política y escríbela. Esta es la parte que la mayoría de equipos omite, y luego se preguntan por qué la solución se deshace sola.

Política predeterminada recomendada

HTTPS en todas partes (sin excepciones).
Elige un hostname: o www o sin www. Me da igual cuál. Me importa que esté aplicada.
Consistencia de barra final:
- Para los “pretty permalinks” de WordPress, la elección común es barra para URLs tipo directorio (entradas/páginas): /post-name/.
- Sea cual sea tu elección, asegúrate de que el servidor web y WordPress estén de acuerdo.
No archivos index: normaliza /index.php a /.
Parámetros: permite parámetros de marketing para analítica, pero no dejes que creen duplicados indexables.

Cómo afecta esto a la canibalización

Cuando existen duplicados, Google puede posicionar diferentes variantes en distintos momentos. Eso parece “canibalización”, porque tu propio sitio sigue intercambiando qué URL es elegible. Una vez que consolidas a una canónica, dejas de competir contigo mismo y empiezas a competir con los demás. Mucho más sano.

Tareas prácticas con comandos: demuestra el problema y luego arréglalo

Abajo hay tareas prácticas que puedes ejecutar desde un shell. Cada tarea incluye: un comando, salida realista, lo que significa y la decisión que tomarás.

Supuestos: puedes ejecutar comandos desde una estación de trabajo o un host bastión. Reemplaza example.com por tu dominio.

Task 1: Check redirect behavior across protocol/host variants

cr0x@server:~$ for u in http://example.com https://example.com http://www.example.com https://www.example.com; do echo "== $u =="; curl -sI "$u" | egrep -i 'HTTP/|location:|canonical'; done
== http://example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://example.com ==
HTTP/2 301
location: https://www.example.com/
== http://www.example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://www.example.com ==
HTTP/2 200

Qué significa: Ideal: tres variantes 301 hacia la canónica, la canónica responde 200. No hay bucles de redirección, ni 200 en no canónicas.

Decisión: Si alguna no canónica devuelve 200, necesitas redirecciones en el borde. Si ves 302, cámbialo a 301 salvo que sea una migración temporal.

Task 2: Detect redirect chains (one hop only)

cr0x@server:~$ curl -sIL http://example.com | awk 'BEGIN{c=0} /^HTTP/{c++; print "Hop " c ": " $0} /^location:/{print "  " $0}'
Hop 1: HTTP/1.1 301 Moved Permanently
  location: https://example.com/
Hop 2: HTTP/2 301
  location: https://www.example.com/
Hop 3: HTTP/2 200

Qué significa: Tres saltos. No es catastrófico, pero es descuidado y lento a escala.

Decisión: Colapsa en una sola redirección: HTTP+sin-www debe ir directamente a HTTPS+www (o a tu canónica elegida).

Task 3: Verify canonical tag matches final URL

cr0x@server:~$ curl -s https://www.example.com/some-post/ | grep -i '<link rel="canonical"' | head -n 1
<link rel="canonical" href="https://example.com/some-post/" />

Qué significa: La página se sirve en www pero el canonical apunta a non-www. Es una contradicción.

Decisión: Arregla las opciones “Dirección del sitio (URL)” y/o la configuración del plugin SEO para que el canonical use el host canónico. También asegúrate de corregir URLs codificadas en el theme.

Task 4: Check trailing slash behavior on a post

cr0x@server:~$ curl -sI https://www.example.com/some-post | egrep -i 'HTTP/|location:'
HTTP/2 301
location: https://www.example.com/some-post/

Qué significa: Sin barra redirige a con barra. Bien (si la política es usar barra).

Decisión: Asegura que este comportamiento sea consistente en entradas, páginas y categorías. La inconsistencia es cómo se generan duplicados.

Task 5: Check trailing slash behavior on a category

cr0x@server:~$ curl -sI https://www.example.com/category/widgets | egrep -i 'HTTP/|location:'
HTTP/2 200

Qué significa: La categoría sin barra devuelve 200. Si /category/widgets/ también devuelve 200, tienes duplicados.

Decisión: Decide una regla y aplícala (típicamente barra). Configura reglas de reescritura en nginx/Apache y verifica la estructura de enlaces permanentes de WordPress.

Task 6: Spot “index.php” duplicates

cr0x@server:~$ curl -sI https://www.example.com/index.php | egrep -i 'HTTP/|location:'
HTTP/2 200

Qué significa: Tu página de inicio es accesible vía /index.php. Es un duplicado clásico.

Decisión: Añade una redirección 301 de /index.php a / en el nivel del servidor web (o la redirección canónica de WordPress, pero a nivel de servidor es más limpio).

Task 7: Check headers for caching of redirects (CDN traps)

cr0x@server:~$ curl -sI http://example.com/some-post/ | egrep -i 'HTTP/|location:|cache-control:|age:|via:'
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/some-post/
cache-control: max-age=3600
age: 3540
via: 1.1 varnish

Qué significa: La redirección está cacheada por una hora y ya lleva tiempo. Bien si es correcta; peligroso si es errónea porque persiste.

Decisión: Si estás cambiando reglas canónicas activamente, reduce el TTL de cache de redirecciones temporalmente o purga caches de borde tras los cambios.

Task 8: Check sitemap URLs for canonical host/protocol

cr0x@server:~$ curl -s https://www.example.com/sitemap_index.xml | head -n 20
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>http://example.com/post-sitemap.xml</loc>
    <lastmod>2025-12-01T12:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

Qué significa: El sitemap anuncia URLs http://example.com. Es un daño autoinfligido.

Decisión: Corrige las URLs del sitio en WordPress, la configuración del plugin SEO y asegúrate de que el generador de sitemaps use HTTPS+host canónico.

Task 9: Crawl for non-canonical internal links (quick and dirty)

cr0x@server:~$ curl -s https://www.example.com/ | grep -Eo 'href="https?://[^"]+"' | head
href="http://example.com/about/"
href="https://example.com/contact/"
href="https://www.example.com/blog/"

Qué significa: La página de inicio contiene enlaces internos absolutos mezclados (http y non-www). Eso sigue generando duplicados.

Decisión: Actualiza la URL del sitio en WordPress, arregla plantillas del theme y ejecuta un search/replace en la base de datos para URLs antiguas.

Task 10: Audit WordPress configured URLs via WP-CLI

cr0x@server:~$ wp option get siteurl && wp option get home
https://example.com
https://example.com

Qué significa: WordPress piensa que la canónica es non-www.

Decisión: Si tu canónica elegida es www, establece ambas opciones a https://www.example.com, y luego asegúrate de que las redirecciones coincidan.

Task 11: Fix WordPress home/siteurl safely (and know what you just changed)

cr0x@server:~$ wp option update home 'https://www.example.com' && wp option update siteurl 'https://www.example.com'
Success: Updated 'home' option.
Success: Updated 'siteurl' option.

Qué significa: WordPress generará URLs canónicas y enlaces internos usando www (suponiendo que themes/plugins lo respeten).

Decisión: Vuelve a probar inmediatamente las etiquetas canonical y la salida del sitemap. Luego limpia caches (cache de página + CDN) para que el HTML antiguo no siga filtrando hosts mezclados.

Task 12: Find mixed-content / old host URLs in the database (spot check)

cr0x@server:~$ wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%http://example.com/%' LIMIT 5;"
+----+-----------------------------+
| ID | post_title                  |
+----+-----------------------------+
| 12 | About Us                    |
| 87 | How to Choose a Widget      |
| 91 | Pricing                     |
+----+-----------------------------+

Qué significa: Existen enlaces heredados codificados directamente en el contenido de las entradas. Las redirecciones atraparán a los usuarios, pero los rastreadores seguirán descubriendo URLs no canónicas.

Decisión: Ejecuta un search-replace con cuidado (con conciencia de serialización). Es preferible usar wp-cli search-replace y probar sobre una copia de seguridad primero.

Task 13: Perform a serialization-safe search/replace for host/protocol

cr0x@server:~$ wp search-replace 'http://example.com' 'https://www.example.com' --all-tables --dry-run
Success: Made 128 replacements.

Qué significa: La ejecución en seco muestra cuántas sustituciones se harían, sin cambiar datos.

Decisión: Si las sustituciones parecen razonables, ejecútalo otra vez sin --dry-run. Si el número asusta, reduce el alcance e inspecciona muestras primero.

Task 14: Validate robots directives aren’t fighting you

cr0x@server:~$ curl -sI https://www.example.com/some-post/ | egrep -i 'x-robots-tag:|HTTP/'
HTTP/2 200

Qué significa: No hay cabecera X-Robots-Tag. Bien.

Decisión: Si ves X-Robots-Tag: noindex en páginas canónicas, para y arregla eso antes de cualquier otra cosa. No puedes canonicalizar lo que le dijiste a Google que no indexe.

Task 15: Check server config for canonical redirects (nginx)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'server_name|return 301|rewrite' | head -n 30
42:    server_name example.com;
47:    return 301 https://www.example.com$request_uri;
88:    server_name www.example.com;

Qué significa: Hay un bloque de servidor dedicado que redirige non-www a www.

Decisión: Confirma que la redirección ocurre tanto en vhosts HTTP como HTTPS. También asegúrate de que no cause un segundo salto (ver Tarea 2).

Task 16: Confirm Apache is not doing “helpful” MultiViews content negotiation

cr0x@server:~$ apachectl -M 2>/dev/null | grep -i negotiation
negotiation_module (shared)

Qué significa: La negociación de contenido está habilitada; si MultiViews está activado, Apache puede mapear múltiples URLs a un mismo recurso de formas sorprendentes.

Decisión: En vhosts de WordPress, desactiva MultiViews a menos que tengas una razón específica. Causa enrutamiento duplicado y depuración dolorosa.

Ajustes de WordPress que sabotean silenciosamente la canonicalización

1) Desajuste entre “Dirección de WordPress” y “Dirección del sitio”

En Ajustes → Generales, WordPress tiene dos campos de URL:

Dirección de WordPress (URL) (siteurl): dónde residen los archivos core de WordPress.
Dirección del sitio (URL) (home): lo que los visitantes deben escribir.

Por lo general deberían coincidir. Si no lo hacen, puedes provocar etiquetas canonical mezcladas, enlaces internos mixtos y redirecciones extrañas.

2) Estructura de enlaces permanentes y barras finales

WordPress generalmente espera barras finales para los permalinks “bonitos”. Pero tu servidor web puede no hacerlo. Si nginx está configurado para tratar /post y /post/ como distintos, puedes acabar con ambos devolviendo 200 según las reglas de reescritura.

Haz esto: elige una política de barra final y fuerza su aplicación en el nivel del servidor. Luego verifica que las redirecciones canónicas de WordPress no lo contradigan.

3) Plugins SEO: poderosos y ocasionalmente equivocados

Yoast, Rank Math y similares suelen manejar bien las etiquetas canonical. Los fallos suelen venir de:

Cambio de URL del sitio pero el plugin tiene en caché la base canonical antigua.
Código personalizado que filtra la salida canonical incorrectamente.
El plugin genera canonical para páginas paginadas, archivos o tipos de contenido personalizado de forma que entra en conflicto con tu plan de indexación.

4) Archivos que duplican contenido

Los archivos no son inherentemente malos. Pero a menudo se convierten en duplicados cuando:

El theme imprime contenido completo de la entrada en páginas de categoría/etiqueta (no extractos).
Los archivos de autor/fecha replican el listado del blog y no ofrecen valor único.
Las páginas de adjuntos indexan como contenido delgado con el mismo título y sin contexto.

Orientación opinada: si tu sitio no es una publicación con páginas de archivo que aporten valor, marca archivos de autor/fecha como noindex y redirige las URLs de adjuntos al archivo multimedia o a la entrada padre.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: aparecen versiones www y non-www en resultados de Google

Causa raíz: no se fuerza un host canónico en el borde; enlaces internos o sitemap filtran host antiguos.

Solución: aplica un hostname único con 301 en vhosts HTTP y HTTPS; actualiza home/siteurl en WordPress; regenera el sitemap; purga caches.

2) Síntoma: “Duplicate, Google chose different canonical” en Search Console

Causa raíz: etiquetas canonical contradicen redirecciones, o existen múltiples variantes con 200 (barra/no-barra, index.php, parámetros).

Solución: haz las redirecciones deterministas; asegura que la etiqueta canonical apunte a la URL final; elimina duplicados que devuelven 200; normaliza enlaces internos.

3) Síntoma: fluctuaciones diarias en el ranking para la misma página

Causa raíz: canibalización entre variantes de URL o páginas de archivo casi duplicadas. Google rota cuál URL le inspira confianza.

Solución: consolida variantes con 301; considera noindex para archivos de bajo valor; asegura que el sitemap contenga solo URLs canónicas.

4) Síntoma: bucle de redirección entre http y https

Causa raíz: desajuste de terminación SSL: el CDN fuerza HTTPS al origen mientras el origen fuerza HTTP, o WordPress piensa que está en HTTP detrás de un proxy.

Solución: configura correctamente cabeceras proxy (X-Forwarded-Proto), haz que WordPress las respete y aplica redirecciones en la capa correcta (preferiblemente en el borde).

5) Síntoma: cadena de redirección de 2–4 saltos en cada petición

Causa raíz: reglas separadas para HTTP→HTTPS, non-www→www y normalización de barra aplicadas en serie entre CDN y origen.

Solución: colapsa a una sola redirección de canonicalización. Haz que el primer punto de contacto (CDN o LB) la ejecute en un solo salto.

6) Síntoma: sitemap contiene URLs HTTP después de migrar a HTTPS

Causa raíz: home/siteurl de WordPress no actualizado, o plugin con base URL en caché, o proxy inverso que no reenvía correctamente el esquema.

Solución: corrige home/siteurl, limpia caches del plugin, verifica X-Forwarded-Proto y la detección SSL de WordPress.

7) Síntoma: páginas de categoría outrankean entradas inesperadamente

Causa raíz: archivos de categoría indexables con títulos/contenido similar; enlaces internos y migas que impulsan el archivo; señales canonical débiles.

Solución: invierte en las páginas de categoría como landing pages reales (texto único, contenido curado) o márcalas noindex y mantén el foco en las entradas.

8) Síntoma: páginas de adjuntos aparecen como resultados delgados

Causa raíz: páginas de adjuntos indexables por defecto en algunas configuraciones; canonical puede apuntar a sí misma.

Solución: redirige páginas de adjuntos a la entrada padre o al archivo multimedia; márcalas noindex vía plugin SEO si hace falta.

Tres microcasos corporativos desde el terreno

Microcaso 1: El incidente causado por una suposición errónea

La compañía había “estandarizado” en HTTPS años antes. Todos asumían que el sitio era solo HTTPS porque el navegador mostraba el candado y el equipo de marketing solo compartía enlaces HTTPS. Manta de falsa seguridad clásica.

Luego un nuevo equipo de seguridad desplegó un WAF de borde. Durante el despliegue, añadieron una regla para omitir redirecciones en “health checks” y “tráfico de bots” para reducir carga en el origen. No fue malicioso. Fue solo pegar una regla con wildcard de user-agent que afectó más de lo previsto.

Resultado: los rastreadores empezaron a recibir respuestas 200 en HTTP para grandes secciones del sitio. El HTML seguía incluyendo enlaces HTTPS, así que los humanos nunca lo notaron. Google lo notó de inmediato. Semanas después, Search Console se llenó de duplicados y desajustes canónicos. El tráfico se desplazó, no se desplomó—peor, porque parecía que el contenido “simplemente dejó de funcionar”.

La solución no fue una configuración mágica de SEO. Fue borrar la omisión, forzar HTTP→HTTPS en el borde incondicionalmente y purgar caches. La lección: nunca asumas que “migramos a HTTPS” significa que el sistema lo aplica actualmente. Las suposiciones no redirigen tráfico; la configuración sí.

Microcaso 2: La optimización que salió mal

Un ingeniero orientado al rendimiento vio saltos de redirección y decidió “acelerar las cosas”. Cambió reglas de nginx para que ambas versiones, con y sin barra, devolvieran 200 y evitar redirecciones. La velocidad de página mejoró algunos milisegundos y todos se sintieron listos.

Dos meses después, el tráfico orgánico se volvió errático. Algunas entradas rankeaban, luego bajaban, luego reaparecían con URLs ligeramente distintas. El equipo culpó a actualizaciones de Google, luego la calidad del contenido, luego la agencia SEO. Nadie sospechó de la “optimización”.

Al comparar logs, encontramos a Googlebot rastreando ambas variantes intensamente: /post y /post/. Los enlaces internos tampoco eran coherentes—unos los generaba WordPress y otros estaban codificados en plantillas, y no coincidían en barras. El índice se llenó de duplicados y la autoridad de enlaces se dividió entre variantes.

Revertimos a una política canónica única, reintrodujimos 301 de normalización y limpiamos enlaces internos. El rendimiento siguió bien porque el borde manejaba las redirecciones; el origen no quemaba CPU en ellas. La moraleja: no optimices fuera las redirecciones que preservan identidad. Ahorras un milisegundo y pagas con parte de un trimestre de rankings.

Microcaso 3: La práctica aburrida pero correcta que salvó el día

Otra organización corrió WordPress detrás de un CDN y un balanceador. Tenían una regla simple y aburrida: una “prueba de normalización de URL” debía pasar en CI antes de desplegar cualquier configuración que tocara el borde o vhosts.

La prueba no era elegante. Ejecutaba curl -I contra una docena de URLs representativas y afirmaba: un solo salto hacia la canónica, códigos de estado correctos, etiqueta canonical coincide con la URL final y los sitemaps empiezan con la base canónica. Eso era todo.

Un día un proveedor sugirió habilitar una función “Automatic HTTPS Rewrites” junto con una opción separada “Forwarding URL” para forzar www. La combinación creó una cadena y, en un caso, un bucle para archivos paginados. La prueba de CI lo detectó antes del despliegue.

No hubo incidente. No hubo sala de guerra. No hubo “por qué Google indexa staging”. Solo una comprobación fallida y una corrección rápida. Lo aburrido gana. El trabajo SEO más fiable no se distingue de una buena higiene operativa.

Listas de verificación / plan paso a paso

Paso 1: Declara la política canónica (ponla por escrito)

Protocolo canónico: HTTPS
Host canónico: www o non-www
Barra final: sí o no (sé consistente)
Archivos index: nunca canónicos
Política de parámetros: qué parámetros permitir, cuáles ignorar, cuáles bloquear/noindex

Paso 2: Implementa redirecciones de un solo salto en el borde/origen

Hazlo lo más cerca posible del usuario (CDN/LB), pero asegúrate de que sea determinista y comprobable. Si no puedes hacerlo en el borde, hazlo en nginx/Apache.

Patrón ejemplo para nginx (conceptual)

Manténlo simple: un bloque de servidor para el host no canónico devuelve 301 a la canónica. Otro para la canónica sirve contenido. Luego aplica reglas de barra con cuidado para no crear duplicados con respuesta 200.

Paso 3: Haz que WordPress genere URLs canónicas de forma coherente

Configura home y siteurl a la base canónica.
Verifica que las etiquetas canonical coincidan con la base canónica.
Corrige enlaces absolutos codificados en el theme.
Busca y reemplaza URLs antiguas en contenido (con cuidado).

Paso 4: Arregla sitemaps y feeds

El índice de sitemap y los sitemaps hijos deben listar solo URLs canónicas.
Si cambiaste la base de URL, regenera sitemaps y purga caches.
Revisa feeds RSS/Atom por host antiguos si dependes de ellos.

Paso 5: Controla la indexabilidad de archivos para reducir canibalización

Si las páginas de categoría/etiqueta son landing estratégicas, invierte en contenido único y estructura.
Si no lo son, márcalas noindex y mantiene el presupuesto de rastreo en entradas/páginas.
Desactiva o marca noindex archivos de autor/fecha salvo que aporten valor.
Redirige o marca noindex páginas de adjuntos.

Paso 6: Reprueba y monitoriza

Vuelve a ejecutar las Tareas 1–9 tras los cambios.
Monitorea logs por respuestas 200 en variantes no canónicas.
Observa Search Console para informes de duplicación que bajen en semanas (no horas).

Chiste #2: Si tu sitio tiene cinco URLs canónicas, enhorabuena—has inventado un sistema distribuido. Desafortunadamente, es tu sitio de marketing.

Preguntas frecuentes

1) ¿Debo elegir www o non-www para WordPress?

Cualquiera está bien. Elige una y aplícala con redirecciones 301 y enlaces internos coherentes. Operativamente, www puede ser conveniente para CDN y alcance de cookies, pero no es obligatorio.

2) ¿Las etiquetas canonical bastan para resolver contenido duplicado?

No. Las etiquetas canonical son pistas. Para problemas de protocolo/host/barra usa redirecciones 301 más enlaces internos coherentes. Las canonical ayudan a resolver casos extremos como parámetros y sindicación.

3) ¿Por qué sigo viendo duplicados después de arreglar redirecciones?

Porque siguen existiendo rutas de descubrimiento: enlaces internos, sitemaps, backlinks externos, páginas cacheadas y datos de rastreo antiguos. Arregla las fuentes (enlaces internos y sitemaps) y dale tiempo. También verifica que las variantes no canónicas devuelvan efectivamente 301, no 200.

4) ¿Debería forzar barras finales?

Si usas pretty permalinks de WordPress, sí: forzar un patrón consistente de barra final suele ser lo más sencillo. La clave es consistencia y redirección de un solo salto. No sirvas ambas.

5) ¿Los parámetros UTM son contenido duplicado?

Pueden crear URLs duplicadas. Normalmente los permites para analítica pero aseguras que el canonical apunte a la URL limpia, y evitas indexar variantes con parámetros. No bloquees UTMs con redirecciones salvo que entiendas completamente el rastreo de campañas.

6) ¿Cómo empeoran los CDN esto?

Los CDN pueden cachear redirecciones, dividir claves de cache por host/protocolo o aplicar reescrituras “útiles” que entran en conflicto con el origen. La solución es hacer explícitas las reglas de canonicalización y probarlas en borde y origen.

7) ¿Por qué WordPress a veces redirige de forma inesperada?

WordPress tiene su propia lógica de redirección canónica que intenta adivinar el permalink correcto. Si las reglas de reescritura del servidor o las opciones de URL del sitio son inconsistentes, WordPress puede añadir saltos o redirigir al host equivocado. Arregla la política de URL subyacente primero.

8) ¿Debería marcar noindex las etiquetas/categorías para evitar canibalización?

Si esas páginas no aportan valor único, sí: noindex suele ser la solución más limpia. Si son landing importantes, mantenlas indexables pero haz que sean realmente distintas (texto único, contenido curado, buenos títulos).

9) ¿Qué código de estado usar: 301 o 308?

301 es ampliamente soportado y entendido. 308 también está bien (redirección permanente que preserva método), pero 301 sigue siendo la elección conservadora para compatibilidad amplia, especialmente con herramientas antiguas.

10) ¿Puedo arreglar esto puramente en WordPress sin tocar la configuración del servidor?

Puedes mejorar etiquetas canonical y enlaces internos en WordPress, pero la normalización de host/protocolo debería hacerse en el servidor o en el borde. Hacerlo en PHP funciona hasta que caches, proxies o plugins cambian comportamiento bajo carga.

Conclusión: próximos pasos que realmente mueven la aguja

Si no haces nada más esta semana, haz estas tres cosas:

Elige y documenta una política de URL canónica (HTTPS + host elegido + estilo de barra final).
Fórzala con redirecciones 301 de un solo salto en el borde o servidor web, para listeners HTTP y HTTPS.
Evita que WordPress filtre enlaces no canónicos: configura home/siteurl, arregla etiquetas canonical, regenera sitemaps y limpia enlaces absolutos internos.

Luego vuelve a ejecutar las tareas con comandos, especialmente las que detectan 200 en variantes y contradicciones de etiquetas canonical. Cuando tu sitio tenga una sola identidad, los rankings dejan de jugar a las sillas musicales. Y tu yo futuro recibirá menos tickets de “por qué Google indexa ambas versiones”, que es el lujo silencioso de hacerlo bien.