Método NINJA para cambiar de HTTP a HTTPs en webs que viven del SEO

Hola de nuevo familiares y amigos, por aquí un día más Álvaro Peña de iSocialWeb. En este artículo de hoy os voy a contar nuestro método Ninja para portar webs a HTTPs con la beocio repercusión en tráfico posible 😉

Cualquiera que tenga una web, en estos últimos meses ha tenido que radicar frente a la postura de si cambiaba o no su web a HTTPs. En este proceso de transición hemos manido migraciones de todo tipo. Proyectos que no se han inmutado con el cambio o grandes proyectos con caídas importantes. El tema que está claro es que a día de hoy en según que casuísticas el cambio de HTTP a HTTPS no es un cambio 100% seguro.

Webs con mucho tráfico orgánico frente al directo

Si preguntas a profesionales que lleven webs de mucho tráfico de marca, la mayoría de ellos te dirán que google tiene perfectamente controlados los cambios a HTTPs y que este es un proceso sin riesgos (un 💩 pa ellos). Pero esto no es una verdad. Si tienes webs con mucho tráfico orgánico (20K a 1M, dependerá mucho del sector) en comparación con el total de tráfico del site y que por otra parte cuentan con muchas urls entre las que se divide este tráfico, en este caso este no será para nadie un proceso mecánico.

¿Qué pasa cuando se cambia un site a HTTPs?

Simplificando a lo más importante se produce el venidero proceso:

1. Partimos de un site con HTTP que está indexado y rankeando en los resultados de google.
2. Cambiamos las urls a HTTPs. Asumo que se hace correctamente el proceso.
3. Las urls que tiene google en su saco de datos cambian.
4. Hay un proceso de transición entre que esa URL en HTTP listada en google, se cambia por su nueva interpretación en HTTPS. Esta transición altera los resultados en las SERPs y en muchas ocasiones desaparece durante un periodo más o menos dispendioso hasta que vuelve a ser listada en las SERPs y logra o no, recuperar su posición antedicho para todas las keys por las que rankeaba.

Adecuadamente, en este proceso de 4 pasos, hay multitud de factores a tener en cuenta, por lo que no es un proceso rápido ni trivial para el buscador.

Vamos por partes:

¿Qué pasa si tienes en una web un tráfico predominante de marca, social o referal y cambias a HTTPS?

Aquí os comento mi apreciación acerca del proceso y cómo yo lo entiendo. Hablo del caso de marca porque es lo más popular, pero en los otros casos es similar. En webs de tráfico predominante o muy representativo de marca, este tipo de tráfico es recurrente y entrará sin someterse totalmente del canal orgánico. Esto origina que la web, vaya acertadamente o mal el orgánico tendrá un tráfico constante importante y representativo en el total del tráfico del site. Por ende y dependiendo del enlazado interno y la UX del site, hará que el favorecido siga navegando por secciones principales de la web y redistribuyendo tráfico, pese a no aparecer puntualmente en los resultados orgánicos. En conjunto origina que un cambio a HTTPs no genere un desequilibrio importante en el comportamiento del site a nivel de tráfico, ni que google reciba inputs de un desmejoramiento de señales de UX en las URLs que podrían encontrarse afectadas por el cambio.

¿Qué pasa si tienes una web con un % de tráfico principalmente centrado en el orgánico y un cuerpo suspensión de URLs?

Este es en el tipo de webs en las que nos solemos mover en iSocialWeb, webs donde el canal orgánico es la principal fuente de entrada de tráfico. Y es más, en nuestros proyectos propios y en varios clientes tenemos webs dinamita (como nosotros las llamamos), webs con un 80% o más de tráfico orgánico, donde un paso en apócrifo en el SEO te mata. En esta casuística el tráfico desde google es la principal fuente de entrada de señales de UX para el plan y este proceso de transición condiciona y mucho la desarrollo del mismo.

Partiendo de la saco del punto antedicho donde el tráfico venía por la marca y era una fuente principal y asaz constante. Ahora tenemos el caso en el que el tráfico viene en gran medida del canal orgánico. Adicionalmente está la problemática de que el número de URLs del plan es magnate, por lo que el proceso que explicábamos anteriormente de los 4 pasos se tiene que dar sobre múltiples puntos de la web. En sinopsis en esta casuísitica nos encontramos con que muchas urls con tráfico que depende de las SERPs que tendrán una pérdida importante de usuarios, en este impasse de recolocación de resultados.

MÉTODO NINJA: Pasos para cambiar de HTTP a HTTPs

