Los puntos de vista del autor son totalmente suyos (excluyendo el improbable evento de la hipnosis) y es posible que no siempre reflejen los puntos de vista de Moz.
El año pasado, el equipo de Homeday, una de las principales empresas de tecnología inmobiliaria de Alemania, tomó la decisión de migrar a un nuevo sistema de gestión de contenido (CMS). Los objetivos de la migración eran, entre otras cosas, aumentar la velocidad de la página y crear un sitio web de última generación preparado para el futuro con todas las funciones necesarias. Uno de los principales motivadores de la migración fue permitir que los editores de contenido trabajaran más libremente en la creación de páginas sin la ayuda de los desarrolladores.
Después de evaluar varias opciones de CMS, nos decidimos por Contentful por su tecnología moderna, con una experiencia superior tanto para editores como para desarrolladores. Desde un punto de vista técnico, Contentful, como CMS headless, nos permite elegir qué estrategia de renderizado queremos utilizar.
Actualmente estamos realizando la migración en varias etapas, u olas, para reducir el riesgo de problemas que tengan un impacto negativo a gran escala. Durante la primera ola, encontramos un problema con nuestro consentimiento de cookies, lo que provocó una pérdida de visibilidad de casi el 22 % en cinco días. En este artículo, describiré los problemas que enfrentamos durante esta primera ola de migración y cómo los resolvimos.
Configuración de la primera onda de prueba
Para la primera ola de prueba, elegimos 10 páginas de SEO con alto tráfico pero bajas tasas de conversión. Establecimos una infraestructura para informar y monitorear esas 10 páginas:
Seguimiento de clasificación para las palabras clave más relevantes
Tablero de SEO (DataStudio, Moz Pro, SEMRush, Search Console, Google Analytics)
Rastreos regulares
Después de una fase integral de planificación y prueba, migramos las primeras 10 páginas de SEO al nuevo CMS en diciembre de 2021. Aunque surgieron varios desafíos durante la fase de prueba (mayores tiempos de carga, modelo de objeto de documento HTML más grande, etc.), decidimos lanzarnos. ya que no vimos un gran bloqueador y queríamos migrar la primera ola de prueba antes de Navidad.
Primera revisión de desempeño
Muy emocionados por lograr el primer paso de la migración, echamos un vistazo al rendimiento de las páginas migradas al día siguiente.
Lo que vimos a continuación realmente no nos agradó.
De la noche a la mañana, la visibilidad de las palabras clave rastreadas para las páginas migradas se redujo del 62,35 % al 53,59 % — perdimos 8.76% de visibilidad en un día!
Como resultado de esta fuerte caída en las clasificaciones, llevamos a cabo otra extensa ronda de pruebas. Entre otras cosas, probamos los problemas de indexación/cobertura, si se incluyeron todas las metaetiquetas, datos estructurados, enlaces internos, velocidad de la página y compatibilidad con dispositivos móviles.
Segunda revisión de desempeño
Todos los artículos tenían una fecha de caché después de la migración y el contenido estaba completamente indexado y Google lo estaba leyendo. Además, podríamos excluir varios factores de riesgo de migración (cambio de URL, contenido, metaetiquetas, diseño, etc.) como fuentes de error, ya que no ha habido cambios.
La visibilidad de nuestras palabras clave rastreadas sufrió otra caída al 40,60 % en los días siguientes, lo que la convierte en una caída total de casi el 22 % en cinco días. Esto también se mostró claramente en comparación con la competencia de las palabras clave rastreadas (aquí «tráfico estimado»), pero la visibilidad parecía análoga.
Como otros factores de riesgo de migración más las actualizaciones de Google se habían excluido como fuentes de errores, definitivamente tenía que ser un problema técnico. Demasiado JavaScript, puntajes bajos de Core Web Vitals o un modelo de objeto de documento (DOM) más grande y complejo podrían ser causas potenciales. El DOM representa una página como objetos y nodos para que los lenguajes de programación como JavaScript puedan interactuar con la página y cambiar, por ejemplo, el estilo, la estructura y el contenido.
Siguiendo las migas de galleta
Tuvimos que identificar los problemas lo más rápido posible y corregir rápidamente los errores y minimizar los efectos negativos y las caídas de tráfico. Finalmente obtuvimos el primer indicio real de qué razón técnica podría ser la causa cuando una de nuestras herramientas nos mostró que la cantidad de páginas con enlaces externos altos, así como la cantidad de páginas con contenido de tamaño máximo, aumentaron. Es importante que las páginas no superen el tamaño máximo de contenido, ya que es posible que las páginas con una gran cantidad de contenido del cuerpo no se indexen por completo. En cuanto a la alta vinculación externa, es importante que todos los enlaces externos sean confiables y relevantes para los usuarios. Era sospechoso que la cantidad de enlaces externos aumentara así.
Ambas métricas fueron desproporcionadamente altas en comparación con la cantidad de páginas que migramos. ¿Pero por qué?
Después de verificar qué enlaces externos se habían agregado a las páginas migradas, vimos que Google estaba leyendo e indexando el formulario de consentimiento de cookies para todas las páginas migradas. Realizamos una búsqueda en el sitio, verificamos el contenido del consentimiento de cookies y vimos que nuestra teoría se confirmó:
Esto llevó a varios problemas:
Se crearon toneladas de contenido duplicado para cada página debido a la indexación del formulario de consentimiento de cookies.
El tamaño del contenido de las páginas migradas aumentó drásticamente. Esto es un problema, ya que es posible que las páginas con una gran cantidad de contenido del cuerpo no se indexen por completo.
El número de enlaces salientes externos aumentó drásticamente.
Nuestros fragmentos de repente mostraron una fecha en los SERP. Esto sugeriría un blog o un artículo de noticias, mientras que la mayoría de los artículos en Homeday son contenido perenne. Además, debido a la fecha de aparición, se cortó la meta descripción.
Pero ¿por qué estaba pasando esto? Según nuestro proveedor de servicios, Cookiebot, los rastreadores de los motores de búsqueda acceden a sitios web que simulan un consentimiento total. Por lo tanto, obtienen acceso a todo el contenido y El rastreador no indexa la copia de los banners de consentimiento de cookies.
Entonces, ¿por qué no fue este el caso de las páginas migradas? Rastreamos y renderizamos las páginas con diferentes agentes de usuario, pero aún no pudimos encontrar rastros del Cookiebot en el código fuente.
Investigando los DOM de Google y buscando una solución
Las páginas migradas se representan con datos dinámicos que provienen de Contentful y complementos. Los complementos contienen solo código JavaScript y, a veces, provienen de un socio. Uno de estos complementos fue el socio administrador de cookies, que obtiene el HTML de consentimiento de cookies desde fuera de nuestra base de código. Es por eso que no encontramos rastro del código HTML de consentimiento de cookies en los archivos fuente HTML en primer lugar. Vimos un DOM más grande, pero lo rastreamos hasta el DOM predeterminado, más complejo y más grande de Nuxt. Nuxt es un marco de JavaScript con el que trabajamos.
Para validar que Google estaba leyendo la copia del banner de consentimiento de cookies, utilizamos la herramienta de inspección de URL de Google Search Console. Comparamos el DOM de una página migrada con el DOM de una página no migrada. Dentro del DOM de una página migrada, finalmente encontramos el contenido de consentimiento de cookies:
Otra cosa que nos llamó la atención fueron los archivos JavaScript cargados en nuestras páginas antiguas en comparación con los archivos cargados en nuestras páginas migradas. Nuestro sitio web tiene dos scripts para el banner de consentimiento de cookies, proporcionado por un tercero: uno para mostrar el banner y obtener el consentimiento (uc) y otro que importa el contenido del banner (cd).
El único script cargado en nuestras páginas antiguas era uc.jsque es responsable de la banner de consentimiento de cookies. Es el script que necesitamos en cada página para manejar el consentimiento del usuario. Muestra el banner de consentimiento de cookies sin indexar el contenido y guarda la decisión del usuario (si está de acuerdo o no con el uso de cookies).
Para las páginas migradas, además de uc.js, también había un cd.js carga de archivos. Si tenemos una página en la que queremos mostrar más información sobre nuestras cookies al usuario e indexar los datos de las cookies, entonces tenemos que usar cd.js. Pensamos que ambos archivos dependen el uno del otro, lo cual no es correcto. El uc.js puede ejecutarse solo. El archivo cd.js fue la razón por la cual el contenido del banner de cookies se procesó e indexó.
Tomó un tiempo encontrarlo porque pensamos que el segundo archivo era solo un requisito previo para el primero. Determinamos que simplemente eliminar el archivo cd.js cargado sería la solución.
Revisión del rendimiento después de implementar la solución
El día que eliminamos el archivo, la visibilidad de nuestras palabras clave era del 41,70 %, un 21 % más baja que antes de la migración.
Sin embargo, el día después de eliminar el archivo, nuestra visibilidad aumentó al 50,77 % y al día siguiente casi volvió a la normalidad con un 60,11 %. El tráfico estimado se comportó de manera similar. ¡Qué alivio!
Conclusión
Puedo imaginar que muchos SEO han lidiado con pequeños problemas como este. Parece trivial, pero condujo a una caída significativa en la visibilidad y el tráfico durante la migración. Es por eso que sugiero migrar en oleadas y bloquear suficiente tiempo para investigar errores técnicos antes y después de la migración. Además, es fundamental seguir de cerca el rendimiento del sitio durante las semanas posteriores a la migración. Estas son definitivamente mis conclusiones clave de esta ola de migración. Acabamos de completar la segunda ola de migración a principios de mayo de 2022 y puedo afirmar que hasta ahora no aparecieron errores importantes. Tendremos dos oleadas más y, con suerte, completaremos la migración con éxito para fines de junio de 2022.
El rendimiento de las páginas migradas ya casi ha vuelto a la normalidad y continuaremos con la próxima ola.
