RGJ
2021 年11 月 23 日 22:46
22
j127:
它们应该是一样的，因为页面几乎相同。
不，/8 和主题不一样。/8 指的是第 8 篇帖子，时间戳与第 8 篇帖子的时间戳相对应。
如果你将 ?page=2 变体与实际链接到的帖子进行比较，你将获得相同的时间戳。
wget -q -O - https://meta.discourse.org/t/topic-list-previews-legacy/101646/959|grep published_ti
<meta property="article:published_time" content="2020-05-09T04:29:46+00:00" />
wget -q -O - https://meta.discourse.org/t/topic-list-previews-legacy/101646/?page=2|grep published_ti
<meta property="article:published_time" content="2020-05-09T04:29:46+00:00" />
看起来是：Incorrect or failing oneboxes for links to other discourse instances - #14 by techAPJ
3 个赞
j127
2021 年11 月 24 日 00:58
23
我并不是说要删除时间信息，只是说最好只发送顶帖的_机器可读_时间戳。从搜索结果中对页面进行排名的角度来看，论坛主题基本上是一篇文章（顶帖）加上一堆评论。评论何时被发布对搜索引擎来说并不重要。
编辑：另一种将日期传递给 Google 的评论（而不是整个页面）的方式是使用 schema.org 标记 。
当然，/8 指向第 8 个帖子，但从机器人的角度和 Google 的角度来看，它是完全相同的内容和 URL。如果你希望 Google 知道 /8 在搜索结果中应该被视为与主题完全相同，那么网站就不应该发送一个有意的信号表明它们是不同的。只有人类用户需要知道时间戳是不同的，并且该信息会显示在页面文本中。
如果 Google 的某个人必须就何时覆盖网站定义的规范 URL 做出决定，那么其中一个例外情况可能类似于“两个不同的时间戳在有意元数据中意味着不同的页面——因此覆盖规范 URL。”
程序员很难考虑到所有边缘情况，除非他们有遇到过这种情况的经验，所以 Google 的程序员可能无法想象相同的页面可以有两个不同的时间戳，尽管 Discourse 用户很容易理解为什么会发生这种情况。
我以前在一家公司工作过，我的部分工作是让网站从 Google 解禁。（他们没有做任何可疑的事情，但确实存在技术问题。）由于没有人确切知道 Google 的排名技术是如何工作的，而且它会定期变化，所以起点是尝试像搜索引擎工程师一样思考，并删除任何可能对机器来说模棱两可或令人困惑的东西。我无法确切地说出是哪个方法起作用了，但经过一段时间系统地修复类似的问题后，它总是奏效的。
5 个赞
Falco
2021 年11 月 25 日 21:26
24
已添加。如果您想启用此实验性 功能，您需要将值切换到隐藏的站点设置 SiteSetting.allow_indexing_non_canonical_urls。
请与我们分享结果。
8 个赞
rrit
2022 年2 月 22 日 00:14
27
现在谷歌正确地使用了规范网址：
关于具有正确规范标签的替代页面 ：
4 个赞
我不知道每个回复的 /X 链接如何影响 SEO，而且我通常会尽量避免迎合谷歌的喜好。但从实际角度来看，我注意到谷歌没有抓取我 Discourse 论坛上许多长期话题的新回复，而它却能快速索引大多数新话题。而且当它索引新回复时，链接不会指向特定回复，而是指向 /XXXX?page=YY。我不知道这对 SEO 是否有利，但这对搜索特定内容的人类用户肯定不利。
这个话题已经很长时间没有更新了。我想知道：是否有人测试过这个实验性 功能？现在已经过去两年多了，我很想知道这是否仍被视为实验性功能，或者是否有人能确认它解决了问题？
与 @RGJ 在 21 年 11 月所做的类似，我发现了一个使用 Discourse 的大型公共论坛 (Python) ，并进行了一次谷歌搜索，查找其论坛中一个有很多回复的主题 ，看看它是否会显示来自同一主题的大量单独回复。
令我高兴的是，谷歌没有向我显示大量单独回复的结果！唯一的结果是主题本身以及它所属的类别！这是一个好迹象！
不过，当我进行与 @RGJ 在 21 年 11 月进行的相同搜索 时，该特定搜索的问题仍然存在。
我还对这个 Discourse 社区论坛上的另一个主题进行了新的测试搜索 ，发现了一个类似的问题，有多个结果来自同一个主题。
很高兴看到这个问题并不总是 存在于所有 Discourse 论坛上……但我不知道为什么这个问题会在 Python 论坛上得到解决，而在 Discourse 论坛上仍然存在。
有人有什么想法可以解决这个问题吗？
我正在考虑将一个现有的论坛从 NodeBB 迁移到 Discourse，但在这样做之前，我需要知道有一种方法可以解决这个问题，以免给我们的域名造成 SEO 噩梦。
4 个赞
packman
2024 年1 月 20 日 08:37
31
该搜索返回了指向该主题的少量链接，但该主题有 58 篇帖子，所以如果你认为 /nn URL 都被索引了，你应该会看到 58 个单独的结果。有没有可能爬虫在其他帖子中看到了指向该主题帖子的链接，所以它索引了那些单独的页面？
话虽如此，禁用 /nn 对我的论坛来说将是一场噩梦。经常有关于如何解决问题的长篇讨论，其中可能包含多个“这个方法似乎有效”的帖子，但过一会儿又出现“哦不，它无效”的帖子。将来当其他人遇到类似问题时，我们经常会回顾实际的“修复”帖子。如果你只能引导人们到一个包含答案的页面，而该页面可能包含不正确的解决方案，那将对任何人都没有帮助。
而且，是的，可能有一些 Discourse 的方法可以突出显示解决方案，例如“已解决”插件，但我的论坛有 22 年的帖子，只有过去 12 个月是在 Discourse 中发布的。
3 个赞
嘿 Seth！
我认为这篇文章可能会有帮助。
j127
2024 年10 月 12 日 23:54
33
你把那段代码放在 .htaccess 文件中来重定向 Discourse 中的页面吗？
Jagster
2024 年10 月 13 日 05:44
34
Discourse 不使用 Apache2。它可以作为反向代理部署在 Discourse 前面，但这远非最佳选择。
而且我完全不理解这个话题。该网址结构与 SEO 无关。但也许是因为我不理解——但我的论坛仍然具有相当高的 SEO 价值，这来自于内容。
3 个赞
