HTTPS, www y canonical: una sola versión de cada página

Para una persona, http://ejemplo.com/guia y https://www.ejemplo.com/guia/ son la misma página. Para un servidor y para un buscador son dos URL distintas, y si ambas responden con contenido, tienes contenido duplicado que tú mismo has fabricado. Los enlaces se reparten entre variantes, los informes se ensucian y el rastreador gasta tiempo en copias. Este artículo explica cómo dejar una sola versión: qué herramientas hay (redirecciones, rel="canonical", HSTS), cuánto pesa cada una para Google y qué debe pasar exactamente con ocho variantes de una misma URL.

De dónde salen las copias

Una misma página puede multiplicarse por cuatro motivos independientes, y se combinan entre sí:

• Protocolo: http:// frente a https://.
• Host: con www. o sin él (el dominio «desnudo» o apex).
• Barra final: /guia frente a /guia/. Google trata ambas como URL distintas; técnicamente podrían tener contenido diferente.
• Parámetros: ?utm_source=boletin, ?ref=x, identificadores de sesión, ordenaciones.

Sólo con las tres primeras ya salen 2 × 2 × 2 = 8 combinaciones por página, antes de contar parámetros. En un sitio de 200 páginas son 1.600 URL que podrían responder con el mismo contenido. Lo normal es que nadie enlace a la mayoría, pero basta con que algunas aparezcan en enlaces externos o en tus propios menús para que el problema sea real.

Cómo elige Google la canónica

Google agrupa las páginas con contenido igual o muy parecido y elige una como canónica, la que considera más completa y útil; las demás se rastrean con menos frecuencia. Para elegir usa señales, y su documentación las ordena de más a menos fuerte:

El punto que más confusiones evita: indicar una canónica es una sugerencia, no una orden. La propia documentación dice que Google puede elegir otra página por distintos motivos. Las señales se suman, así que lo eficaz es que todas apunten a la misma URL: la redirección, el rel="canonical", el sitemap y tus enlaces internos. Si el canonical dice una cosa y el sitemap otra, le estás pidiendo a Google que decida por ti. Puedes ver cuál ha elegido con la herramienta de inspección de URLs de Search Console.

Las tres herramientas, una por una

Redirecciones 301

Para variantes que no deberían existir (HTTP, el host que no usas, la barra que no usas), la herramienta es una redirección permanente en el servidor. Google trata 301 y 308 como equivalentes y recomienda las redirecciones del lado del servidor frente a meta refresh o JavaScript. Dos ideas de su documentación: las redirecciones permanentes no hacen perder PageRank, y conviene evitar cadenas (la guía de migraciones pide, si no puedes ir directo al destino, idealmente no más de 3 saltos; Googlebot sigue como máximo 10). La forma más simple de cumplirlo es que cualquier variante salte directamente a la URL final en un solo paso, no de HTTP a HTTPS y luego de apex a www.

rel="canonical" autorreferencial

Google recomienda incluir en la propia página canónica un rel="canonical" que apunte a sí misma. Sirve para las variantes que no puedes redirigir, sobre todo las que llevan parámetros de seguimiento: si alguien llega a /guia/?utm_source=boletin, la página responde igual y su canonical dice cuál es la URL buena. Detalles de la documentación que conviene respetar: usa URL absolutas, pon un solo canonical por página (si hay varios, lo probable es que Google los ignore todos), no apuntes a un fragmento #, y no uses robots.txt ni noindex para elegir canónica dentro del sitio.

<link rel="canonical" href="https://www.ejemplo.com/guia/">

HSTS

La cabecera Strict-Transport-Security indica al navegador que, durante max-age segundos, acceda al host sólo por HTTPS, sin pasar siquiera por la redirección. Según MDN, el navegador ignora esta cabecera si llega por HTTP; sólo vale en respuestas HTTPS. includeSubDomains extiende la regla a todos los subdominios, así que antes de activarla comprueba que todos tienen HTTPS. Para entrar en las listas de precarga de los navegadores (preload), max-age debe ser de al menos 31536000 segundos (un año) e incluir includeSubDomains.

