¿Cómo forzar la carga mediante el protocolo HTTPS en un sitio HTML puro?

La pregunta parece sencilla: “¿Cómo obligo a que mi sitio HTML cargue siempre con HTTPS?”. Pero debajo hay una pequeña trampa, una de esas ironías discretas que tanto abundan en la web: HTML no puede forzar HTTPS por sí solo. El lenguaje que pinta titulares, botones e imágenes no gobierna la conexión segura. Es como pedirle al menú del restaurante que cierre la cocina con llave.

Para imponer HTTPS de verdad hay que actuar donde corresponde: en el servidor web, el proveedor de hosting, el CDN, el balanceador de carga o la configuración DNS/SSL de la plataforma. El HTML puede ayudar a evitar contenido mixto, definir URLs canónicas y ordenar la casa, sí; pero la autoridad sobre el protocolo nace antes de que el navegador lea siquiera la primera etiqueta <html>.

Contenido de esta guía

1. Qué significa realmente forzar HTTPS
2. Requisitos previos: certificado SSL/TLS y servidor correctamente configurado
3. Forzar HTTPS en Apache con .htaccess
4. Forzar HTTPS en Nginx
5. Opciones en cPanel, Cloudflare, Netlify, GitHub Pages y otros entornos
6. Qué debes cambiar dentro de un sitio HTML estático
7. HSTS: el candado con memoria
8. Contenido mixto: el enemigo que entra por la ventana
9. SEO, redirecciones 301 y señales canónicas
10. Cómo comprobar que todo funciona
11. Errores frecuentes y cómo resolverlos

Qué significa realmente forzar HTTPS

Forzar HTTPS significa que cualquier intento de acceder a una URL mediante http:// sea redirigido automáticamente a su versión segura https://. Si alguien escribe:

http://ejemplo.com/contacto.html

el servidor debe responder con una redirección, normalmente 301 permanente, hacia:

https://ejemplo.com/contacto.html

La antítesis es clara: HTTP transmite como una postal, HTTPS como una carta sellada. No es que el contenido de la postal sea necesariamente vergonzoso; es que cualquiera en el camino puede leerla, copiarla o cambiarla. En una web de solo HTML —sin formularios complejos, sin carrito, sin área privada— puede parecer exagerado. Pero hoy incluso una página estática carga fuentes, scripts, imágenes, analítica, mapas, píxeles, formularios embebidos. El viejo folleto digital se ha convertido en una pequeña plaza pública con vendedores, cámaras y transeúntes.

HTTPS aporta tres garantías principales:

• Cifrado: protege los datos en tránsito para que no viajen expuestos.
• Integridad: dificulta que un intermediario altere la respuesta del servidor.
• Autenticidad: permite al navegador verificar que está hablando con el dominio correcto mediante un certificado TLS válido.

Desde hace años, los principales navegadores marcan HTTP como “No seguro”. Google Chrome empezó a endurecer estas advertencias progresivamente desde 2018, y el mensaje cultural fue rotundo: la web sin cifrado dejó de ser normal. Como tantas revoluciones técnicas, llegó disfrazada de pequeño icono en la barra de direcciones.

Requisitos previos: no se puede redirigir a una casa que no existe 🏠

Antes de forzar HTTPS, tu sitio debe poder cargar correctamente por HTTPS. Parece obvio, pero no lo es tanto. He visto más de una web con redirección impecable hacia una página que acababa mostrando un error de certificado. La seguridad convertida en callejón sin salida: un prodigio de eficiencia malgastada.

Necesitas:

1. Un certificado SSL/TLS válido para tu dominio, incluyendo www si lo usas.
2. El servidor configurado para servir el sitio en el puerto 443.
3. Una cadena de certificados correcta, con intermedios bien instalados.
4. Redirecciones limpias, sin bucles ni saltos innecesarios.
5. Recursos internos cargando por HTTPS, para evitar contenido mixto.

Dato útil: hoy puedes obtener certificados gratuitos con Let’s Encrypt en la mayoría de hostings. Muchos paneles como cPanel, Plesk, DirectAdmin o proveedores administrados los activan con un clic. Gratis no significa improvisado: Let’s Encrypt es una autoridad certificadora ampliamente aceptada y automatizada.

