.htaccess y HTTPS: redirigir http a https, activar HSTS y cabeceras de seguridad en Apache

Para forzar HTTPS en Apache, lo más limpio es un Redirect permanent en el VirtualHost del puerto 80. Si solo tienes .htaccess, usa mod_rewrite con una regla 301 que lleve a https y al dominio canónico en un solo salto. Después añade HSTS con Header always set solo en respuestas HTTPS, empezando con un max-age corto, y el resto de cabeceras de seguridad.

Para comprobarlo en tu web: Auditoría SEO

Apache controla tres cosas de esta guía: adónde redirige cada petición, qué cabeceras acompañan a cada respuesta y, si tienes acceso al servidor, con qué certificado y qué versiones de TLS responde. El certificado en sí no se configura en un .htaccess: lo instala tu hosting o lo pones tú en el VirtualHost. Todos los fragmentos de esta guía se han probado el 07-10-2026 con Apache httpd 2.4.69 en su imagen oficial de Docker (httpd:2.4), con un certificado autofirmado y curl desde otro contenedor. La compresión, la caché y los bots de IA están en la guía hermana de .htaccess para compresión, caché y bots.

¿VirtualHost o .htaccess?

Un .htaccess es un fichero de configuración que Apache lee en cada directorio, en cada petición. La propia documentación de Apache es clara: si tienes acceso al fichero de configuración principal, pon ahí todo, incluidas las reglas de mod_rewrite, porque se cargan una vez al arrancar y no en cada petición1. En un .htaccess, además, las expresiones regulares se recompilan en cada petición1.

El .htaccess existe para quien no tiene acceso de administrador: un hosting compartido, por ejemplo. Y solo funciona si el administrador lo permite con AllowOverride, cuyo valor por defecto es None: con él, Apache ignora los .htaccess por completo1.

Paso 1: redirigir http a https desde el VirtualHost

La documentación de Apache dice que la forma más limpia de llevar http a https es un Redirect en un VirtualHost dedicado al puerto 80, sin mod_rewrite2. Si además quieres que example.com lleve a www.example.com, basta con añadir un VirtualHost en el 443 para el dominio sin www:

<VirtualHost *:80>
    ServerName www.example.com
    ServerAlias example.com
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado.crt"
    SSLCertificateKeyFile "/ruta/a/la/clave.key"
    Header always set Strict-Transport-Security "max-age=300"
    Redirect permanent "/" "https://www.example.com/"
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    DocumentRoot "/var/www/example"
    SSLEngine on
    SSLCertificateFile "/ruta/al/certificado.crt"
    SSLCertificateKeyFile "/ruta/a/la/clave.key"
    Header always set Strict-Transport-Security "max-age=300"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-uri /csp-informes"
</VirtualHost>

Una sola versión de cada URL evita duplicados entre http y https, y Google pregunta en su guía de experiencia de página si tus páginas se sirven de forma segura3. En la prueba, http://example.com/blog/?a=1 llegó a https://www.example.com/blog/?a=1 con un único 301: Redirect conserva la ruta y la consulta. Tras cada cambio, httpd -t (o apachectl configtest) valida la sintaxis antes de recargar.

Paso 1 bis: en .htaccess, https y www en un solo salto

Si solo tienes .htaccess, la documentación de Apache propone mod_rewrite con la variable %{HTTPS}, que vale on cuando la conexión va cifrada2. Esta versión une la redirección a https y la del dominio canónico, para que nadie pase por dos 301 seguidos:

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L,NE]

Línea a línea:

1. La regla salta si la conexión no es HTTPS o si el dominio no es exactamente www.example.com.
2. R=301 es una redirección permanente; L corta el resto de reglas; NE evita que Apache vuelva a codificar caracteres que ya venían codificados en la URL.
3. La consulta (?a=1) se conserva sola, porque la URL de destino no lleva ?.

Resultado con Apache 2.4.69: las cuatro combinaciones (http o https, con o sin www) acaban en https://www.example.com/ con un solo salto. Si prefieres el dominio sin www, cambia las dos apariciones del dominio.

Un aviso antes de copiarla: si tu web está detrás de un CDN o un proxy que termina el TLS, Apache recibe la petición en http y %{HTTPS} nunca vale on. La regla redirigiría siempre y entraría en bucle. La documentación de Apache propone mirar entonces la cabecera X-Forwarded-Proto que pone el proxy, y avisa de que solo te fíes de ella si controlas ese proxy y la sobrescribe en cada petición, porque cualquiera puede falsificarla2. Lo más sencillo suele ser redirigir a https en el propio CDN.

Paso 2: HSTS sin quedarte encerrado

HSTS (Strict-Transport-Security) es una cabecera que pide al navegador que, durante max-age segundos, entre siempre por HTTPS en ese dominio, sin pasar por http. El navegador la ignora si llega por una conexión sin cifrar4, así que en un .htaccess que atiende los dos puertos conviene enviarla solo por HTTPS:

Header always set Strict-Transport-Security "max-age=300" "expr=%{HTTPS} == 'on'"

La condición expr= es la forma que documenta mod_headers para poner una cabecera solo cuando se cumple una expresión5. En la prueba, la respuesta http no llevaba HSTS y la https sí.

