Los metadatos canónicos no cambian correctamente en la aplicación Discourse cuando no son cargados por un rastreador web

Hay un error en la aplicación Discourse relacionado con la actualización del elemento de metadatos <link rel="canonical"> en la sección <head> del DOM de Discourse.

Básicamente, cuando un cliente del navegador entra en la aplicación y esta se carga por primera vez, el elemento <link rel="canonical" href=""> se establece según esa carga inicial de página; pero luego, cuando un usuario hace clic en la aplicación (comportamiento normal del usuario), sin recargar la página manualmente, el enlace <link rel="canonical"> no se actualiza.

He probado este error y lo he reproducido en el sitio meta:

Fig 1. Entrar en meta desde la página de inicio: el enlace canónico es correcto, al igual que el elemento title.

Fig 2. Visitar un tema. El elemento title cambia correctamente, pero el enlace canónico no es correcto (no se actualiza como debería).

Fig 3. Visitar otro tema. El elemento title cambia correctamente, pero el enlace canónico no es correcto (no se actualiza como debería).

Implicaciones para SEO

Este error podría afectar negativamente al SEO, ya que cuando Google indexa la página, si Googlebot no está “recargando forzadamente” cada página, la información canónica será incorrecta para cada página (como se ve en las secuencias de imágenes anteriores).

Reproducibilidad

He reproducido este error de forma consistente tanto en el sitio meta como en nuestro sitio.

Notas

He visto este tipo de problemas de ciclo de vida en node.js (SPA) con otros frameworks web (no solo Ember), donde los elementos del DOM no se actualizan, basándose en los ganchos de ciclo de vida (de Ember y otros frameworks SPA) dentro del framework de la aplicación web.

1 me gusta

Esto nunca ocurrirá, ya que no servimos la SPA para Googlebot. También puedes configurar tu agente de usuario como el de Googlebot para ver cómo funciona.

4 Me gusta

Hola @Falco

Gracias por tu respuesta.

Sí, no hay problema cuando el UA está configurado como GoogleBot (acabo de confirmarlo).

Estoy de acuerdo en que puede no ser un problema para el SEO, ya que no sirves la SPA a GoogleBot, pero aun así es un error en la SPA.

Además, necesito pensar en las implicaciones de no servir la SPA a GoogleBot.

Gracias por informarme sobre ese “pequeño detalle”…:slight_smile:

(Nota: No tenía idea de que “Temas sugeridos” no se servían a GoogleBot, pero ahora lo sé… gracias por informarme).

1 me gusta

Servimos un documento completamente diferente a los rastreadores, ya que no todos pueden ejecutar JavaScript y queremos que Discourse sea accesible para esos clientes también. Incluso si reciben funcionalidad reducida, pueden consumir todo el contenido.

5 Me gusta

Muchas gracias por informarme.

Ahora me doy cuenta de que algunas discusiones anteriores sobre SPA, “scroll infinito” y otros problemas relacionados con SEO eran completamente erróneas, ya que el SPA no se sirve a GoogleBot.

Esto cambia mi enfoque hacia cierto código personalizado que escribí recientemente; y ahora sé que debo verificar usando el User Agent de GoogleBot en la consola.

Muchas gracias por eso, @Falco! Muy apreciado.

Pregunta:

¿Cuál es la mejor manera de agregar un único archivo JavaScript personalizado al HTML que se renderiza para GoogleBot?

¿Existe una “forma estándar” de modificar el HTML servido a los bots?

La razón por la que pregunto es que tenemos cierto código personalizado creado en un plugin que escribí (destinado a bots); pero verifiqué usando el User Agent de GoogleBot en la consola (gracias de nuevo por decirme que debía hacerlo), y ninguno de ese código personalizado del plugin es consumido por GoogleBot.

1 me gusta

Mientras tanto, como no puedo lograr lo que quiero en un complemento (basado en Handlebars) para el HTML que se sirve a los rastreadores, hemos decidido simplemente eliminar las etiquetas canónicas de Discourse, lo cual es una solución parcial por ahora hasta que pueda encontrar la forma de modificar la etiqueta canónica con JavaScript para los rastreadores web.

Discourse ofrece un buen mecanismo para este tipo de cambios en los archivos yml del contenedor, por lo que eso es lo que he hecho hoy.

Estoy muy agradecido con Discourse Meta por señalar que la aplicación de Discourse que se sirve a los rastreadores (identificados) no es la misma que las páginas que se sirven a los usuarios.

Tenga en cuenta que no estoy recomendando esta “solución interina” a otros administradores de sistemas de Discourse. Simplemente estoy compartiendo lo que he decidido hacer por ahora y cómo lo hice (hasta que encontremos una solución más interesante).

2 Me gusta