HTTP, HTTPS, SSL y TLS: nombres que conviene ordenar

Se suele decir “certificado SSL”, aunque técnicamente el protocolo moderno es TLS. SSL es el nombre antiguo que quedó pegado al habla cotidiana como esas palabras de la infancia que sobreviven aunque ya no sean exactas. En la práctica, cuando un hosting dice “activar SSL”, normalmente está hablando de habilitar HTTPS mediante TLS.

Si tienes un sitio HTML puro, es decir, archivos como index.html, servicios.html, contacto.html, carpetas de imágenes, CSS y JavaScript, la lógica no cambia: la redirección se configura fuera del HTML.

Forzar HTTPS en Apache con .htaccess

Apache sigue siendo uno de los servidores más comunes en alojamientos compartidos. Si tu hosting permite usar archivos .htaccess, esta suele ser la vía más rápida.

Coloca o edita el archivo .htaccess en la raíz pública de tu sitio, normalmente public_html, www o la carpeta donde se encuentra tu index.html.

Redirección básica de HTTP a HTTPS

RewriteEngine On

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

Esta regla indica: si la conexión no es HTTPS, redirige al mismo host y a la misma ruta, pero usando https://.

Redirección HTTPS y dominio con www

Si quieres que todo cargue en https://www.ejemplo.com, incluso cuando alguien entra por http://ejemplo.com, puedes usar:

RewriteEngine On

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.ejemplo\.com$ [NC]
RewriteRule ^(.*)$ https://www.ejemplo.com%{REQUEST_URI} [L,R=301]

Redirección HTTPS y dominio sin www

Si prefieres la versión sin www, que hoy es bastante habitual:

RewriteEngine On

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.ejemplo\.com$ [NC]
RewriteRule ^(.*)$ https://ejemplo.com%{REQUEST_URI} [L,R=301]

Cuidado: sustituye ejemplo.com por tu dominio real. Y no mezcles reglas copiadas de varios tutoriales como quien prepara una sopa con todos los condimentos del armario. Las redirecciones duplicadas pueden generar bucles, cadenas largas o comportamientos intermitentes.

Cuando Apache está detrás de un proxy o CDN

Si usas Cloudflare, un balanceador de carga o un proxy inverso, puede ocurrir que Apache “vea” la conexión como HTTP aunque el visitante haya llegado por HTTPS al proxy. En ese caso, la variable %{HTTPS} puede no bastar.

Algunos entornos envían la cabecera X-Forwarded-Proto. Podrías necesitar algo como:

RewriteEngine On

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

No todos los servidores gestionan igual estas cabeceras. Si usas hosting administrado, conviene revisar la documentación del proveedor antes de convertir el .htaccess en una novela rusa.

Forzar HTTPS en Nginx

Nginx no usa .htaccess. Sus reglas se definen en la configuración del servidor, normalmente en archivos dentro de /etc/nginx/sites-available/, /etc/nginx/conf.d/ o configuraciones equivalentes según la distribución.

Redirección básica en Nginx

server {
    listen 80;
    listen [::]:80;
    server_name ejemplo.com www.ejemplo.com;

    return 301 https://$host$request_uri;
}

Y luego tu bloque HTTPS:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name ejemplo.com www.ejemplo.com;

    ssl_certificate /ruta/al/certificado/fullchain.pem;
    ssl_certificate_key /ruta/a/la/clave/privkey.pem;

    root /var/www/ejemplo;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Forzar HTTPS y versión sin www

