Versiones de una web: www, sin www, http y https en SEO

Escribe tu dominio en cuatro formas distintas y comprueba qué ocurre: http://ejemplo.com, http://www.ejemplo.com, https://ejemplo.com y https://www.ejemplo.com. Si más de una te devuelve un 200 sin redirigir, tienes la misma web publicada varias veces, y los enlaces entrantes, las señales y los datos de analítica se reparten entre copias.

Este artículo trata de esa canonicalización de host: qué dice Google, cómo elegir la versión preferida, cómo redirigir las demás sin cadenas, qué papel tienen el certificado, HSTS, el canonical y Search Console, y cómo auditarlo. He montado una instancia de Nginx y otra de Apache solo para probar las reglas, y al final cuento qué hace y qué no he podido verificar de mi propia web.

Cuántas URLs tiene tu home sin que lo sepas

Una dirección web se compone de protocolo, host y ruta, y basta con que cambie una pieza para que sea otra URL. Por eso la home de un sitio sin configurar puede responder en cuatro direcciones, y cada página interna hereda ese mismo multiplicador.

Las dos últimas filas dependen de tu servidor. En mi instancia de pruebas de Nginx sobre Linux, /Pagina/ devolvió 200 porque la carpeta se llamaba así, y /pagina/ devolvió 404: son rutas distintas. Que ocurra lo mismo en tu hosting depende de si el servidor y el sistema de archivos distinguen mayúsculas.

Esta guía se centra en protocolo y host. Barras finales y mayúsculas se resuelven igual (una regla que redirige a la forma elegida), y el catálogo de reglas está en el artículo sobre qué tipo de redirección usar en cada caso.

Qué hace Google con las variantes y cómo elige la canónica

Google no trata las variantes como una sola página. Su documentación sobre canonicalización las describe como duplicados: cita expresamente las variantes de protocolo, «por ejemplo, las versiones HTTP y HTTPS de un sitio», y explica que agrupa las páginas con contenido principal igual o muy parecido y elige una como canónica.

Las señales que nombra para esa elección son cuatro: si la página se sirve por HTTP o HTTPS, las redirecciones, la presencia de la URL en un sitemap y las anotaciones rel="canonical". No explica el peso de cada una, y añade que indicar un canonical es «una pista, no una regla»: Google puede elegir otra.

Hay dos frases de la guía sobre consolidación de URLs duplicadas que conviene tener a mano. La primera: Google prefiere las páginas HTTPS frente a las HTTP equivalentes como canónicas, salvo problemas como un certificado no válido. La segunda es una advertencia: las redirecciones de HTTPS a HTTP hacen que Google prefiera HTTP «con mucha fuerza». Un https que redirige a http, aunque sea por una regla heredada, deshace el trabajo.

Sobre www frente a sin www, en las páginas oficiales que he leído no hay ninguna preferencia. La guía de consolidación se limita a poner ejemplos de URLs alternativas, entre ellas una con www, y a decir que elijas una como canónica. Si ves en otro blog que «Google prefiere www», no es lo que dice su documentación. El papel del elemento link en este reparto está en cómo funciona el canonical.

Elegir la versión preferida: https sí, www según criterio

La decisión tiene dos partes de naturaleza distinta. La del protocolo está resuelta: https, porque es el que Google prefiere cuando hay duplicados y el que protege al usuario. La del host no tiene respuesta documentada, y yo la decido con estos criterios.

La conclusión práctica es corta: si ya tienes una versión con enlaces e historial, quédate con ella. Si empiezas de cero y tu proveedor de DNS no te da problemas con el dominio raíz, cualquiera de las dos vale. Lo que sí hace daño es cambiar de opinión cada pocos meses, porque cada cambio es una migración.

Si el cambio es inevitable, trátalo como lo que es: una migración SEO con mapa de URLs, redirecciones y seguimiento, no como un ajuste de configuración.

La redirección: un único 301 y sin cadenas

