Não estou dizendo para remover a informação de horário, mas apenas que seria melhor enviar apenas o timestamp legível por máquina para a postagem principal. Do ponto de vista de ranqueamento de uma página nos resultados de busca, um tópico de fórum é basicamente um artigo (postagem principal) com um monte de comentários. Não importa para um motor de busca quando os comentários foram feitos.
Editar: outra forma de passar a data para o Google para um comentário (em oposição à página inteira) é marcação schema.org.
Claro, /8 aponta para a 8ª postagem, mas da perspectiva de um bot e da perspectiva do Google, é exatamente o mesmo conteúdo e URL. Se você quer que o Google saiba que /8 deve ser tratado exatamente da mesma forma que o tópico nos resultados de busca, então o site provavelmente não deveria enviar um sinal intencional de que eles são diferentes. Apenas o usuário humano precisa saber que os timestamps são diferentes, e essa informação é impressa no texto da página.
Se alguém no Google tiver que tomar decisões sobre quando substituir URLs canônicas definidas pelo site, uma dessas exceções poderia ser algo como “dois timestamps diferentes nos metadados intencionais significam páginas diferentes – portanto, substitua a URL canônica.”
Muitas vezes é difícil para os programadores pensarem em todos os casos extremos, a menos que tenham experiência em encontrar essa coisa, então pode ser inconcebível para os programadores do Google que páginas idênticas possam ter dois timestamps diferentes, embora seja fácil para os usuários do Discourse entenderem por que isso pode acontecer.
Eu costumava trabalhar em uma empresa onde parte do meu trabalho era tirar sites do banimento do Google. (Eles não estavam fazendo nada de errado, mas havia apenas problemas técnicos.) Como ninguém sabia exatamente como a tecnologia de ranqueamento do Google funciona, e ela muda regularmente, o ponto de partida era tentar pensar como um engenheiro de busca e remover qualquer coisa que pudesse ser ambígua ou confusa para as máquinas. Eu nunca poderia dizer exatamente qual coisa funcionou, mas sempre funcionou depois de algum tempo corrigindo sistematicamente coisas como essa.
[quote=“Falco, post:5, topic:209648”]adicionar um cabeçalho X-Robots-Tag: noindex à carga útil de resposta dessas páginas.
[/quote]
Isso está incluído. Se você quiser habilitar este recurso experimental, você precisa alterar o valor para a configuração oculta do site SiteSetting.allow_indexing_non_canonical_urls.
Atualmente, o Google está usando corretamente os URLs canônicos:
Podemos supervisionar isso via Google Search Console com o relatório ‘Index’ → ‘Coverage’ → ‘Alternate page with proper canonical tag’
Sobre Página alternativa com tag canônica adequada:
“Esta página é uma duplicata de uma página que o Google reconhece como canônica. Esta página aponta corretamente para a página canônica, portanto, não há nada que você precise fazer.”
Não tenho ideia de como os links /X para cada resposta afetam o SEO, e geralmente tento evitar me curvar aos caprichos do Google. Mas, de um ponto de vista prático, estou vendo que o Google não está indexando novas respostas em muitos tópicos de longa duração no meu fórum Discourse, enquanto ele indexa rapidamente a maioria dos novos tópicos. E quando ele indexa uma nova resposta, o link não vai para a resposta específica, mas sim para /XXXX?page=YY. Não tenho ideia se isso é bom para SEO, mas definitivamente não é bom para usuários humanos que estão procurando algo específico.
Este tópico está silencioso há bastante tempo. Fiquei curioso: alguém testou este recurso experimental? Agora que se passaram mais de dois anos, eu adoraria saber se isso ainda é considerado um experimento ou se alguém pode confirmar que isso resolve o problema?
Para minha alegria, o Google NÃO me mostrou uma longa lista de respostas individuais nos resultados! Os únicos resultados foram o próprio tópico e a categoria em que ele se encontra! Este é um ÓTIMO sinal!
Embora, quando faço a mesma pesquisa que @RGJ fez em novembro de 2021, o problema ainda existe com essa pesquisa específica.
Também executei uma nova pesquisa de teste com outro tópico nesta comunidade de fóruns Discourse e encontrei um problema semelhante, com vários resultados que vieram do mesmo tópico.
É ótimo ver que este problema não existe sempre em todos os fóruns Discourse… mas não entendo por que o problema seria resolvido com o fórum Python enquanto ele ainda existe no fórum Discourse.
Alguém tem alguma ideia de como fazer esse problema desaparecer?
Estou considerando migrar um fórum existente do NodeBB para o Discourse, mas antes de fazê-lo, preciso saber se há uma maneira de resolver isso para que não crie um pesadelo de SEO para nosso domínio.
Essa pesquisa retorna um pequeno número de links para o tópico, mas o tópico tem 58 posts, então você esperaria ver 58 resultados individuais se os URLs /nn estivessem sendo indexados. É possível que o spider esteja vendo links para posts no tópico em outros posts, então ele indexa essas páginas individuais?
Dito isso, desativar /nn seria um pesadelo para o meu fórum. Muitas vezes há longas discussões sobre como resolver problemas que podem conter múltiplos, isso parece funcionar, seguido por alguns posts depois por um post “ah não, não funciona”. Frequentemente nos referimos a posts de “correção” reais quando outra pessoa tem esse problema no futuro. Se tudo o que você pode fazer é direcionar as pessoas para uma página que contém a resposta em algum lugar e que possivelmente contém soluções incorretas, isso não vai ajudar ninguém.
E, sim, pode haver maneiras no Discourse de destacar soluções, por exemplo, o plugin Solved, mas meu fórum tem 22 anos de posts onde apenas os últimos 12 meses foram feitos no Discourse.
O Discourse não usa Apache2. Ele pode ser usado na frente do Discourse como um proxy reverso, mas está longe de ser o ideal para isso.
E eu não entendo esse tópico. Essa estrutura de URL não tem nada a ver com SEO. Mas talvez o motivo seja que eu não entendo — mas meu fórum ainda tem um valor de SEO bastante alto, mas isso vem do conteúdo.