server {
    listen 80;
    listen [::]:80;
    server_name ejemplo.com www.ejemplo.com;

    return 301 https://ejemplo.com$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.ejemplo.com;

    ssl_certificate /ruta/al/certificado/fullchain.pem;
    ssl_certificate_key /ruta/a/la/clave/privkey.pem;

    return 301 https://ejemplo.com$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name ejemplo.com;

    ssl_certificate /ruta/al/certificado/fullchain.pem;
    ssl_certificate_key /ruta/a/la/clave/privkey.pem;

    root /var/www/ejemplo;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Después de editar, conviene probar la configuración y recargar el servicio:

sudo nginx -t
sudo systemctl reload nginx

Buena práctica: evita hacer redirecciones en cascada. Lo ideal es que cualquier variante llegue a la URL final en un solo salto: de http://www.ejemplo.com/pagina.html directamente a https://ejemplo.com/pagina.html, no pasando primero por HTTPS con www y después sin www.

Cómo hacerlo según tu plataforma o proveedor ⚙️

No todos los sitios HTML viven en un servidor clásico. Algunos descansan en alojamientos compartidos, otros en CDNs, otros en plataformas estáticas que despliegan desde Git. La web moderna es un archipiélago: muchas islas, cada una con su propio faro.

Cloudflare: una mención especial

Cloudflare es magnífico cuando se configura bien y un laberinto con alfombra roja cuando se configura a medias. Para forzar HTTPS:

1. Entra en Cloudflare.
2. Ve a SSL/TLS.
3. Usa preferiblemente Full (strict), si tu servidor tiene certificado válido.
4. Ve a SSL/TLS → Edge Certificates.
5. Activa Always Use HTTPS.
6. Opcionalmente, activa Automatic HTTPS Rewrites para ayudar con recursos mixtos.

No confundas “Flexible SSL” con seguridad completa. En modo Flexible, el visitante se conecta por HTTPS a Cloudflare, pero Cloudflare puede conectarse por HTTP a tu servidor. Es como poner una puerta blindada en la entrada y dejar abierta la del patio. A veces sirve como transición, pero no debería ser el destino final.

Qué debes cambiar dentro de un sitio HTML puro

Aunque el HTML no puede forzar HTTPS desde el inicio de la conexión, sí puede reforzar la coherencia del sitio. Aquí empieza el trabajo fino, ese que no se ve en la fachada pero evita goteras.

1. Usa enlaces internos relativos o HTTPS absoluto

Si en tu HTML tienes enlaces internos con HTTP:

<a href="http://ejemplo.com/servicios.html">Servicios</a>

cámbialos a:

<a href="https://ejemplo.com/servicios.html">Servicios</a>

o, mejor aún, si se trata de enlaces dentro del mismo dominio:

<a href="/servicios.html">Servicios</a>

Las rutas relativas al dominio suelen ser más limpias y evitan atarte a un protocolo en cada enlace.

2. Actualiza imágenes, CSS, JavaScript y fuentes

Busca referencias como estas:

<img src="http://ejemplo.com/img/logo.png" alt="Logo">
<link rel="stylesheet" href="http://ejemplo.com/css/estilos.css">
<script src="http://ejemplo.com/js/app.js"></script>

y cámbialas por:

<img src="/img/logo.png" alt="Logo">
<link rel="stylesheet" href="/css/estilos.css">
<script src="/js/app.js"></script>

Para recursos externos, usa siempre https:// si el proveedor lo soporta:

<script src="https://cdn.ejemploexterno.com/libreria.min.js"></script>

3. Añade etiqueta canonical con HTTPS

En cada página importante, define la URL canónica con HTTPS:

<link rel="canonical" href="https://ejemplo.com/pagina.html">

Esto ayuda a los motores de búsqueda a entender cuál es la versión preferida. No sustituye una redirección 301, pero la acompaña como un buen cartel acompaña a una carretera bien trazada.

4. Actualiza Open Graph, Twitter Cards y datos estructurados

Si usas metadatos sociales, revisa que apunten a HTTPS:

<meta property="og:url" content="https://ejemplo.com/pagina.html">
<meta property="og:image" content="https://ejemplo.com/img/imagen-social.jpg">

Lo mismo aplica para JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://ejemplo.com/"
}
</script>

5. Actualiza sitemap.xml y robots.txt

Tu sitemap.xml debe listar URLs HTTPS:

<url>
  <loc>https://ejemplo.com/</loc>
</url>

Y si en robots.txt indicas el sitemap, hazlo también con HTTPS:

Sitemap: https://ejemplo.com/sitemap.xml

HSTS: el candado con memoria 🧠🔒

Una redirección 301 le dice al navegador: “si vienes por HTTP, ve a HTTPS”. HSTS —HTTP Strict Transport Security— va un paso más allá: le dice al navegador que, durante cierto tiempo, ni siquiera intente usar HTTP para ese dominio.

