Saltar al contenido

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

28 agosto, 2018
metodo ninja cambio https

alvaro peñaHola 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 migrar webs a HTTPs con la menor repercusión en tráfico posible ;)

Cualquiera que tenga una web, en estos últimos meses ha tenido que vivir frente a la tesitura de si cambiaba o no su web a HTTPs. En este proceso de transición hemos visto 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 realidad. 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 además cuentan con muchas urls entre las que se divide este tráfico, en este caso este no será para nada un proceso automático.

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

Simplificando a lo más importante se produce el siguiente 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 base de datos cambian.
  4. Hay un proceso de transición entre que esa URL en HTTP listada en google, se cambia por su nueva versión en HTTPS. Esta transición altera los resultados en las SERPs y en muchas ocasiones desaparece durante un periodo más o menos largo hasta que vuelve a ser listada en las SERPs y logra o no, recuperar su posición anterior para todas las keys por las que rankeaba.

Bien, 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 común, 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 depender totalmente del canal orgánico. Esto origina que la web, vaya bien 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 usuario 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 empeoramiento de señales de UX en las URLs que podrían verse afectadas por el cambio.

¿Qué pasa si tienes una web con un % de tráfico principalmente centrado en el orgánico y un volumen alto 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 falso 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 proyecto y este proceso de transición condiciona y mucho la evolución del mismo.

Partiendo de la base del punto anterior donde el tráfico venía por la marca y era una fuente principal y bastante 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 proyecto es grande, 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 resumen en esta casuísitica nos encontramos con que muchas urls con tráfico que depende de las SERPs que tendrán una pérdida notable 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 aconsejado, 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 apenas han notado cambios en su tráfico y el tiempo de transición es de apenas 2 o 3 días de media.

Vamos a comentar este proceso cogiendo como base un proyecto con un entorno de WordPress que es a día de hoy el entorno más común.

Pasos de cambio de HTTP a HTTPS:

  • Hacer una copia de seguridad de la Base 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 proyecto 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 versión https.

cambio direccion wordpress

  • El paso anterior no asegura que todas las URLs estén como HTTPS, así que haremos además esto. Instalar plugin “Better Search Replace” y buscar en la Base 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 base de datos muy grande (por ejemplo, miles de posts publicados o categorías) os recomiendo que hagáis primero una simulación, y en caso que falle, bajar 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 buscar y con https a sustituir. 2º Seleccionamos todas las tablas de la base de datos. 3º Dejamos el simulacro y lo pasamos. 4º si no fa fallo, quitamos el simulacro y hacemos el cambio. Y si da fallo, bajamos en la pestaña ajustes la velocidad al mínimo y repetimos el proceso.

cambio bd

  • Si tienes una CDN cambiar en el plugin de CDN los estáticos para que respondan con https: Es importante que todos los recursos de la web pasen a responder por https.
  • Revisar el código de la web para que no haya rutas absolutas con http y cambiarlas a https.
  • Limpiar 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 proyecto 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 valor le aportan al proyecto y los apunto hacia la versión https, si además le puedes enviar tráfico a estos links pues mejor que mejor.
  • Eliminar en GSC el sitemap de la versión o versiones en http
  • Dar de alta GSC las versiones de https con www y sin
  • Añadir sitemap en la versión https en la que responde el dominio con o sin www.
  • Generar un sitemap html que contenga todas las urls con más tráfico del proyecto (se puede hacer uno de posts, otro de categorías… depende del proyecto)
  • Hacer un “Fetch and Render” desde GSC de estas urls y enviar al índice esta y todos los enlaces a los que apunta.
  • Hacer también un “Fetch and Render” individual de las urls que traigan más tráfico al proyecto.

Una vez hecho todo esto y revisando bien que estén hechos todos los procesos, no queda otra cosa que esperar. El tiempo de espera depende mucho del proyecto, volumen 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 versió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 notificar en GSC el cambio de dominio.
  • Si puedes enviar tráfico de calidada las principales URLs estos días para reducir al máximo el impacto de la bajada de UX, hazlo y luego vete bajando ese tráfico de forma paulatina.

Si todo va bien en 2 o 3 días tendrás el proyecto 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 volumen de visitas considerable, tiene la casuística que tiene pocas URLs (menos de 30) y en este punto, no se notó el cambio:

cambio https v1 isocialweb

En este segundo caso era una web con un volumen más alto de urls, aunque no excesivo 5000.

cambio https v2 isocialweb

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

Patreon

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

4.9 (98%) 10 votes

Entradas relacionadas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Comentarios (6)

Genial Alvaro, y para no llevarnos sustos cambiar a https en Analitycs

Responder

;) Gracias por el comentario Victor. Espero que te sirva de ayuda!
Un abrazo!

Responder

Ya te digo yo que, como uses algún page builder con enlaces internos dentro de sus módulos de botones, imágenes, texto, etc. te puede hacer un estropicio al utilizar este método/plugin de buscar y reemplazar porque no es capaz de buscar en datos serializados. Otro método más fiable pero algo más técnico sería mediante el “Database Search and Replace Script in PHP” de Interconnect/IT

Responder

Hola Angel,
muchas gracias por el aporte. Totalmente de acuerdo contigo, hay casuísticas que pueden no estar contempladas con un plugin así. Pero como bien comentas otra solución aumenta el nivel de complejidad, pero lo dicho, gracias por el aporte ;)

Responder

Buen artículo, gracias por compartir esta información!

Responder

Creo que lo has explicado bastante bien lo bueno que si pr ejemplo tienes la pagina en wordpress es mas o menos sencillo hacer la migracion. Muchas gracias por el articulo

Responder