[{"data":1,"prerenderedAt":347},["ShallowReactive",2],{"blog-canonical-vs-301-vs-noindex":3,"blog-prev-canonical-vs-301-vs-noindex":181,"blog-next-canonical-vs-301-vs-noindex":257},{"id":4,"title":5,"author":6,"body":7,"canonical":166,"category":167,"cover":166,"date":168,"description":169,"draft":170,"extension":171,"keywords":166,"meta":172,"navigation":173,"noindex":170,"ogImage":166,"path":174,"seo":175,"seoDescription":166,"seoTitle":166,"stem":176,"tags":177,"updated":166,"__hash__":180},"blog\u002Fblog\u002Fcanonical-vs-301-vs-noindex.md","同一内容多个地址，canonical 和 301 怎么分工","元析智能",{"type":8,"value":9,"toc":156},"minimark",[10,14,18,85,88,110,116,119,132,135,138,141,144,147,150,153],[11,12,13],"p",{},"这三个东西经常被当成\"让页面消失\"的三种说法，其实意图完全不同。canonical 是\"两个 URL 都保留，但请把主版本记在账上\"；301 是\"旧地址永久作废，内容搬家了\"；noindex 是\"页面给人看，但别进搜索结果\"。选错了不会立刻报错，只会慢慢损耗。",[15,16,17],"h2",{"id":17},"一张对照表",[19,20,21,37],"table",{},[22,23,24],"thead",{},[25,26,27,31,34],"tr",{},[28,29,30],"th",{},"你的诉求",[28,32,33],{},"该用",[28,35,36],{},"用错的代价",[38,39,40,52,63,74],"tbody",{},[25,41,42,46,49],{},[43,44,45],"td",{},"同一内容有参数、排序、追踪等变体",[43,47,48],{},"canonical",[43,50,51],{},"用 301 会让带参数的分享链接失效",[25,53,54,57,60],{},[43,55,56],{},"老 URL 永久废弃，内容已迁移",[43,58,59],{},"301",[43,61,62],{},"用 canonical 等于告诉蜘蛛两个地址都还行，老页继续占预算",[25,64,65,68,71],{},[43,66,67],{},"页面要留给人看，不进搜索",[43,69,70],{},"noindex",[43,72,73],{},"用 robots 屏蔽会让 spider 读不到 noindex，且内链传不出去",[25,75,76,79,82],{},[43,77,78],{},"内容彻底删除，不留替代",[43,80,81],{},"404 \u002F 410",[43,83,84],{},"挂 301 到首页会被判软 404",[15,86,87],{"id":87},"一个真实的产品页",[11,89,90,91,95,96,95,99,102,103,106,107,109],{},"2025 年 9 月，一个数据平台客户的产品页有四个地址：",[92,93,94],"code",{},"\u002Fpricing","、",[92,97,98],{},"\u002Fpricing?plan=team",[92,100,101],{},"\u002Fpricing\u002F","，还有大小写混写的 ",[92,104,105],{},"\u002FPricing","。他们之前用 301 把所有变体都跳到 ",[92,108,94],{},"，结果市场部发出去的短链、客服给客户复制的链接全被弹回，客服每天接到链接打不开的投诉 6 起。",[11,111,112,113,115],{},"改成 canonical 集中到 ",[92,114,94],{},"，四个地址都能正常打开，主版本三周内排名从第 7 位回到第 3 位。同一个内容、同一批关键词，之前一直上不去，就是因为权重被四个地址分着。",[15,117,118],{"id":118},"混用会出什么事",[120,121,122,126,129],"ul",{},[123,124,125],"li",{},"canonical 指向一个还在 301 的地址，蜘蛛要多跳一次，最后可能两边都不认。",[123,127,128],{},"同时写 noindex 和 canonical，等于给两个相反的指令，搜索引擎一般按 noindex 处理，但会降低对这个站配置的信任。",[123,130,131],{},"robots.txt 屏蔽 + canonical，spider 读不到 canonical，屏蔽就变成纯粹的信息损失。",[15,133,134],{"id":134},"我们的判断标准",[11,136,137],{},"内容还在、只是形态重复，用 canonical；内容真的搬走了，用 301，不要长期用 canonical 吊着老地址；页面必须给人访问但不想被搜到，用 noindex，并且保留它原有的内链，别让链接断掉。",[11,139,140],{},"还有一条：能用 301 解决的永久迁移，别偷懒写 canonical。301 是一次性动作，canonical 是长期声明，后者需要每次改版都记得维护。",[15,142,143],{"id":143},"怎么验证有没有用混",[11,145,146],{},"拿一个星期做一次抽查就够了。第一步，用 Screaming Frog 跑全站，导出每个页面的状态码和 canonical 列，筛出\"canonical 指向的 URL 本身返回 3xx\"的记录，这类是典型混用。第二步，筛出\"页面是 200 但 canonical 指向别的域名\"的记录，跨域 canonical 只在内容分发场景下成立，产品页出现就是配置错误。第三步，把 GSC 索引报告里\"网页会自动重定向\"和\"备用网页（有适当的规范标记）\"两类数量拉出来对比，如果重定向类明显偏多，说明本该用 301 的地方也在用 canonical。",[11,148,149],{},"三步做完通常能捞出一二十个问题页。修的时候按流量排序，先修有排名的那些，别从首页开始。",[15,151,152],{"id":152},"一个边界",[11,154,155],{},"canonical 不是垃圾桶。如果一个地址将来要独立运营、要拿自己的排名，就别把它 canonical 掉。内容相同才合并，只是相关不算重复。",{"title":157,"searchDepth":158,"depth":158,"links":159},"",2,[160,161,162,163,164,165],{"id":17,"depth":158,"text":17},{"id":87,"depth":158,"text":87},{"id":118,"depth":158,"text":118},{"id":134,"depth":158,"text":134},{"id":143,"depth":158,"text":143},{"id":152,"depth":158,"text":152},null,"技术SEO","2025-10-07","三个手段被混用，是因为没分清\"内容重复\"\"永久搬家\"\"不想被收录\"。我们用一张对照表和 2025 年 9 月一个产品页的案例，讲清各自管什么，以及混用的代价。",false,"md",{},true,"\u002Fblog\u002Fcanonical-vs-301-vs-noindex",{"title":5,"description":169},"blog\u002Fcanonical-vs-301-vs-noindex",[48,178,179],"重定向","重复内容","o6JyiVYo_zYeIHrO6CkniGj9Kdaw7VLb2ESng6q9vqY",{"id":182,"title":183,"author":6,"body":184,"canonical":166,"category":167,"cover":166,"date":246,"description":247,"draft":170,"extension":171,"keywords":166,"meta":248,"navigation":173,"noindex":170,"ogImage":166,"path":249,"seo":250,"seoDescription":166,"seoTitle":166,"stem":251,"tags":252,"updated":166,"__hash__":256},"blog\u002Fblog\u002Fgsc-excluded-pages-triage.md","GSC 收录报告里已排除的页面，一半不用处理",{"type":8,"value":185,"toc":240},[186,189,192,195,198,201,204,207,210,214,217,220,234,237],[11,187,188],{},"GSC 页面索引报告里的已排除，一半是正常状态。真正需要动手的只有两类：已抓取但未编入索引，以及本该收录却被误伤。其余原因等它自愈就行，越折腾越乱。",[15,190,191],{"id":191},"把四类原因分开看",[11,193,194],{},"备用网页有适当的规范标记，不用管。但要打开页面确认 canonical 指向的是你想收的那个 URL，指错了才是问题。",[11,196,197],{},"已抓取、尚未编入索引，这是内容质量问题。页面被爬了，但 Google 判断不值得收，通常因为内容太薄、跟别的页重复，或者整站权重不够。处理方式是合并同类页或补内容，不是反复提交。",[11,199,200],{},"已发现、尚未编入索引，是抓取预算或内链不足。加内链、把 URL 放进站点地图、在相关文章里链过去，比在 GSC 里点请求编入索引有效得多。",[11,202,203],{},"被 robots 屏蔽或返回 404，先确认是不是误伤。筛选页、登录页、标签页被屏蔽是对的；核心产品页被屏蔽就是事故，得当天改。",[15,205,206],{"id":206},"我按什么顺序查",[11,208,209],{},"先看数量趋势，四类各占多少，隔四周比一次；再看样本 URL 是不是你关心的页面；最后回服务器日志确认 Googlebot 到底来没来。顺序反了容易拍脑袋，很多人一看到已排除就去放开 robots，结果把筛选页全放了出来。",[15,211,213],{"id":212},"收录率不是-kpi","收录率不是 KPI",[11,215,216],{},"2025 年 9 月我们看过一个数据工具站，把 1200 多个筛选组合页全部取消 noindex，三个月后 Googlebot 每天抓 6000 次，大半落在内容几乎一样的筛选页上，产品页反而抓得更浅。收录量从 900 涨到 2100，自然流量一点没动。",[15,218,219],{"id":219},"一份四周一次的检查表",[120,221,222,225,228,231],{},[123,223,224],{},"每周一导一次页面索引报告，记下四类的页数，只记数不解释；",[123,226,227],{},"每月挑 20 个已发现未编入的 URL，回到内链和日志找原因；",[123,229,230],{},"有批量新页面上线时，单独跟两周，看收录有没有跟上；",[123,232,233],{},"改过 robots 或 canonical 之后，至少等 3 周再下结论。",[11,235,236],{},"还有一点很多人不知道：GSC 的报告本身有 2 到 3 天延迟。当天改当天看，看到的一定是旧数据，白白怀疑自己的改动没用。只有某一类数量在四周内翻倍，才值得开一次专项，平时别天天刷。这套表我们放在共享文档里，交接时不用重新想一遍。",[11,238,239],{},"该问的问题不是收录率多少，而是该收的页面收了没有。核心产品页、文档页、案例页、博客文章，这四类要做到全部收录，其他页面收不收无所谓。这套标准我们写进每次诊断报告的第一页，免得客户盯着一个百分比焦虑。",{"title":157,"searchDepth":158,"depth":158,"links":241},[242,243,244,245],{"id":191,"depth":158,"text":191},{"id":206,"depth":158,"text":206},{"id":212,"depth":158,"text":213},{"id":219,"depth":158,"text":219},"2025-10-06","已排除听着吓人，其实多数是正常状态。真正要动手的只有已抓取未编入索引和误伤两类。我们按四周对比一次，先说清哪四类不用管，再说该管的两类怎么处理。",{},"\u002Fblog\u002Fgsc-excluded-pages-triage",{"title":183,"description":247},"blog\u002Fgsc-excluded-pages-triage",[253,254,255],"GSC","收录","站点诊断","2tqulkvlEiNUpM2essXv1cxyKnaDLXcpgEvKAjNWGuM",{"id":258,"title":259,"author":6,"body":260,"canonical":166,"category":167,"cover":166,"date":336,"description":337,"draft":170,"extension":171,"keywords":166,"meta":338,"navigation":173,"noindex":170,"ogImage":166,"path":339,"seo":340,"seoDescription":166,"seoTitle":166,"stem":341,"tags":342,"updated":166,"__hash__":346},"blog\u002Fblog\u002Finp-long-task-sources.md","INP 高但不知道怎么改，先查这四类长任务占了多少",{"type":8,"value":261,"toc":327},[262,265,268,272,275,278,282,285,288,292,295,299,302,306,309,312,315,318,321,324],[11,263,264],{},"INP 高，八成是主线程被长任务占住了。今年 9 月我们给 7 个软件站查过 INP，四类来源能解释其中 6 个：框架水合、输入处理器里的同步计算、第三方脚本抢线程、大列表一次性渲染。定位方法不复杂，打开 Performance 面板录一段真实操作，看 Interactions 和长任务轨道。",[11,266,267],{},"先把概念说清楚。INP 是 Interaction to Next Paint，2024 年 3 月正式替代 FID 成为 Core Web Vitals 的交互指标。它算的是用户每次点击、按键到界面画出下一帧的延迟，取整段会话里偏差最大的那次。FID 只算第一次输入的延迟，所以有些站 FID 一直很好看，换成 INP 立刻露馅。",[15,269,271],{"id":270},"第一类框架水合","第一类：框架水合",[11,273,274],{},"Next.js、Nuxt 这类站，HTML 出来了，JS 还没执行完，这段时间用户点任何东西都没反应。一个开发者工具站首屏水合占了 1.2 秒，用户在这段时间点了三次导航，INP 直接记了 780 毫秒。",[11,276,277],{},"查法：Performance 面板里找 hydrate 或者 long task，看它和用户首次点击的时间关系。改法不是优化水合本身，而是让首屏不依赖 JS——导航用原生链接，首屏内容服务端渲染，交互组件按需加载。",[15,279,281],{"id":280},"第二类输入处理器里的同步计算","第二类：输入处理器里的同步计算",[11,283,284],{},"筛选、搜索、表单校验是重灾区。一个 B2B 后台的筛选器，每次点击同步算 1200 行数据的匹配，主线程卡 300 毫秒。用户连续点两下，感受就是卡死。",[11,286,287],{},"改法：把计算挪出事件处理器，用 requestAnimationFrame 或 startTransition 分帧；列表超过 200 行就上虚拟滚动。这类改动通常能砍掉一半的 INP。",[15,289,291],{"id":290},"第三类第三方脚本抢主线程","第三类：第三方脚本抢主线程",[11,293,294],{},"热力图、AB 测试、客服组件，都喜欢在用户第一次交互时上报。我们见过一个站，点击后 180 毫秒内跑了 4 个第三方回调。查法是 Performance 面板里看长任务下面挂的脚本 URL，一眼能认出是谁。",[15,296,298],{"id":297},"第四类大列表和复杂-dom","第四类：大列表和复杂 DOM",[11,300,301],{},"一次渲染 500 个 DOM 节点，浏览器光做样式计算就要 100 多毫秒。文档页的侧边目录、定价页的对比表都是高发区。改法是分页、虚拟滚动、content-visibility。",[15,303,305],{"id":304},"查-inp-的顺序","查 INP 的顺序",[11,307,308],{},"先看 RUM 的 P75 和 P95，差距大说明问题集中在少数交互上，找到那个元素比全局优化划算。再去实验室复现，最后才动手改。我们一般先修 P95 最差的那个交互，因为它往往和其他问题同根。",[15,310,311],{"id":311},"怎么归因到具体元素",[11,313,314],{},"实验室只能看到\"主线程卡了多久\"，看不到\"用户点了哪个按钮\"。要归因到元素，得在代码里埋一条 Interaction 记录：用 PerformanceObserver 监听 event 和 first-input，把 duration 超过 200 毫秒的交互连同比元素信息和页面路径一起上报。我们给客户搭的版本一天收上来十几万条，按页面聚合，最差的那个页面和按钮十分钟内就能锁定。",[11,316,317],{},"这一条比分数本身有用。分数只告诉你\"差\"，归因告诉你\"改哪里\"。",[15,319,320],{"id":320},"移动端是重灾区",[11,322,323],{},"同一个站，桌面端 INP 120 毫秒、移动端 380 毫秒，在我们查过的站里是常态。中低端安卓机的单核性能只有开发机的五分之一，脚本解析和执行的时间都要乘上去。所以 INP 的验收一定要看移动端，尤其是国内安卓机型的分布。",[11,325,326],{},"还有一条边界：INP 低于 200 毫秒就别折腾了。这类改动风险高、验收难，收益已经不明显，把时间花在内容和转化上更划算。",{"title":157,"searchDepth":158,"depth":158,"links":328},[329,330,331,332,333,334,335],{"id":270,"depth":158,"text":271},{"id":280,"depth":158,"text":281},{"id":290,"depth":158,"text":291},{"id":297,"depth":158,"text":298},{"id":304,"depth":158,"text":305},{"id":311,"depth":158,"text":311},{"id":320,"depth":158,"text":320},"2025-10-08","查过 7 个软件站的 INP，四类长任务能解释其中 6 个：框架水合、输入处理器里的同步计算、第三方脚本抢线程、大列表一次渲染。附带定位方法和每类的改法，附实测数字。",{},"\u002Fblog\u002Finp-long-task-sources",{"title":259,"description":337},"blog\u002Finp-long-task-sources",[343,344,345],"INP","交互延迟","长任务","z1Tf2GoNpNNz5tdk0UJax9AObIhacvt27Xs52lQm7_g",1794088111827]