Es una idea elegante, casi severa. Como un portero que no discute con nadie: si la lista dice HTTPS, se entra por HTTPS.

La cabecera básica es:

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

Eso indica que durante un año —31.536.000 segundos— el navegador debe usar HTTPS para ese dominio. Si añades preload, podrías solicitar la inclusión en la lista de precarga de navegadores, pero hay que hacerlo con prudencia.

HSTS en Apache

En .htaccess, si el módulo headers está disponible:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

HSTS en Nginx

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

Activa HSTS solo cuando estés seguro. Si incluyes subdominios y alguno no tiene HTTPS funcional, puedes dejarlo inaccesible para usuarios que ya recibieron la cabecera. HSTS es poderoso; no es una pegatina decorativa.

¿Conviene usar HSTS preload?

El preload hace que los navegadores sepan de antemano que tu dominio debe cargarse por HTTPS, incluso antes de la primera visita. Para entrar en esa lista normalmente se exige una cabecera como:

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

Y cumplir requisitos específicos, como redirigir HTTP a HTTPS y servir HTTPS correctamente en todo el dominio y subdominios incluidos. Es excelente para marcas consolidadas, bancos, plataformas con alta exposición y proyectos donde todos los subdominios están bajo control. Para un sitio pequeño que todavía está reorganizando DNS, correos, subdominios de pruebas y experimentos nocturnos, puede ser demasiado definitivo. Hay herramientas que se parecen a una llave; esta se parece más a soldar la puerta.

Contenido mixto: cuando el sitio entra seguro y sale distraído 🧩

El contenido mixto ocurre cuando una página cargada por HTTPS solicita recursos mediante HTTP. Por ejemplo:

<img src="http://otrodominio.com/banner.jpg" alt="Banner">

o:

<script src="http://cdn.antiguo.com/plugin.js"></script>

El navegador puede bloquear esos recursos o mostrar advertencias. En especial, los scripts y hojas de estilo por HTTP son peligrosos porque pueden alterar el comportamiento de la página. Es la paradoja del castillo con foso y puente levadizo… y una ventana abierta en la despensa.

Cómo detectar contenido mixto

• Abre la web en Chrome, Firefox o Edge.
• Presiona F12 o abre las herramientas de desarrollo.
• Ve a la pestaña Console.
• Busca mensajes como Mixed Content o blocked insecure content.
• Revisa también la pestaña Network y filtra por http://.

Usar Content Security Policy para actualizar solicitudes inseguras

Una medida complementaria es enviar una cabecera CSP con upgrade-insecure-requests. Esta instrucción pide al navegador que intente convertir solicitudes HTTP a HTTPS automáticamente.

En HTML, puedes añadir:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

Pero es mejor enviarlo como cabecera desde el servidor cuando sea posible:

Content-Security-Policy: upgrade-insecure-requests

Importante: esta directiva no hace magia. Si el recurso externo no existe por HTTPS, puede fallar. Sirve como red de seguridad, no como sustituto de limpiar tus URLs.

HTTPS, SEO y redirecciones 301: no solo seguridad, también señal de confianza 📈

Google confirmó hace años que HTTPS es una señal de posicionamiento, aunque ligera comparada con contenido, autoridad, intención de búsqueda y experiencia de usuario. Pero reducir HTTPS a “un factor SEO” sería pobre. Es confianza visible, compatibilidad con APIs modernas y requisito para muchas funciones del navegador.

Además, una migración mal hecha puede fragmentar señales. Si tu sitio responde en estas cuatro variantes:

• http://ejemplo.com
• http://www.ejemplo.com
• https://ejemplo.com
• https://www.ejemplo.com

debes elegir una versión final y redirigir las demás hacia ella con 301 permanente. No se trata de capricho estético. Para buscadores, analítica y usuarios, la consistencia es oxígeno.

Lista SEO tras activar HTTPS

✅ Redirección 301

Todas las URLs HTTP deben apuntar a su equivalente HTTPS, idealmente con un solo salto.

✅ Canonical actualizado

Las etiquetas rel="canonical" deben usar la versión HTTPS final.

✅ Sitemap renovado

