Cómo redirigir HTTP a HTTPS en WordPress

Migrar tu sitio WordPress de HTTP a HTTPS ya no es opcional. Los navegadores marcan los sitios HTTP como "No seguro", Google utiliza HTTPS como señal de posicionamiento y los datos de tus visitantes se transmiten en texto plano sin cifrado. Tras instalar un certificado SSL, debes redirigir adecuadamente todo el tráfico HTTP a HTTPS y corregir cualquier problema de contenido mixto que quede. Esta guía cubre cada paso del proceso, desde obtener un certificado hasta depurar bucles de redirección detrás de balanceadores de carga.

Por qué HTTPS importa más allá de la seguridad básica

La razón obvia para HTTPS es el cifrado. Sin él, todo entre el navegador de tu visitante y tu servidor (envíos de formularios, credenciales de inicio de sesión, cookies, datos personales) puede ser interceptado por cualquiera en la misma red. Pero HTTPS importa por varias otras razones que afectan directamente al éxito de tu sitio:

• Factor de posicionamiento SEO: Google confirmó en agosto de 2014 que HTTPS es una señal de posicionamiento. Aunque es una señal ligera, en igualdad de condiciones, la versión HTTPS de una página posicionará mejor que la versión HTTP. En nichos competitivos, cada señal cuenta.
• Avisos del navegador: Chrome, Firefox, Safari y Edge muestran avisos de "No seguro" para páginas HTTP, especialmente las que tienen campos de formulario. Esto erosiona la confianza del visitante y aumenta la tasa de rebote. Chrome ha ido haciendo estos avisos más visibles progresivamente desde Chrome 68 (julio de 2018).
• Soporte de HTTP/2 y HTTP/3: Los protocolos modernos como HTTP/2 y HTTP/3, que mejoran drásticamente la velocidad de carga de páginas mediante multiplexación y compresión de cabeceras, requieren HTTPS en la práctica. Todos los navegadores principales solo admiten HTTP/2 sobre TLS.
• Datos de referente: Cuando un visitante hace clic en un enlace desde una página HTTPS a una página HTTP, el navegador elimina la cabecera referer. Esto significa que pierdes datos analíticos sobre de dónde proviene tu tráfico. Si tu sitio está en HTTPS, conservas los datos de referente desde otros sitios HTTPS.
• Service Workers y PWA: Las funcionalidades de Progressive Web App como el almacenamiento en caché sin conexión, las notificaciones push y el aviso "Añadir a la pantalla de inicio" requieren HTTPS.

Obtener un certificado SSL gratuito con Let's Encrypt

No necesitas pagar por un certificado SSL. Let's Encrypt proporciona certificados gratuitos, automatizados y validados por dominio (DV) que son confiables para todos los principales navegadores. La mayoría de proveedores de hosting han integrado Let's Encrypt en sus paneles de control, pero si gestionas tu propio servidor, así es como configurarlo con Certbot:

# Instalar Certbot en Ubuntu/Debian
sudo apt update
sudo apt install certbot

# Para Apache
sudo apt install python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

# Para Nginx
sudo apt install python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot configurará automáticamente tu servidor web para usar el certificado y establecerá una tarea cron para la auto-renovación. Los certificados de Let's Encrypt son válidos durante 90 días, pero el proceso de auto-renovación lo gestiona de forma transparente. Para verificar que la auto-renovación funciona:

# Probar el proceso de renovación (no renueva realmente)
sudo certbot renew --dry-run

# Comprobar el temporizador de renovación
sudo systemctl status certbot.timer

Si tu proveedor de hosting ofrece SSL con un solo clic a través de su panel de control (SiteGround, Bluehost, HostGator, etc.), úsalo en su lugar. Es el mismo certificado de Let's Encrypt pero gestionado por tu host, lo que significa una cosa menos que mantener.

Paso 1: Actualizar las URLs de WordPress

Antes de configurar las redirecciones, dile a WordPress que tu sitio ahora utiliza HTTPS. Ve a Ajustes > Generales y actualiza ambos campos:

• Dirección de WordPress (URL): Cambia http://example.com a https://example.com
• Dirección del sitio (URL): Cambia http://example.com a https://example.com

Si no puedes acceder al panel de administración (por ejemplo, si ya estás atrapado en un bucle de redirección), puedes establecer estos valores directamente en wp-config.php:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

O actualiza la base de datos directamente vía WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Paso 2: Redirección HTTP a HTTPS a nivel del servidor

La redirección debe ocurrir a nivel del servidor (no en PHP) por dos razones: es más rápida porque no requiere cargar WordPress, y garantiza que todas las peticiones (incluidos archivos estáticos, imágenes y llamadas a la API) sean redirigidas, no solo las URLs gestionadas por WordPress.

Apache (.htaccess)

Añade esto en la parte superior de tu archivo .htaccess, antes de las reglas de reescritura de WordPress (antes del comentario # BEGIN WordPress):

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

El flag R=301 envía una redirección permanente, lo que indica a los motores de búsqueda que actualicen su índice a la versión HTTPS. No uses R=302 (redirección temporal) porque los motores de búsqueda no transferirán el link equity a la nueva URL.

Nginx

En tu configuración de Nginx, crea un bloque server separado para HTTP que redirija todo a HTTPS:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # ... resto de tu configuración
}

Usar return 301 en Nginx es más eficiente que usar rewrite porque no requiere procesamiento de regex.

Paso 3: Forzar HTTPS en wp-config.php

Añade estas líneas a tu archivo wp-config.php, encima del comentario "That's all, stop editing!":

// Forzar SSL para el área de administración de WordPress
define('FORCE_SSL_ADMIN', true);

// Manejar SSL detrás de un proxy inverso o balanceador de carga
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

La constante FORCE_SSL_ADMIN garantiza que la página de inicio de sesión y el panel de administración de WordPress siempre utilicen HTTPS, incluso si alguien intenta acceder a ellos directamente vía HTTP.

Corregir bucles de redirección detrás de balanceadores de carga y proxies inversos

Este es uno de los problemas más comunes con las configuraciones HTTPS de WordPress, y hace tropezar a mucha gente. Si tu sitio está detrás de un balanceador de carga, Cloudflare, un proxy inverso o un CDN, la conexión entre el proxy y tu servidor a menudo es HTTP plano, aunque la conexión entre el visitante y el proxy sea HTTPS. Tu servidor ve una petición HTTP e intenta redirigir a HTTPS, el proxy reenvía la petición como HTTP y acabas en un bucle de redirección infinito. El navegador muestra "ERR_TOO_MANY_REDIRECTS".

La solución es la comprobación de la cabecera X-Forwarded-Proto mostrada arriba. El proxy añade esta cabecera para indicar a tu servidor qué protocolo utilizó la petición original. Cuando WordPress ve que el protocolo reenviado es HTTPS, trata la conexión como segura y no dispara una redirección.

Si la comprobación de cabecera estándar no funciona, tu proxy podría usar una cabecera diferente. Comprueba con tu proveedor de hosting. Variaciones comunes incluyen:

// Para algunos balanceadores de carga que usan X-Forwarded-Ssl
if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') {
    $_SERVER['HTTPS'] = 'on';
}

// Para Cloudflare (que también establece X-Forwarded-Proto, pero por si acaso)
if (isset($_SERVER['HTTP_CF_VISITOR'])) {
    $visitor = json_decode($_SERVER['HTTP_CF_VISITOR']);
    if (isset($visitor->scheme) && $visitor->scheme === 'https') {
        $_SERVER['HTTPS'] = 'on';
    }
}

Paso 4: Reemplazar las URLs HTTP en la base de datos

Tu base de datos de WordPress contiene URLs HTTP codificadas a fuego en el contenido de las entradas, los ajustes de los widgets, las opciones del tema y datos serializados. Necesitas reemplazarlas todas por versiones HTTPS. La mejor herramienta para esto es el comando search-replace de WP-CLI:

# Primero, ejecuta una prueba en seco para ver qué cambiaría
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Si la prueba en seco se ve bien, ejecuta el reemplazo real
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Maneja también las variaciones www/sin-www si corresponde
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

