Migración HTTPS: checklist paso a paso (2026)

HTTPS es un estándar desde hace 9 años, la mayoría de webs ya tienen HTTPS activado. Pero muchas lo tienen a medias.

Mixed content (recursos que siguen cargándose por HTTP dentro de una página HTTPS), redirects que dan dos saltos en vez de uno, HSTS (una cabecera de seguridad que casi nadie configura) sin activar, y Search Console con la propiedad HTTP como principal. Para Google, eso es casi como no tener HTTPS.

Y Chrome está apretando las tuercas: en abril de 2026 activará HTTPS-First para los mil millones de usuarios que tienen activada la navegación segura mejorada, y en octubre de 2026 lo hará para todos¹. Ya no es un cartelito discreto de “No seguro” — es una pantalla de bloqueo antes de que el usuario pueda entrar.

Esta checklist sirve tanto si vas a migrar desde cero como si ya tienes HTTPS pero sospechas que algo no está bien del todo.

Por qué HTTPS sigue importando en 2026

No voy a intentar convencerte de que uses HTTPS. Eso ya está hecho. Lo que quiero que entiendas es qué pasa cuando lo tienes mal configurado.

Google confirmó HTTPS como factor de ranking en 2014². ¿El impacto directo en posiciones? Mínimo. Google lo dijo claramente: es una señal ligera, un “desempate” entre páginas similares. Pero los efectos secundarios son otra historia:

Confianza del usuario. Chrome marca las webs HTTP como “No seguro” desde 2018. Desde abril de 2026, HTTPS-First se activa progresivamente para todos los usuarios de Chrome¹. Una web HTTP mostrará una pantalla de advertencia completa antes de cargar. Si tu web no tiene HTTPS limpio, vas a perder visitas antes de que Google tenga que opinar.
Rendimiento. HTTP/2 y HTTP/3 (el protocolo que usa QUIC) requieren HTTPS. Sin el certificado, tu servidor se queda en HTTP/1.1 — sin las optimizaciones de velocidad que marcan la diferencia en Core Web Vitals (las métricas de rendimiento que mide Google). Más sobre esto en la sección de HTTP/3.
Compatibilidad. Funciones modernas del navegador (geolocalización, cámara, notificaciones push, webs que funcionan offline) solo funcionan sobre HTTPS. Si tu web necesita alguna de estas, no hay alternativa.

Y cuando la migración se hace mal, las consecuencias son reales. SISTRIX tiene documentados casos como Tesco.com/direct, que perdió un 70% de visibilidad en una semana tras una migración chapucera, o Lush, que nunca se recuperó del todo después de cambiar de dominio y protocolo a la vez⁸. La lección que repiten todos los casos de éxito: haz un solo cambio a la vez. Si vas a migrar a HTTPS, no rediseñes la web al mismo tiempo.

El boost SEO directo es mínimo. Pero la suma de confianza + rendimiento + compatibilidad + el riesgo de hacerlo mal hace que HTTPS bien configurado no sea opcional.

Certificados SSL en 2026

Hoy cualquier hosting que se precie activa un certificado DV (Domain Validation) de Let’s Encrypt automáticamente al conectar un dominio. Netlify, Vercel, Cloudflare, cualquier cPanel moderno — todos lo incluyen. No tienes que comprar nada, no tienes que instalar nada, no tienes que renovar nada manualmente. Si estás eligiendo hosting, en la comparativa de hosting puedes ver cuáles incluyen SSL automático.

DV, OV, EV — ¿cuál necesitas?

Tipo	Qué valida	Para quién	Precio
DV (Domain Validation)	Que controlas el dominio	El 99% de las webs	Gratis (Let’s Encrypt)
OV (Organization Validation)	Que la empresa existe	Empresas que lo necesitan por compliance	~50-200€/año
EV (Extended Validation)	Verificación exhaustiva de la empresa	Banca, seguros, grandes ecommerce	~200-1000€/año