Incluye solo URLs HTTPS y vuelve a enviarlo en Google Search Console y Bing Webmaster Tools.

✅ Enlaces internos corregidos

Evita enlaces absolutos con HTTP dentro de menús, pies de página y botones.

✅ Recursos seguros

Imágenes, CSS, JS, fuentes y iframes deben cargarse por HTTPS.

✅ Analítica revisada

Comprueba que Google Analytics, Tag Manager, píxeles y conversiones sigan funcionando.

Un comentario casi doméstico: una vez migré una web estática pequeña, de esas que parecían no tener más misterio que una lámpara de escritorio. Tres páginas, cuatro imágenes, un formulario externo. Todo perfecto… salvo un logotipo cargado desde un subdominio olvidado en HTTP. El navegador no gritaba; carraspeaba. Y a veces ese carraspeo basta para que un cliente pregunte si la web “está hackeada”. La confianza, en internet, tiene el grosor de un icono.

Cómo comprobar que HTTPS está bien forzado 🔎

No basta con abrir la portada y ver el candado. Hay que probar como probaría un usuario despistado, un buscador obstinado y un navegador quisquilloso.

1. Prueba manual en el navegador

Escribe explícitamente:

http://tudominio.com

y verifica que termina en:

https://tudominio.com

Haz lo mismo con páginas internas:

http://tudominio.com/contacto.html

Debe redirigir a:

https://tudominio.com/contacto.html

2. Usa curl desde terminal

curl -I http://ejemplo.com

Una respuesta correcta debería mostrar algo similar a:

HTTP/1.1 301 Moved Permanently
Location: https://ejemplo.com/

También puedes seguir redirecciones:

curl -IL http://ejemplo.com

Así verás si hay demasiados saltos.

3. Revisa el certificado

Herramientas útiles:

• SSL Labs Server Test: analiza certificado, protocolos TLS, cifrados y configuración general.
• Why No Padlock: ayuda a detectar contenido mixto.
• SecurityHeaders.com: revisa cabeceras de seguridad como HSTS y CSP.
• Google Search Console: permite inspeccionar indexación, sitemaps y versión canónica.

4. Comprueba con y sin www

Prueba todas las variantes:

http://ejemplo.com
http://www.ejemplo.com
https://ejemplo.com
https://www.ejemplo.com

Todas deberían terminar en una única versión final. Esa disciplina ahorra problemas de SEO, cookies, analítica y caché.

Errores frecuentes al forzar HTTPS y cómo evitarlos

Error 1: activar la redirección antes del certificado

El resultado suele ser un aviso del navegador: “La conexión no es privada”. Técnicamente quisiste proteger al usuario; prácticamente lo asustaste en la entrada. Primero certificado válido, después redirección.

Error 2: crear bucles de redirección

Ocurre cuando el servidor y el CDN se contradicen. Por ejemplo, Cloudflare en modo Flexible y Apache redirigiendo a HTTPS pueden provocar un bucle porque el origen cree que siempre recibe HTTP.

Solución: usa Full o Full (strict) en Cloudflare, instala certificado en el servidor de origen y simplifica reglas.

Error 3: mantener recursos HTTP en la página

El sitio carga por HTTPS, pero una fuente, un script o una imagen sigue entrando por HTTP. Resultado: advertencias, bloqueos o pérdida del candado visual.

Solución: búsqueda global en tus archivos por:

http://

y revisar cada aparición con paciencia de relojero.

Error 4: olvidar subdominios

Tu dominio principal funciona, pero blog.ejemplo.com, cdn.ejemplo.com o assets.ejemplo.com no. Si activas HSTS con includeSubDomains, el problema puede volverse serio.

Solución: audita subdominios antes de aplicar políticas globales.

Error 5: usar redirecciones temporales 302 sin motivo

Para una migración definitiva de HTTP a HTTPS, normalmente corresponde 301. La redirección 302 indica temporalidad y puede retrasar la consolidación de señales en buscadores.

Error 6: no actualizar integraciones externas

Herramientas de email marketing, formularios embebidos, pasarelas, iframes de reserva o CRM pueden tener URLs antiguas. La web estática a veces parece simple, pero sus dependencias se comportan como raíces bajo la tierra: no se ven, pero levantan aceras.

