Google Search Console 检测到 500 个服务器错误（AKA Webmaster Tools，AKA GWT）

Question

我已请求我客户的开发人员修复在抓取错误报告中不断出现的 500 个错误，但在我们找到确定这些 URL 来自何处的根本问题之前，他不想解决此问题。

检测到的 URL 似乎来自该网站的旧版本（并且可能来自他们设置的其他一些域，这些域实际上是具有不同域名的站点的副本，这些域已被重定向)。

他的问题是：

• 为什么 GSC 现在检测到这些 URL，它在哪里找到它们（这些链接中的绝大多数是从提供 500 错误的其他页面内部链接的）
• GSC 如何找到新的？值得注意的是，我对其中一些进行了 Wayback Machine 搜索，其中一些似乎与 2010 年一样古老，所以我猜测 WBM 是否可以找到它们，它们是在某个时候存在的页面，并且尚未配置重定向正确 - 因此 Google 会找到它们 (?)
• 为什么 GSC 会从列表中删除 URL（我已经解释了它在爬网并多次发现错误后会这样做）

有一些 URL 是从外部来源链接的 - 澳大利亚网站上的一些随机页面可能已被黑客入侵，基于 URL 的格式错误，并给出了出现的结果我执行了一个站点：在此域上搜索。大约一周后检查这些错误后，它们已经从列表中消失了，在我看来，这些 URL 所链接的站点可能已在某种程度上受到损害，但已被修复，因此这些 URL 也已被删除来自错误报告。

我的建议是将所有这些提供 500 错误的 URL 重定向到主页，因为他已经对其中的一些进行了重写（我现在已将其标记为已修复），但随着新的不断出现，他不希望必须继续编写重定向规则来重定向出现的任何新 URL。这很公平，因为谁知道 GSC 会接收多长时间和多少个 URL。

如果它有帮助的话，该站点当前托管在 IIS 服务器上，我知道它以前托管在 Apache 服务器上。它现在内置在 .net 中（我认为以前是 .php）所以我不知道重写是否存在某种兼容性问题。所有服务器错误都是由站点旧版本的 URL 引起的。这些页面是否应该提供 404，但出于某种原因却提供 500？

希望有人可以帮助我 - 否则我会把头伸进烤箱。

非常感谢，

维克

Answer 1

这介于评论和答案之间——评论太长了:)

您知道实际的错误是什么吗？

我会大胆猜测，正如您所提到的，有许多 URL 指向较旧的 PHP 版本，并且 IIS 可能未设置为处理 PHP 扩展。

与其简单地将用户重定向到主页 - 这可能会造成混淆，尤其是当他们单击一些上下文链接时，为什么不构建自定义错误页面；这在 .Net 中非常简单。您可以做一些很酷的事情，例如解析 URL 以提供建议。我想这样的任务对于一个半体面的开发人员来说不会超过几个小时。