No digo que se elimine la información de la hora, sino que sería mejor enviar solo la marca de tiempo legible por máquina para la publicación principal. Desde la perspectiva de clasificar una página en los resultados de búsqueda, un tema del foro es básicamente un artículo (publicación principal) con una serie de comentarios. Al motor de búsqueda no le importa cuándo se hicieron los comentarios.
Editar: otra forma de pasar la fecha a Google para un comentario (en lugar de toda la página) es marcado schema.org.
Claro, /8 apunta a la octava publicación, pero desde la perspectiva de un bot y desde la perspectiva de Google, es exactamente el mismo contenido y URL. Si quieres que Google sepa que /8 debe tratarse exactamente de la misma manera que el tema en los resultados de búsqueda, entonces el sitio probablemente no debería enviar una señal intencional de que son diferentes. Solo el usuario humano necesita saber que las marcas de tiempo son diferentes, y esa información se imprime en el texto de la página.
Si alguien en Google tiene que tomar decisiones sobre cuándo anular las URL canónicas definidas por el sitio, una de esas excepciones podría ser algo como “dos marcas de tiempo diferentes en los metadatos intencionales significan páginas diferentes, por lo tanto, anular la URL canónica”.
A menudo es difícil para los programadores pensar en todos los casos extremos a menos que tengan experiencia en encontrarse con esa situación, por lo que podría ser inconcebible para los programadores de Google que páginas idénticas puedan tener dos marcas de tiempo diferentes, aunque es fácil para los usuarios de Discourse entender por qué podría suceder.
Solía trabajar en una empresa donde parte de mi trabajo era conseguir que los sitios fueran desbaneados de Google. (No estaban haciendo nada turbio, pero había problemas técnicos). Como nadie sabía exactamente cómo funciona la tecnología de clasificación de Google, y cambia regularmente, el punto de partida era tratar de pensar como un ingeniero de búsqueda y eliminar cualquier cosa que pudiera ser ambigua o confusa para las máquinas. Nunca pude decir exactamente qué funcionó, pero siempre funcionó después de un tiempo de arreglar sistemáticamente cosas como esa.
Esto está incluido. Si desea habilitar esta característica experimental, necesita cambiar el valor a la configuración oculta del sitio SiteSetting.allow_indexing_non_canonical_urls.
Ahora mismo Google está utilizando correctamente las URL canónicas:
Podemos supervisar esto a través de Google Search Console con el informe ‘Index’ → ‘Coverage’ → ‘Alternate page with proper canonical tag’
Acerca de Página alternativa con etiqueta canónica correcta:
“Esta página es un duplicado de una página que Google reconoce como canónica. Esta página apunta correctamente a la página canónica, por lo que no tienes que hacer nada”.
No tengo idea de cómo los enlaces /X para cada respuesta afectan al SEO, y generalmente intento evitar complacer los caprichos de Google. Pero desde un punto de vista práctico, veo que Google no está indexando las nuevas respuestas en muchos temas de larga duración en mi foro de Discourse, mientras que sí indexa rápidamente la mayoría de los temas nuevos. Y cuando indexa una nueva respuesta, el enlace no va a la respuesta específica, sino a /XXXX?page=YY. No tengo idea de si eso es bueno para el SEO, pero definitivamente no es bueno para los usuarios humanos que buscan algo específico.
Este tema ha estado en silencio durante bastante tiempo. Tenía curiosidad: ¿alguien ha probado esta función experimental? Ahora que han pasado más de dos años, me encantaría saber si todavía se considera un experimento o si alguien puede confirmar que soluciona el problema.
¡Para mi deleite, Google NO me mostró una gran lista de respuestas individuales en los resultados! ¡Los únicos resultados fueron el tema en sí y luego la categoría en la que se encuentra! ¡Esta es una GRAN señal!
Sin embargo, cuando hago la misma búsqueda que @RGJ hizo en noviembre de 2021, el problema aún existe con esa búsqueda específica.
También realicé una nueva búsqueda de prueba con otro tema en esta comunidad de Discourse y encontré un problema similar, con múltiples resultados que provenían del mismo tema.
Es genial ver que este problema no existe siempre con todos los foros de Discourse… pero no entiendo por qué el problema se resolvería con el foro de Python mientras que todavía existe en el foro de Discourse.
¿Alguien tiene alguna idea sobre cómo hacer desaparecer este problema?
Estoy considerando migrar un foro existente de NodeBB a Discourse, pero antes de hacerlo, necesito saber si hay una manera de resolverlo para que no cree una pesadilla de SEO para nuestro dominio.
Esa búsqueda devuelve un pequeño número de enlaces al tema, pero el tema tiene 58 publicaciones, por lo que se esperaría ver 58 resultados individuales si las URL /nn estuvieran siendo indexadas. ¿Es posible que la araña esté viendo enlaces a publicaciones en el tema en otras publicaciones, por lo que indexa esas páginas individuales?
Habiendo dicho eso, desactivar /nn sería una pesadilla para mi foro. A menudo hay largas discusiones sobre cómo resolver problemas que pueden contener múltiples, esto parece funcionar, seguido unas pocas publicaciones después por una publicación de “oh no, no funciona”. A menudo nos referimos a las publicaciones de “solución” cuando alguien más tiene ese problema en el futuro. Si todo lo que puedes hacer es dirigir a las personas a una página que contiene la respuesta en algún lugar y que posiblemente contiene soluciones incorrectas, eso no ayudará a nadie.
Y, sí, puede haber formas en Discourse de resaltar soluciones, por ejemplo, el plugin Solved, pero mi foro tiene 22 años de publicaciones donde solo los últimos 12 meses se realizaron en Discourse.
Discourse no utiliza Apache2. Se puede usar delante de Discourse como proxy inverso, pero está muy lejos de ser óptimo en eso.
Y no entiendo este tema en absoluto. Esa estructura de URL no tiene nada que ver con el SEO. Pero quizás la razón es que no lo entiendo, pero mi foro todavía tiene un valor SEO bastante alto, pero proviene del contenido.