Configuraciones rápidas según escenario

Escenario A: sitio HTML en hosting compartido con Apache

1. Activa certificado SSL/TLS desde el panel.
2. Comprueba que https://tudominio.com carga correctamente.
3. Añade redirección en .htaccess.
4. Actualiza enlaces internos, canonical, sitemap y recursos.
5. Comprueba contenido mixto y redirecciones.

RewriteEngine On

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

Escenario B: sitio HTML detrás de Cloudflare

1. Instala certificado en el servidor de origen.
2. Configura Cloudflare en Full (strict).
3. Activa Always Use HTTPS.
4. Revisa reglas duplicadas en servidor para evitar bucles.
5. Activa HSTS solo tras verificar subdominios y HTTPS completo.

Escenario C: sitio estático en GitHub Pages

1. Configura el dominio personalizado si aplica.
2. Espera a que GitHub emita el certificado.
3. Activa Enforce HTTPS.
4. Actualiza URLs absolutas dentro del HTML.
5. Reenvía sitemap HTTPS en Search Console.

Escenario D: sitio estático en Netlify

1. Asocia tu dominio.
2. Verifica DNS.
3. Activa HTTPS automático.
4. Si necesitas reglas personalizadas, usa _redirects.

http://ejemplo.com/* https://ejemplo.com/:splat 301!
http://www.ejemplo.com/* https://ejemplo.com/:splat 301!
https://www.ejemplo.com/* https://ejemplo.com/:splat 301!

Cabeceras de seguridad recomendadas para acompañar HTTPS 🛡️

Forzar HTTPS es el primer escalón, no la catedral entera. Si tienes acceso a cabeceras HTTP, considera implementar algunas defensas adicionales. No todas son obligatorias para todos los proyectos, pero conviene conocerlas.

En Apache, un conjunto razonable podría verse así:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>

Y en Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

Sobre CSP: una política CSP completa puede romper scripts, fuentes o estilos si se define sin inventario previo. Empieza con auditoría, prueba en entorno controlado y, si hace falta, usa primero Content-Security-Policy-Report-Only.

Checklist final para una migración HTTPS impecable

• 🔐 Certificado TLS válido instalado para dominio raíz y www.
• 🌐 Sitio accesible correctamente por https:// antes de redirigir.
• ➡️ Redirección 301 desde HTTP a HTTPS.
• 🧭 Elección clara entre dominio con www o sin www.
• 🔗 Enlaces internos actualizados o convertidos a rutas relativas.
• 🖼️ Imágenes, CSS, JS, fuentes e iframes cargando por HTTPS.
• 📄 Canonical, Open Graph, JSON-LD y sitemap usando URLs HTTPS.
• 🤖 robots.txt apuntando al sitemap HTTPS.
• 📊 Search Console y herramientas de analítica revisadas.
• 🧪 Pruebas con curl -IL, navegador y herramientas SSL.
• 🛡️ HSTS aplicado con cautela, especialmente si hay subdominios.

Entonces, ¿puede un HTML puro forzar HTTPS?

La respuesta corta: no por sí solo. La respuesta útil: sí puedes lograr que un sitio HTML puro cargue siempre por HTTPS configurando correctamente el servidor, hosting o CDN, y limpiando después el HTML para que todo sea coherente.

La web tiene estas paradojas encantadoras: una página compuesta por archivos estáticos puede necesitar decisiones de infraestructura muy serias. Un simple index.html puede depender de certificados, cabeceras, DNS, redirecciones, políticas de seguridad y rastreadores de búsqueda. Lo mínimo, cuando se mira de cerca, rara vez es pequeño.

Forzar HTTPS no es una moda ni una ceremonia para tranquilizar navegadores. Es una promesa técnica: quien llegue a tu sitio no será enviado por un camino oscuro cuando existe una avenida iluminada. Y en internet, donde casi todo viaja invisible, esa promesa vale más de lo que parece. 🚀

Consejo profesional: documenta la configuración aplicada —reglas de redirección, proveedor del certificado, fecha de renovación, cabeceras activas y versión canónica del dominio—. El futuro tú, ese pobre desconocido que heredará tus decisiones dentro de seis meses, lo agradecerá.