Pasar su sitio al protocolo HTTPS: el procedimiento y las redirecciones

HTTPS es la versión cifrada del protocolo HTTP. Se ha convertido en la norma: Chrome y Firefox marcan como «No seguras» las páginas en HTTP, los visitantes dudan en introducir sus datos en ellas y Google tiene en cuenta el HTTPS en su clasificación.

Pasar un sitio a HTTPS es una migración en sí misma. El nombre de dominio no cambia, pero sí el protocolo de todas las URL, y Google considera http:// y https:// dos direcciones distintas: cada página debe redirigirse a su equivalente en HTTPS, en un solo salto. Este artículo da el procedimiento, luego las reglas de redirección, con o sin www, y el orden en que escribirlas. Para el otro lado, el del visitante, consulte cómo reconocer un sitio seguro.

El HTTPS aporta tres garantías:

• la confidencialidad: los intercambios entre el navegador y el servidor están cifrados; en una wifi pública, nadie puede leer una contraseña o un número de tarjeta;
• la integridad: las páginas y los datos no pueden modificarse durante su transporte;
• la autenticación: el certificado acredita que el sitio es realmente el de ese nombre de dominio.

Chrome ya no muestra la mención «Seguro» para los sitios en HTTPS: es al revés, las páginas en HTTP llevan la mención «No seguro», que pasa a rojo en cuanto se introducen datos. El HTTPS es también una señal de clasificación para Google, modesta: no sustituye a un contenido pertinente.

La mayoría de los proveedores de alojamiento ofrecen gratuitamente un certificado Let's Encrypt, que se activa desde el área de cliente y se renueva automáticamente. Para un certificado de pago, el procedimiento pasa por una CSR (solicitud de firma de certificado), generada en el servidor: contiene la clave pública y el nombre de dominio que se va a certificar, y es lo que se envía a la autoridad de certificación. También aquí, el proveedor suele encargarse.

Existen tres niveles de validación: solo el dominio (DV), la organización (OV) y la validación extendida (EV), que verifica con más detalle la identidad de la empresa. Todos cifran de la misma manera, y los navegadores ya no distinguen los certificados EV en la barra de direcciones desde 2019. Compruebe que el certificado cubre todas las variantes servidas: exemple.fr y www.exemple.fr, y los posibles subdominios.

Antes del cambio, sustituya las direcciones en http:// por https:// allí donde el sitio las escriba: enlaces internos de los contenidos, menús, etiquetas canonical y hreflang, sitemap, datos estructurados. Los recursos que cargan las páginas (imágenes, scripts, hojas de estilo, fuentes) también deben estar en HTTPS: si no, el navegador señala contenido mixto y puede bloquear el recurso.

En WordPress, actualice la «Dirección de WordPress» y la «Dirección del sitio» en los ajustes generales y luego sustituya las direcciones antiguas en la base de datos con una herramienta de búsqueda y reemplazo que respete los datos serializados (WP-CLI search-replace, por ejemplo). Revise también los ajustes de los plugins que guardan direcciones, y la dirección del sitemap en el robots.txt.

No hace falta redirigir las páginas una a una: solo cambia el protocolo, así que una regla en la configuración del servidor basta para todas las URL, ruta incluida. Es una redirección 301, permanente: indica a Google que sustituya la dirección antigua por la nueva en su índice, y lleva a la página correcta a los visitantes que guardaron un marcador en HTTP. Las reglas, con o sin www, y su orden se detallan más abajo.

Una propiedad de tipo «Dominio» ya cubre todas las variantes, en HTTP y en HTTPS. Si no, añada la propiedad https:// de su sitio (con o sin www, la que vaya a ser canónica) y envíe en ella el sitemap en HTTPS. Google descubrirá antes las nuevas direcciones y usted seguirá su indexación en el informe de páginas.

Compruebe el certificado (válido, en cada variante de host), la ausencia de contenido mixto y, sobre todo, las redirecciones: cada dirección antigua debe responder con una sola 301 hacia su dirección final. Siga después la indexación y el tráfico durante las semanas siguientes; si bajan, revise primero las redirecciones y el certificado.

Una misma página puede responder bajo cuatro direcciones: http://exemple.fr, http://www.exemple.fr, https://exemple.fr y https://www.exemple.fr. Elija una, la versión canónica (aquí, en HTTPS con www), y redirija las otras tres hacia ella, en un solo salto y con la misma ruta.

El error más frecuente es escribir dos reglas que se encadenan: una que pasa a HTTPS y otra que añade el www. http://exemple.fr/page va entonces a https://exemple.fr/page y luego a https://www.exemple.fr/page: dos redirecciones en lugar de una, más lentas para el visitante y para Google. La elección entre www y sin www se trata en nuestro artículo sobre la redirección www.