Sube el max-age por etapas, como recomienda el servicio de precarga de HSTS: 5 minutos (300), una semana (604800), un mes (2592000), esperando en cada etapa el max-age completo antes de pasar a la siguiente6. Luego, un año (31536000).

Dos directivas merecen cuidado:

• includeSubDomains aplica la regla a todos los subdominios4. Si intranet.example.com o el panel de correo no tienen HTTPS, dejarán de abrirse.
• preload sirve para entrar en la lista que los navegadores traen de serie. Exige un max-age de al menos un año, includeSubDomains, HTTPS en todos los subdominios y la cabecera también en las redirecciones; y salir de la lista tarda meses, sin garantías en algunos navegadores6. MDN recuerda que preload no forma parte de la especificación4.

Paso 3: las demás cabeceras de seguridad

El bloque completo para el .htaccess, tal como se probó:

Header always set Strict-Transport-Security "max-age=300" "expr=%{HTTPS} == 'on'"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-uri /csp-informes"

Por qué always: mod_headers tiene dos tablas de cabeceras, y solo la de always se aplica a las respuestas que no son 2xx, como una redirección o un error5. En la prueba, el 404 llevaba las seis cabeceras y el 301 de https sin www a https con www llevaba HSTS.

La CSP en Report-Only no bloquea nada: el navegador anota lo que habría bloqueado. Para recibir esos avisos en tu servidor necesitas report-to o el antiguo report-uri10. Cuando pasen unas semanas sin avisos inesperados, cambia el nombre de la cabecera a Content-Security-Policy. Y no añadas X-XSS-Protection: 1: MDN advierte de que puede crear vulnerabilidades en webs seguras y recomienda CSP en su lugar11.

¿IfModule sí o no?

Muchos .htaccess de ejemplo envuelven todo en <IfModule mod_headers.c>. La documentación de Apache dice que esa sección solo hace falta si un mismo fichero tiene que funcionar en instalaciones con y sin el módulo, y que en condiciones normales no se necesita12. Lo comprobamos con mod_headers sin cargar:

La conclusión práctica: en tu propio .htaccess, mejor sin <IfModule>, para que un fallo se vea. Y recuerda que httpd -t no lee los .htaccess: después de cada cambio, pide la página.

Cómo comprobarlo

1. Redirección. curl -I http://example.com/ tiene que devolver 301 y una cabecera Location con la URL final en https. Con curl -IL ves todos los saltos: lo correcto es uno.
2. Cabeceras. curl -I https://www.example.com/ tiene que mostrar las seis. Prueba también una URL que no exista: el 404 también debe llevarlas.
3. HSTS solo por HTTPS. En la respuesta de http:// no debe aparecer Strict-Transport-Security.
4. Nota pública. El HTTP Observatory de Mozilla analiza la redirección, HSTS y el resto de cabeceras y da una nota13.

Qué hace SmoothSeen con esto

SmoothSeen comprueba, dentro de Posicionamiento web, si la página responde por HTTPS, si la versión http redirige a https y qué cabeceras de seguridad envía, con el HTTP Observatory de Mozilla. No entra en tu servidor ni lee tu .htaccess: mira lo mismo que un navegador y te dice qué falta, con el resto del análisis en un plan de acción priorizado.

Qué hacer esta semana

Pide curl -IL http:// de tu dominio sin www y cuenta los saltos hasta la URL final. Si son más de uno, o si faltan cabeceras en el 404, aplica el paso que corresponda y empieza HSTS con max-age=300. Para ver todo esto junto con el resto del posicionamiento web, haz una auditoría SEO.

Preguntas frecuentes

¿Por qué mi .htaccess no hace nada?

Lo más probable es que el servidor tenga AllowOverride None para ese directorio, que es el valor por defecto de Apache: con él, el fichero se ignora entero. Comprueba también que se llame exactamente .htaccess, con el punto delante, y que esté en la raíz pública de la web. Si tu hosting no permite cambiar AllowOverride, pregunta a su soporte.

¿Es mejor una redirección 301 o 302 para pasar a HTTPS?

Una 301, porque el cambio es definitivo. La documentación de Apache explica que una redirección permanente indica a los buscadores que actualicen su índice. Una 302 dice que el cambio es temporal y la URL antigua puede seguir apareciendo. Reserva la 302 para pruebas puntuales y cámbiala en cuanto confirmes que todo funciona.

¿Cómo desactivo HSTS si me equivoco?

Envía la misma cabecera con max-age=0 por HTTPS: el navegador olvida la regla en cuanto la recibe. Por http no sirve, porque el navegador ignora HSTS en conexiones sin cifrar. Si además pediste la precarga, tendrás que solicitar la baja de la lista, y llegar a todos los usuarios tarda meses: por eso conviene empezar con valores cortos.

¿Estas cabeceras mejoran el posicionamiento en Google?

No directamente. Google incluye «¿se sirven tus páginas de forma segura?» entre sus preguntas de experiencia de página, pero dice que, aparte de las Core Web Vitals, esos aspectos no ayudan por sí solos a posicionar más alto. Lo que sí ganas es una sola versión de cada URL, sin duplicados entre http y https, y visitantes mejor protegidos.