El flag --dry-run es importante. Te muestra exactamente cuántos reemplazos se harán en cada tabla sin modificar nada realmente. Revisa la salida antes de ejecutar el reemplazo real. El flag --all-tables garantiza que se incluyan tablas personalizadas (de plugins como WooCommerce, ACF o constructores de páginas).

WP-CLI maneja correctamente los datos serializados, lo cual es crítico. Si intentas hacer un simple find-and-replace SQL, romperás los arrays serializados porque los valores de longitud de cadena ya no coincidirán. Nunca ejecutes una consulta SQL REPLACE() en bruto para este propósito.

Corregir problemas de contenido mixto

El contenido mixto se produce cuando tu página HTTPS carga recursos (imágenes, scripts, hojas de estilo, iframes) sobre HTTP. Los navegadores bloquean por completo el contenido activo mixto (scripts, hojas de estilo) y pueden avisar sobre el contenido pasivo mixto (imágenes). Esto resulta en funcionalidad rota o iconos de aviso amarillos en la barra de direcciones.

Para encontrar problemas de contenido mixto:

1. Consola del navegador: Abre las DevTools (F12) y mira la pestaña Console. Los avisos de contenido mixto aparecen como mensajes amarillos o rojos que listan las URLs exactas de los recursos infractores.
2. InspectWP: Ejecuta un análisis y revisa la sección HTML. InspectWP detecta los recursos no seguros (HTTP) cargados en páginas HTTPS y los lista uno a uno.
3. Why No Padlock: El sitio whynopadlock.com escanea tu página y reporta todos los recursos de contenido mixto con sus URLs de origen.

Fuentes comunes de contenido mixto y cómo solucionarlas:

• URLs codificadas a fuego en archivos del tema: Busca en los archivos PHP y CSS de tu tema referencias a http://. Reemplázalas por https:// o, mejor aún, usa URLs relativas al protocolo (//) o funciones de WordPress como esc_url().
• Imágenes en el contenido de las entradas: El comando search-replace de WP-CLI (Paso 4) maneja la mayoría de estos casos. Para los más persistentes, revisa el HTML en bruto en el editor de Texto.
• Widgets y ajustes del Personalizador: Las URLs de imágenes en widgets, cabeceras personalizadas y ajustes del Personalizador se almacenan como datos serializados. WP-CLI search-replace los maneja correctamente.
• Contenido de constructores de páginas: Elementor, Beaver Builder, Divi y otros constructores de páginas almacenan su contenido en formatos personalizados. WP-CLI con --all-tables normalmente los detecta, pero verifícalo cargando páginas creadas con tu constructor.
• Recursos externos: Si cargas fuentes, scripts o imágenes desde dominios externos sobre HTTP, actualiza esas URLs. La mayoría de CDNs y servicios de fuentes (Google Fonts, cdnjs, etc.) admiten HTTPS.

Usar Really Simple SSL como alternativa

Si el enfoque manual te resulta abrumador, el plugin Really Simple SSL automatiza la mayor parte del proceso. Instálalo, actívalo y hará lo siguiente:

• Detecta tu certificado SSL automáticamente.
• Actualiza el Site URL y Home URL de WordPress a HTTPS.
• Configura una redirección 301 de HTTP a HTTPS vía PHP (o .htaccess si es posible).
• Corrige el contenido mixto reemplazando las URLs HTTP al vuelo.

El inconveniente de Really Simple SSL es que corrige el contenido mixto dinámicamente en cada carga de página, lo que añade una pequeña sobrecarga de procesamiento. Es mejor solucionar las causas raíz (URLs en la base de datos, referencias codificadas a fuego) y luego eliminar el plugin. Piensa en él como un puente útil durante la migración, no como una solución permanente.

Paso 5: Añadir la cabecera HSTS

HTTP Strict Transport Security (HSTS) indica a los navegadores que utilicen siempre HTTPS para tu dominio, incluso si el usuario teclea http:// en la barra de direcciones. Después de confirmar que HTTPS funciona correctamente en tu sitio (sin contenido mixto, sin bucles de redirección), añade la cabecera HSTS:

Apache (.htaccess)

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

El valor max-age=31536000 (un año) indica a los navegadores que recuerden la política HSTS durante 12 meses. Empieza con un valor más corto como max-age=86400 (un día) durante las pruebas, y luego auméntalo cuando estés seguro de que todo funciona. La directiva includeSubDomains extiende la política a todos los subdominios. Solo añade preload si planeas enviar tu dominio a la lista de preload de HSTS (hstspreload.org), que codifica a fuego el requisito de HTTPS de tu dominio en los propios navegadores.

Configuración HTTPS en CDN y Cloudflare

Si utilizas Cloudflare u otro CDN, la configuración HTTPS tiene una capa extra de complejidad:

• Cloudflare Flexible SSL: El tráfico se cifra entre el visitante y Cloudflare, pero la conexión entre Cloudflare y tu servidor es HTTP plano. Es la más fácil de configurar (no se necesita certificado SSL en tu servidor) pero proporciona seguridad incompleta. Los datos entre Cloudflare y tu servidor están sin cifrar.
• Cloudflare Full SSL: El tráfico se cifra en ambos lados, pero Cloudflare no verifica el certificado de tu servidor. Necesitas un certificado SSL en tu servidor, pero puede ser autofirmado.
• Cloudflare Full (Strict) SSL: La configuración recomendada. El tráfico se cifra en ambos lados y Cloudflare verifica el certificado de tu servidor. Usa un certificado válido de Let's Encrypt o un Cloudflare Origin Certificate.

Si cambias de Flexible a Full (Strict), asegúrate primero de que tu servidor tenga un certificado SSL válido instalado. De lo contrario, tu sitio se caerá porque Cloudflare no podrá establecer una conexión segura con tu servidor.

Cloudflare también ofrece "Always Use HTTPS" en SSL/TLS > Edge Certificates, que realiza la redirección de HTTP a HTTPS en el edge de Cloudflare. Esto es más rápido que una redirección en tu servidor de origen porque el visitante nunca llega a tu servidor para la petición HTTP.

Comprobar la caducidad del certificado SSL y la auto-renovación

Un certificado SSL caducado es peor que no tener certificado. Los navegadores muestran un aviso a página completa que la mayoría de visitantes no atravesarán, y tu sitio queda efectivamente fuera de línea. Así es como monitorizar tu certificado:

# Comprobar la fecha de caducidad del certificado
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Comprobar los días que faltan para la caducidad
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Si usas Let's Encrypt con Certbot, la auto-renovación debería estar configurada automáticamente. Pero verifica que realmente funciona comprobando los logs de renovación de Certbot:

# Comprobar el log de renovación de Certbot
cat /var/log/letsencrypt/letsencrypt.log | tail -20

# Listar todos los certificados y sus fechas de caducidad
sudo certbot certificates

Para sitios en producción, configura una monitorización que te avise cuando tu certificado se acerque a la caducidad. Servicios como UptimeRobot, StatusCake o incluso una simple tarea cron que compruebe la fecha del certificado pueden salvarte de caídas inesperadas.

Verifica tu configuración HTTPS con InspectWP

Tras completar la migración, ejecuta un análisis con InspectWP para verificar que todo funciona correctamente. InspectWP comprueba varios aspectos relacionados con HTTPS:

• Detección SSL/TLS: Confirma que tu sitio se sirve sobre HTTPS.
• Contenido mixto: Detecta cualquier recurso HTTP (imágenes, scripts, hojas de estilo) cargado en tus páginas HTTPS.
• Cabecera HSTS: Verifica que la cabecera Strict-Transport-Security está presente y configurada correctamente.
• Redirección HTTP: Comprueba si la versión HTTP de tu sitio redirige adecuadamente a HTTPS.
• Cabeceras de seguridad: Revisa otras cabeceras relacionadas con la seguridad que complementan tu configuración HTTPS.

Si InspectWP reporta avisos de contenido mixto, usa la consola del navegador para identificar los recursos específicos y corrígelos usando los métodos descritos arriba. Ejecuta otro análisis después de cada corrección hasta que el informe vuelva limpio.