HTTPS (HyperText Transfer Protocol Secure) es la versión cifrada del protocolo HTTP, el estándar de comunicación de la web. La diferencia esencial con HTTP es que HTTPS cifra todos los datos que se transmiten entre el navegador del usuario y el servidor web usando el protocolo TLS (Transport Layer Security), haciendo imposible que terceros intercepten o lean esa comunicación. En 2026, cualquier sitio web sin HTTPS aparece marcado como "No seguro" en Chrome y tiene una desventaja de posicionamiento en Google. HTTPS ya no es una opción avanzada para sitios de e-commerce o banca: es el estándar mínimo de seguridad para cualquier presencia web, independientemente de su tamaño o propósito.
Qué significa HTTPS: desglosando el acrónimo
HTTPS son las siglas de HyperText Transfer Protocol Secure. Para entender qué aporta el HTTPS, es útil entender primero qué es el HTTP del que parte:
- HyperText Transfer Protocol (HTTP) es el protocolo que define cómo se comunican el navegador y el servidor web. Cuando escribes una URL en el navegador y pulsas Enter, tu navegador envía una solicitud HTTP al servidor; el servidor responde con otra mensaje HTTP que contiene la página web solicitada.
- Secure (Seguro) es el añadido que aporta HTTPS: una capa de cifrado TLS que envuelve toda esa comunicación, haciendo que los datos sean ilegibles para cualquier tercero que los intercepte.
HTTPS no es un protocolo diferente a HTTP: es HTTP funcionando sobre una conexión cifrada TLS. Esto significa que todas las reglas y convenciones de HTTP (métodos GET, POST, PUT, DELETE; códigos de estado 200, 404, 500; cabeceras HTTP) se aplican exactamente igual en HTTPS. La única diferencia es que toda esa comunicación viaja envuelta en cifrado.
Cómo funciona HTTPS: lo que ocurre cuando visitas una web segura
Cuando escribes https://tudominio.com en el navegador o haces clic en un enlace HTTPS, ocurren estas cosas en fracciones de segundo antes de que veas cualquier contenido:
Fase 1: Resolución DNS
El navegador pregunta al servidor DNS cuál es la dirección IP del dominio que quieres visitar. Esta consulta DNS ocurre antes de que se establezca la conexión HTTPS y, en la configuración por defecto, no está cifrada (aunque el protocolo DNS over HTTPS, DoH, está cambiando esto).
Fase 2: Conexión TCP
El navegador establece una conexión TCP con el servidor en el puerto 443 (el puerto por defecto de HTTPS, frente al puerto 80 de HTTP). Esto implica el three-way handshake TCP: SYN, SYN-ACK, ACK.
Fase 3: Handshake TLS
Una vez establecida la conexión TCP, el navegador y el servidor negocian los parámetros de la conexión cifrada mediante el handshake TLS. Con TLS 1.3 (el estándar actual), este proceso ocurre en un único viaje de ida y vuelta:
- El navegador envía al servidor la lista de versiones de TLS y algoritmos de cifrado que soporta.
- El servidor elige la versión y el algoritmo, y envía su certificado SSL/TLS.
- El navegador verifica el certificado: comprueba que está firmado por una Autoridad Certificadora de confianza, que no ha caducado y que el dominio del certificado coincide con el dominio al que está accediendo.
- Ambas partes generan una clave de sesión simétrica única para esta conexión, sin transmitirla nunca por la red.
Fase 4: Comunicación cifrada
A partir de aquí, toda la comunicación HTTP (la solicitud de la página, la respuesta con el HTML, las solicitudes de imágenes, CSS y JavaScript) viaja cifrada con esa clave de sesión única. Nadie que intercepte el tráfico puede leer nada: solo verá datos binarios sin ningún significado interpretable.
Qué protege HTTPS y qué no protege
Entender exactamente qué protege HTTPS y qué no es importante para no crear una falsa sensación de seguridad total:
| HTTPS SÍ protege | HTTPS NO protege |
|---|---|
| Los datos que envías en formularios (contraseñas, datos personales, números de tarjeta) | El hecho de que estás visitando un dominio determinado (el dominio es visible en el SNI del handshake TLS y en el DNS) |
| El contenido exacto de las páginas que visitas (URLs completas, parámetros de búsqueda) | Tu dirección IP: el servidor sabe desde qué IP te conectas |
| Los datos que el servidor te devuelve (el contenido de la página web) | Vulnerabilidades en el código de la aplicación web (XSS, SQL injection, CSRF) |
| Las cookies de sesión que intercambian navegador y servidor | Malware en tu dispositivo que lee los datos antes de que sean cifrados |
| Las cabeceras HTTP (incluyendo cookies, tokens de autenticación) | Ataques de phishing donde el atacante tiene su propio certificado HTTPS válido para un dominio fraudulento |
| La integridad de los datos: detecta si alguien modificó los datos en tránsito | La seguridad del servidor donde está alojado el sitio web |
Punto clave: que un sitio tenga HTTPS (el candado en la barra de direcciones) solo garantiza que la comunicación está cifrada. No garantiza que el sitio sea legítimo, seguro o confiable. Los sitios de phishing también pueden tener HTTPS y certificados válidos. Siempre verifica el dominio exacto, no solo el candado.
La diferencia práctica entre HTTP y HTTPS: un ejemplo real
Imagina que accedes a la web de tu banco desde una red WiFi pública en un aeropuerto. Hay alguien en la misma red ejecutando un ataque man-in-the-middle (interceptando el tráfico WiFi). Esto es lo que ocurre en cada escenario:
Con HTTP: el atacante puede ver exactamente qué páginas visitas, leer todos los datos que envías en formularios (incluyendo tu usuario, contraseña y número de cuenta), ver las cookies de sesión (y usarlas para impersonarte sin necesidad de conocer tu contraseña) y modificar el contenido que el servidor te envía (por ejemplo, cambiando el número de cuenta destino en una transferencia).
Con HTTPS: el atacante puede ver que estás conectado a tubanco.com (el dominio es visible), pero no puede leer ningún dato de la comunicación, no puede ver qué páginas concretas visitas ni qué datos envías, no puede obtener tus cookies de sesión ni modificar el contenido en tránsito. Cualquier intento de modificar los datos es detectado automáticamente por el mecanismo de integridad de TLS.
El indicador visual de HTTPS en los navegadores
Los navegadores modernos comunican de forma clara al usuario si la conexión es segura o no:
En Google Chrome
| Indicador en la barra de direcciones | Significado | Cuándo aparece |
|---|---|---|
| Icono de candado cerrado (gris) | Conexión HTTPS válida: la comunicación está cifrada | En cualquier página HTTPS con certificado válido |
| Sin icono o icono de información (i) | Conexión HTTPS válida pero con algunas advertencias menores | Con contenido mixto pasivo (imágenes HTTP en página HTTPS) |
| "No seguro" en texto rojo | Conexión HTTP sin cifrado: los datos viajan en texto plano | En cualquier página HTTP; en páginas HTTPS con contenido mixto activo |
| Advertencia de certificado (pantalla roja de error) | El certificado SSL tiene un problema: caducado, para otro dominio, o no confiable | Cuando el certificado no supera la verificación del navegador |
Desde Chrome 94 (2021), Google eliminó el icono de candado verde con texto "Seguro" que aparecía antes, argumentando que muchos usuarios lo confundían con una garantía de que el sitio era legítimo y confiable, cuando en realidad solo garantiza el cifrado de la comunicación. Ahora el candado es gris y neutral: indica cifrado, no confiabilidad del contenido.
En Firefox
Firefox muestra un icono de candado gris para HTTPS válido y un candado tachado con advertencia de color para problemas de certificado o contenido mixto. En páginas HTTP sin cifrado, muestra un candado tachado en gris.
Por qué HTTPS es imprescindible en 2026: los cinco motivos principales
Motivo 1: La seguridad de tus usuarios
El motivo más fundamental. Si tu sitio tiene formularios de cualquier tipo (contacto, login, registro, checkout), los datos que los usuarios introducen viajan del navegador al servidor. Sin HTTPS, cualquier persona en la misma red que el usuario puede interceptar esos datos. Esto incluye:
- Contraseñas de acceso a cuentas.
- Datos personales (nombre, apellidos, dirección, teléfono, email).
- Números de tarjeta de crédito y datos de pago.
- Mensajes de correo electrónico o mensajes privados enviados a través de formularios.
- Tokens de sesión que permiten impersonar al usuario sin necesitar su contraseña.
El riesgo es especialmente alto en redes WiFi públicas (aeropuertos, cafeterías, hoteles), donde los ataques man-in-the-middle son técnicamente sencillos de ejecutar.
Motivo 2: Google Chrome marca tu sitio como "No seguro"
Desde julio de 2018, Google Chrome muestra el texto "No seguro" en la barra de direcciones de todas las páginas HTTP que tienen formularios. Desde septiembre de 2021, muestra este indicador en todas las páginas HTTP, independientemente de si tienen formularios o no. En 2026, Chrome tiene una cuota de mercado de navegadores de escritorio superior al 65% a nivel global.
El impacto en las métricas de negocio es directo y medible:
- Los usuarios ven el aviso "No seguro" y desconfían del sitio, especialmente antes de introducir cualquier dato.
- La tasa de rebote aumenta en páginas con formularios que muestran el aviso.
- La tasa de conversión (registros, compras, contactos) cae de forma significativa.
- La credibilidad percibida del negocio se ve afectada negativamente.
Motivo 3: Posicionamiento en Google
Google anunció en agosto de 2014 que HTTPS es una señal de ranking. En el contexto de la actualización de Core Web Vitals de 2021, confirmó que HTTPS forma parte de las señales de experiencia de página que alimentan el sistema de ranking de Google Search. Las implicaciones prácticas son:
- Dos páginas equivalentes en calidad de contenido, relevancia y autoridad de dominio, si una tiene HTTPS y la otra no, la de HTTPS tiene ventaja en el ranking.
- La migración de HTTP a HTTPS, cuando se hace correctamente con redirecciones 301, no pierde posicionamiento y puede mejorarlo.
- Las páginas que devuelven advertencias de certificado SSL (certificado caducado, para el dominio incorrecto) pueden ser penalizadas porque Google las considera inseguras para el usuario.
Motivo 4: HTTP/2 y HTTP/3 solo funcionan con HTTPS
Las versiones modernas del protocolo HTTP ofrecen mejoras de rendimiento sustanciales que impactan directamente en el Core Web Vitals y la experiencia de usuario:
| Característica | HTTP/1.1 | HTTP/2 (solo HTTPS) | HTTP/3 (solo HTTPS) |
|---|---|---|---|
| Solicitudes simultáneas | 6-8 por dominio (limitado) | Ilimitadas sobre una conexión | Ilimitadas, sin head-of-line blocking |
| Compresión de cabeceras | No | Sí (HPACK) | Sí (QPACK, más eficiente) |
| Server Push | No | Sí | Sí (mejorado) |
| Protocolo de transporte | TCP | TCP | QUIC (sobre UDP, más rápido) |
| Requiere TLS | No | Sí (en la práctica) | Sí (siempre) |
Sin HTTPS, tu servidor solo puede usar HTTP/1.1 con los navegadores, independientemente de si el servidor soporta HTTP/2. Los navegadores no implementan HTTP/2 o HTTP/3 sobre conexiones no cifradas. Un sitio sin HTTPS está condenado a las limitaciones de rendimiento de HTTP/1.1.
Motivo 5: Obligaciones legales en Europa
En Europa, la transmisión de datos personales sin cifrado puede constituir una infracción del RGPD (Reglamento General de Protección de Datos). El artículo 32 del RGPD exige que los responsables del tratamiento implementen medidas técnicas apropiadas para garantizar un nivel de seguridad adecuado al riesgo, citando explícitamente el cifrado como una de esas medidas. Si tu sitio recopila cualquier dato personal de ciudadanos europeos (nombre, email, dirección IP, cookies de seguimiento), transmitirlos sin cifrado puede considerarse una violación del principio de integridad y confidencialidad del RGPD.
La AEPD (Agencia Española de Protección de Datos) puede sancionar a empresas que no adopten medidas técnicas adecuadas para proteger los datos en tránsito. Las multas por infracciones del RGPD pueden llegar hasta el 4% de la facturación global anual o 20 millones de euros (lo que sea mayor).
El impacto de no tener HTTPS: datos concretos
Más allá de los argumentos técnicos, el impacto de no tener HTTPS en un sitio web se puede cuantificar en métricas de negocio concretas:
| Métrica | Impacto de no tener HTTPS | Fuente |
|---|---|---|
| Tasa de rebote en páginas con formularios | Aumenta significativamente cuando Chrome muestra "No seguro" | Estudios de UX y A/B testing publicados por Google |
| Tasa de conversión en checkout | Caída drástica: los usuarios abandonan antes de introducir datos de pago en una página "No segura" | Análisis de e-commerce con y sin HTTPS |
| Posición en resultados de Google | Desventaja frente a competidores con HTTPS equivalente en contenido y autoridad | Google Search Central Blog, 2014 y 2021 |
| Compatibilidad con HTTP/2 | Sin HTTPS: HTTP/1.1 únicamente, con sus limitaciones de rendimiento | Especificación HTTP/2 (RFC 7540) |
| Cumplimiento RGPD | Riesgo de sanción por la AEPD si se transmiten datos personales sin cifrado | Artículo 32 del RGPD |
Cómo saber si tu sitio web ya tiene HTTPS
Verificar si tu sitio tiene HTTPS correctamente configurado es sencillo:
Desde el navegador
- Abre tu sitio web en Chrome.
- Mira la barra de direcciones: si la URL empieza por
https://y hay un icono de candado, el certificado SSL está instalado. - Haz clic en el candado para ver los detalles del certificado: emisor, fecha de caducidad y dominio al que está asociado.
Desde la línea de comandos
# Verificar si el sitio responde en HTTPS:
curl -I https://tudominio.com
# Verificar que HTTP redirige correctamente a HTTPS:
curl -I http://tudominio.com
# Debe mostrar: HTTP/1.1 301 Moved Permanently
# y: Location: https://tudominio.com/
# Ver los detalles del certificado SSL:
echo | openssl s_client -connect tudominio.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
# Verificar qué versiones de TLS acepta el servidor:
nmap --script ssl-enum-ciphers -p 443 tudominio.com | grep -E "TLSv|cipher"Con herramientas online
- SSL Labs (ssllabs.com/ssltest/): el análisis más completo. Evalúa el certificado, la cadena de certificados, las versiones de TLS, los algoritmos de cifrado y asigna una nota de A+ a F.
- Why No Padlock (whynopadlock.com): detecta específicamente el problema de contenido mixto (recursos HTTP en una página HTTPS).
- Google Search Console: en la sección Seguridad y Acciones Manuales muestra problemas de seguridad detectados por Google, incluyendo problemas de certificado.
Cómo activar HTTPS si aún no lo tienes
El proceso de activación de HTTPS varía según el tipo de servidor y el panel de control que uses:
En Plesk (los servidores de sys4net)
En todos los planes de hosting de sys4net, Let's Encrypt está preintegrado en Plesk. La activación es inmediata desde el panel de control:
- Accede a Plesk.
- Ve a Websites y Dominios > [tu dominio] > SSL/TLS Certificates.
- Haz clic en "Instalar" junto a Let's Encrypt.
- Marca también "Asegurar www.[tudominio]" si quieres cubrir la versión con www.
- Haz clic en "Obtener de forma gratuita".
En menos de un minuto tendrás HTTPS activo con renovación automática incluida.
En WordPress (si usas un hosting que no tiene Plesk)
# Si tu hosting incluye Let's Encrypt en el panel de control:
# Actívalo desde el panel (cPanel, DirectAdmin, Hestia, etc.)
# Si tienes acceso SSH al servidor:
sudo apt install certbot python3-certbot-apache # Para Apache
sudo certbot --apache -d tudominio.com -d www.tudominio.com
# Después de activar HTTPS, actualiza WordPress para que use HTTPS:
# En wp-config.php:
define('WP_HOME', 'https://tudominio.com');
define('WP_SITEURL', 'https://tudominio.com');
# Actualiza las URLs en la base de datos:
wp search-replace 'http://tudominio.com' 'https://tudominio.com' --skip-columns=guidLos pasos después de activar HTTPS
Activar el certificado SSL es solo el primer paso. Después de activar HTTPS, hay varias acciones que debes realizar para que la migración sea completa y no perjudique el SEO:
- Configura la redirección 301 de HTTP a HTTPS: todas las URLs HTTP deben redirigir automáticamente a su equivalente HTTPS. Plesk lo hace automáticamente al activar Let's Encrypt.
- Actualiza las URLs internas del sitio: los enlaces internos, las imágenes y los recursos que usan URLs HTTP absoluta deben actualizarse a HTTPS para evitar el contenido mixto.
- Actualiza el sitemap XML: el sitemap debe usar URLs HTTPS. En WordPress, los plugins de SEO (Yoast, Rank Math) lo actualizan automáticamente.
- Actualiza Google Search Console: añade la versión HTTPS de tu sitio como propiedad en Search Console. La versión HTTP y HTTPS son propiedades distintas para Google.
- Actualiza Google Analytics: cambia la URL del sitio en la configuración de Google Analytics a la versión HTTPS para que el tráfico se atribuya correctamente.
- Actualiza los backlinks más importantes: contacta con los sitios que te enlazan con las URLs HTTP más importantes (las que tienen más tráfico o autoridad) para que actualicen los enlaces a la versión HTTPS.
- Verifica la configuración con SSL Labs: comprueba que el certificado está correctamente instalado y que el servidor solo acepta TLS 1.2 y TLS 1.3.
Preguntas frecuentes sobre HTTPS
¿HTTPS hace mi web más lenta?
No de forma significativa en 2026. Con TLS 1.3, el handshake TLS requiere solo un viaje de ida y vuelta (1-RTT), lo que añade una latencia mínima, típicamente de unos pocos milisegundos. Además, HTTPS habilita HTTP/2 y HTTP/3, que son significativamente más rápidos que HTTP/1.1 gracias a la multiplexación de solicitudes, compresión de cabeceras y otras optimizaciones. En la práctica, un sitio bien configurado con HTTPS, HTTP/2 y TLS 1.3 carga igual o más rápido que el mismo sitio con HTTP/1.1 sin cifrado.
¿Cuánto cuesta activar HTTPS?
Puede ser completamente gratuito. Let's Encrypt ofrece certificados SSL/TLS DV sin ningún coste y con renovación automática cada 90 días. En los servidores de sys4net, Let's Encrypt está incluido y preconfigurado en todos los planes de hosting. Si necesitas un certificado de mayor nivel de validación (OV para mostrar el nombre de tu organización, o EV para validación extendida), los precios oscilan entre 50 y varios cientos de euros anuales dependiendo del tipo y del proveedor.
¿Perderé posicionamiento en Google al migrar de HTTP a HTTPS?
No, si la migración se hace correctamente. La clave es configurar redirecciones 301 (permanentes) de todas las URLs HTTP a sus equivalentes HTTPS, actualizar el sitemap XML, añadir la versión HTTPS en Google Search Console y actualizar los enlaces internos. Con una migración correcta, Google transfiere todo el posicionamiento y la autoridad de las URLs HTTP a las URLs HTTPS en pocas semanas. A largo plazo, la versión HTTPS puede mejorar ligeramente el posicionamiento por la señal de ranking que representa HTTPS.
¿El candado en la barra de direcciones significa que el sitio es seguro y confiable?
El candado solo garantiza que la comunicación entre tu navegador y el servidor está cifrada. No garantiza que el sitio sea legítimo, que el propietario sea quien dice ser, ni que el contenido sea seguro o verdadero. Los sitios de phishing también pueden tener HTTPS y certificados válidos: obtener un certificado DV solo requiere demostrar que controlas el dominio, algo que un atacante puede hacer con un dominio fraudulento. Siempre verifica el dominio exacto en la barra de direcciones, no solo el candado.
¿Qué pasa con los visitantes que acceden a mi sitio usando la URL HTTP antigua después de activar HTTPS?
Si tienes correctamente configurada la redirección 301 de HTTP a HTTPS (lo que Plesk hace automáticamente al activar Let's Encrypt), los visitantes que acceden por HTTP son redirigidos de forma automática a la versión HTTPS sin ninguna intervención por su parte. El navegador sigue la redirección de forma transparente y el usuario termina en la versión segura del sitio. Esta redirección es también la que indica a Google que las URLs HTTPS son las canónicas, transfiriéndoles el posicionamiento de las URLs HTTP.
¿HTTPS funciona igual en móviles que en ordenadores de escritorio?
Sí, exactamente igual. El protocolo HTTPS y el handshake TLS son independientes del dispositivo o del sistema operativo. Los navegadores móviles (Chrome para Android, Safari para iOS) implementan TLS 1.3 de la misma forma que los navegadores de escritorio y muestran los mismos indicadores visuales de seguridad. De hecho, en el contexto del Mobile-First Indexing de Google, donde la versión móvil del sitio es la que Google usa para indexar y rankear, tener HTTPS en la versión móvil es especialmente importante.