JavaScript SEO: evitar las trampas de la representación del lado del servidor

JavaScript SEO es actualmente uno de los temas candentes en la industria de SEO, ya que la web moderna evoluciona y más y más sitios web se relanzan o se crean en aplicaciones web basadas en JavaScript, principalmente en React o AngularJS. Con esto, se agrega más complejidad al SEO, ya que debemos asegurarnos de que Google pueda procesar JavaScript de manera efectiva, para que las páginas se puedan indexar y clasificar correctamente. Esto se puede lograr utilizando la representación del lado del servidor. Sin embargo, esto no viene libre de riesgos. En este artículo, analizo cinco errores de representación del lado del servidor y explico cómo puede evitarlos.

Si está buscando apoyo en la optimización técnica de su sitio web, ¿por qué no concertar una cita sin compromiso con nuestros consultores de Digital Strategies Group y averiguar dónde pueden ayudarlo?

¡Pedir una cita!

¿Qué tipos diferentes de representación del lado del servidor existen?

La representación previa de su sitio web para Google en su servidor (rendimiento del lado del servidor, SSR) es una opción para garantizar que su sitio web de JavaScript sea compatible con Googlbot. De esta manera, puede entregar la versión HTML prerenderizada de su sitio web a Google, mientras que el usuario obtiene la versión normal del navegador (aún no renderizada).

Sin embargo, cuando se trata de renderizado del lado del servidor, también hay diferentes formas de renderizar, como puede ver en el siguiente gráfico, que Google ha proporcionado de manera útil, con algunas adiciones útiles de Jan-Willem Bobbink.

Hay tres formas principales de configurar y ejecutar la representación del lado del servidor:

1. Representación del lado del servidor con HTML dinámico

El renderizado del lado del servidor crea una versión HTML renderizada de cada URL bajo demanda.

2. Representación estática con HTML estático

Básicamente, esto crea una versión HTML prerenderizada (estática) de una URL con anticipación y la almacena en el caché.

3. Representación del lado del servidor con (re)hidratación con HTML dinámico y JS/DOM

El servidor proporciona una versión HTML estática de la URL y el cliente (navegador, etc.) que ya incluye un marcado de modelo de objeto de documento (DOM) estructurado. El cliente toma esto y lo convierte en un DOM dinámico que puede reaccionar a los cambios del lado del cliente y lo hace más interactivo.

Google publicó una excelente descripción general de la representación de la web, con todos los pros y los contras, además de una explicación más detallada si está interesado. Pero antes que nada, si está buscando ayuda sobre el tema de JavaScript SEO o Server Side Rendering, asegúrese de contactarnos aquí en Searchmetrics Digital Strategies Group.

¡Ponerse en contacto!

Dificultades al renderizar sitios web de JavaScript a través del servidor

Recientemente nos encontramos con algunos problemas de SSR con uno de nuestros clientes. Ejecutan su sitio web en Angular JS y lo renderizan con Rendertron a través de Headless Chrome.

Usan un enfoque de renderizado SSR estático, lo que significa que renderizan una página y almacenan en caché el HTML renderizado en el servidor (antes de tiempo). El HTML almacenado en caché no se reemplazará automáticamente, sino que se basa en la lógica de representación. Los siguientes son cinco problemas que encontramos al trabajar en este sitio web. Los comparto contigo aquí, para que si tienes desafíos similares, tengas una idea de cómo enfrentarlos. Sin embargo, esto se puede considerar como una lista inacabada/ampliable.

1. Cuando no haces nada

Cuando no te importa y no prestas atención a cómo Google muestra tu página, déjame mostrarte cómo Google muestra (realmente ve) tu página. Esto se basa en un sitio web creado en una aplicación de una sola página (SPA) que utiliza un marco de JavaScript, sin representación del lado del servidor.

Esto no parece particularmente prometedor, ¿verdad? Es exactamente por eso que es importante usar SSR, porque luego se ve así:

2 . Paginación

