[{"data":1,"prerenderedAt":344},["ShallowReactive",2],{"blog-robots-block-vs-noindex":3,"blog-prev-robots-block-vs-noindex":164,"blog-next-robots-block-vs-noindex":255},{"id":4,"title":5,"author":6,"body":7,"canonical":149,"category":150,"cover":149,"date":151,"description":152,"draft":153,"extension":154,"keywords":149,"meta":155,"navigation":156,"noindex":153,"ogImage":149,"path":157,"seo":158,"seoDescription":149,"seoTitle":149,"stem":159,"tags":160,"updated":149,"__hash__":163},"blog\u002Fblog\u002Frobots-block-vs-noindex.md","robots 屏蔽和 noindex，选错会让页面彻底消失","元析智能",{"type":8,"value":9,"toc":139},"minimark",[10,14,18,21,24,27,104,107,110,113,116,119,127,130,133,136],[11,12,13],"p",{},"robots 拦的是\"来不来抓\"，noindex 拦的是\"进不进库\"。想让页面从搜索结果里消失，用 noindex；想省抓取预算、不想让蜘蛛为它浪费请求，用 robots。最危险的做法是两个一起上。",[15,16,17],"h2",{"id":17},"为什么叠在一起会出事",[11,19,20],{},"被 robots 屏蔽的 URL，蜘蛛不会去读页面上的 noindex。如果站内或外站有链接指向它，它仍然可能被收录，只是收录成一个没有摘要、标题是 URL 本身的条目。用户搜到它，看不到内容，也不知道它是什么。2025 年 11 月一个开发者工具站就踩了这个坑：老版本文档页同时写了 robots 和 noindex，侧边栏链接还删了，半年后这批页面仍挂在搜索结果里，点击率 0.4%。",[11,22,23],{},"清理的时候我们花了两步：先把侧边栏链接加回去，删掉 robots 里的那行规则，保留 noindex。六周后这批页面才从搜索结果里消失。",[15,25,26],{"id":26},"选择标准",[28,29,30,46],"table",{},[31,32,33],"thead",{},[34,35,36,40,43],"tr",{},[37,38,39],"th",{},"场景",[37,41,42],{},"用什么",[37,44,45],{},"原因",[47,48,49,61,72,83,94],"tbody",{},[34,50,51,55,58],{},[52,53,54],"td",{},"后台、API、测试环境",[52,56,57],{},"robots",[52,59,60],{},"没有内容价值，也不该被访问",[34,62,63,66,69],{},[52,64,65],{},"已下线但保留给用户看的老页面",[52,67,68],{},"noindex",[52,70,71],{},"保留内链，权重还能流动",[34,73,74,77,80],{},[52,75,76],{},"分页的深层页",[52,78,79],{},"canonical 或 noindex",[52,81,82],{},"用 robots 会切断内链发现",[34,84,85,88,91],{},[52,86,87],{},"参数筛选页",[52,89,90],{},"canonical 优先",[52,92,93],{},"必要时 robots 拦组合参数",[34,95,96,99,101],{},[52,97,98],{},"站内搜索结果页",[52,100,68],{},[52,102,103],{},"大量低质重复页",[15,105,106],{"id":106},"验证方法",[11,108,109],{},"GSC 的网址检查会明确告诉你页面处于哪种状态：\"已被 robots.txt 屏蔽\"和\"已排除，被 noindex 标记\"是两个不同的结论，别混。curl 一下页面看 meta 里到底写了什么，再看 robots.txt 里有没有匹配规则。",[11,111,112],{},"还有一个容易忽略的点：noindex 要保留至少几周再撤内链。搜索引擎需要重新抓一次才能读到标记，撤太快等于什么都没做。",[15,114,115],{"id":115},"两个常见误解",[11,117,118],{},"第一个误解：以为 robots 屏蔽后页面就不占索引位置了。实际上它可能还在索引里，只是没有摘要，这种条目对品牌形象是负分。第二个误解：以为 noindex 页面会被立刻删除。搜索引擎要重新抓取才会读到标记，页面多的时候排期很长，所以别在上线第二天就催结果。",[11,120,121,122,126],{},"还有个反直觉的点：对分页的深层页用 robots 屏蔽，会让蜘蛛找不到更早的列表内容，反而伤害收录。这类页面交给 canonical 更合适，实在要挡，只挡 ",[123,124,125],"code",{},"?page="," 超过某一页的参数。",[15,128,129],{"id":129},"我们给客户的默认配置",[11,131,132],{},"后台和 API 路径进 robots；测试环境整站加 Basic Auth，不用 robots；老页面保留 noindex 并留在导航的归档区；站内搜索结果页 noindex；参数页先配 canonical，再按抓取量决定是否屏蔽。这套配置几年不用改。",[15,134,135],{"id":135},"立场",[11,137,138],{},"一个页面只用一种控制指令。要它消失，用 noindex，别加 robots；要蜘蛛别来，用 robots，但它不会从索引里消失。想让两者同时成立，那你其实想要的是 404 或 410——直接删除，比掖着藏着干净。",{"title":140,"searchDepth":141,"depth":141,"links":142},"",2,[143,144,145,146,147,148],{"id":17,"depth":141,"text":17},{"id":26,"depth":141,"text":26},{"id":106,"depth":141,"text":106},{"id":115,"depth":141,"text":115},{"id":129,"depth":141,"text":129},{"id":135,"depth":141,"text":135},null,"技术SEO","2026-01-18","两个指令管的事不一样：robots 拦抓取，noindex 拦索引。我们用 2025 年 11 月一个文档页同时加上两者的案例，讲清选择标准、叠加的风险，以及替代方案。",false,"md",{},true,"\u002Fblog\u002Frobots-block-vs-noindex",{"title":5,"description":152},"blog\u002Frobots-block-vs-noindex",[161,68,162],"robots.txt","收录","EUaWViqpniycoAnj_FAX3ukYru8ioOlzUyfs1aHj3WE",{"id":165,"title":166,"author":6,"body":167,"canonical":149,"category":150,"cover":149,"date":244,"description":245,"draft":153,"extension":154,"keywords":149,"meta":246,"navigation":156,"noindex":153,"ogImage":149,"path":247,"seo":248,"seoDescription":149,"seoTitle":149,"stem":249,"tags":250,"updated":149,"__hash__":254},"blog\u002Fblog\u002Fjs-rendered-site-crawl-check.md","前端渲染的站，工具爬不到的内容怎么查",{"type":8,"value":168,"toc":236},[169,172,176,179,182,185,188,191,194,197,200,203,206,209,212,215,218,221,224,227,230,233],[11,170,171],{},"2026 年 1 月我们看一个 React 写的文档站，用 curl 抓首页 HTML，正文里一个标题都找不到，浏览器渲染完却有 42 个标题。这类站不是不能做 SEO，但前提是先搞清楚搜索引擎到底能看到什么。",[15,173,175],{"id":174},"两个视角先分清","两个视角，先分清",[11,177,178],{},"源码视角：curl 或者查看页面源代码，看到的是服务器返回的原始 HTML。渲染视角：浏览器执行 JS 之后的 DOM。",[11,180,181],{},"搜索引擎两个都看，先看源码，再排队渲染。渲染要花资源，所以有预算限制，页面越多、越深，越容易被漏掉。",[11,183,184],{},"我的做法是两个都抓一遍。curl 下来的 HTML 里搜 h1、正文关键词、内链，渲染后的 DOM 里再搜一遍，缺什么一目了然。",[15,186,187],{"id":187},"三种常见缺失",[11,189,190],{},"第一种，整站客户端渲染。源码里只有一个空的 div 加一段脚本，所有内容都靠 JS 生成。这类站被抓到的概率取决于渲染预算，首页和热门页问题不大，长尾页经常抓不到。",[11,192,193],{},"第二种，懒加载。图片和正文要滚动才加载，蜘蛛不滚动。首屏以下的内容经常抓不到，或者抓到的是占位符。",[11,195,196],{},"第三种，折叠内容。tab 切换、展开更多里的文字，源码里没有，渲染后要点击才出现。蜘蛛不会点。",[15,198,199],{"id":199},"怎么查",[11,201,202],{},"先 curl 抓 5 个不同类型的页面：首页、产品页、文档页、博客文章、列表页。统计每个页面的标题数、正文字数、内链数，再和浏览器渲染后的数字对比。",[11,204,205],{},"GSC 的 URL 检查里有一个已渲染 HTML 的查看入口，能直接看到 Google 拿到的版本。这个比任何第三方工具都准。",[11,207,208],{},"最后看日志。如果 Googlebot 抓了 URL 但不抓 JS 和 CSS 资源，渲染一定不完整。日志里按资源类型统计一下就能看出来。",[15,210,211],{"id":211},"怎么改",[11,213,214],{},"能上服务端渲染就上，改造成本一次性，收益长期。改不动的话，至少把首屏关键内容和内链放进原始 HTML。",[11,216,217],{},"还有个便宜办法，用预渲染服务给蜘蛛返回渲染好的 HTML，用户仍然走 JS。这个方案适合内容为主的站，不适合交互复杂的应用。",[15,219,220],{"id":220},"预渲染的代价",[11,222,223],{},"预渲染服务按页面数收费，几千页的站一个月几十美元，页面多的要上百。它能解决被抓到的问题，解决不了体验问题。",[11,225,226],{},"我们用它做过两个内容型站点，效果还行。交互重的应用不建议用，预渲染出来的页面和真实应用差太多，用户点进去会觉得是另一个页面。",[11,228,229],{},"还有一点，预渲染要按 UA 判断，别把真实用户也导到预渲染版本上。配错了会出现用户看到旧内容的事故。",[15,231,232],{"id":232},"我们的判断",[11,234,235],{},"完全依赖客户端渲染、又不肯改架构的 B2B 站，我们不接 SEO 项目。内容做得再好，蜘蛛看不到就是零。先花两个月改架构，比后面两年补内容便宜。",{"title":140,"searchDepth":141,"depth":141,"links":237},[238,239,240,241,242,243],{"id":174,"depth":141,"text":175},{"id":187,"depth":141,"text":187},{"id":199,"depth":141,"text":199},{"id":211,"depth":141,"text":211},{"id":220,"depth":141,"text":220},{"id":232,"depth":141,"text":232},"2026-01-17","一个 React 文档站首屏 HTML 里一个标题都没有，渲染后有 42 个。这篇写源码和渲染后 DOM 怎么对比、三种常见缺失，以及改架构还是改内容。",{},"\u002Fblog\u002Fjs-rendered-site-crawl-check",{"title":166,"description":245},"blog\u002Fjs-rendered-site-crawl-check",[251,252,253],"JavaScript渲染","抓取","技术检测","lUfzeCkh4UTT-pF0e5AfL3OzlpnNOjAsPSjIxGtREyI",{"id":256,"title":257,"author":6,"body":258,"canonical":149,"category":150,"cover":149,"date":333,"description":334,"draft":153,"extension":154,"keywords":149,"meta":335,"navigation":156,"noindex":153,"ogImage":149,"path":336,"seo":337,"seoDescription":149,"seoTitle":149,"stem":338,"tags":339,"updated":149,"__hash__":343},"blog\u002Fblog\u002Fwebp-avif-image-compression.md","把站内 4200 张图转成 WebP 和 AVIF，我们记下了三个数",{"type":8,"value":259,"toc":325},[260,263,266,269,272,276,279,282,285,288,291,298,301,304,307,310,313,316,319,322],[11,261,262],{},"把站内 4200 张图批量转格式能省多少？我们的实测：PNG 转 WebP 平均小 62%，JPEG 转 WebP 平均小 34%，WebP 再转 AVIF 还能再小 18%，但编码时间多五倍。这是去年 11 月一个设计工具站的项目，数据可以直接拿去估自己的站。",[15,264,265],{"id":265},"先算账再动手",[11,267,268],{},"这个站媒体库 4200 张图：PNG 1400 张，主要是界面截图和图标；JPEG 2800 张，博客配图和案例图。转之前总体积 3.1GB，转成 WebP 之后 1.4GB，平均压掉 55%。",[11,270,271],{},"PNG 那批收益最大，因为里面很多是界面截图，色块多、渐变少，WebP 对这类图特别友好。JPEG 那批收益小一些，因为原图本来就压过一轮。",[15,273,275],{"id":274},"avif-值不值","AVIF 值不值",[11,277,278],{},"AVIF 压缩率确实更好。我们抽 200 张图对比，WebP 平均 96KB，AVIF 平均 79KB。但代价是编码慢：同一台机器转 WebP 用 12 分钟，转 AVIF 要 1 小时，CI 里根本跑不动。",[11,280,281],{},"我的判断是：首屏大图的 AVIF 值得，剩下 95% 的图用 WebP。为了 18% 的体积把构建时间拉长五倍，工程上不划算。",[15,283,284],{"id":284},"三个必踩的坑",[11,286,287],{},"第一个坑是质量参数直接照搬。WebP 的 q=75 和 AVIF 的 q=50 视觉质量接近，硬套同一个数不是太糊就是太大，得按格式分别调。",[11,289,290],{},"第二个坑是透明背景。PNG 转 WebP 支持透明，但有些老工具链会丢掉 alpha 通道，图标变黑底。转完必须抽一批 PNG 图标肉眼过一遍。",[11,292,293,294,297],{},"第三个坑是兼容兜底。AVIF 的浏览器支持已经不错，但旧设备还在用，用 ",[123,295,296],{},"\u003Cpicture>"," 加 WebP 兜底，别只给一个 src。",[15,299,300],{"id":300},"什么图不该转",[11,302,303],{},"三类图建议保留原格式。图标类的小 PNG 和 SVG 本来就几 KB，转格式的收益还不如多一次请求；带大面积纯色文字的截图，WebP 有损模式会把字边缘压糊，我们用无损或者 q=90 才过关；GIF 动图别转 WebP 动图，转成 MP4 更小，实在不行就保留。",[11,305,306],{},"这个站转完第一版有 60 多张博客长图文字发虚，编辑在群里骂了一轮。后来用无损 WebP 重转那批，体积还是比 PNG 小 30%，问题解决。",[15,308,309],{"id":309},"落地方式",[11,311,312],{},"我们没手工转，改的是上传流程：编辑器上传时自动生成 WebP，原图留档。历史图片用脚本批量跑，跑完 grep 一遍 HTML 和数据库里的引用路径。这一步最花时间，因为总有几十张图是硬编码在正文里的。",[11,314,315],{},"这个站改完，移动端首屏图片传输从 1.9MB 降到 620KB。但要说清楚：格式只能解决体积，解决不了\"该不该出现在首屏\"。有些站首屏放三张装饰图，转成 AVIF 也救不回来。",[15,317,318],{"id":318},"转完之后要立个规矩",[11,320,321],{},"批量转换是一次性的，不立规矩三个月就反弹。我们给这个站加了两条：编辑器上传时超过 500KB 的图自动压缩并生成 WebP；每周跑一次巡检，把超过 300KB 的图列出来给内容团队。",[11,323,324],{},"巡检脚本不到 40 行，按页面路径输出图片体积排名，谁传了大图一目了然。这条规矩执行三个月，媒体库平均体积又降了 11%。",{"title":140,"searchDepth":141,"depth":141,"links":326},[327,328,329,330,331,332],{"id":265,"depth":141,"text":265},{"id":274,"depth":141,"text":275},{"id":284,"depth":141,"text":284},{"id":300,"depth":141,"text":300},{"id":309,"depth":141,"text":309},{"id":318,"depth":141,"text":318},"2026-01-19","实测 PNG 转 WebP 小 62%、JPEG 转 WebP 小 34%、再转 AVIF 只多小 18% 但编码慢五倍。三个必踩的坑：质量参数照搬、透明通道丢失、兼容兜底。",{},"\u002Fblog\u002Fwebp-avif-image-compression",{"title":257,"description":334},"blog\u002Fwebp-avif-image-compression",[340,341,342],"图片优化","WebP","AVIF","Rj3KS2SZmZe52cWKT5Gq2KLaetP2WoN9_Kjbt3QBzR0",1794088109132]