[{"data":1,"prerenderedAt":312},["ShallowReactive",2],{"blog-canonical-on-parameter-pages":3,"blog-prev-canonical-on-parameter-pages":105,"blog-next-canonical-on-parameter-pages":209},{"id":4,"title":5,"author":6,"body":7,"canonical":89,"category":90,"cover":89,"date":91,"description":92,"draft":93,"extension":94,"keywords":89,"meta":95,"navigation":96,"noindex":93,"ogImage":89,"path":97,"seo":98,"seoDescription":89,"seoTitle":89,"stem":99,"tags":100,"updated":89,"__hash__":104},"blog\u002Fblog\u002Fcanonical-on-parameter-pages.md","带参数的页面 canonical 怎么写，三种场景","元析智能",{"type":8,"value":9,"toc":78},"minimark",[10,14,19,22,25,29,41,44,48,51,54,57,60,63,66,69,72,75],[11,12,13],"p",{},"参数页 canonical 的判断标准只有一条：这个带参数的地址，能不能独立回答一个搜索问题。能，就指向自己；不能，就指向无参数的规范页。",[15,16,18],"h2",{"id":17},"场景一筛选参数","场景一：筛选参数",[11,20,21],{},"如果某个筛选组合有稳定的搜索需求，比如\"支持私有化部署的 CRM\"，最好做成静态路径页，别让参数页参与排名。没有独立需求的组合，canonical 指向无参数的列表页。",[11,23,24],{},"这里有个常见错误：把所有筛选页都 canonical 到首页。2026 年 6 月一个 API 目录站就这么干，5 万个参数页的 canonical 全部指向首页，结果蜘蛛把首页当成所有页的规范版本，参数页整批掉出索引，首页也承担了不该有的主题。",[15,26,28],{"id":27},"场景二排序参数","场景二：排序参数",[11,30,31,32,36,37,40],{},"排序不改变内容的集合，只改变顺序。canonical 指向无排序的默认页，",[33,34,35],"code",{},"?sort=price"," 和 ",[33,38,39],{},"?sort=new"," 都指向默认列表。用户和蜘蛛都能正常访问，只是不单独收录。",[11,42,43],{},"如果排序页有独立价值——比如\"最新发布\"本身是一个栏目——那就不要参数，做成独立路径。",[15,45,47],{"id":46},"场景三追踪参数","场景三：追踪参数",[11,49,50],{},"utm、gclid、ref 这类参数，优先级从高到低是：链接生成时别加 > 服务器 302 清洗 > canonical 指向干净地址。canonical 是最后一道兜底，不是方案。只靠 canonical，蜘蛛每次还是会抓一遍带参数的地址，浪费的抓取预算不会回来。",[15,52,53],{"id":53},"怎么验证写对了",[11,55,56],{},"Screaming Frog 导出所有带参数的 URL 和它们的 canonical，逐条看指向：指向首页的、指向 404 的、指向自己的分别是哪些。GSC 看\"Google 选择的规范网页与用户指定的不同\"这一项，数量大说明你的声明和 Google 的判断不一致。日志里看参数 URL 的抓取量有没有下降。",[15,58,59],{"id":59},"我们在模板里怎么写",[11,61,62],{},"给前端一个判断函数，输入当前 URL 和参数白名单，输出 canonical。有白名单里的参数就保留，其余全部剥掉。这个函数放在服务端渲染层，别放在浏览器里执行——蜘蛛拿到的初始 HTML 里必须已经有正确的 canonical，靠 JS 改的不算数。",[11,64,65],{},"我们给客户交付时会附一份参数清单：哪些参数允许进 URL、哪些必须清洗、哪些保留但不索引。开发照着实现，比口头说\"参数要处理一下\"有效得多。",[15,67,68],{"id":68},"一个补充",[11,70,71],{},"分页参数别和筛选参数混在一起处理。分页页 canonical 指向自己，筛选页 canonical 指向无筛选版本，两套规则分开写，模板里也要分开实现。",[15,73,74],{"id":74},"立场",[11,76,77],{},"能静态化的页面就别用参数，参数页的 canonical 是兜底不是方案。一个站如果靠 canonical 治理参数，说明前端和产品还没把 URL 设计当回事。",{"title":79,"searchDepth":80,"depth":80,"links":81},"",2,[82,83,84,85,86,87,88],{"id":17,"depth":80,"text":18},{"id":27,"depth":80,"text":28},{"id":46,"depth":80,"text":47},{"id":53,"depth":80,"text":53},{"id":59,"depth":80,"text":59},{"id":68,"depth":80,"text":68},{"id":74,"depth":80,"text":74},null,"技术SEO","2026-08-19","参数页的 canonical 是最容易写错的一类。筛选、排序、追踪三种参数，写法完全不同。这篇给每种的正确配置、一个 2026 年 6 月的案例，以及写错之后怎么排查。",false,"md",{},true,"\u002Fblog\u002Fcanonical-on-parameter-pages",{"title":5,"description":92},"blog\u002Fcanonical-on-parameter-pages",[101,102,103],"canonical","URL参数","重复内容","ZwaXEfJw-NfJuS8ygaY8NnrhzSR7DlH0e5QZSJdJWDI",{"id":106,"title":107,"author":6,"body":108,"canonical":89,"category":197,"cover":89,"date":198,"description":199,"draft":93,"extension":94,"keywords":89,"meta":200,"navigation":96,"noindex":93,"ogImage":89,"path":201,"seo":202,"seoDescription":89,"seoTitle":89,"stem":203,"tags":204,"updated":89,"__hash__":208},"blog\u002Fblog\u002Fproject-delay-communication.md","项目延期不可怕，可怕的是最后一天才说",{"type":8,"value":109,"toc":189},[110,113,116,119,122,125,128,131,134,137,140,144,147,150,153,156,159,162,165,168,171,174,177,180,183,186],[11,111,112],{},"2026 年 8 月我们一个项目延期了三周，发现当天就告诉了客户，比原定交付日早了十天。客户没有生气，反而说这样他能安排别的事。延期本身不致命，致命的是最后一天才说。",[15,114,115],{"id":115},"延期的三种原因",[11,117,118],{},"第一种，等客户。产品文档没给、后台权限没开、案例没确认。这类最常见，也最容易说清。",[11,120,121],{},"第二种，我们自己产能不够。稿子排太满、审稿人请假、技术排查比预估的久。",[11,123,124],{},"第三种，外部变化。算法更新打乱了优先级，第三方工具接口变了要重做。",[11,126,127],{},"三种原因的处理方式不一样，但第一件事都一样：当天说。",[15,129,130],{"id":130},"为什么当天就要说",[11,132,133],{},"因为客户需要时间调整。他的发布会、投放计划、内部汇报都挂在你的交付日上。你晚说一天，他就少一天余量。",[11,135,136],{},"还有个原因是信任。延期被发现和主动说，性质完全不同。被发现一次，后面每次交付他都会怀疑。",[11,138,139],{},"我们的规矩是：只要判断可能延期超过三天，当天发消息，不等确认。",[15,141,143],{"id":142},"怎么说四句话","怎么说：四句话",[11,145,146],{},"第一句，事实。原定几号交付，现在预计几号，延期多久。",[11,148,149],{},"第二句，影响。哪些交付物受影响，哪些不受影响。",[11,151,152],{},"第三句，原因，一句话，不辩解。",[11,154,155],{},"第四句，方案。接下来怎么补，需要客户配合什么。",[11,157,158],{},"四句话能说完的事，别写一页。写得越长，越像在找理由。",[15,160,161],{"id":161},"三种不该出现的解释",[11,163,164],{},"第一种，怪客户。“因为你们文档给晚了”，哪怕是真的，也要换成“我们在等文档，预计 X 号能拿到”。",[11,166,167],{},"第二种，过度道歉。连着说五次抱歉，客户会觉得你心里没底。",[11,169,170],{},"第三种，承诺一个明显做不到的新时间。为了安抚客户把交付日再提前一周，下次延期时更难看。",[15,172,173],{"id":173},"延期之后怎么补信任",[11,175,176],{},"延期之后的三周，我们每周多给客户一次口头同步，十分钟，说清进展和风险。成本不高，但客户能感觉到事情在被推进。",[11,178,179],{},"交付完成之后，把延期原因写进复盘，下个项目排期时把同类风险标出来。客户看到你真的在改，比说十次抱歉有用。",[15,181,182],{"id":182},"延期之后要补什么",[11,184,185],{},"补两件事：一是把延期原因写进复盘，看是流程问题还是估算问题；二是下一个交付节点提前两天给客户看一眼进度，别让他等到交付日。",[11,187,188],{},"我们现在的项目周报里有固定一行：本周有风险的任务。写这一行的时候没人爱写，但它让延期变成了可讨论的事，而不是突然的坏消息。",{"title":79,"searchDepth":80,"depth":80,"links":190},[191,192,193,194,195,196],{"id":115,"depth":80,"text":115},{"id":130,"depth":80,"text":130},{"id":142,"depth":80,"text":143},{"id":161,"depth":80,"text":161},{"id":173,"depth":80,"text":173},{"id":182,"depth":80,"text":182},"行业观察","2026-08-18","延期三周，提前十天告知，客户反而更信任我们。这篇写发现延期当天要做的四件事、跟客户说的四句话模板，以及三种不该出现的解释。",{},"\u002Fblog\u002Fproject-delay-communication",{"title":107,"description":199},"blog\u002Fproject-delay-communication",[205,206,207],"项目延期","客户沟通","交付管理","Sbw78FJ0033IzZ--fXyKrsEsNHO99MFeIQYPSUNIfFk",{"id":210,"title":211,"author":6,"body":212,"canonical":89,"category":90,"cover":89,"date":301,"description":302,"draft":93,"extension":94,"keywords":89,"meta":303,"navigation":96,"noindex":93,"ogImage":89,"path":304,"seo":305,"seoDescription":89,"seoTitle":89,"stem":306,"tags":307,"updated":89,"__hash__":311},"blog\u002Fblog\u002Fcdn-cache-crawl.md","CDN 缓存配错，改版后蜘蛛三天没看到新内容",{"type":8,"value":213,"toc":292},[214,217,220,223,226,229,232,235,238,241,244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289],[11,215,216],{},"一次改版上线三天，搜索引擎抓到的还是旧页面，原因是 CDN 缓存把 HTML 缓存了 7 天。缓存和抓取的关系，很多技术团队没意识到。",[15,218,219],{"id":219},"那次事故",[11,221,222],{},"2026 年 3 月，一个客户的官网改版，产品页 URL 和结构都变了，301 也配好了。上线三天，Google 和百度抓到的还是旧页面，新页面的收录为零。",[11,224,225],{},"查日志发现，蜘蛛请求的返回内容来自 CDN 缓存，缓存 key 没带版本号，HTML 的缓存时间被设成了 7 天。",[11,227,228],{},"我们把 HTML 的缓存策略改成\"短缓存 + 主动刷新\"，重新推送 CDN，第二天蜘蛛就抓到了新页面。但已经浪费了三天，加上恢复，排名掉了两周。",[15,230,231],{"id":231},"缓存和抓取的关系",[11,233,234],{},"搜索引擎抓的是 CDN 返回的内容，不是你源站的内容。CDN 缓存错，它看到的就是旧版本。",[11,236,237],{},"更麻烦的是缓存不一致：不同节点缓存的内容不同，蜘蛛今天抓到一个版本、明天抓到另一个版本，会被判定为页面不稳定。",[15,239,240],{"id":240},"三个配置原则",[11,242,243],{},"第一，HTML 不做长缓存。HTML 用短缓存（比如 5 分钟）或者协商缓存，图片、JS、CSS 这些带哈希的静态资源可以长缓存。",[11,245,246],{},"第二，缓存 key 带上版本。改版时版本号变，缓存自然失效，不用手动刷。",[11,248,249],{},"第三，按 UA 区分缓存要谨慎。有些站按设备做不同页面，缓存 key 里必须带 UA 维度，否则手机用户拿到桌面版。",[15,251,252],{"id":252},"怎么验证",[11,254,255],{},"改版或发布后，做三件事：",[11,257,258],{},"用 curl 请求目标 URL，看返回头里的缓存状态（HIT\u002FMISS）、缓存时间、以及内容是不是新的。",[11,260,261],{},"用搜索引擎的抓取工具（GSC 的 URL 检查、百度的抓取诊断）抓一次，看拿到的 HTML 是不是新版本。",[11,263,264],{},"在不同地区、不同网络下各请求一次，确认缓存一致。我们一般抽 3 个城市。",[15,266,267],{"id":267},"另外两个坑",[11,269,270],{},"第一个，CDN 默认缓存 HTML。很多云厂商的默认规则是\"静态资源缓存、HTML 不缓存\"，但也有些套餐默认缓存所有内容。上线前一定确认。",[11,272,273],{},"第二个，回源 HOST 配错。CDN 回源到错误的域名，拿到的是默认站点或者 404，蜘蛛看到的就是空页面。这个错误很隐蔽，查日志能看到大量 404 但源站正常。",[15,275,276],{"id":276},"一个流程建议",[11,278,279],{},"我们把\"CDN 缓存检查\"加进了上线清单：改版、迁移、大版本发布，发布后 10 分钟内必查。",[11,281,282],{},"检查项就三条：HTML 缓存时间、缓存 key 是否带版本、蜘蛛抓到的内容是否是新版本。",[15,284,285],{"id":285},"判断",[11,287,288],{},"CDN 是技术 SEO 里最容易被忽略的一层，因为它不在代码里，在基础设施里。开发不管、运维不懂 SEO，出了问题两边都查不到。",[11,290,291],{},"改版前把缓存策略定好，比改版后救火便宜得多。",{"title":79,"searchDepth":80,"depth":80,"links":293},[294,295,296,297,298,299,300],{"id":219,"depth":80,"text":219},{"id":231,"depth":80,"text":231},{"id":240,"depth":80,"text":240},{"id":252,"depth":80,"text":252},{"id":267,"depth":80,"text":267},{"id":276,"depth":80,"text":276},{"id":285,"depth":80,"text":285},"2026-08-20","一次改版上线三天，搜索引擎抓到的还是旧页面，原因是 CDN 缓存把 HTML 缓存了 7 天。缓存和抓取的关系、三个配置原则、怎么验证都在这篇，附我们踩过的两次坑。这层不出问题则已，出问题就是全站级别的，别等出事再查。",{},"\u002Fblog\u002Fcdn-cache-crawl",{"title":211,"description":302},"blog\u002Fcdn-cache-crawl",[308,309,310],"CDN","缓存","抓取","ZyS6fM8EZ9kMvRp4SEEoxnE60e0MoaQYCVWPRnfVehQ",1794088102653]