¿Cómo lidiar con sus páginas paginadas cuando se trata de renderizar? Bueno, especialmente en la publicación, las páginas paginadas aún pueden ser buenas para servir a Google con sus artículos (más recientes) mientras Google los rastrea. Si echa un vistazo a sus archivos de registro, verá cómo Google accede a su paginación, para que sepa dónde tiene sentido proporcionar una versión renderizada previamente (Spoiler: no necesita proporcionar 399 URL con una versión renderizada )

Como nuestro cliente renderiza con un enfoque de SSR estático, solo renderiza la primera página y refleja la versión en caché de la página 1 hasta la página 10. Sin ninguna versión renderizada desde la página 11 en adelante. Aquí hay dos capturas de pantalla que muestran el problema bastante bien, con exactamente el mismo contenido de la página 1 que también se proporciona en las páginas 2-10.

Esto significa que le das a Google 10 páginas con el mismo contenido y artículos. Idealmente, desea que Google represente todas las páginas como únicas con artículos correctamente paginados.

3 . Renovar la versión renderizada de las páginas de categoría después de que se publique un nuevo artículo/producto

Nuestro cliente ha aumentado su clasificación en casi todas las propiedades de Google News de manera bastante significativa, como los carruseles de AMP, los recuadros de noticias de Google y los recuadros de noticias móviles, con la excepción de los carruseles de editores. Comenzamos a investigar esto y resultó que nuestro cliente no actualizó su versión en caché cuando se publicó un nuevo artículo. Descubrimos que renovaron su versión en caché de las categorías principales una semana después:

y en subcategorías incluso un mes después.

Esto llevó al hecho de que todavía tenían un artículo antiguo sobre el tema del Brexit en su versión prerenderizada, pero no tenían todos los artículos nuevos publicados sobre el tema. Nuestra suposición aquí es que, debido a este problema, no había suficientes artículos nuevos para que Google llenara un carrusel y esto tuvo un gran impacto negativo en su rendimiento. Todavía estamos investigando el impacto del cambio.

4 . La renderización puede causar contenido duplicado y canonicalización incorrecta

Proporcionar una versión renderizada previamente de una URL puede causar problemas en el sistema. Como nuestro cliente entregó páginas renderizadas previamente, cada una con su propia URL creada por el motor de renderizado, estas URL tenían los parámetros “p=1; render=1” y eran totalmente indexables:

Incluso hubo una nueva configuración canónica por parte del motor SSR para esa URL. Bastante espeluznante, ¿eh?

Idealmente, desea excluir estos parámetros del rastreo de Google.

5 . Cambio de título de página al renderizar

También descubrimos que los títulos de las páginas actuales se renderizaron a través de JavaScript. Esto se hizo de una manera que significaba que el metatítulo HTML siempre mostraba el nombre de la marca cuando JavaScript estaba deshabilitado. Y cuando el agente de usuario no es Googlebot, solo muestra el título de la página HTML. Vea los siguientes dos ejemplos a continuación. El primero muestra la URL con JavaScript deshabilitado. La segunda es la misma URL, pero con JavaScript habilitado.

Para asegurarse de que los metadatos siempre se representen correctamente, debe incluirlos en la versión no procesada (JavaScript) de la URL.

Conclusión

La representación del lado del servidor no se puede utilizar como un enfoque estándar para la representación de aplicaciones de una sola página. Se necesita atención especial para los enfoques estáticos en los que solo proporciona una instantánea. Como puede ver en el ejemplo de nuestro cliente, debe asegurarse de que el motor SSR siempre proporcione una versión actualizada de la URL; de lo contrario, Google no verá ni capturará sus artículos más recientes, y usted estará perdiendo tráfico valioso.

Antes de relanzar desde un sitio web basado en HTML a un marco basado en JavaScript, asegúrese de que se incluya la representación del lado del servidor y que siempre esté sirviendo dinámicamente.

Si tiene problemas con JavaScript o está buscando ayuda en la optimización técnica de su sitio web, entonces ¿por qué no programar una cita no vinculante con nuestros consultores de Digital Strategies Group y averiguar dónde pueden ayudarlo?

¡Pedir una cita!