La regla se dice en una línea: cualquier variante no canónica debe responder con un 301 a la URL final, con la ruta y la query conservadas, en un solo salto. La guía de Google sobre movimientos de sitio pide redirecciones permanentes del lado del servidor (menciona 301 y 308), redirigir directamente al destino final y evitar las cadenas: indica que idealmente no pasen de 3 saltos y que siempre sean menos de 5.

Lo que más se ve en auditorías es una cadena de dos saltos: http://www redirige a https://www, y esta redirige a https:// sin www. Funciona, pero cada salto es una petición más para usuarios y rastreadores. Esta configuración de Nginx evita el salto intermedio con tres bloques de servidor (el ejemplo supone que la versión elegida es https://ejemplo.com):

server {
    listen 80;
    server_name ejemplo.com www.ejemplo.com;
    return 301 https://ejemplo.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.ejemplo.com;
    ssl_certificate     /ruta/cert-con-ambos-hosts.crt;
    ssl_certificate_key /ruta/clave.key;
    add_header Strict-Transport-Security "max-age=31536000" always;
    return 301 https://ejemplo.com$request_uri;
}
server {
    listen 443 ssl;
    server_name ejemplo.com;
    ssl_certificate     /ruta/cert-con-ambos-hosts.crt;
    ssl_certificate_key /ruta/clave.key;
    add_header Strict-Transport-Security "max-age=31536000" always;
    root /var/www/ejemplo;
}

La probé en una instancia propia de Nginx 1.24 con el host ficticio example.test, un certificado autofirmado con los dos nombres y puertos 8342 y 8343 en lugar de 80 y 443 (por eso las redirecciones de abajo incluyen puerto; en producción no). Resultado de las cuatro variantes:

http://example.test:8342/                  301 https://example.test:8343/
http://www.example.test:8342/pagina/       301 https://example.test:8343/pagina/
https://www.example.test:8343/pagina/?a=1  301 https://example.test:8343/pagina/?a=1
https://example.test:8343/                 200

Las tres variantes no canónicas llegan a su destino en un salto, con la ruta y el parámetro intactos, y la versión elegida responde 200. En Apache, la regla equivalente dentro del host virtual usa mod_rewrite; las reglas para .htaccess y su comportamiento están en el artículo sobre reglas de .htaccess. Si usas Nginx, hay más casos en redirecciones en Nginx. Si no quieres escribirlas a mano, mi generador de redirecciones las genera.

La misma regla en Apache

En Apache probé un host virtual con una sola regla condicional para el puerto seguro, en lugar de duplicar bloques:

<VirtualHost *:80>
    ServerName ejemplo.com
    ServerAlias www.ejemplo.com
    RewriteEngine On
    RewriteRule ^ https://ejemplo.com%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
    ServerName ejemplo.com
    ServerAlias www.ejemplo.com
    SSLEngine on
    SSLCertificateFile    /ruta/cert-con-ambos-hosts.crt
    SSLCertificateKeyFile /ruta/clave.key
    Header always set Strict-Transport-Security "max-age=31536000"
    RewriteEngine On
    RewriteCond %{HTTP_HOST} !^ejemplo\.com$ [NC]
    RewriteRule ^ https://ejemplo.com%{REQUEST_URI} [R=301,L]
</VirtualHost>

En Apache 2.4 de pruebas (puertos 8440 y 8441, mismo certificado), http con y sin www y https con www devolvieron un 301 a la versión final en un salto, con ruta y parámetros, y la respuesta incluyó la cabecera HSTS. Lo que no pude comprobar es el 200 del host canónico: mi entorno de pruebas devolvió 403 por permisos del directorio, así que no lo doy por probado. Tienes más variantes en redirecciones en Apache. La query se conserva: en mi prueba ?a=1 llegó intacto al destino en ambos servidores.

El certificado tiene que cubrir los dos hosts

Esta es la causa más tonta y más frecuente de un https roto: la redirección de https://www a https:// solo puede ejecutarse si el navegador acepta antes el certificado del host www. Con un certificado emitido solo para el dominio raíz, quien teclea la variante con www ve una advertencia de seguridad antes de que el servidor pueda redirigir nada.

