La pregunta Haga una pregunta de SEO de esta semana:
«¿Cómo se prueba un entorno de prueba para detectar los riesgos de SEO antes de un lanzamiento a gran escala?»
Es una de las preguntas más importantes a responder cuando se considera implementar nuevos sitios web, migraciones o cambios significativos en su sitio activo.
Primero, veamos la diferencia entre un sitio de “ensayo” y un sitio de “producción”.
El sitio de preparación a menudo también se denomina sitio de “desarrollo”, “preproducción” u otro nombre que sea específico de su empresa. Es un sitio de prueba que pretende reflejar su sitio en vivo tanto como sea posible para ayudar a los desarrolladores a probar los cambios en un entorno privado y seguro antes de lanzarlos.
El sitio de “producción” es su sitio en vivo. Es el que es accesible al público en general y debería funcionar lo más perfectamente posible.
Hay algunos casos en los que los desarrolladores pueden implementar directamente en el sitio de producción sin realizar pruebas primero en un sitio de prueba. Por ejemplo, cuando no hay un sitio de prueba para usar o no hay forma de imitar las condiciones para realizar la prueba sin implementar el cambio en el sitio activo. Hacer esto es arriesgado. Si una implementación rompe algo más en el código, podría afectar críticamente la usabilidad del sitio en vivo.
Cómo realizar una prueba de estrés en el entorno de puesta en escena
Como SEO, es muy importante que probemos implementaciones que potencialmente podrían afectar el rendimiento de SEO antes de su lanzamiento. A menudo, nos encontramos descubriendo implementaciones después de que ya han comenzado a afectar el tráfico y las clasificaciones. Esto no es nada ideal, ya que el robot de Google puede tardar un poco en detectar los cambios una vez que se ha solucionado una mala implementación. Es mucho mejor probar cómo el robot de Google podría procesar los cambios antes de poder hacerlo.
Refleje el sitio de producción lo más fielmente posible
El aspecto más importante del sitio de preparación es que esté lo más cerca posible del entorno de producción. Esto es fundamental porque permite que cualquier prueba que realice revele el mismo resultado que si hubiera ejecutado la prueba en el entorno de producción.
Cualquier desviación entre los dos entornos debe catalogarse. Estas discrepancias deben comunicarse para que los evaluadores sepan que deben prestar especial atención a las áreas del sitio de producción que difieren de las de puesta en escena. Una vez que la implementación entre en funcionamiento, los evaluadores pueden asegurarse rápidamente de que estas áreas del sitio de producción se comporten como se esperaba.
Rastree el sitio a escala con múltiples agentes de usuario
Un área que a menudo se pasa por alto al realizar pruebas de estrés en el entorno de prueba es el uso de varios agentes de usuario diferentes al rastrear el sitio.
Al utilizar diferentes agentes, por ejemplo, imitando Googlebot Smartphone y Googlebot Desktop, es más probable que detecte problemas técnicos con el sitio que no son obvios en el primer rastreo. Por ejemplo, el rastreo como robot de Google de escritorio y robot de Google móvil podría mostrar problemas con el procesamiento que solo ocurren en dispositivos móviles.
Asegúrese de rastrear el sitio con agentes de usuario que sean importantes para su industria específica. Si su objetivo es Google News como canal, asegúrese de rastrear el sitio como el bot de Google News. Si las imágenes o los videos son importantes para su SEO, rastree como robots de Google-Image y Google-Video.
Para poner a prueba su sitio de prueba, asegúrese de rastrearlo con un agente de usuario móvil, un agente de usuario de escritorio y falsificar dos robots de motores de búsqueda, por ejemplo, Google y Bing. De esta manera obtendrá una buena cobertura de las experiencias de diferentes bots importantes. Si es posible, intente rastrear también como un bot LLM.
Verifique el renderizado
Un buen punto de partida a la hora de probar un entorno de prueba antes de una implementación a gran escala es el renderizado. Los sitios web modernos suelen utilizar mucho JavaScript, lo que, aunque no es intrínsecamente malo, puede plantear problemas para el procesamiento de algunos robots de búsqueda. Para obtener más información sobre cómo los robots de búsqueda procesan JavaScript, consulte esta guía.
Configure su herramienta de rastreo para que incluya representación de JavaScript y vea qué elementos puede detectar. Por ejemplo, ¿puedes ver las etiquetas del encabezado, el metatítulo y el marcado del esquema? Luego, vuelva a rastrear el sitio sin habilitar la representación de JavaScript. Asegúrese de que esos mismos elementos todavía estén disponibles para los bots.
En caso de duda, realice algunas comprobaciones sobre las páginas del sitio de prueba. Inspeccione el modelo de objetos de documento (DOM) para ver si los elementos de código críticos son visibles en la primera carga de la página.
Es importante que lo que ve en la página sea lo que los robots de búsqueda puedan analizar y representar.
Pruebe elementos de SEO de forma masiva y en todos los tipos de páginas
Realizar pruebas de forma masiva es importante cuando se prueba un sitio antes de un lanzamiento importante. Al realizar sus pruebas, asegúrese de que se realicen en diferentes tipos de páginas y, si corresponde, en todos los idiomas.
Si su sitio utiliza plantillas, asegúrese de probar cada una de las plantillas que son fundamentales para el éxito de su SEO. Por ejemplo, en un sitio de comercio electrónico, esto significa marcar las páginas de categorías y productos como una alta prioridad.
Para sitios multilingües, asegúrese de que sus pruebas se realicen en diferentes idiomas y configure una VPN para dirigirse a los países para los que esos idiomas son importantes. Falsifique esos países al ejecutar sus rastreos para asegurarse de que los usuarios vean el idioma y el contenido correctos para su región. Aunque el robot de Google rastrea con frecuencia desde direcciones IP de EE. UU., también utiliza configuraciones distribuidas geográficamente, particularmente para sitios multilingües o que se adaptan a la configuración regional.
En su sitio de prueba, es posible que no todos los idiomas estén representados, o tal vez haya un proceso de localización diferente al que existe en producción. Esto nos lleva de nuevo al primer punto de necesitar que el sitio de preparación sea lo más comparable posible al sitio de producción.
Si no es así, en particular para los elementos de localización, estos deben estar en la parte superior de sus comprobaciones posteriores a la implementación.
Comparar el rendimiento de la producción actual
Un buen aspecto para recordar es que su sitio de prueba puede estar en un servidor de menor rendimiento. Esto significa que al realizar pruebas de velocidad en escena, los resultados pueden ser peores que si las pruebas se ejecutaran en producción. Esto puede limitar su capacidad para ejecutar comprobaciones significativas antes de la implementación.
Para solucionar este problema, asegúrese de comparar el rendimiento en producción para poder ejecutar las pruebas nuevamente rápidamente después de la implementación. Esto significará esperar hasta que los cambios se hayan implementado, pero puede ser la única manera de obtener una comprensión precisa de áreas como la velocidad de carga de la página en situaciones en las que el servidor de prueba simplemente no es tan bueno como el de producción.
Prueba para casos extremos
Los desarrolladores intentarán descifrar su código cuando lo prueben; nosotros también deberíamos hacerlo. Cuando pruebe su sitio de prueba antes de la implementación, ejecútelo en algunos casos extremos. En la práctica, esto significa pensar en escenarios que, aunque improbables, son posibles. Por ejemplo,
- Estoy visitando el sitio web desde EE. UU., pero mi idioma es francés. ¿En qué idioma están las metaetiquetas?
- Estoy viendo el sitio web en un dispositivo móvil pero tengo la ventana gráfica configurada en escritorio. ¿A qué contenido puedo acceder al que de otro modo no podría acceder desde el móvil?
- Si desactivo JavaScript, ¿puedo seguir usando los menús desplegables?
Prueba de problemas previamente conocidos
Asegúrese de que no se hayan reintroducido problemas anteriores en el código durante el trabajo más reciente. Incluso si la implementación masiva es para un área pequeña, como la implementación de una nueva plantilla de metatítulo, eso no quiere decir que los problemas no se reintroduzcan en otros lugares.
No pruebe solo el elemento que se está cambiando, sino verifique las áreas críticas de SEO. En particular, si se ha trabajado recientemente para mejorar las páginas del sitio, verifique que sigan vigentes con esta última implementación.
Del mismo modo, si hay errores conocidos que han afectado su rendimiento de SEO en el pasado, verifíquelos incluso si la implementación no está relacionada con ellos. Es fácil que los errores vuelvan a colarse en el código, especialmente si ya estuvieron allí antes.
Más recursos:
Imagen de portada: Paul Poetry/Search Engine Journal
