[{"data":1,"prerenderedAt":305},["ShallowReactive",2],{"blog-duplicate-content-four-types":3,"blog-prev-duplicate-content-four-types":134,"blog-next-duplicate-content-four-types":222},{"id":4,"title":5,"author":6,"body":7,"canonical":118,"category":119,"cover":118,"date":120,"description":121,"draft":122,"extension":123,"keywords":118,"meta":124,"navigation":125,"noindex":122,"ogImage":118,"path":126,"seo":127,"seoDescription":118,"seoTitle":118,"stem":128,"tags":129,"updated":118,"__hash__":133},"blog\u002Fblog\u002Fduplicate-content-four-types.md","重复内容自查：先分清四种重复再动手","元析智能",{"type":8,"value":9,"toc":108},"minimark",[10,14,18,25,31,37,43,47,50,66,69,72,75,78,90,93,96,99,102,105],[11,12,13],"p",{},"重复内容不是一种病，是四种。用错药比不治更糟——最常见的就是所有重复都拿 canonical 去压，最后连本该保留的独立页面也被合并掉。",[15,16,17],"h2",{"id":17},"四种重复和各自修法",[11,19,20,24],{},[21,22,23],"strong",{},"参数型","：同一页带 utm、排序、筛选参数。修法是 canonical 加参数规则，别用 301，否则用户点筛选条件会被弹回列表页。",[11,26,27,30],{},[21,28,29],{},"路径型","：尾斜杠、大小写、www 与非 www、http 与 https。修法只有一种——服务器层 301 统一，一次到位，别用 canonical 糊。",[11,32,33,36],{},[21,34,35],{},"跨域型","：主站和博客分域、中英文分域、CDN 镜像域。要么跨域 canonical，要么整站 301 合并，选一个方向长期执行，改来改去最伤。",[11,38,39,42],{},[21,40,41],{},"内容型","：同一篇文章放进多个栏目、产品描述在多个页面复用、机翻多语言。修法是 canonical 到主版本，副本 noindex，同时收敛内链。",[15,44,46],{"id":45},"_2025-年-10-月那个-4-万-url-的站","2025 年 10 月那个 4 万 URL 的站",[11,48,49],{},"自查发现 2.6 万个 URL 是重复变体，客户自己的判断是\"全都 canonical 一下\"。我们按类型拆开：",[51,52,53,57,60,63],"ul",{},[54,55,56],"li",{},"路径型 3000 条，上周就修完了，一条 nginx 规则解决。",[54,58,59],{},"参数型 1.8 万条，canonical 加 robots 组合规则，两周。",[54,61,62],{},"跨域型 4000 条，博客整站 301 回主域，三周。",[54,64,65],{},"内容型 1000 条，合并了 30 篇，人工改了一个月。",[11,67,68],{},"三个月后有效页面从 1.4 万降到 1.4 万上下但结构干净了，自然点击涨 41%。收录总数还降了，这是好事。",[15,70,71],{"id":71},"怎么查",[11,73,74],{},"Screaming Frog 按内容相似度分组，能一次看出哪些 URL 内容重复率超过 90%。GSC 的\"重复网页，Google 选择的规范网页与用户指定的不同\"报告，直接告诉你 Google 选了谁当主版本。日志里看参数 URL 的抓取量，量大的先修。",[15,76,77],{"id":77},"分页和标签页最容易被忘",[11,79,80,81,85,86,89],{},"分页页的重复很少被当回事。",[82,83,84],"code",{},"\u002Fblog?page=2"," 和 ",[82,87,88],{},"\u002Fblog\u002Fpage\u002F2"," 是两条不同的路径，内容一样，如果两套都存在，就是路径型重复。标签页也类似：一篇文章挂 8 个标签，等于 8 个入口指向同一篇，蜘蛛会反复抓。",[11,91,92],{},"处理方式：分页只保留一种 URL 形式，其余 301；分页页自己 canonical 到自己，不要指向第一页（那样第二页的内容永远不收录）；标签页合并到主题页，实在要留就 noindex 但保留链接。",[15,94,95],{"id":95},"清理后的观察期",[11,97,98],{},"改完至少观察 6 周。前两周索引数可能还在涨，因为蜘蛛在重新抓；第 3 到 4 周开始降，这是正常清理；第 5 周后看有效页面的展示和点击有没有涨。我们那个 4 万 URL 的站，点击增长是在第 7 周才明显起来的。",[11,100,101],{},"如果 8 周后没有任何变化，先别怀疑 canonical，回去看日志里参数页的抓取量有没有降。抓取量没降，说明你的屏蔽规则没生效。",[15,103,104],{"id":104},"顺序",[11,106,107],{},"先修结构性重复（路径、跨域），再修参数型，内容型放最后。结构重复不修，canonical 就是往漏水的桶里倒水：蜘蛛每次还是从新地址进来，再被跳一次。",{"title":109,"searchDepth":110,"depth":110,"links":111},"",2,[112,113,114,115,116,117],{"id":17,"depth":110,"text":17},{"id":45,"depth":110,"text":46},{"id":71,"depth":110,"text":71},{"id":77,"depth":110,"text":77},{"id":95,"depth":110,"text":95},{"id":104,"depth":110,"text":104},null,"技术SEO","2026-02-06","一发现重复就急着上 canonical，结果越改越乱。我们把重复分成参数型、路径型、跨域型、内容型四种，每种对应不同修法，配一个 2025 年 10 月 4 万 URL 站点的清理记录。",false,"md",{},true,"\u002Fblog\u002Fduplicate-content-four-types",{"title":5,"description":121},"blog\u002Fduplicate-content-four-types",[130,131,132],"重复内容","canonical","网站诊断","SlOKHsDWVx8j6a2zRKtHngZIbES2AnqEHGGUWJ9oYbg",{"id":135,"title":136,"author":6,"body":137,"canonical":118,"category":119,"cover":118,"date":211,"description":212,"draft":122,"extension":123,"keywords":118,"meta":213,"navigation":125,"noindex":122,"ogImage":118,"path":214,"seo":215,"seoDescription":118,"seoTitle":118,"stem":216,"tags":217,"updated":118,"__hash__":221},"blog\u002Fblog\u002Fgsc-crawl-stats-vs-logs.md","GSC 抓取统计和服务器日志对不上，原因有四个",{"type":8,"value":138,"toc":203},[139,142,146,149,152,156,159,162,166,169,172,176,179,182,185,188,191,194,197,200],[11,140,141],{},"GSC 抓取统计显示 12 万次，服务器日志里只有 8 万次 Googlebot 请求，差的四万很容易被当成数据出错。其实对不上是常态，四个原因几乎每次都会遇到。",[15,143,145],{"id":144},"原因一gsc-是抽样","原因一：GSC 是抽样",[11,147,148],{},"抓取统计报告基于抽样数据，不是全量。站点越大，抽样比例越低，页面上看到的数字是估算值。它能用来看趋势，不能用来对账。",[11,150,151],{},"另外这个报告只保留 90 天，时间窗口一长就对不上。想拿半年数据，得自己每周导一次。",[15,153,155],{"id":154},"原因二cdn-和缓存","原因二：CDN 和缓存",[11,157,158],{},"如果站前有 CDN，Googlebot 的请求很多打在边缘节点，回源的只有未命中的部分。GSC 统计的是边缘收到的请求，你的日志记的是回源请求，中间差的量取决于缓存命中率。",[11,160,161],{},"缓存命中率高的站，这个差距能到 40%。查的办法很简单，看 CDN 后台的命中率，再对比日志和 GSC 的比例。",[15,163,165],{"id":164},"原因三日志里的-googlebot-有很多假货","原因三：日志里的 Googlebot 有很多假货",[11,167,168],{},"UA 里写 Googlebot 的请求，一大半不是真的。有人用脚本扫站、有人抓数据，都爱伪装成蜘蛛。",[11,170,171],{},"验证方式只有一种：反向 DNS 查询，确认来源 IP 属于 Google 的网段。我们写脚本把日志里的 IP 逐个反查，通常能筛掉三到五成的假 Googlebot。不加这一步，你会以为蜘蛛抓得很勤，其实抓你没用的东西。",[15,173,175],{"id":174},"原因四统计口径不同","原因四：统计口径不同",[11,177,178],{},"GSC 按请求算，一次页面加二十个资源就是二十一次。日志里如果你按页面请求统计，只算 document 类型，两个数天然差几倍。先统一口径，再比数字。",[11,180,181],{},"我们统一成只算 HTML 页面请求，CSS、JS、图片全部剔除。这一步做完，双方的量级通常能接近到 20% 以内。",[15,183,184],{"id":184},"怎么用这两个数",[11,186,187],{},"日志用来看路径分布：哪些目录被抓得多，哪些页面被反复抓，状态码分布是什么样。GSC 用来看趋势：整体抓取量是在涨还是跌，和收录变化对不对得上。",[11,189,190],{},"两个数不需要精确相等。差一倍以内、趋势一致，就是健康的。差得离谱，先查 CDN 和假蜘蛛，大部分问题出在这两处。",[15,192,193],{"id":193},"查错的顺序",[11,195,196],{},"2026 年 2 月我按这个顺序查过一次，四十分钟定位到原因：先做 IP 反查，去掉假蜘蛛；再看 CDN 命中率；然后统一口径只算 HTML；最后才对比趋势。",[11,198,199],{},"顺序很重要。先查口径，往往发现是两个数本来就不该相等，后面的排查都省了。反过来先怀疑工具坏了，容易白折腾。",[11,201,202],{},"别花一周去把两个数调平，调不平。把精力放在日志里的路径分布上，那里才有能改的东西。",{"title":109,"searchDepth":110,"depth":110,"links":204},[205,206,207,208,209,210],{"id":144,"depth":110,"text":145},{"id":154,"depth":110,"text":155},{"id":164,"depth":110,"text":165},{"id":174,"depth":110,"text":175},{"id":184,"depth":110,"text":184},{"id":193,"depth":110,"text":193},"2026-02-05","GSC 显示 12 万次抓取，日志只有 8 万，差的四万去哪了。这篇写抽样、CDN 缓存、假蜘蛛和统计口径四个原因，以及怎么对齐两个数。",{},"\u002Fblog\u002Fgsc-crawl-stats-vs-logs",{"title":136,"description":212},"blog\u002Fgsc-crawl-stats-vs-logs",[218,219,220],"GSC","日志分析","抓取统计","DWL-ROEb7BgGCb5Ao4TKv6-ha49LQ_6R5MD6dXuwEV0",{"id":223,"title":224,"author":6,"body":225,"canonical":118,"category":119,"cover":118,"date":294,"description":295,"draft":122,"extension":123,"keywords":118,"meta":296,"navigation":125,"noindex":122,"ogImage":118,"path":297,"seo":298,"seoDescription":118,"seoTitle":118,"stem":299,"tags":300,"updated":118,"__hash__":304},"blog\u002Fblog\u002Fproduct-demo-video-weight.md","产品演示视频别一进页面就自动播放，流量代价算给你看",{"type":8,"value":226,"toc":286},[227,230,233,236,239,243,246,249,252,255,258,261,264,267,270,273,276,279],[11,228,229],{},"产品演示视频别一进页面就自动播放。去年 12 月我们查一个 SaaS 首页，三个 Wistia 播放器嵌在首屏下方，光播放器脚本就 690KB，首屏 LCP 3.2 秒里有 0.9 秒在等它们。",[15,231,232],{"id":232},"先算代价",[11,234,235],{},"视频本身 18MB，播放器脚本 690KB，加上封面图和统计脚本，一个\"看看产品长什么样\"的模块占了首屏资源的一半。移动端更糟：62% 的用户根本不会点播放，但所有人都在为它付流量。",[11,237,238],{},"我们拉了一个月的统计：这个模块移动端展示 8.4 万次，实际播放 1.2 万次，播放率 14%。也就是说 86% 的加载是白费的。",[15,240,242],{"id":241},"改法封面图加点击加载","改法：封面图加点击加载",[11,244,245],{},"三步。第一步，把播放器换成点击后才注入的 iframe，初始只放一张 60KB 的 WebP 封面。第二步，封面上加播放按钮，用原生 button 保证可访问性。第三步，点击时才加载播放器脚本，用户等一秒可以接受，因为他已经表达了意愿。",[11,247,248],{},"改完首屏资源从 2.1MB 降到 740KB，LCP 从 3.2 秒到 1.8 秒。播放率没降，反而从 14% 涨到 17%，因为页面快了，模块更早出现在视野里。",[15,250,251],{"id":251},"什么情况可以自动播放",[11,253,254],{},"只有一种：静音、循环、无控制条的背景视频，体积压到 1.5MB 以内，并且用 poster 兜底。这种视频的作用是氛围，不是内容。",[11,256,257],{},"就算这样也要注意移动端。iOS 的低电量模式会拦住自动播放，用户看到的是静止封面，所以封面本身要好看、能传达信息。",[15,259,260],{"id":260},"视频托管的取舍",[11,262,263],{},"自托管的好处是没第三方脚本、能控制缓存，坏处是带宽和转码自己扛。用 YouTube 或 Vimeo 省事，代价是多一个第三方域名、多一层 DNS 和 TLS。",[11,265,266],{},"我们的默认建议是：演示视频放第三方，但必须点击后才加载；产品内的短视频自托管，走 CDN。最不该做的是用第三方播放器做首屏自动播放，那是两头不讨好。",[15,268,269],{"id":269},"一个容易忽略的细节",[11,271,272],{},"视频封面图和播放器不要放在同一个 DOM 容器里手动切换，否则容易引起布局位移。封面和 iframe 用同一个固定比例的外层容器，切换时高度不变。这个站在改版时踩过一次，CLS 从 0.02 跳到 0.17，查了半天才发现是播放器初始化时把容器撑高了。",[15,274,275],{"id":275},"如果老板坚持要自动播放",[11,277,278],{},"我的经验是拿播放率和转化数据说话，而不是讲性能原理。这个站改完两周，播放率从 14% 到 17%，预约演示的转化没变差也没变好。也就是说自动播放并没有带来额外收益，但它确实拖慢了首屏。",[11,280,281,282,285],{},"如果一定要保留自动播放，折中方案是：只在桌面端自动播放，移动端用封面加点击；视频压到 1.5MB 以内，用 AV1 或者 H.265；加 ",[82,283,284],{},"preload=\"none\"","，让浏览器别预取整个文件。这三条做完，代价能压到可接受的范围。",{"title":109,"searchDepth":110,"depth":110,"links":287},[288,289,290,291,292,293],{"id":232,"depth":110,"text":232},{"id":241,"depth":110,"text":242},{"id":251,"depth":110,"text":251},{"id":260,"depth":110,"text":260},{"id":269,"depth":110,"text":269},{"id":275,"depth":110,"text":275},"2026-02-07","一个 SaaS 首页三个播放器脚本 690KB，移动端 86% 的加载是白费的，播放率只有 14%。改成封面图加点击加载后 LCP 从 3.2 秒到 1.8 秒，播放率反而涨了。",{},"\u002Fblog\u002Fproduct-demo-video-weight",{"title":224,"description":295},"blog\u002Fproduct-demo-video-weight",[301,302,303],"视频优化","第三方脚本","LCP","ZLYYCnXB8WzsS2x_pPFWgWts9vyDKoE_uEvlLQ-Vop4",1794088108617]