[{"data":1,"prerenderedAt":326},["ShallowReactive",2],{"blog-old-domain-301-retention":3,"blog-prev-old-domain-301-retention":87,"blog-next-old-domain-301-retention":216},{"id":4,"title":5,"author":6,"body":7,"canonical":71,"category":72,"cover":71,"date":73,"description":74,"draft":75,"extension":76,"keywords":71,"meta":77,"navigation":78,"noindex":75,"ogImage":71,"path":79,"seo":80,"seoDescription":71,"seoTitle":71,"stem":81,"tags":82,"updated":71,"__hash__":86},"blog\u002Fblog\u002Fold-domain-301-retention.md","改域名后旧域名要挂多久，9 次迁移的恢复数据","元析智能",{"type":8,"value":9,"toc":60},"minimark",[10,14,18,21,24,27,30,33,36,39,42,45,48,51,54,57],[11,12,13],"p",{},"旧域名 301 至少保留 12 个月，多数情况建议一直保留，只做跳转不再放内容。这个结论来自我们做过的 9 次域名迁移。",[15,16,17],"h2",{"id":17},"恢复曲线",[11,19,20],{},"9 次迁移里，自然点击回到迁移前 90% 的时间：最快 3 周，最慢 6 个月，中位数 9 周。看起来还行，但旧域名带来的外链价值和书签流量，2 到 3 年后还有残留。尤其是行业目录、老客户收藏夹、合作方文档里留的旧链接，你不会知道它们什么时候被点。",[15,22,23],{"id":23},"撤早了会怎样",[11,25,26],{},"2025 年 6 月一个换域名的客户，三个月后就把旧域的 301 撤了，只保留了新域。第四个月，一个行业目录站还在链旧域名，用户点进去 404，丢了一条高权重外链的流量。更麻烦的是，那条外链他们改不动，对方编辑早就离职了。",[15,28,29],{"id":29},"成本几乎为零",[11,31,32],{},"域名续费一年几十到几百块。旧域名只需要一个 nginx 配置或者一条 CDN 规则，把整站 301 到新域，服务器成本可以忽略。相比重新买回域名或者丢外链的代价，这笔账很好算。",[15,34,35],{"id":35},"什么时候可以撤",[11,37,38],{},"三个条件同时成立：旧域的外链已经基本改完；GSC 里旧域的点击连续三个月接近零；搜索结果里旧域 URL 基本被新域替换。即使三个都满足，我们一般也建议继续挂着，反正不花钱。",[15,40,41],{"id":41},"旧域名挂着还要维护什么",[11,43,44],{},"证书要续，不然 https 访问会报错，蜘蛛抓到的就是证书错误。DNS 别过期，这是最低级的失误。旧域的 GSC 资源留着，能看到还有哪些页面在被访问，这些数据是新域看不到的。",[11,46,47],{},"邮件也值得提一句：如果旧域名同时用于企业邮箱，换域名时要把 MX 记录和邮件转发规划好，别因为撤域名把客户邮件弄丢。这件事和 SEO 无关，但迁移项目里经常一起发生。",[15,49,50],{"id":50},"一个技术细节",[11,52,53],{},"旧域的 301 规则要覆盖所有协议和主机名的组合：http、https、www、非 www。2025 年那次掉 62% 的站，就是因为只做了主域的规则。规则做完，用 curl 测四个组合，确认都跳到新域对应路径，而不是首页。",[15,55,56],{"id":56},"立场",[11,58,59],{},"域名是资产，撤 301 省不下什么，出问题却很难补救。做迁移时就把\"旧域名永久保留\"写进方案，省得后面扯皮。",{"title":61,"searchDepth":62,"depth":62,"links":63},"",2,[64,65,66,67,68,69,70],{"id":17,"depth":62,"text":17},{"id":23,"depth":62,"text":23},{"id":29,"depth":62,"text":29},{"id":35,"depth":62,"text":35},{"id":41,"depth":62,"text":41},{"id":50,"depth":62,"text":50},{"id":56,"depth":62,"text":56},null,"技术SEO","2026-09-09","旧域名 301 三个月就撤，是很多团队的做法，但我们在 9 次迁移里看到恢复期普遍在 8 周到 6 个月。这篇讲旧域名保留时长、成本，以及什么时候可以撤。",false,"md",{},true,"\u002Fblog\u002Fold-domain-301-retention",{"title":5,"description":74},"blog\u002Fold-domain-301-retention",[83,84,85],"网站迁移",301,"域名","pfX_zZmZL1EX7P83-1VRLWj-vfhJnrbCngf3XPEhyVU",{"id":88,"title":89,"author":6,"body":90,"canonical":71,"category":72,"cover":71,"date":205,"description":206,"draft":75,"extension":76,"keywords":71,"meta":207,"navigation":78,"noindex":75,"ogImage":71,"path":208,"seo":209,"seoDescription":71,"seoTitle":71,"stem":210,"tags":211,"updated":71,"__hash__":215},"blog\u002Fblog\u002Ffake-crawler-detection.md","假蜘蛛比真蜘蛛多：我们怎么验证百度谷歌爬虫",{"type":8,"value":91,"toc":196},[92,95,98,101,104,108,120,123,126,130,133,136,139,143,146,157,160,163,166,169,172,175,178,181,184,187,190,193],[11,93,94],{},"日志里自称 Googlebot 和 Baiduspider 的请求，很多是假的：采集器、扫描器、竞品爬虫都会伪装。我们用 DNS 反查、IP 段核对和行为特征三步验证，一个站一天能筛出 3 万多条假蜘蛛请求。",[15,96,97],{"id":97},"为什么会有假蜘蛛",[11,99,100],{},"伪装成搜索引擎爬虫有三个好处：绕过 robots 限制、绕过部分站点的反爬规则、以及不被当成恶意流量。",[11,102,103],{},"内容被大量采集、页面被频繁扫描、服务器被压测，很多都是假蜘蛛干的。",[15,105,107],{"id":106},"第一步dns-反查","第一步：DNS 反查",[11,109,110,111,115,116,119],{},"Googlebot 的验证方式是：拿请求来源 IP 做反向 DNS 查询，得到的主机名必须是以 ",[112,113,114],"code",{},"googlebot.com"," 或 ",[112,117,118],{},"google.com"," 结尾，再正向解析确认 IP 一致。",[11,121,122],{},"百度蜘蛛也可以用类似方式验证，反向解析后确认域名属于百度。",[11,124,125],{},"这一步能筛掉 80% 以上的假蜘蛛。我们写了个脚本，每天跑一次日志，把\"自称蜘蛛但反查失败\"的 IP 列出来。",[15,127,129],{"id":128},"第二步核对官方-ip-段","第二步：核对官方 IP 段",[11,131,132],{},"Google 会公布 Googlebot 的 IP 段，百度也有官方的蜘蛛 IP 段文档。",[11,134,135],{},"把日志里的 IP 和官方段比对，不在段内的一律当假蜘蛛。",[11,137,138],{},"这一步比反查更简单，但官方段会更新，要定期同步。我们一般每月更新一次。",[15,140,142],{"id":141},"第三步看行为特征","第三步：看行为特征",[11,144,145],{},"真蜘蛛和假蜘蛛的行为差别很大：",[11,147,148,149,152,153,156],{},"真蜘蛛会遵守 robots，不会请求后台路径；假蜘蛛经常扫 ",[112,150,151],{},"\u002Fadmin","、",[112,154,155],{},"\u002Fwp-login.php","。",[11,158,159],{},"真蜘蛛的抓取有节奏，假蜘蛛经常短时间高频请求。",[11,161,162],{},"真蜘蛛的 UA 和 IP 一致，假蜘蛛经常 UA 乱换。",[11,164,165],{},"三个特征一起看，基本能确认。",[15,167,168],{"id":168},"我们抓过一次",[11,170,171],{},"2026 年 4 月，一个客户的日志里每天有 4 万多条\"百度蜘蛛\"请求。反查发现，其中 3.2 万条来自 6 个 IP，这些 IP 不在百度段内，却在高频请求产品页。",[11,173,174],{},"进一步查，这些请求带的 referer 指向一个竞品域名。基本可以确认是竞品在采集。",[11,176,177],{},"我们把 IP 段封掉，同时在 robots 里做了频率限制，采集停了。",[15,179,180],{"id":180},"怎么挡",[11,182,183],{},"三件事：WAF 里加规则，只放行验证通过的搜索引擎 IP；服务器层面对未验证的 UA 做限速；把验证脚本做成每日任务，异常时告警。",[11,185,186],{},"注意：别把真蜘蛛也挡了。我们见过客户为了防采集，把整个 UA 段屏蔽，结果百度蜘蛛也被挡了，收录掉了两个月。",[15,188,189],{"id":189},"判断",[11,191,192],{},"假蜘蛛是技术 SEO 的\"暗面\"，它不影响收录，但影响数据判断和安全。",[11,194,195],{},"如果你在分析爬虫日志，先验证真假，再谈抓取预算。否则你优化的可能只是一堆假流量。这件事我们做了三个月，采集量降了 90%，服务器压力也小了一半。",{"title":61,"searchDepth":62,"depth":62,"links":197},[198,199,200,201,202,203,204],{"id":97,"depth":62,"text":97},{"id":106,"depth":62,"text":107},{"id":128,"depth":62,"text":129},{"id":141,"depth":62,"text":142},{"id":168,"depth":62,"text":168},{"id":180,"depth":62,"text":180},{"id":189,"depth":62,"text":189},"2026-09-08","日志里自称 Googlebot 和 Baiduspider 的请求，很多是假的：采集器、扫描器、竞品爬虫都会伪装。我们用 DNS 反查、IP 段核对和行为特征三步验证，一个站一天能筛出 3 万多条假蜘蛛请求。这套方法我们每周跑一次，基本能挡住假蜘蛛。",{},"\u002Fblog\u002Ffake-crawler-detection",{"title":89,"description":206},"blog\u002Ffake-crawler-detection",[212,213,214],"爬虫","日志分析","安全","UxR53c2k0NcHQQXHxagbMktHAvs6K2w4-li7k3YVtfM",{"id":217,"title":218,"author":6,"body":219,"canonical":71,"category":72,"cover":71,"date":315,"description":316,"draft":75,"extension":76,"keywords":71,"meta":317,"navigation":78,"noindex":75,"ogImage":71,"path":318,"seo":319,"seoDescription":71,"seoTitle":71,"stem":320,"tags":321,"updated":71,"__hash__":325},"blog\u002Fblog\u002Frum-vs-synthetic-monitoring.md","合成监控和真实用户监控，到底要不要都做",{"type":8,"value":220,"toc":306},[221,224,227,230,233,236,239,242,245,248,251,254,257,260,263,266,269,272,275,278,281,285,288,291,294,297,300,303],[11,222,223],{},"2026 年 9 月有人问我们，既然有 CrUX 的真实用户数据，还要不要自己做监控。答案是都要，但用途不一样。合成监控解决有没有变差，真实用户监控解决用户到底什么感受。",[15,225,226],{"id":226},"合成监控是什么",[11,228,229],{},"固定地点、固定设备、固定网络条件，定时跑同一个页面。",[11,231,232],{},"它的好处是可重复。今天和昨天的数据可以直接比，因为条件没变。上线之后性能掉了，它能第一时间发现。",[11,234,235],{},"坏处是它只代表一个假想用户。真实用户的设备、网络、浏览器版本千差万别，合成数据测不到长尾。",[15,237,238],{"id":238},"真实用户监控是什么",[11,240,241],{},"在页面上埋一段脚本，用浏览器的 Performance API 采集每个访客的指标，上报到服务器。",[11,243,244],{},"它能按设备、地区、网络类型分组，看到中位数和 75 分位。CrUX 就是 Google 用自己的数据做的同类东西。",[11,246,247],{},"坏处是数据脏。用户切后台、网络中断、脚本被拦截，都会产生异常值，需要清洗。",[15,249,250],{"id":250},"两者的偏差有多大",[11,252,253],{},"我们对比过一个站，合成监控显示 LCP 1.9 秒，真实用户 75 分位是 3.6 秒。",[11,255,256],{},"原因很简单：合成用的是城市宽带加中端设备，真实用户里有三成在三四线城市的 4G 网络上，还有一部分用着三年前的安卓机。",[11,258,259],{},"这个偏差不是误差，是结构性的。合成数据只能代表一部分用户。",[15,261,262],{"id":262},"一个容易忽略的细节",[11,264,265],{},"RUM 数据里有种情况会被算错：用户打开页面后切到后台，页面被浏览器冻结，采集到的 LCP 会异常大。",[11,267,268],{},"处理办法是上报时带上页面可见性状态，把切后台的样本单独标记，分析时排除。这类样本能占 5% 到 10%，不清洗会拉偏 75 分位。",[15,270,271],{"id":271},"我们的组合",[11,273,274],{},"核心页面选三个，合成监控每天跑，发现回归就告警。",[11,276,277],{},"真实用户数据看两个维度：按设备分组和按地区分组。移动端和 PC 分开看，差距通常很大。",[11,279,280],{},"采样率不用太高。日访问一万的站，采 10% 就足够稳定，全量采反而增加上报开销。",[15,282,284],{"id":283},"自建-rum-的最小方案","自建 RUM 的最小方案",[11,286,287],{},"用官方的 web-vitals 库采集三个指标，页面卸载时用 sendBeacon 上报，服务端存一张表。",[11,289,290],{},"一个前端加一个后端接口，半天能写完。数据量不大，一张表能存一年。",[11,292,293],{},"采集时带上设备类型、网络类型、页面路径、浏览器版本。这几个维度决定了后面能不能分析。",[15,295,296],{"id":296},"一个态度",[11,298,299],{},"监控的目的不是收集数据，是在出问题时能快速定位。",[11,301,302],{},"只有合成监控，你会漏掉真实用户的糟糕体验。只有真实用户数据，你会看不出是哪次上线导致的。",[11,304,305],{},"两个都做，成本不高，判断会清楚很多。真正的门槛不是技术，是有人愿意每周看一眼数据。",{"title":61,"searchDepth":62,"depth":62,"links":307},[308,309,310,311,312,313,314],{"id":226,"depth":62,"text":226},{"id":238,"depth":62,"text":238},{"id":250,"depth":62,"text":250},{"id":262,"depth":62,"text":262},{"id":271,"depth":62,"text":271},{"id":283,"depth":62,"text":284},{"id":296,"depth":62,"text":296},"2026-09-10","合成监控能发现回归，真实用户数据能反映体验。这篇写两者的偏差在哪、核心页面怎么选、采样率多少够用，以及自建 RUM 的最小方案。",{},"\u002Fblog\u002Frum-vs-synthetic-monitoring",{"title":218,"description":316},"blog\u002Frum-vs-synthetic-monitoring",[322,323,324],"RUM","性能监控","CoreWebVitals","7jgTq8vpLFT8nfFXUYoCEt1Fm2dVYFVBPYZaVBWKXXI",1794088101982]