不允许google访问以 asp 结尾的url

昨天下午，不允我正调试一个客户网站，结尾突然发现所有指向 asp 后缀页面的不允Google蜘蛛请求全被拒了。日志里一串403，结尾时间戳精确到秒，不允像是结尾有人按下了开关。

这不是不允网络故障，也不是结尾服务器配置错误。这是不允我在防火墙规则里亲手加的一条：deny from googlebot，条件匹配URL以 .asp 结尾。结尾听起来很疯狂？不允让我解释下为什么这么做。

那个客户的结尾网站是2003年用经典ASP写的，数据库里存着十几万条产品记录。不允页面本身没什么问题，结尾但Google的不允抓取逻辑有个致命习惯——它喜欢往URL后面塞参数。比如 product.asp?id=1，它会尝试 product.asp?id=1&sort=price，再试 product.asp?id=1&page=2&lang=en。每次尝试，服务器都要重新查一遍数据库，生成完整HTML。

上个月，服务器的CPU使用率连续三天飙到95%。我登录后台看实时日志，Googlebot在6小时内抓了四万多个带不同参数的ASP页面，其中90%的内容完全一样——只是排序方式不同。这些URL就像无底洞，搜索引擎的爬虫以为自己在探索新大陆，实际上只是在同一个页面上反复打转。

更麻烦的是，这些动态生成的URL会被Google索引。搜索结果里出现十几个内容相同的页面，每个都标注“产品详情”，用户点进去发现长得一模一样，转头就骂网站垃圾。客户每天收到投诉邮件，说搜索结果重复、页面打开慢。我试着用robots.txt阻止抓取参数，但Google官方文档明确说过，robots.txt不处理问号后面的内容。用 canonical 标签？代码太老，改起来容易出bug。

所以，干脆一刀切。凡是 .asp 结尾的URL，Googlebot一律不许碰。反正真正的产品页有静态缓存版本，在另一个目录下，不影响收录。那些动态生成的变体，让它们消失在搜索引擎的视野里，反而清净了。

规则上线后，服务器CPU负载立刻降到20%以下。一周后，Google搜索控制台里显示的“已编入索引”页面数量从五万降到八千，但自然搜索流量反而涨了12%。因为剩下的页面都是高质量的——没有重复内容，加载速度快，用户停留时间明显变长。

有人可能会问，为什么不直接升级技术栈，把ASP换成现代化的框架？说实话，我也提过这个方案。但客户的预算只够维持现有系统运行，换架构意味着重新开发、数据迁移、测试，至少六个月的工期。对一个年利润刚过百万的小公司来说，这笔钱花得不值。与其大动干戈，不如用一条简单规则，让搜索引擎和服务器都喘口气。

现在每次看到日志里那些被拒的请求，我都觉得挺讽刺——Google一直标榜自己“只索引高质量内容”，但它的爬虫行为恰恰制造了大量低质量URL。你不给它设限，它就无限索取。这条规则像一道篱笆，把搜索引擎挡在正确的地方之外，也把服务器的命救了回来。

如果你也维护着老旧的动态网站，不妨试试这个思路。别心疼那些被屏蔽的URL，它们本来就不该存在。适当的“拒绝”，有时候比无条件的“允许”更明智。