Para realizar este punto hemos contado con la increíble ayuda de nuestro equipo de sistemas, los amigos de Brutalsys que nos han prudente, recomendado y ayudado enormemente en los procesos de migración y de ahí sale este método. Este método ha sido testado en más de 50 dominios con webs de mucho tráfico y se ha ido puliendo en cada paso, hasta que las últimas webs migradas casi nada han notado cambios en su tráfico y el tiempo de transición es de casi nada 2 o 3 días de media.

Vamos a comentar este proceso cogiendo como saco un plan con un entorno de WordPress que es a día de hoy el entorno más popular.

Pasos de cambio de HTTP a HTTPS:

• Hacer una copia de seguridad de la Pulvínulo de Datos: Vamos a tocar información sensible y mejor tener un respaldo.
• Habilitar que la web responda tanto para http como para https para todas las urls. Esto se lo tendréis que pedir al equipo de IT, vuestro proveedor de hosting o quien corresponda de perfil técnico.
• Cambiar en el WP la dirección del plan a https (Ajustes > Generales): Esto hará que tanto los canonicals, como los sitemaps, enlaces internos… que no estén metidos a pelo en el código apunten a la interpretación https.

• El paso antedicho no asegura que todas las URLs estén como HTTPS, así que haremos por otra parte esto. Instalar plugin «Better Search Replace» y agenciárselas en la Pulvínulo de Datos el nombre de dominio con http para sustituirlo por https. Una vez instalado el plugin, este se encuentra en la sección herramientas. Si tenéis una saco de datos muy magnate (por ejemplo, miles de posts publicados o categorías) os recomiendo que hagáis primero una simulación, y en caso que falle, apearse la velocidad en la segunda pestaña del plugin (esta funcionalidad no la tienen otros plugins que hacen esta función). El proceso es sencillo: 1º ponemos las urls con http a agenciárselas y con https a sustituir. 2º Seleccionamos todas las tablas de la saco de datos. 3º Dejamos el simulacro y lo pasamos. 4º si no fa arbitraje, quitamos el simulacro y hacemos el cambio. Y si da arbitraje, bajamos en la pestaña ajustes la velocidad al imperceptible y repetimos el proceso.

• Si tienes una CDN cambiar en el plugin de CDN los estáticos para que respondan con https: Es importante que todos los posibles de la web pasen a reponer por https.
• Revisar el código de la web para que no haya rutas absolutas con http y cambiarlas a https.
• Afanar cache y revisar con screaming frog, fandango… que no haya urls con http: Revisar scrapeando toda la web, que tu no se haya colado ningún http.
• Cambiar los enlaces principales que apunten a este plan tipo: PBN o enlaces potentes, de forma paulatina no todos el mismo día. Yo aquí lo que hago es cambiar los enlaces que sé que más valencia le aportan al plan y los apunto con destino a la interpretación https, si por otra parte le puedes destinar tráfico a estos links pues mejor que mejor.
• Eliminar en GSC el sitemap de la interpretación o versiones en http
• Dar de inscripción GSC las versiones de https con www y sin
• Añadir sitemap en la interpretación https en la que alega el dominio con o sin www.
• Crear un sitemap html que contenga todas las urls con más tráfico del plan (se puede hacer uno de posts, otro de categorías… depende del plan)
• Hacer un «Fetch and Render» desde GSC de estas urls y destinar al índice esta y todos los enlaces a los que apunta.
• Hacer asimismo un «Fetch and Render» individual de las urls que traigan más tráfico al plan.

Una vez hecho todo esto y revisando acertadamente que estén hechos todos los procesos, no queda otra cosa que esperar. El tiempo de paciencia depende mucho del plan, cuerpo de urls…

Si tienes sitemaps categorizados de tu site, puede ir revisando la indexación de estos desde GSC y revisando si para tus principales keys empieza a aparecer la interpretación https de la web.

• Una vez indexadas con https las urls principales o que te traen más tráfico, hacer redirección 301 de http a https y informar en GSC el cambio de dominio.
• Si puedes destinar tráfico de calidada las principales URLs estos días para aminorar al mayor el impacto de la pendiente de UX, hazlo y luego vete bajando ese tráfico de forma paulatina.

Si todo va acertadamente en 2 o 3 días tendrás el plan migrado.

CASOS REALES DE MIGRACIÓN CON ESTE MÉTODO

Os pongo dos casos de dos webs de nuestros proyectos propios que hemos cambiando de HTTP a HTTPs. En la primera pese a tener un cuerpo de visitas considerable, tiene la casuística que tiene pocas URLs (menos de 30) y en este punto, no se notó el cambio:

En este segundo caso era una web con un cuerpo más suspensión de urls, aunque no excesivo 5000.

Esperamos que este pequeño procedimiento os ayude con vuestros cambios! A disfrutar del verano!