Google Search Console检测到500个服务器错误（AKA网站站长工具，AKA GWT）

Question

我已请求我的客户开发人员修复了导致出现在抓取错误报告中的500个错误，但他们不想解决这个问题，直到我们找到确定这些网址来源的根问题。

正在检测的网址似乎来自网站的旧版本（并且可能来自他们设置的其他一些域名，这些域名实际上是具有不同域名的网站的重复版本，后来这些域名已被重定向）。

他的问题是：

• 为什么GSC现在会检测这些URL，以及它们在哪里找到它们（绝大多数这些链接都是从其他服务于500错误的页面内部链接的）
• GSC如何找到新的？值得注意的是，我对其中的一些进行了Wayback Machine搜索，有些看起来和2010年一样久，所以我猜测WBM是否可以找到它们，它们是某些点存在的页面并且重定向尚未配置正确 - 因此谷歌为什么找到它们（？）
• 为什么GSC从列表中删除URL（我已经解释过它在爬行并多次查找错误后这样做了）

有一些网址是从外部来源链接的 - 一个澳大利亚网站上的随机页面可能根据网址格式错误而被黑客攻击，并给出了结果我执行了一个网站：搜索此域名。大约一个星期左右检查这些错误后，他们已经从列表中消失了，它看起来像这些网址链接的网站可能已经以某种方式受到损害，但已被修复，因此这些网址也已被删除来自错误报告。

我的建议是将所有这些服务于500错误的URL重定向到主页，因为他已经为其中的一些（我现在已经标记为已修复）重写了，但是随着新的不断出现，他不想要必须继续编写重定向规则以重定向出现的任何新URL。这是公平的，因为谁知道GSC将接收多长时间以及多少URL。

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

希望有人可以帮助我 - 如果没有，我会把头伸进烤箱里。

非常感谢，

维克

Answer 1

这是评论和答案之间的一种 - 评论时间太长了：）

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

我会冒这样的猜测，正如你所提到的那样，有许多URL指向较旧的PHP版本，并且IIS可能没有设置来处理PHP扩展。

而不是简单地将用户重定向到主页 - 这可能会令人困惑，特别是当他们点击某些上下文链接时，为什么不，建立一个自定义错误页面;这在.Net中非常直接。你可以做一些很酷的事情，比如解析URL来提供建议。我认为这种任务不会花费几个小时才能成为一个不错的开发者。