La respuesta corta: DV con Let’s Encrypt para casi todo el mundo. OV y EV solo si tu sector lo exige por normativa o si tu departamento legal insiste. El candado verde que mostraban los EV en el navegador ya no existe — Chrome lo eliminó en 2019. Así que el argumento visual de “inspira más confianza” ya no se sostiene.

Wildcard y multi-dominio

Si gestionas subdominios (blog.tudominio.com, app.tudominio.com, staging.tudominio.com), un certificado wildcard (*.tudominio.com) te cubre todos con un solo certificado. Let’s Encrypt los emite gratis. Solo necesitas validación por DNS en vez de por HTTP.

El cambio importante: de 90 a 45 días

Let’s Encrypt anunció en diciembre de 2025 que sus certificados pasarán de 90 a 45 días de validez³. El objetivo es mejorar la seguridad, pero la consecuencia práctica es clara: si renuevas certificados a mano (con recordatorios en el calendario, ejecutando certbot manualmente), vas a tener problemas.

Esto no es teórico. El 88% de las empresas ha sufrido caídas por certificados expirados⁴. Le ha pasado a Microsoft Teams (20 millones de usuarios afectados en febrero de 2025), a Riot Games con League of Legends (dos veces), y a LinkedIn (dos veces en dos años).

La solución: automatiza la renovación con certbot (la herramienta de Let’s Encrypt para gestionar certificados) y una tarea programada en el servidor, o usa un hosting que lo gestione solo. Si dependes de un recordatorio manual cada 45 días, algún día vas a olvidarlo.

Checklist pre-migración

Todo lo que hay que preparar ANTES de tocar nada. Si te saltas esta fase y algo sale mal durante la migración, no tendrás referencia para saber qué ha cambiado.

1. Backup completo Base de datos + archivos. Si usas WordPress, un plugin como UpdraftPlus o la línea de comandos de WordPress, WP-CLI (wp db export), te lo resuelve en un minuto. Si algo sale mal, quieres poder volver al estado anterior en menos de 5 minutos, no en 5 horas.

2. Rastreo completo con Screaming Frog o cualquier otro crawler técnico Haz un crawl de tu web en HTTP antes de tocar nada. Exporta los resultados. Este es tu snapshot de referencia: después de la migración, harás otro crawl en HTTPS y compararás. Si algo se ha roto, lo verás aquí.

3. Exportar rankings actuales Saca un export de Google Search Console (Rendimiento → Exportar) y de tu herramienta de tracking si usas alguna. Quieres saber en qué posición estabas para cada keyword ANTES de migrar. Si después de la migración algo baja, necesitas datos para saber si es por la migración o por otra cosa.

