HyperText Transfer Protocol Secure (HTTPS) es una versión encriptada de HTTP, que es el protocolo principal utilizado para transferir datos a través de la World Wide Web.
HTTPS protege la comunicación entre su navegador y servidor de ser interceptada y manipulada por atacantes. Esto proporciona confidencialidad, integridad y autenticación a la gran mayoría del tráfico WWW actual.
Cualquier sitio web que muestre un icono de candado en la barra de direcciones está usando HTTPS.
En este artículo, aprenderás:
- Los fundamentos de HTTP y HTTPS
- Cómo funcionan los certificados TLS
- Cómo HTTPS ayuda al SEO
- Cómo configurar HTTPS
- Cómo verificar posibles errores de migración HTTPS
HTTP vs. HTTPS: comprensión de los conceptos básicos
Primero, permítanme simplificar e ilustrar la comunicación entre el cliente (navegador) y el servidor cuando hay un atacante en el medio.
http request respons atacante posibilidades
Como puede ver, los atacantes pueden obtener datos confidenciales como datos de inicio de sesión y pago o inyectar código malicioso en los recursos solicitados.
Los posibles ataques a la red pueden ocurrir en cualquier lugar con un enrutador o ISP no confiable. Por lo tanto, cualquier red WiFi pública es vulnerable a tales ataques. Afortunadamente, parece que el público en general se está dando cuenta de este hecho (aumentando el uso de VPN).
Sin embargo, la carga de hacer que la experiencia de navegación de todos sea segura está y debe estar en los webmasters.
Ahí es donde entra en juego la adopción de HTTPS.
HTTPS encripta las solicitudes y respuestas HTTP para que un atacante interceptor solo vea caracteres aleatorios en lugar de los detalles de la tarjeta de crédito, por ejemplo.
Una analogía de cómo funciona HTTPS sería enviar objetos de valor en una caja de combinación bloqueada indestructible. Solo las partes que envían y reciben conocen la combinación y si los atacantes se apoderan de ella, no entrarán.
Ahora, suceden muchas cosas cuando se forma una conexión HTTPS. Principalmente, HTTPS se basa en el cifrado TLS (Transfer Layer Security) para asegurar las conexiones.
Cómo funcionan los certificados TLS
La única forma de habilitar HTTPS en su sitio web es obtener un certificado TLS e instalarlo en su servidor. También lo encontrará como un certificado SSL o SSL / TLS, pero no se preocupe, es todo lo mismo. SSL todavía es una terminología ampliamente utilizada, aunque técnicamente todos usamos su sucesor TLS.
Los certificados TLS son emitidos por las Autoridades de certificación (CA). El rol de CA es ser un tercero confiable en la relación cliente-servidor. Básicamente, cualquier persona puede emitir certificados TLS, pero los navegadores solo admiten las CA de confianza pública.
Puede verificar el certificado TLS de cada sitio web y su CA emisora haciendo clic en el icono de candado en la barra de direcciones de su navegador.
Puede hacer clic en el certificado para obtener más información. Lo importante aquí es la línea «Emitido para:». Esto es cuando nos adentramos en diferentes tipos de estándares de validación para certificados TLS, que es lo que diferencia principalmente a los certificados gratuitos y de pago.
DV, OV y EV: ¿Qué significa y cuál elegir?
Los certificados TLS gratuitos que vienen con sus planes de alojamiento y CDN solo hacen validación de dominio (DV).
Esto valida que el propietario de un certificado controla un nombre de dominio dado. Una técnica de validación tan básica es lo suficientemente buena para blogs y sitios web que no manejan información confidencial, pero no es ideal para aquellos que lo hacen.
Los sitios web que utilizan un certificado DV TLS parecen seguros, pero no verá la línea «Emitido para:» cuando haga clic en el icono de bloqueo.
El certificado DV TLS más común proviene de una CA sin fines de lucro llamada Let’s Encrypt. Eso es lo que usan la mayoría de las compañías que ofrecen certificados TLS renovables automáticamente y gratuitos.
No hay nada de malo con los certificados solo DV, después de todo, es el único tipo de certificado TLS que puede emitirse automáticamente a escala. Sin embargo, HTTPS es tan fuerte como el certificado subyacente que autentica el servidor con el que está hablando.
Si su sitio web permite inicios de sesión o pagos, debe invertir en un certificado TLS que ofrezca validación de organización (OV) o validación extendida (EV). Estos dos tipos difieren en el proceso de verificación y el EV es más riguroso.
Si está buscando comprar solo uno, le recomiendo ir directamente al certificado TLS EV. Es el más confiable y no cuesta mucho más que OV.
Comodín y certificados SAN TLS
Dejando atrás los estándares de validación, pasemos a otra categoría de certificados TLS.
Los certificados comodín y SAN se utilizan para proteger múltiples (sub) dominios a la vez. Si compró un certificado EV TLS estándar para example.com, necesitaría un certificado separado para blog.example.com.
Los certificados comodín pueden proteger subdominios ilimitados (example.com, blog.example.com, docs.example.com), mientras que los certificados SAN también tienen la opción de proteger otros dominios (example.com, blog.example.com, different.org )
Estos tipos se combinan con los tipos de validación para que pueda ver todo tipo de combinaciones cuando explore las opciones que ofrecen las CA. También lo guiarán a través del proceso de validación.
Cómo HTTPS ayuda al SEO
Pretty much all the benefits of HTTPS tie back to SEO:
- Señal de clasificación ligera
- Mejor seguridad y privacidad.
- Conserva los datos de referencia
- Permite el uso de protocolos modernos que mejoran la seguridad y la velocidad del sitio
Señal de clasificación ligera
Google anunció que HTTPS es un factor de clasificación ligero en 2014. Se parece más a un desempate que a algo que dispararía sus clasificaciones si otras variables del factor de clasificación permanecieran sin cambios.
Esto es básicamente la contribución de Google para una adopción HTTPS mundial más rápida.
Mejor seguridad y privacidad.
Ya hablamos sobre este. Pero, ¿cómo está conectado esto con el SEO?
Cuando aterrice en un sitio web no seguro, verá algo como esto:
Realmente no genera confianza, ¿verdad? Soy consciente de mi sesgo profesional, pero personalmente presto atención a esto y rápidamente doy una mala primera impresión si lo veo en cualquier sitio web.
Supongo que migrar a HTTPS puede mejorar el tiempo de permanencia y evitar que el pogo se pegue. Si bien estos son solo factores de clasificación teorizados (no confirmados), hacer que las personas se «peguen» cuando aterrizan en su sitio web es algo que desea independientemente del SEO.
Conserva los datos de referencia
Si su sitio web todavía está en HTTP y está utilizando servicios de análisis web como Google Analytics, tengo malas noticias para usted: no se pasan datos de referencia de HTTPS a páginas HTTP.
Como la mayoría de la web se ejecuta en HTTPS en estos días, la fuente de la mayoría del tráfico de referencia (clics en enlaces de otros sitios web) se etiquetará como directa en la mayoría de los software de análisis.
Una desventaja de esto es que hace que sus datos sean desordenados y sesgados. Otra es que no puede ver sus mejores fuentes de referencia, lo cual es una oportunidad de creación de enlaces desperdiciada.
NOTA AL MARGEN. Si está interesado en los errores comunes de seguimiento de Google Analytics, consulte esta publicación.
Permite el uso de protocolos modernos que mejoran la seguridad y la velocidad del sitio
En papel, HTTPS es más lento que HTTP debido a las características de seguridad agregadas. Sin embargo, tener HTTPS es el requisito previo para usar la última tecnología de seguridad y rendimiento web.
En otras palabras, además de la seguridad, HTTPS también permite que su sitio web mejore la velocidad de su página cuando utiliza protocolos como TLS 1.3 y HTTP / 2. Y además de una mejor experiencia de usuario, Google considera la velocidad de la página como un factor de clasificación ligero similar a HTTPS:
- Estás lanzando un nuevo sitio web
Has ganado la lotería. Elija HTTPS desde el principio y nunca tendrá que preocuparse por HTTP y los errores asociados con la migración.
Todo lo que necesita hacer es tener un buen proveedor de alojamiento que lo guíe a través del proceso y que sea compatible con las últimas versiones de los protocolos HTTP y TLS.
Después de que todo esté en funcionamiento, implemente HSTS como el último paso para sellar la seguridad.
- Ya tienes un sitio web habilitado para HTTPS
El hecho de que estés leyendo este artículo me dice que probablemente no esté configurado correctamente. Siga los consejos de la siguiente sección para verificar si hay errores comunes. - Aún tienes un sitio web ejecutándose en HTTP
Tomará un tiempo preparar todo y hacerlo. La complejidad de la migración depende de:
El tamaño y la complejidad de su sitio web.
¿Qué tipo de CMS usas?
Sus proveedores de hosting / CDN
Sus habilidades técnicas
Si bien creo que los propietarios de sitios web pequeños que se ejecutan en CMS populares y alojamiento sólido pueden hacer la migración por sí mismos, hay muchas variables en juego.
Le sugiero que consulte la documentación de su CMS / servidor / hosting / CDN y proceda en consecuencia, y con precaución. Debes ejecutar muchos pasos, así que crea o sigue una lista de verificación de migración y no intentes incluir otras actividades.
Si todo esto le parece demasiado técnico, contrate a un profesional. Le ahorrará horas de su tiempo, ahorrará nervios y garantizará una implementación a prueba de futuro.
Cómo verificar posibles errores de migración HTTPS
Incluso si marcó toda la lista de verificación de migración HTTPS, es probable que aún encuentre algunos problemas.
De hecho, en 2016, analizamos 10,000 dominios de alto rango para varios errores HTTPS y encontramos lo siguiente:
- El 90.9% de los dominios tenían una implementación HTTPS subóptima
- HTTPS no funcionaba correctamente en el 65.39% de los dominios
- El 23.01% de los dominios estaban usando redireccionamientos temporales 302 en lugar de 301 permanentes
- Si bien muchas cosas han cambiado y mejorado desde entonces, le recomiendo que compruebe los cinco errores comunes de migración HTTPS a continuación. No tomará mucho tiempo, y la mayoría de ellos no son tan difíciles de arreglar.
Error 1: quedan páginas HTTP
En primer lugar, debe asegurarse de que todas las páginas de su sitio sean Ya en HTTPS.
Puede descubrir las páginas HTTP sobrantes rastreando a fondo el sitio web. Esto no debería ser nada nuevo si se atiene a cualquier lista de verificación de migración HTTPS. Solo asegúrese de que el rastreador tenga todas las fuentes de URL necesarias para que no deje páginas atrás.
PROPINA – Las páginas que no están en su mapa del sitio y tienen cero enlaces apuntando a ellas son imposibles de descubrir rastreando. Esto a menudo puede suceder con páginas de aterrizaje PPC dedicadas. Una forma de encontrarlos es exportar la lista de URL de sus administradores de anuncios como Google Ads o FB Business Manager.
A partir de ahí, asegúrese de que las páginas huérfanas se migraron correctamente.
Y no olvide actualizarlos en los paneles de su campaña al formato HTTPS más reciente.
Error 2: páginas HTTPS con contenido HTTP
Este error ocurre cuando el archivo HTML inicial se carga usando HTTPS pero sus archivos de recursos (imágenes, CSS, JavaScript) aún no se han actualizado a HTTPS.
5 https con auditoría de sitio de contenido http
Si se trata de un problema en su sitio web, lo verá tanto en la descripción general del rastreo como en el informe de páginas internas. Todos los errores, advertencias y avisos en Site Audit contienen una descripción del problema y consejos sobre cómo solucionarlo.
Error 3: enlaces internos no actualizados a HTTPS
No actualizar sus enlaces internos a HTTPS provoca redireccionamientos innecesarios. Obviamente, eso es mejor que aterrizar en una página HTTP, pero ya hemos pasado por este error. Es fácil detectar estos enlaces y corregirlos.
Encontrará este problema en el informe Enlaces en Auditoría del sitio:
6 enlaces internos a la auditoría del sitio http
Simplemente vuelva a escribir las URL en https: // y ya está. Esto solo es aplicable si ya se ha asegurado de que no queden páginas HTTP utilizando el consejo del error n. ° 1.
Error 4: etiquetas no actualizadas a HTTPS
Hay dos tipos de etiquetas que puede estar utilizando en su sitio web que también necesitan que sus URL se actualicen a HTTPS: etiquetas canónicas y etiquetas Open Graph.
Las etiquetas canónicas le dicen a Google lo que usted considera la página más autorizada de un grupo de páginas similares o duplicadas. Señalar eso en una versión HTTP definitivamente puede enviar una mala señal a Google y probablemente será ignorado.
Si usa etiquetas Open Graph para optimizar sus publicaciones en redes sociales, Facebook requiere las etiquetas URL. Deben ser lo mismo que las URL canónicas.
Para buscar páginas con etiquetas HTTP canónicas y OG, configure este filtro personalizado en el Explorador de páginas:
7 gráfico abierto canónico https
Nuevamente, todo lo que queda es reescribirlos en https: // dada una migración completamente terminada.
Error 5: redireccionamientos fallidos
Los redireccionamientos pueden ser complicados. Hay muchas cosas que podrían salir mal, desde redireccionamientos rotos hasta cadenas y bucles de redireccionamiento.
Afortunadamente, es fácil detectar estos errores con Site Audit. Simplemente revise el informe de redireccionamientos y revise todos los problemas.
8 redirecciones fallidas
Después de hacer clic en el botón «Ver URL afectadas», verá un informe similar a este, solo que con más columnas y métricas predeterminadas:
9 cadenas de redireccionamiento
Lo mejor aquí es que realmente verá todas las URL afectadas: las redirigidas, las que están dentro de la cadena de redireccionamiento y las que enlazan con las redirigidas.
Hay dos cosas que debes hacer aquí.
El primero es dividir las redirecciones, en este caso:
https://blog.example.com/123/> -> redireccionamiento 301 ->> https://example.com/blog/987/
Esto aseguraría que todos los vínculos de retroceso que apunten a https://blog.example.com/123/ y https://example.com/blog/123/ se redirijan solo una vez. Eso está bien para los backlinks externos, ya que llegar a los webmasters con solicitudes de edición de enlaces sería muy ineficaz y bastante molesto.
Sin embargo, podemos hacerlo mejor internamente.
Debe esforzarse por el menor número de redireccionamientos. Es entonces cuando entra en juego la columna de número de enlaces entrantes.
Los enlaces entrantes son URL que enlazan con la URL afectada por la cadena de redireccionamiento. Deberá intercambiar los enlaces en esas páginas por URL que devuelvan un código de estado HTTP 200. Si hace clic en el número de inlinks, verá todos ellos:
Por supuesto, nuevamente, el siguiente paso sería verificar los enlaces entrantes de las URL dentro de la cadena de redireccionamiento. Sin embargo, eso es de menor prioridad ya que ya rompimos la cadena de redireccionamiento. Estos se etiquetarían como redireccionamientos 301 estándar en el informe de redireccionamientos 3XX en el siguiente rastreo.
Fuentes de información
- https://ahrefs.com/blog/what-is-https/
