那么，从这里...
在 ASP.NET 中，您可以选择如何响应它 - 它在 web.config 中作为 CustomErrors。打开它，然后重定向到一个花哨的 404 页面（也许你已经这样做了）。然后，花哨的 404 页面可能正在检查请求的查询字符串（它作为另一个查询字符串传递到自定义错误页面）以查看它是否是有效的重定向，是否存在于您的数据库中等。只需执行 Response.Redirect( ） 从那里。
然后大篷车写道：
谢谢，我们现在确实有 404，但我们不希望在此过程中将其检测为 404。如果可能，我们希望不直接单独处理它。
..我想知道这是多么糟糕的做法。我不希望将我的“漂亮”网址放在互联网上（只是名片），并且我有一个 404-redirecting-to-a-helpful-site 代码示例，但我不想投入生产并且有一个浏览器的问题，它把最初的 404 看得太严重了。谁能帮助我更多地了解为什么我不想使用 customErrors / 404 将用户引导到他们真正想要的页面？
使用 customeErrors 作为 404 错误处理程序的主要问题是，每次 customErrors 接收错误请求而不是将 404 错误返回到浏览器并让浏览器知道有错误请求时，它反而返回 302 表示页面已重新定位到您的 customErrors 页面。这对大多数用户来说还不错，因为他们不知道甚至没有注意到差异，问题在于网络爬虫确实知道差异并且他们收到的状态代码直接影响他们的索引工作方式。
考虑这样一种情况，您在http://mysite.com/MyAwesomePageAboutStuff.aspx有一个页面一段时间，然后有一天您决定不再需要它并删除该文件。如果 Google 或其他爬虫已将该 URL 编入索引并在您删除它后返回该 URL，则爬虫将获得 302 状态代码而不是 404 错误，并且由于此状态代码，爬虫将更新页面的 url 以指向您的错误页面，而不是删除不存在的链接。现在，每当有人通过搜索引擎找到该网址时，他们最终都会出现在您的错误页面上。
这并不是一个真正的大问题，但从长远来看，您肯定可以看到这会给您的用户带来的麻烦。
在这里寻找一些确凿的数据。
我使用 404 作为处理程序创建了一个虚 url 系统。我这边不需要 302，因为 404 会动态加载内容并返回。我完全能够处理任何和所有 POST / GET 和 SERVER 数据。
效果很好。如果你有兴趣 TarantulaHawk 在 SourceForge 上。