Lo reproduje con un certificado cuyo nombre alternativo solo incluía example.test. La petición a la variante con www falló en el cliente:

curl: (60) SSL: no alternative certificate subject name matches target host name 'www.example.test'

Mientras que el host raíz, con el mismo certificado, respondió su 301 con normalidad. Para evitarlo, emite el certificado con ambos nombres (como nombres alternativos o con un comodín) y comprueba además que existe el registro DNS de www: sin él, la variante ni siquiera resuelve y no hay nada que redirigir.

HSTS: qué añade y por qué va al final

Con la redirección 301, el primer acceso a http:// sigue viajando sin cifrar antes de que el servidor responda. HSTS (Strict-Transport-Security) le dice al navegador que, durante un tiempo, ese host solo se visita por https. Según MDN, el navegador no lo aplica hasta que ha hecho al menos una conexión segura y ha recibido la cabecera, y la ignora si llega por http.

La cabecera tiene tres directivas. max-age es obligatoria y marca los segundos que el navegador recuerda la política. includeSubDomains extiende la política a todos los subdominios. preload solo tiene sentido si vas a pedir la inclusión en la lista de precarga de los navegadores, que se gestiona en hstspreload.org.

Los requisitos de hstspreload.org son concretos: certificado válido, redirección de http a https en el mismo host, todos los subdominios por https (incluido www si existe su registro DNS) y la cabecera en el dominio base con max-age de al menos 31536000, includeSubDomains y preload. Cualquier redirección servida desde el https debe llevar también la cabecera, y por eso en mi configuración de prueba el bloque de www la envía. En cambio, la redirección servida por http no debe llevarla: el navegador la ignoraría.

El riesgo es la irreversibilidad. MDN advierte de que, ante un error de certificado en un host con HSTS, el navegador no ofrece al usuario forma de continuar, y de que quitar la política exige enviar max-age=0 por https y esperar a que cada navegador lo reciba. La propia página de preload avisa de que la inclusión «no se puede deshacer fácilmente» y de que la retirada tarda meses en llegar a los usuarios. Mi orden es siempre el mismo: redirección estable, certificado con renovación automática comprobada, HSTS con un valor corto, y solo después subir el tiempo. El preload, únicamente si todo el dominio y sus subdominios van a estar en https a largo plazo.

Canonical, sitemap y enlaces internos: todo a la misma versión

La redirección arregla lo que ocurre cuando alguien llega por la variante equivocada. El resto de señales deben apuntar a la versión elegida para que no se contradigan: Google nombra las redirecciones, el sitemap y el canonical entre sus señales, y si dos de ellas discrepan, la elección queda en manos del algoritmo.

• Canonical absoluto y autorreferencial con el protocolo y el host definitivos en todas las páginas.
• Sitemap XML con las URL finales y la referencia Sitemap: de robots.txt con el host correcto; la guía del sitemap XML detalla qué incluir.
• Enlaces internos a la versión final, no a una que redirige. Cada enlace a una variante añade un salto innecesario.
• Recursos (imágenes, scripts, hojas de estilo) cargados por https. El contenido mixto aparece cuando una página https carga recursos por http; según web.dev, la mayoría de navegadores lo bloquea y Chrome puede actualizar automáticamente el contenido pasivo, pero si no existe versión https el recurso no se carga.

Search Console, cookies y analítica

En Search Console, según su ayuda, una propiedad de dominio incluye todos los subdominios (m, www y los demás) y varios protocolos, mientras que una propiedad de prefijo de URL cubre solo las URL que empiezan exactamente por ese prefijo, protocolo incluido. Con prefijos necesitarías una propiedad por cada variante para ver todos los datos; con la de dominio basta una. Los matices de elegir una u otra los trato en propiedad de dominio frente a prefijo, y aquí solo importa que, tras unificar, las variantes antiguas dejarán de aparecer en los informes.

