Saltar al contenido
CULTURA DE ALGORITMO

11 Características SEO de HTTPS que NO Conocías

11 agosto 2020
indicador https con candado en la barra de direcciones de un navegador web

Hace unos días revisando algunas cuentas en Twitter de referencia en el mundo del SEO, en inglés, encontré un hilo muy interesante de Patrick Stox en el que nos listaba una serie de características SEO del protocolo HTTPS.

Algunos de ellos los desconocía completamente, por eso he decidido traducirlo y compartirlo contigo por si te fuera de utilidad. En el hilo original puedes encontrar nuevas actualizaciones y aportaciones de otros usuarios.

Aquí va.

Creo que la mayoría de la gente sabe que HTTPS es una señal de clasificación muy débil para Google. Esto es lo que puede que no sepas sobre HTTPS y cosas que pueden serte útiles como profesional del SEO.

CERTIFICADOS SSL

Los certificados requeridos para HTTPS se llaman comúnmente «certificados SSL» pero la última versión de SSL fue la 3.0 en 1996. A estos se les llama con frecuencia «certificados SSL/TSL» o «certificados TLS». Incluso las primeras versiones de TLS, 1.0 y 1.1, fueron desaprobadas en 2020.

HTTPS ES NECESARIO

HTTPS es necesario para muchas tecnologías modernas de la web. HTTP/2 (H2), HTTP/3 (H3), Accelerated Mobile Pages (AMP), Progressive Web Apps (PWAs), rutinas de servicios, geolocalización, notificaciones push y muchas otras requieren HTTPS por defecto.

MIGRAR A HTTPS

Al migrar a HTTPS, no es necesario realizar un cambio de dirección en Google Search Console. Debes configurar una propiedad de dominio o una nueva propiedad con HTTPS de manera que puedas monitorizar la migración. Deberías volver a subir tu archivo disavow. No es necesario que actualices los enlaces a tu sitio.

GOOGLE PREFIERE HTTPS

Google prefiere las páginas HTTPS a las páginas HTTP. Esto significa que si tienes dos páginas con contenido duplicado, es probable que Google indexe la versión HTTPS de la página que será la que se muestre a los usuarios.

CERTIFICADOS COMODÍN

Hay muchos tipos de certificados. El más común es el Domain Validated (DV) que es el que se suele obtener gratuitamente de tu hosting, CDN, o emisores como LetsEncrypt. Los certificados Organization Validated (OV) y Extended Validation (EV) pueden considerarse más fiables.

Lo que tal vez no sepas es que hay certificados comodín que también cubren subdominios como http://blog.domain.com. Un certificado para un dominio es mucho más fácil de mantener si necesitas diferentes subdominios.

También hay certificados MDC/SAN/UCC que cubren múltiples dominios como http://domain.com y http://other-domain.com. Cuando se redirigen los dominios antiguos, a menudo se descuidan, lo que significa que si tienes un certificado que cubre ese sitio web, puede que no se renueve.

En este caso, si obtienes un certificado que cubre varios dominios, es menos probable que el certificado caduque, ya que el mismo certificado también cubre tu dominio principal. Deberías configurar la monitorización de los dominios antiguos con algo como las alertas @contentking. Si caduca tu certificado, los usuarios recibirán un warning en tus páginas antiguas y no serán redirigidos al nuevo sitio. Google no tendrá este problema y seguirá viendo y siguiendo tus redirecciones correctamente.

GOOGLE NO VALIDA LOS CERTIFICADOS

De hecho, Google no valida los certificados. Google sólo mira la URL para determinar si una página es segura. Una URL comienza con http:// (inseguro) o https:// (seguro).

Puede aparentar ser segura sin serlo de extremo a extremo como con la opción Flexible SSL de @Cloudflare. Con esto, tu conexión es segura entre Cloudflare y tus usuarios, pero no entre Cloudflare y tu servidor. La ruta completa de conexión no es segura.

NO SE PUEDE REDIRIGIR HTTPS DESDE EL NIVEL DNS

Otro hecho divertido es que no se puede redirigir a HTTPS desde el nivel DNS. DNS no soporta protocolos como HTTP/HTTPS. Algunos servicios DNS tienen soluciones para esto, así que comprueba con tu proveedor. He visto a algunos SEO dejar el hosting antiguo activo sólo para hacer redirecciones.

Deberías redirigir el dominio al nuevo servidor y manejar las redirecciones y actualizaciones a HTTPS allí. Puedes mantener las rutas de las páginas en las redirecciones, así que comprueba tu configuración o la documentación.

CÓDIGOS DE ESTADO CONFUSOS

Mientras que un código de estado 307 es similar a redirecciones temporales como un 302, a menudo cuando ves esto es debido al HTTP Strict Transport Security (HSTS) que básicamente dice que la página debe ser solicitada con HTTPS.

El código de estado de la redirección real se puede confundir y podría ser un 301 o un 302. Puedes comprobarlo en la primera solicitud a un sitio o usando una pestaña de incógnito para ver si la redirección real es un código de estado 301 o 302. Debería ser un 301.

REFERRER POLICY ES TU AMIGA

Mucha gente se actualizó a HTTPS para no perderse los datos de referencia de otros sitios web. Por defecto, el referido se pasa así:

HTTP > HTTP – SÍ
HTTPS > HTTPS – SÍ
HTTP > HTTPS – SÍ
HTTPS > HTTP – NO

HTTPS permitido para un mejor análisis sobre páginas referenciadas.

¿Sabías que esto puede ser controlado con lo que se llama Política de Referencias? 👉 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy

Por eso algunas páginas web aparecen sólo con su nombre de dominio y no con la página de referencia en tu analytics.

Hay un nuevo valor por defecto en Chrome 85 que significa que no se pasan URLs de páginas en Chrome y perderás los datos de la página en tu analytics.

Todavía puedes cambiar la Política de Referencias para tu sitio, pero esto beneficia principalmente a otros sitios web. Seguirás perdiendo gran parte de los datos de la página de referencia a tu propio sitio web. Para ver quién está dirigiendo tu tráfico, tendrás que obtener datos de un índice de backlinks como @ahrefs.

Puede usar el valor de referrer en tu propio sitio web para enviar la página de referencia junto con los formularios de contacto. Esto resuelve muchos dolores de cabeza para los clientes, especialmente con peticiones vagas como «¿puedo obtener un presupuesto?» o «¿puedo obtener más detalles?» enviando la página donde se originó la petición.

CONTENIDO MIXTO EN HTTPS

Un problema común al pasar a HTTPS es el contenido mixto. Se trata de solicitudes a archivos que todavía están en http://. Aunque se puede escanear un sitio web para encontrar estas referencias para actualizarlas, es mucho trabajo. Hay una forma más fácil con Content Security Policy (CSP).

Una de esas políticas se llama upgrade-insecure-requests que cuando se añaden a tu encabezado pueden resolver los problemas de contenido mixto al forzar las peticiones a https://.

Sin embargo, esto no resuelve problemas como las etiquetas canónicas,  Og: tags, enlaces u otras referencias de enlaces.

NASTY HTTP

Los sitios HTTP permiten algunas cosas desagradables como inyectar anuncios o incluso cambiar el contenido. Los ISPs, hoteles, aerolíneas, etc. han sido atrapados en el pasado, pero si la web no se hubiera migrado mayoritariamente a HTTPS podríamos haber visto algunos cambios de contenido interesantes o incluso censura.


¡Haz clic para puntuar esta entrada!
- Votos: 2 • Promedio: 5