4. Revisar enlaces internos: ¿absolutos o relativos? Si tus enlaces internos usan URLs absolutas (http://tudominio.com/pagina/), tendrás que cambiarlos todos. Si usan rutas relativas (/pagina/), no hace falta tocarlos. Compruébalo antes de migrar para saber cuánto trabajo te espera.

5. Revisar recursos embebidos Scripts externos, contenido incrustado de otras webs (iframes), imágenes cargadas desde otros dominios. Si alguno de estos recursos se carga por HTTP, va a generar mixed content después de la migración. Es más fácil identificarlos ahora que cazarlos uno a uno después.

6. Preparar Search Console Añade la propiedad HTTPS de tu dominio en Google Search Console antes de migrar. Cuando migres, GSC necesitará la propiedad HTTPS ya verificada para empezar a recoger datos inmediatamente. Si usas la verificación por dominio (con registro DNS), ya cubre ambas versiones.

7. Disavow: descárgalo antes Si alguna vez subiste un archivo de disavow a Search Console (la lista de enlaces tóxicos que le pides a Google que ignore), descárgalo. El disavow está asociado a la propiedad, y la propiedad HTTPS es nueva. Tendrás que volver a subirlo después de la migración.

Checklist durante la migración

Aquí es donde pasan las cosas. Ve paso a paso y no te saltes ninguno.

1. Activar el certificado SSL

Si tu hosting tiene Let’s Encrypt integrado (la mayoría), esto es un clic. Si usas Netlify, Vercel o Cloudflare, ya lo tienes activado. Si estás en un servidor propio, certbot (la herramienta de Let’s Encrypt) te lo resuelve:

sudo certbot --nginx -d tudominio.com -d www.tudominio.com

Comprueba que funciona: abre https://tudominio.com en el navegador. Si ves el candado, el certificado está instalado.

2. Redirect 301 global: HTTP → HTTPS

Este es el paso más importante y donde más gente la lía. Necesitas que TODAS las URLs HTTP redirijan a su equivalente HTTPS con un 301 (redirect permanente). Y tiene que ser en un solo salto — nada de http://dominio.com → http://www.dominio.com → https://www.dominio.com. Eso son dos redirects, y cada salto pierde un poco de autoridad.

Apache (.htaccess) — con www y HTTPS en un solo salto:

RewriteEngine On

# Forzar HTTPS + www en un solo redirect
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.tudominio.com%{REQUEST_URI} [L,R=301]

Si usas tu dominio sin www, cambia la lógica:

RewriteEngine On

# Forzar HTTPS sin www en un solo redirect
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://tudominio.com%{REQUEST_URI} [L,R=301]

Nginx:

server {
    listen 80;
    listen 443 ssl;
    server_name tudominio.com;
    return 301 https://www.tudominio.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.tudominio.com;
    # ... tu configuración SSL y root aquí
}

Comprueba el redirect con curl:

curl -I http://tudominio.com
# Debería devolver: HTTP/1.1 301 Moved Permanently
# Location: https://www.tudominio.com/

3. Actualizar URLs en base de datos

Si usas WordPress, todas las URLs de tus posts, páginas, imágenes y menús están guardadas como URLs absolutas en la base de datos. Necesitas cambiar http:// por https:// en todas.

La forma más fiable es WP-CLI (la línea de comandos de WordPress):

wp search-replace 'http://tudominio.com' 'https://tudominio.com' --dry-run
# --dry-run = prueba sin hacer cambios reales. Si tiene buena pinta:
wp search-replace 'http://tudominio.com' 'https://tudominio.com'

Si no tienes acceso SSH, el plugin Better Search Replace hace lo mismo desde el admin de WordPress.

Un aviso sobre Really Simple SSL: es un plugin popular para “arreglar” HTTPS, pero funciona tapando el problema en vez de solucionarlo. Reescribe URLs al vuelo en vez de cambiarlas en la base de datos, y ha habido versiones que han roto sitios enteros⁵. Mejor hacer el cambio limpio en la base de datos y no depender de un plugin para algo tan básico.

4. Actualizar canonical tags

El canonical tag es una etiqueta HTML que le dice a Google cuál es la URL “oficial” de cada página. Comprueba que todas tus páginas lo tengan apuntando a la versión HTTPS:

<link rel="canonical" href="https://www.tudominio.com/tu-pagina/" />

Si usas WordPress con Yoast o Rank Math, los canonicals deberían actualizarse solos al cambiar las URLs en la base de datos. Pero compruébalo: mira el código fuente de unas cuantas páginas (clic derecho → Ver código fuente, busca “canonical”) y confirma que dicen https://.

5. Actualizar sitemap y enviarlo a GSC

Genera un sitemap nuevo con todas las URLs en HTTPS. Envíalo desde Google Search Console (propiedad HTTPS) → Sitemaps → Añadir.

6. Revisar robots.txt

Abre https://tudominio.com/robots.txt y comprueba que no haya ninguna regla que bloquee las URLs HTTPS. Suena raro, pero he visto robots.txt con Disallow: / en la versión HTTPS porque alguien lo puso durante el desarrollo y se olvidó de quitarlo.

7. Actualizar URLs en campañas activas

Google Ads, email marketing, redes sociales, enlaces en bio. Todo lo que apunte a http:// debería actualizarse a https://. Sí, los redirects 301 funcionarán, pero en publicidad cada redirect añade latencia y puede causar discrepancias en el tracking.

Si usas Cloudflare: cuidado con Flexible SSL

Este es el problema que más veo en foros y que peor explican las guías. Si usas Cloudflare (y millones de webs lo usan en el plan gratuito), necesitas entender la diferencia entre sus modos SSL antes de tocar nada.

Cloudflare tiene tres modos principales:

Modo	Navegador → Cloudflare	Cloudflare → Tu servidor	¿Seguro?
Flexible	HTTPS ✅	HTTP ❌	No realmente
Full	HTTPS ✅	HTTPS ✅ (sin validar cert)	Parcial
Full (Strict)	HTTPS ✅	HTTPS ✅ (valida cert)	Sí

El problema con Flexible: tu visitante ve el candado en el navegador, pero el tráfico entre Cloudflare y tu servidor viaja sin cifrar. Es una falsa seguridad. Y lo peor: cuando sigues las instrucciones de cualquier guía de migración HTTPS y añades un redirect 301 en tu .htaccess o plugin, se crea un bucle infinito.

¿Por qué? Porque tu servidor recibe la petición de Cloudflare por HTTP (así funciona Flexible), intenta redirigir a HTTPS, Cloudflare la recibe y la vuelve a enviar por HTTP a tu servidor, que intenta redirigir otra vez… y así hasta el ERR_TOO_MANY_REDIRECTS.

La solución: cambia el modo SSL de Cloudflare a Full (Strict) y asegúrate de tener un certificado SSL real en tu servidor origen (Let’s Encrypt funciona). Así el tráfico está cifrado de verdad en todo el recorrido y tus redirects no entran en un bucle.

Si ves ERR_TOO_MANY_REDIRECTS después de activar HTTPS, lo primero que tienes que mirar es el modo SSL de Cloudflare. En el 90% de los casos, ese es el problema.

Checklist post-migración

Has hecho la migración. Ahora toca comprobar que todo funciona y que no se te ha escapado nada.

1. Comprobar propiedad HTTPS en Google Search Console Si no la añadiste antes (deberías haberlo hecho en la fase pre-migración), hazlo ahora. Mejor aún: usa la verificación por dominio (DNS), que cubre HTTP, HTTPS, www y sin www de golpe.

2. Enviar sitemap actualizado Si no lo hiciste durante la migración, envía el sitemap con URLs HTTPS desde la propiedad HTTPS de GSC. Esto acelera la reindexación.

3. Rastreo con Screaming Frog: comparar Haz un crawl nuevo de tu web en HTTPS. Compáralo con el snapshot que hiciste antes de la migración. Busca: páginas que devuelven 404, redirects que no funcionan, canonical tags que siguen apuntando a HTTP.

4. Comprobar mixed content Abre tu web en Chrome, pulsa F12, ve a la pestaña Console. Si hay recursos cargándose por HTTP dentro de una página HTTPS, verás errores de “Mixed Content”. Los más comunes: imágenes hardcodeadas con http:// en la base de datos, fuentes cargadas desde CDNs antiguos, y scripts de terceros que no soportan HTTPS.

Para encontrarlos todos de golpe, Screaming Frog tiene un filtro específico: Bulk Export → Response Codes → Mixed Content.

5. Comprobar redirects: sin cadenas ni loops Comprueba con curl o Screaming Frog que cada redirect va de A a B en un solo salto. Si tienes cadenas (A → B → C), reescribe para que A vaya directamente a C.

6. Comprobar canonical tags Revisa una muestra de páginas (home, categorías, posts clave) y confirma que el canonical apunta a https://.

7. Monitorear rankings 2-4 semanas Es normal ver fluctuaciones los primeros días. Google está procesando los 301 y reindexando. Si después de 2-3 semanas algo no se ha recuperado, busca errores en GSC → Indexación → Páginas.

8. Comprobar que Analytics no se ha roto Esto pilla a mucha gente: migras a HTTPS, miras Analytics al día siguiente, y el tráfico ha caído un 80%. Pánico. Pero el tráfico no ha caído — has dejado de medirlo. Si tu código de seguimiento de Google Analytics (GA4) o Google Tag Manager (GTM) no está funcionando en la versión HTTPS, o si tienes filtros que excluyen el protocolo nuevo, tus datos van a desaparecer. Comprueba que el tracking funciona en la versión HTTPS antes de diagnosticar una caída de tráfico que probablemente no existe.

9. Actualizar perfiles externos Google Business Profile, redes sociales, directorios, perfiles de foros, firmas de email. Todo lo que tenga tu URL antigua debería actualizarse. Los 301 funcionan, pero un enlace limpio siempre es mejor que uno redirigido.

HSTS: la parte que nadie configura bien

HSTS (HTTP Strict Transport Security) es un header que le dice al navegador: “esta web solo funciona en HTTPS. Ni se te ocurra cargarla por HTTP.” Cuando un navegador recibe este header, durante el tiempo que indique el max-age, ni siquiera intenta conectar por HTTP — va directamente a HTTPS, sin pasar por el redirect 301.

¿Por qué importa? Porque sin HSTS, la primera petición de cada sesión sigue yendo por HTTP y depende del redirect 301 para llegar a HTTPS. Eso es un viaje extra al servidor y, en redes WiFi públicas, una ventana para que alguien intercepte la conexión entre tu usuario y tu web.

Cómo configurarlo

El header correcto es:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

max-age=31536000 — 1 año. Empieza con un valor bajo (86400 = 1 día) para probar, y súbelo cuando confirmes que todo funciona.
includeSubDomains — aplica HSTS a todos los subdominios.
preload — necesario si quieres entrar en la lista preload (ver abajo).

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;

Netlify (_headers o netlify.toml):

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Comprueba que el header se envía correctamente:

curl -sI https://tudominio.com | grep -i strict
# Debería devolver: strict-transport-security: max-age=31536000; includeSubDomains; preload

HSTS preload: piénsalo dos veces

La lista preload de HSTS es una base de datos que viene integrada en Chrome, Firefox, Safari y Edge⁶. Si tu dominio está en esa lista, los navegadores NUNCA intentarán conectar por HTTP, ni siquiera la primera vez. Suena genial. Pero tiene letra pequeña:

Es prácticamente irreversible. Una vez que entras en la lista, salir tarda entre 6 y 14 semanas, porque depende de los ciclos de release de Chrome.
Afecta a TODOS los subdominios. Si tienes un subdominio de staging, un panel de administración interno, o un servicio de terceros en un subdominio que no soporta HTTPS, se va a romper. Google mismo no puede activar HSTS preload en su dominio principal porque no todos sus subdominios lo soportan.
La tasa de abandono es altísima. El 47% de los dominios que han estado en la lista preload han sido eliminados después — 108,000 de 229,000⁷.

Mi recomendación: activa HSTS con un max-age alto (31536000). Eso ya te da el 95% del beneficio. El preload solo si controlas absolutamente todos tus subdominios y entiendes las consecuencias. Si tienes dudas, no lo hagas — no puedes deshacerlo rápido.

Para enviar tu dominio a la lista preload: hstspreload.org. Para comprobar el estado actual de tu dominio: usa el mismo sitio.

HTTP/2 y HTTP/3: el bonus de rendimiento

HTTPS no es solo seguridad. Es velocidad.

HTTP/2 lleva años siendo el estándar. La diferencia clave con HTTP/1.1: en vez de pedir los archivos de tu web uno a uno (primero el CSS, luego el JS, luego las imágenes…), HTTP/2 los pide todos a la vez por una sola conexión. Resultado: menos espera, carga más rápida. Y HTTP/2 requiere HTTPS.

HTTP/3 va un paso más allá. Usa un protocolo de red más moderno (QUIC) que mejora especialmente las conexiones en redes móviles y WiFi inestables — esas situaciones donde la web “se atasca” unos segundos cargando. Cloudflare, Google y la mayoría de CDNs (redes de distribución de contenido, como Cloudflare o Fastly) ya lo soportan.

¿Cómo saber si tu servidor ya usa HTTP/3?

curl -sI --http3 https://tudominio.com 2>&1 | head -1
# Si dice "HTTP/3 200", lo tienes

También puedes comprobarlo en Chrome DevTools → Network → columna “Protocol”. Verás h2 (HTTP/2) o h3 (HTTP/3).

¿Impacto real en Core Web Vitals (las métricas de rendimiento que mide Google)? HTTP/3 mejora especialmente el tiempo que tarda en llegar el primer byte de tu web al navegador, sobre todo en conexiones lentas. Si tu público navega mucho desde móvil, se nota. Si es principalmente desktop con fibra, la diferencia es menor.

Lo importante: sin HTTPS, estás atascado en HTTP/1.1. Con HTTPS, tienes acceso a HTTP/2 y HTTP/3 (si tu servidor o CDN lo soporta). Es rendimiento gratis.

Errores comunes que veo auditando

Estos son los fallos que encuentro una y otra vez cuando reviso el apartado de seguridad en una auditoría SEO técnica. Si reconoces alguno, arréglalo.

1. Mixed content por imágenes escritas a mano en la base de datos. WordPress guarda las URLs de las imágenes como texto literal, tipo http://tudominio.com/wp-content/uploads/imagen.jpg. El search-replace del paso 3 debería haberlas pillado, pero a veces quedan en widgets, en opciones del tema, o en tablas custom de plugins. Revisa la consola de Chrome (F12 → Console) en varias páginas, no solo en la home.

2. Redirects con doble salto. http://dominio.com → http://www.dominio.com → https://www.dominio.com. Son dos redirects. Cada salto pierde un poco de autoridad y añade latencia. El .htaccess o configuración de nginx debería resolver protocolo y www en un solo 301.

3. HSTS no configurado. O peor: configurado con un max-age de 300 segundos (5 minutos), que no sirve para nada. Si vas a activar HSTS, ponle al menos 31536000 (1 año). Un max-age bajo es como no tenerlo.

4. Canonical apuntando a HTTP. El canonical dice http:// pero la página se sirve en https://. Google suele resolverlo solo, pero es una señal contradictoria que puede confundir la indexación. Es fácil de arreglar y no hay excusa para dejarlo.

5. Sitemap con URLs HTTP. El sitemap que tienes enviado a Search Console sigue listando http://tudominio.com/pagina/. Genera uno nuevo con las URLs HTTPS y envíalo.

6. Search Console sin propiedad HTTPS. Solo tienes la propiedad http:// verificada. GSC necesita la propiedad HTTPS para recoger datos correctamente. Mejor aún: usa la verificación por dominio (DNS) y cúbrelo todo.

7. Internal links absolutos sin actualizar. Tu menú de navegación, tu footer, tus enlaces internos en el contenido — si alguno sigue apuntando a http://, el usuario ve un redirect (latencia) y Googlebot rastrea una URL que no es la canónica (mala señal).

8. Cloudflare en modo Flexible sin saberlo. El SSL de Cloudflare está en Flexible, los redirects hacen un loop, y alguien instaló un plugin que lo “arregla” reescribiendo URLs al vuelo. Todo parece funcionar, pero el tráfico entre Cloudflare y el servidor viaja sin cifrar. He visto esto más veces de las que me gustaría.

9. Analytics roto post-migración. Migras a HTTPS, miras los datos al día siguiente, y parece que has perdido todo el tráfico. Pero no lo has perdido — tu snippet de tracking no funciona en la versión HTTPS, o un filtro de vista excluye el protocolo nuevo. Antes de entrar en pánico, comprueba que GA4/GTM está disparando correctamente en HTTPS.

Si reconoces más de dos o tres de estos errores en tu web, tu migración necesita una revisión seria. La buena noticia es que todos tienen solución — y la mayoría se arreglan en una tarde.

Herramientas

La lista corta de lo que necesitas para una migración HTTPS limpia:

Screaming Frog — crawl completo antes y después de la migración. Detecta mixed content, redirects con cadenas, canonicals incorrectos y enlaces internos sin actualizar. Es la herramienta que más uso.
Chrome DevTools (F12 → Console) — para encontrar errores de mixed content en tiempo real. Gratis y siempre disponible.
SSL Labs (ssllabs.com/ssltest) — test completo de la configuración de tu certificado SSL. Te da una calificación de A a F y te dice exactamente qué mejorar.
hstspreload.org — para comprobar el estado HSTS de tu dominio y enviarlo a la lista preload si decides hacerlo.
Google Search Console — monitoreo post-migración. Errores de indexación, cobertura, y rendimiento de la propiedad HTTPS.
curl — para comprobar redirects, headers HSTS y soporte HTTP/3 desde la terminal. Rápido y fiable.

Conclusión

En 2026 la conversación ya no es “debería migrar a HTTPS”. Es “¿lo tengo bien configurado?”.

La mayoría de webs ya tienen el certificado instalado. Pero entre mixed content, redirects mal hechos, HSTS sin configurar y Cloudflare en modo Flexible, son muchas las que lo tienen a medias. Chrome ya está activando HTTPS-First progresivamente — cada vez queda menos margen para dejarlo para después.

Si has seguido esta checklist paso a paso, tu migración debería estar limpia. Si al comprobar has encontrado problemas que no sabes resolver, o si prefieres que alguien le eche un ojo a cómo está tu web, escríbeme. Me dedico a esto.

Y si quieres ir más allá de HTTPS y revisar tu web entera, tengo una guía completa de auditoría SEO técnica que cubre las 6 áreas que miro en cada proyecto.

Referencias

[1] Google Security Blog — Chrome will default to HTTPS-First mode — https://security.googleblog.com/2025/10/https-by-default.html

[2] Google Webmaster Central Blog — HTTPS as a ranking signal (2014) — https://webmaster-es.googleblog.com/2014/08/https-como-senal-del-ranking.html

[3] Let’s Encrypt — Certificates will have 45-day lifetime (diciembre 2025) — https://letsencrypt.org/2025/12/02/from-90-to-45

[4] Keyfactor — 88% of companies have experienced outages caused by expired certificates — https://www.keyfactor.com/blog/the-enemy-of-uptime-an-expired-ssl-certificate/

[5] WordPress.org Support — Website broken after installing Really Simple SSL (múltiples reportes, versión 7.2.3) — https://wordpress.org/support/topic/website-broken-after-installing-really-simple-ssl/

[6] Chromium — HTTP Strict Transport Security — https://www.chromium.org/hsts/

[7] APNIC Blog — HSTS Preload: Adoption and Challenges — 47% de dominios eliminados (108,000 de 229,000) — https://blog.apnic.net/2023/07/26/hsts-preload-adoption-and-challenges/

[8] SISTRIX — Migración, migraciones, migrañas: los temores no están bien fundados — Casos documentados de Tesco, Lush, Deutsche Welle y otros — https://www.sistrix.es/blog/migracion-migraciones-migranas-los-temores-no-estan-bien-fundados/