问题出现得很突然,日志倒是留得挺全。运营在每篇文章的相关推荐里加了 utm_source=related,方便看点击来源。上线后日志里同一篇文章出现带参数和不带参数两种抓取,带参数版本占了总请求的三成。
刚开始盯着「canonical 虽然指向干净地址,但抓取已经发生,预算照样消耗」,折腾了半个多小时,排掉了。
把日志和配置对完,能解释这个现象的基本就这几处。带查询参数的地址被当成独立 URL,抓取和收录都分开算。少数情况下是内链模块把统计参数写死在模板里,全站链接都带。
另外,参数值随栏目变化,同类地址成倍增加。
上来先统计带参数的请求占比
awk '{print $7}' /var/log/nginx/access.log | grep -c 'utm_source=related'
去掉模板里的统计参数
grep -rn 'utm_source=related' /var/www/html/wp-content/themes/ | wc -l
接着在边缘把参数跳回干净地址
if ($arg_utm_source = related) { return 301 https://$host$uri; }
复核相关推荐的链接
curl -s https://www.example.com/post/1/ | grep -o 'href="[^"]*utm_source[^"]*"' | head
别只看报错消失,验证要多做一步。内链去掉参数后,日志里 utm 请求归零,同一批文章的抓取次数下降三成,点击统计改用事件埋点。
补一句。统计参数是给分析工具用的,不该写进站内链接,否则每加一个渠道就多一批重复 URL。拖得越久,排查成本越高,因为现场状态会被后续操作覆盖。