Google menciona HSTS entre las formas de reforzar la preferencia por HTTPS, pero no sustituye a la redirección 301: el primer acceso de un navegador nuevo sigue llegando por HTTP.

Caso práctico: ocho variantes de una misma página

Supongamos que la versión elegida es https://www.ejemplo.com/guia/: HTTPS, con www y con barra final. Elegir www o no, y barra o no, es indiferente para Google; lo que importa es elegir una y ser coherente. Esto es lo que debería pasar con cada variante:

La variante 8 se trata distinto a propósito. Google sugiere eliminar parámetros innecesarios o redirigir los de seguimiento a la versión canónica, pero si tu herramienta de analítica necesita leer el utm_source en la página de destino, redirigir rompe la medición. El canonical sin parámetros es la salida práctica: la página responde y Google recibe la indicación de cuál es la URL buena.

Configuración de ejemplo

Los fragmentos siguientes son ilustrativos: muestran la lógica, no una configuración lista para producción. Prueba siempre en un entorno de pruebas y revisa la documentación de tu servidor o plataforma.

Nginx

# Ilustrativo: http y apex -> https://www (un solo salto)
server {
    listen 80;
    server_name ejemplo.com www.ejemplo.com;
    return 301 https://www.ejemplo.com$request_uri;
}

server {
    listen 443 ssl;
    server_name ejemplo.com;
    # certificados aquí (deben cubrir también el apex)
    return 301 https://www.ejemplo.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.ejemplo.com;
    # certificados aquí
    add_header Strict-Transport-Security "max-age=300" always;

    # Añadir barra final a rutas sin extensión
    rewrite ^([^.?]*[^/])$ $1/ permanent;
}

Usar el host fijo (https://www.ejemplo.com) en lugar de $host hace que el apex y HTTP lleguen a la versión final en un solo salto. Ojo: la regla de la barra final, si se aplica a una URL del bloque de HTTP, añade un segundo salto a las variantes sin barra que llegan por HTTP o por el apex (4 y 6 de la tabla, y la combinación que falta); para dejarlo todo en uno habría que calcular la URL final completa en el primer bloque. Para la mayoría de sitios, dos saltos en esos casos marginales es aceptable.

Netlify

Según su documentación, Netlify redirige automáticamente entre el dominio apex y el subdominio www cuando ambos están asignados al sitio, y su función de Pretty URLs normaliza las rutas (por ejemplo, /about a /about/). No se puede añadir o quitar la barra final con una regla del archivo _redirects, porque la plataforma normaliza la ruta antes de aplicar las reglas y provocaría un bucle. Las reglas de dominio sí se escriben así:

# _redirects (ilustrativo): el subdominio de Netlify -> dominio propio
https://mi-sitio.netlify.app/*  https://www.ejemplo.com/:splat  301!

Lista de comprobación tras configurar

• Las ocho variantes de una URL de prueba responden como en la tabla (puedes revisarlas con curl -I o con las herramientas de red del navegador).
• Ninguna variante necesita más de dos saltos, y ninguna redirige a HTTP.
• La página canónica tiene un único rel="canonical" absoluto que apunta a sí misma.
• El sitemap sólo lista URL canónicas (HTTPS, host elegido, barra elegida).
• Los enlaces internos de menús, pies y artículos apuntan a la versión canónica, no a variantes.
• El certificado cubre tanto el apex como www.
• HSTS se envía sólo por HTTPS y empezaste con un max-age corto.
• En Search Console, la inspección de URLs muestra como canónica la que elegiste (puede tardar en actualizarse).

Cuándo no tocar nada: si el sitio ya tiene años de enlaces apuntando a la versión sin www y todo funciona, no cambies de host sólo por gusto; cambiarlo es una migración, con su riesgo. Y si vas a migrar o reorganizar URL, revisa antes qué código debe responder cada URL y qué controla el sitemap. Si estás eligiendo plataforma, ten en cuenta que estos ajustes se hacen de forma distinta en un sitio estático o en WordPress.