¿Qué es SSL/HTTPS? Diferencia con TLS

Google confirmó en agosto de 2014, en su blog oficial para webmasters, que HTTPS pasaba a contar como señal de ranking. Lo describió entonces como una señal «ligera», con menos peso que la relevancia del contenido o la calidad de los enlaces, pero con la intención declarada de animar a todo el sector a cifrar sus conexiones. Más de una década después, ese empujón cumplió su objetivo: HTTPS es hoy el estándar de facto y encontrar un sitio relevante servido todavía por HTTP es la excepción, no la norma.

El verdadero punto de inflexión no llegó por el algoritmo de búsqueda, sino por el navegador. En febrero de 2018, el equipo de Chromium anunció que a partir de Chrome 68, publicado en julio de ese año, cualquier página cargada por HTTP mostraría la etiqueta «No seguro» junto a la URL, sin necesidad de que hubiera un formulario de contraseña o de tarjeta de por medio como ocurría hasta entonces. Esa advertencia aparece antes de que el usuario lea una sola línea del contenido.

Ahí está la diferencia práctica que conviene tener clara: el bonus de ranking por HTTPS es pequeño y actúa sobre todo como desempate entre páginas igual de relevantes. El aviso de «No seguro», en cambio, es una alerta explícita y visible que un visitante interpreta al instante como «esta web no es de fiar», sin que medie ningún algoritmo. Ese daño a la confianza, abandono inmediato, carritos vacíos, formularios sin rellenar, pesa en la práctica más que el punto extra de ranking, y suele ser el argumento que convence a un cliente reacio a migrar cuando el SEO por sí solo no basta.

Migrar de HTTP a HTTPS parece un cambio técnico menor, pero es de los que más tráfico hunden cuando se hace deprisa. El primer punto, y el que más se salta, es que cada URL en HTTP necesita su propio redirect 301 hacia la versión equivalente en HTTPS, no solo la home. Un redirect genérico de todo el dominio a la home nueva rompe cada URL indexada y desperdicia el enlazado que ya tenía cada página.

El segundo problema, casi inevitable si no se audita antes, es el contenido mixto o mixed content: imágenes, hojas de estilo, scripts o iframes que la página nueva sigue cargando desde una URL http:// en lugar de https://. El navegador puede bloquear directamente esos recursos o, como mínimo, quitar el candado de la barra de direcciones, lo que anula visualmente el esfuerzo de haber migrado. Conviene revisar recurso por recurso antes de dar el cambio por cerrado, no solo el HTML de las páginas principales.

El tercer punto son las señales que Google usa para entender cuál es la versión canónica: las etiquetas canonical y los enlaces internos tienen que apuntar ya a https, no seguir referenciando la versión antigua. Dejar canonicals apuntando a http después de migrar manda una señal contradictoria justo cuando se necesita que Google confíe en la versión nueva. Lo mismo ocurre con las entradas del sitemap, los datos estructurados y los recursos enlazados de forma fija, como las imágenes Open Graph: ahí también suele quedar la dirección http antigua, porque estaba escrita directamente en una plantilla o en un archivo de configuración en lugar de seguir el protocolo actual de forma dinámica.

Por último, Search Console trata http y https como propiedades distintas, así que hace falta verificar la propiedad https como una entidad nueva y volver a enviar el sitemap actualizado con las URLs correctas. La herramienta de cambio de dirección de Google no es necesaria en una migración que solo cambia el protocolo, pero sí conviene mantener ambas propiedades verificadas y vigiladas en paralelo mientras dura la transición, y dejar los redirects activos al menos un año para dar tiempo a que el índice se actualice del todo.

No todos los certificados verifican lo mismo, aunque el candado del navegador se vea igual. Un certificado de validación de dominio (DV) solo comprueba que quien lo solicita controla ese dominio; se emite en minutos, muchas veces de forma gratuita a través de Let's Encrypt, y es el nivel que necesita la inmensa mayoría de blogs, webs corporativas y landing pages.

Un certificado de validación de organización (OV) añade una comprobación de que existe una empresa real detrás del dominio, con papeleo y verificación manual de por medio. Un certificado de validación extendida (EV) va un paso más allá y verifica la identidad legal de la organización con el nivel de rigor más alto del sector.

Durante años, EV se vendió con el argumento de que mostraba el nombre de la empresa en verde junto a la URL, pero Chrome eliminó esa indicación visual en la versión 77, en 2019, tras comprobar en sus estudios de usabilidad que casi ningún usuario la notaba ni entendía lo que significaba. Firefox siguió el mismo camino poco después. Hoy esa información solo aparece si alguien hace clic en el candado y entra a ver los detalles de la conexión, así que un certificado EV ya no compra un distintivo visible: compra una validación legal más estricta, relevante sobre todo por motivos de cumplimiento normativo o de responsabilidad en sectores como la banca o el comercio electrónico de alto volumen, no por diferenciarse en la barra de direcciones.

Más allá del tipo de validación, conviene mirar también la cobertura del certificado: uno de dominio único cubre solo esa dirección, uno wildcard suma automáticamente todos los subdominios (tienda.ejemplo.es o blog.ejemplo.es, por ejemplo), y uno multidominio (SAN) agrupa varios dominios distintos bajo un mismo certificado. Qué variante conviene depende menos del nivel de validación que de cómo esté estructurado el propio sitio.

• Redirige con 301 cada URL en HTTP a su equivalente exacta en HTTPS, no solo el dominio raíz, y evita cadenas de varios saltos.
• Audita todos los recursos de la página (imágenes, CSS, JavaScript, iframes) antes de dar la migración por terminada, para eliminar cualquier referencia que siga apuntando a http://.
• Actualiza canonicals, hreflang y enlaces internos para que apunten directamente a la versión https, en lugar de depender de un redirect intermedio.
• Verifica la propiedad https como nueva propiedad en Search Console y sube el sitemap actualizado en cuanto el cambio esté en producción.
• Configura la renovación automática del certificado; un certificado caducado tira el candado y, en muchos navegadores, sustituye la página entera por una pantalla de advertencia a pantalla completa.
• Añade la cabecera HSTS una vez confirmado que todo funciona en https, para que el navegador ni siquiera intente cargar la versión http en visitas futuras.

• Migrar solo la home a https y dejar el resto del sitio en http, o redirigir todas las URLs antiguas a la home nueva en lugar de a su equivalente exacta.
• Dejar recursos con contenido mixto sin corregir, lo que bloquea elementos de la página o elimina el candado aunque la URL principal ya sea https.
• Olvidar actualizar canonicals y enlaces internos, de forma que sigan apuntando a http después de la migración.
• No verificar la propiedad https en Search Console, lo que deja a Google sin datos de rendimiento de la versión nueva durante semanas.
• Dejar caducar el certificado por no automatizar la renovación, lo que reintroduce el aviso de «No seguro» en un sitio que ya estaba migrado.
• Pagar de más por un certificado EV pensando que sigue mostrando el nombre de la empresa en verde, una función que Chrome y Firefox retiraron en 2019.