Las cookies tienen su propia lógica de host. Una cookie sin atributo Domain pertenece solo al host que la crea, de modo que un visitante que alterna entre www y sin www tendría dos cookies de sesión distintas. Si además la cookie lleva el atributo Secure, solo viaja por https. Al unificar el host desaparece ese reparto, y en analítica evitas sesiones partidas y referrals entre tus propias variantes.

Errores típicos y qué se ve en cada uno

Reproduje tres de los fallos más habituales para ver su síntoma exacto; el cuarto lo cito de la documentación de Google.

Sobre el 302: la documentación de Google recomienda las redirecciones permanentes para indicar que la URL redirigida es una versión peor que la de destino. El detalle de cuándo usar cada código lo tienes en códigos de respuesta, y el criterio para elegir entre 301 y 308 en la sección de preguntas.

Cómo lo tengo en mi web (y qué no he podido verificar)

Esto es lo que consta en el código de cristofercruz.net.

• La versión elegida es https://cristofercruz.net, sin www. Está fijada en SITE_URL de includes/config.php.
• El canonical sale de includes/header.php como SITE_URL más la ruta de la página, de modo que es siempre absoluto, con https y sin www, sin depender del host con el que llegó la petición. Los hreflang es-ES y x-default usan esa misma URL.
• El sitemap del blog (blog/sitemap.php) construye las URL con SITE_URL, y las dos líneas Sitemap: de robots.txt apuntan a https://cristofercruz.net.
• El .htaccess activa RewriteEngine, pero sus reglas solo bloquean /tools/ y .git. No contiene ninguna redirección de http a https ni de www a sin www, y no envía la cabecera Strict-Transport-Security.
• Las cookies de sesión de los formularios se marcan Secure solo cuando la petición llega por https, y el formulario de contacto acepta como origen tanto cristofercruz.net como www.cristofercruz.net.

En resumen: la redirección de las variantes no está en el código del sitio. El README del proyecto lo deja anotado como pendiente de verificar en el hosting, porque depende del servidor, y yo no he comprobado qué hace el servidor real con las cuatro variantes. Mientras tanto, el diseño evita lo peor: aunque alguna variante respondiera con 200, su canonical apuntaría a la versión sin www con https. Pero eso es una pista, no una garantía, y por eso mi tarea pendiente es medir las cuatro variantes con curl en producción y, si hace falta, añadir la regla en el servidor. HSTS no lo uso hoy.

Cómo auditarlo con curl

La auditoría son cuatro peticiones. El indicador -w imprime el código de estado y el destino de la redirección sin descargar el cuerpo:

for u in http://ejemplo.com/ http://www.ejemplo.com/ https://ejemplo.com/ https://www.ejemplo.com/; do
  curl -s -o /dev/null -w "$u  %{http_code} %{redirect_url}\n" "$u"
done

Lo que espero ver: tres líneas con 301 apuntando todas a la misma URL final, y una con 200. Si alguna dice 200 sin ser la elegida, es un duplicado vivo. Si dice 302, es una redirección temporal. Si no responde o curl falla con el error 60, mira el certificado y el DNS.

Para contar saltos, curl -sIL -o /dev/null -w "%{num_redirects} %{url_effective}\n" URL sigue la redirección y devuelve cuántas hizo; lo ideal es 1 desde cualquier variante. Y para HSTS, curl -sI https://ejemplo.com/ | grep -i strict debe devolver la cabecera con el valor que decidiste.

Después de curl, revisa en el código de la página que el canonical sea la versión elegida, que el sitemap contenga solo esas URL, y en Search Console qué variantes siguen apareciendo en el informe de páginas. Las variantes que Google ya conocía tardan en desaparecer; que sigan unas semanas no significa que la redirección falle.

Preguntas frecuentes

Referencias y fuentes

1. Consolidar URLs duplicadas Google Search Central
2. Qué es la canonicalización de URLs Google Search Central
3. Migración de sitio con cambios de URL Google Search Central
4. Estructura de URL recomendada Google Search Central
5. Añadir una propiedad de sitio web a Search Console Ayuda de Search Console
6. Strict-Transport-Security MDN Web Docs
7. HSTS Preload List Submission hstspreload.org
8. What is mixed content? web.dev