En el archivo .htaccess de la raíz del sitio, o en la configuración del servidor:

RewriteEngine On

# Toda dirección en http, o en otro host distinto de www.exemple.fr, va en una sola redirección a https://www.exemple.fr, misma ruta
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Las dos condiciones se unen con [OR]: la regla se aplica si la petición llega en HTTP, o a un host distinto del canónico, y envía directamente a la dirección final. Detrás de una CDN o de un balanceador de carga que termina el HTTPS, el servidor recibe todas las peticiones en HTTP: %{HTTPS} vale entonces siempre off, y hay que comprobar la cabecera X-Forwarded-Proto, so pena de bucle de redirección.

Un bloque server para HTTP, otro para HTTPS sin www; el sitio propiamente dicho lo sirve el bloque https://www.exemple.fr:

# http, con o sin www: hacia https://www.exemple.fr, misma ruta
server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

# https sin www: hacia https://www.exemple.fr (el certificado debe cubrir exemple.fr)
server {
    listen 443 ssl;
    server_name exemple.fr;
    return 301 https://www.exemple.fr$request_uri;
}

Cuando el paso a HTTPS acompaña un rediseño, las URL también cambian: el servidor lleva entonces dos tipos de reglas. Las redirecciones precisas, una por URL, son el plan de redirección: tal página antigua hacia tal página nueva. Las reglas genéricas se aplican a todo un conjunto de direcciones: el paso a HTTPS, el añadido del www, un directorio entero trasladado.

Apache lee las reglas en orden y se detiene en la primera que redirige. Si la regla genérica va primero, http://exemple.fr/ancienne-page.html va primero a https://www.exemple.fr/ancienne-page.html y luego una segunda petición encuentra la redirección precisa hacia /nouvelle-page: una cadena de dos redirecciones, y una etapa intermedia que no existe. Ponga por tanto primero las redirecciones precisas, con la dirección final completa (protocolo y host incluidos), luego las reglas por patrón y por último las reglas genéricas:

RewriteEngine On

# 1. Las redirecciones precisas, URL por URL (el plan de redirección), hacia la dirección final completa
RewriteRule "^/?ancienne-page\.html$" "https://www.exemple.fr/nouvelle-page" [L,R=301,NC,QSD,NE]
RewriteRule "^/?categorie/produit-42$" "https://www.exemple.fr/boutique/produit-42" [L,R=301,NC,QSD,NE]

# 2. Las reglas por patrón (un directorio entero)
RewriteRule ^actualites/(.*)$ https://www.exemple.fr/blog/$1 [L,R=301]

# 3. Las reglas genéricas: http hacia https, host sin www hacia www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.exemple\.fr$ [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]

Así, la dirección antigua en HTTP lleva en un solo salto a la nueva dirección en HTTPS; las direcciones sin redirección precisa pasan por la regla genérica. La misma lógica vale entre una regla por patrón y las excepciones que cubre: primero la excepción.

Con Nginx, un return escrito directamente en el bloque server se ejecuta antes que cualquier bloque location: las redirecciones precisas colocadas en bloques location nunca se leerían para las peticiones en HTTP. Consúltelas antes de la regla genérica, por ejemplo con un map:

# En el contexto http: las redirecciones precisas, ruta por ruta
map $uri $nouvelle_adresse {
    default "";
    /ancienne-page.html /nouvelle-page;
    /categorie/produit-42 /boutique/produit-42;
}

server {
    listen 80;
    server_name exemple.fr www.exemple.fr;
    # Primero las redirecciones precisas, después la regla genérica (misma prueba en el bloque 443)
    if ($nouvelle_adresse) {
        return 301 https://www.exemple.fr$nouvelle_adresse;
    }
    return 301 https://www.exemple.fr$request_uri;
}

El archivo .htaccess que exporta Swan solo contiene redirecciones precisas, una por URL, hacia la dirección completa del dominio de producción (o de pruebas), protocolo y host incluidos: colóquelas antes de sus reglas genéricas. No contiene regla de paso a HTTPS, que queda por escribir en la configuración del sitio. Para decidir dónde guardar estas reglas, consulte dónde colocar el plan de redirección.

Para comprobar que una dirección antigua lleva en un solo salto a su destino, consúltela en HTTP: la respuesta debe ser una 301 cuya cabecera Location sea la dirección final en HTTPS.

curl -sI http://exemple.fr/ancienne-page.html

HTTP/1.1 301 Moved Permanently
Location: https://www.exemple.fr/nouvelle-page

Si Location apunta a una dirección intermedia (la misma página en HTTPS, o el host sin www), una regla genérica va antes que la redirección precisa. Los riesgos de una cadena de redirecciones para el posicionamiento se tratan en nuestro artículo sobre los riesgos de las redirecciones para el SEO.