[{"data":1,"prerenderedAt":324},["ShallowReactive",2],{"blog-image-seo-technical":3,"blog-prev-image-seo-technical":136,"blog-next-image-seo-technical":216},{"id":4,"title":5,"author":6,"body":7,"canonical":120,"category":121,"cover":120,"date":122,"description":123,"draft":124,"extension":125,"keywords":120,"meta":126,"navigation":127,"noindex":124,"ogImage":120,"path":128,"seo":129,"seoDescription":120,"seoTitle":120,"stem":130,"tags":131,"updated":120,"__hash__":135},"blog\u002Fblog\u002Fimage-seo-technical.md","1200 张产品图只被收录 40 张，问题在三个地方","元析智能",{"type":8,"value":9,"toc":110},"minimark",[10,14,19,31,38,45,49,56,59,62,66,69,76,79,83,86,89,92,95,98,101,104,107],[11,12,13],"p",{},"产品图不收录，不是图片不够好看。我们查了 6 个软件站，问题集中在懒加载写法、图片 URL 参数和页面结构三处。1200 张图修完收录到 780 张。",[15,16,18],"h2",{"id":17},"问题一懒加载写成了没有-src","问题一：懒加载写成了\"没有 src\"",[11,20,21,22,26,27,30],{},"很多站为了性能，图片的 ",[23,24,25],"code",{},"src"," 写成占位图，真实地址放在 ",[23,28,29],{},"data-src","，等滚动到才加载。搜索引擎的爬虫不滚动页面，看到的永远是占位图。",[11,32,33,34,37],{},"查法：用抓取诊断或者 curl 看页面 HTML，搜索 ",[23,35,36],{},"\u003Cimg","，看 src 是不是占位图。",[11,39,40,41,44],{},"改法：首屏图片直接给真实 src，非首屏用原生 ",[23,42,43],{},"loading=\"lazy\"","，它会在 HTML 里保留真实地址，只是延迟加载。",[15,46,48],{"id":47},"问题二图片-url-带一堆参数","问题二：图片 URL 带一堆参数",[11,50,51,52,55],{},"图片做了 CDN 压缩和裁剪，URL 变成 ",[23,53,54],{},"image.jpg?w=800&h=600&q=80&format=webp","。同一个图有 10 个版本，搜索引擎会当成 10 张不同的图，权重分散。",[11,57,58],{},"查法：导出所有图片 URL，按路径去重，看一个原图对应多少个参数版本。",[11,60,61],{},"改法：用 canonical 或者 robots 收敛参数，只保留一个标准尺寸可被索引。最干净的做法是 CDN 层做内容协商，URL 不变，按 UA 返回合适格式。",[15,63,65],{"id":64},"问题三图片没有上下文","问题三：图片没有上下文",[11,67,68],{},"图片被收录不等于有排名。搜索引擎需要知道这张图讲什么，靠的是 alt、文件名、周围文字和所在页面的主题。",[11,70,71,72,75],{},"我们见过客户的图片 alt 全写成\"产品截图 1\"\"产品截图 2\"，文件名是 ",[23,73,74],{},"IMG_2024.png","。这种图片即使收录了，也搜不到。",[11,77,78],{},"改法：alt 写清楚图里是什么，文件名用有意义的英文短句，图片周围有说明文字。我们一般要求产品图的 alt 至少 10 个字、包含一个关键词。",[15,80,82],{"id":81},"额外一件事图片和页面要一起优化","额外一件事：图片和页面要一起优化",[11,84,85],{},"图片搜索的流量，最终是导到页面的。如果图片页是一个没有任何内容的附件页，用户点进来就走。",[11,87,88],{},"我们的做法是让图片可索引、同时图片所在的产品页\u002F文章页要有完整内容。图片搜索只是入口，转化还是靠页面。",[15,90,91],{"id":91},"修完的数据",[11,93,94],{},"2026 年 2 月我们开始查这个站，三周修完，每周看一次数据。",[11,96,97],{},"修完之后还有一个意外收获：产品图的 alt 写清楚之后，页面本身的图片相关搜索词也多了，比如\"XX 系统 后台截图\"这种长尾词，带来了一些注册。",[11,99,100],{},"那个客户 1200 张产品图，修了 3 周：懒加载改造、URL 参数收敛、alt 和文件名重写。",[11,102,103],{},"第 6 周看数据：收录从 40 张涨到 780 张，图片搜索带来的访问从每月 200 涨到 900 多，其中 12% 的用户到了产品页还停留超过 1 分钟。",[15,105,106],{"id":106},"一句判断",[11,108,109],{},"图片 SEO 是技术活，不是设计活。修好抓取路径和上下文，普通的产品截图也能带来流量。别在图片上堆关键词，搜索引擎现在能看出来。",{"title":111,"searchDepth":112,"depth":112,"links":113},"",2,[114,115,116,117,118,119],{"id":17,"depth":112,"text":18},{"id":47,"depth":112,"text":48},{"id":64,"depth":112,"text":65},{"id":81,"depth":112,"text":82},{"id":91,"depth":112,"text":91},{"id":106,"depth":112,"text":106},null,"技术SEO","2026-07-12","产品图不收录，不是图片不够好看。我们查了 6 个软件站，问题集中在懒加载写法、图片 URL 参数和页面结构三处。1200 张图修完收录到 780 张，图片搜索带来的访问涨了 3 倍。三个修法都不难，难在有人愿意去查。文末有修完的数据。",false,"md",{},true,"\u002Fblog\u002Fimage-seo-technical",{"title":5,"description":123},"blog\u002Fimage-seo-technical",[132,133,134],"图片SEO","收录","站点技术","ofEYh2G69aTRD8RzgIG0nOwI_iLJsMAjpEMCmncOH_4",{"id":137,"title":138,"author":6,"body":139,"canonical":120,"category":121,"cover":120,"date":205,"description":206,"draft":124,"extension":125,"keywords":120,"meta":207,"navigation":127,"noindex":124,"ogImage":120,"path":208,"seo":209,"seoDescription":120,"seoTitle":120,"stem":210,"tags":211,"updated":120,"__hash__":215},"blog\u002Fblog\u002Fcrawl-frequency-server-response.md","抓取频次上不去，先看服务器那 200 毫秒",{"type":8,"value":140,"toc":196},[141,144,147,150,153,157,160,163,166,169,172,175,178,181,184,187,190,193],[11,142,143],{},"抓取频次是搜索引擎给的配额，影响配额的因素里，服务器响应时间排第一，站点结构第二，内容更新频率第三。很多人一上来就研究权重，其实先看服务器那 200 毫秒更划算。",[15,145,146],{"id":146},"怎么测",[11,148,149],{},"日志里算每个请求的耗时，取 P95，别取平均值。GSC 的抓取统计能看总请求量和平均响应时间。分路径看，动态页和静态页要分开算，不然会被平均数骗。",[11,151,152],{},"我们的判断标准：P95 超过 800 毫秒就要优化，超过 1.5 秒基本会拖累抓取。百度对响应时间比 Google 更敏感，1200 毫秒以上就能看到抓取量明显下滑。",[15,154,156],{"id":155},"_2026-年-4-月那次优化","2026 年 4 月那次优化",[11,158,159],{},"一个 API 工具站，日抓取 900 次，P95 响应 1.1 秒。查下来三个原因：文档页每次请求都查数据库、没做页面级缓存、CDN 只缓存静态资源不缓存 HTML。",[11,161,162],{},"改法：页面级缓存 10 分钟，渲染结果存 Redis，数据库加索引，CDN 加 HTML 缓存规则。P95 从 1.1 秒压到 180 毫秒。一个月后日抓取 2400 次，收录涨 34%。",[15,164,165],{"id":165},"其他影响因素",[11,167,168],{},"5xx 比例、404 比例、sitemap 有效性、内容更新频率、外链数量。这些都要在响应时间之后看。5xx 尤其要命，蜘蛛连续遇到几次服务端错误会主动降频，恢复比降频慢得多。",[15,170,171],{"id":171},"验证方法",[11,173,174],{},"改完持续观察 3 到 4 周。抓取量涨了但收录没涨，说明问题在发现或质量环节；抓取量没动，说明瓶颈不在响应时间，回去看结构。",[15,176,177],{"id":177},"一个配套动作",[11,179,180],{},"压响应时间的同时，把 404 和 5xx 也清一遍。我们见过一个站响应时间只有 120 毫秒，但 5xx 占 3%，抓取量一直上不去。修完错误率后，抓取量涨得比优化响应时间还快。",[11,182,183],{},"监控上加一条：蜘蛛请求的错误率超过 1% 就报警。这条比看总抓取量更早发现问题。",[15,185,186],{"id":186},"一个误解",[11,188,189],{},"有人说\"抓取频次是看权重的，小站怎么优化都没用\"。对了一半。权重（外链、品牌）决定上限，响应时间和结构决定能不能接近上限。小站优化响应时间，从日抓 100 次到 500 次是常见的，这 5 倍不是权重给的。",[15,191,192],{"id":192},"立场",[11,194,195],{},"服务器优化是 SEO 里最被低估的一项，因为它看起来不像 SEO。它归运维，但影响的是抓取。做 SEO 的人至少要能看懂 P95 和 5xx 比率。",{"title":111,"searchDepth":112,"depth":112,"links":197},[198,199,200,201,202,203,204],{"id":146,"depth":112,"text":146},{"id":155,"depth":112,"text":156},{"id":165,"depth":112,"text":165},{"id":171,"depth":112,"text":171},{"id":177,"depth":112,"text":177},{"id":186,"depth":112,"text":186},{"id":192,"depth":112,"text":192},"2026-07-11","很多人以为抓取少是\"权重不够\"，其实服务器响应时间的影响更直接。我们把一个客户的 TTFB 从 1.1 秒压到 180 毫秒，Googlebot 抓取量一个月涨了 2.7 倍。这篇讲测量、优化和验证。",{},"\u002Fblog\u002Fcrawl-frequency-server-response",{"title":138,"description":206},"blog\u002Fcrawl-frequency-server-response",[212,213,214],"抓取频次","性能","日志分析","eSOfSs37DkR2PRpIQlYBRQGrCB6OiGNihWHZh3PZYyk",{"id":217,"title":218,"author":6,"body":219,"canonical":120,"category":121,"cover":120,"date":313,"description":314,"draft":124,"extension":125,"keywords":120,"meta":315,"navigation":127,"noindex":124,"ogImage":120,"path":316,"seo":317,"seoDescription":120,"seoTitle":120,"stem":318,"tags":319,"updated":120,"__hash__":323},"blog\u002Fblog\u002Fcritical-css-inline.md","把关键 CSS 内联进 HTML，首屏能省半秒",{"type":8,"value":220,"toc":304},[221,224,228,231,234,238,241,244,247,250,253,256,259,262,265,268,271,274,277,280,283,286,289,292,295,298,301],[11,222,223],{},"2026 年 8 月我们给一个官网做关键 CSS 内联，首屏渲染时间从 1.6 秒提前到 1.2 秒。改动只有一件事：把首屏需要的样式写进 HTML 的 head 里，剩下的样式延后加载。",[15,225,227],{"id":226},"为什么-css-会阻塞渲染","为什么 CSS 会阻塞渲染",[11,229,230],{},"浏览器要先拿到 CSS 才能确定页面长什么样，所以在 CSS 下载完成之前，它不会渲染任何内容。",[11,232,233],{},"一个 200KB 的样式文件，在 3G 网络下要下两秒。这两秒里用户看到的是白屏，即使 HTML 已经到了。",[15,235,237],{"id":236},"关键-css-怎么抽","关键 CSS 怎么抽",[11,239,240],{},"关键 CSS 指的是渲染首屏可见区域所必需的样式。写一个工具扫一遍页面，把首屏元素的样式挑出来，通常只有十几 KB。",[11,242,243],{},"原则是宁少勿多。内联的每一 KB 都拖慢 HTML 的传输，收益抵不过成本。",[11,245,246],{},"我们的经验是控制在 4KB 以内，压缩后 2KB 左右。超过这个数，说明把不该内联的样式也塞进去了。",[15,248,249],{"id":249},"剩余样式怎么异步加载",[11,251,252],{},"常见写法是 preload 加 onload 切换成样式表，或者用媒体查询的 hack。",[11,254,255],{},"这两种做法都有个副作用：样式加载完之前，页面可能闪一下无样式的内容。所以关键 CSS 必须覆盖首屏，否则会看到明显的跳动。",[11,257,258],{},"现在更稳的做法是用构建工具自动处理整个流程，别手写。",[15,260,261],{"id":261},"三个常见坑",[11,263,264],{},"第一个，内联太多。有人把整份样式表塞进 HTML，结果 HTML 变成 300KB，首屏更慢。",[11,266,267],{},"第二个，首屏判断错。工具按视口高度判定首屏，但用户实际看到的第一屏和工具算的不一样，尤其是移动端。要人工看一眼。",[11,269,270],{},"第三个，动态样式。主题切换、深色模式这类样式不在静态 CSS 里，内联会漏掉，导致闪烁。",[15,272,273],{"id":273},"怎么验证",[11,275,276],{},"改之前和改之后各测一次，看两个数：首次内容绘制和最大内容绘制。",[11,278,279],{},"测的时候一定要禁用缓存，并且用移动端配 4G 降速。桌面端加缓存测出来的差异很小，容易误判。",[11,281,282],{},"还要看真实用户的变化。实验室数据能证明改动生效，CrUX 才能证明用户感知到了。",[15,284,285],{"id":285},"一个折中做法",[11,287,288],{},"如果站点有几百个页面模板，逐个内联不现实。我们通常只对三类页面做：首页、核心产品页、投放落地页。",[11,290,291],{},"这三类页面吃掉了大部分首屏流量，其余页面用正常的样式表加载。这个取舍比全站上构建工具简单得多。",[15,293,294],{"id":294},"一个判断",[11,296,297],{},"关键 CSS 内联适合首屏简单、样式集中的页面，比如官网首页、落地页、文章页。",[11,299,300],{},"对于交互复杂、首屏依赖大量组件样式的应用，内联效果有限，优先做代码分割和延迟加载。",[11,302,303],{},"这件事的收益在几百毫秒量级，不是决定性的。但如果首屏本来就卡在 3 秒附近，这半秒能把它推进合格线。",{"title":111,"searchDepth":112,"depth":112,"links":305},[306,307,308,309,310,311,312],{"id":226,"depth":112,"text":227},{"id":236,"depth":112,"text":237},{"id":249,"depth":112,"text":249},{"id":261,"depth":112,"text":261},{"id":273,"depth":112,"text":273},{"id":285,"depth":112,"text":285},{"id":294,"depth":112,"text":294},"2026-07-13","CSS 阻塞渲染，把首屏样式内联进 HTML 能提前首屏时间。这篇写关键 CSS 怎么抽、四 KB 上限怎么守、剩余样式怎么异步加载，以及三个常见坑。",{},"\u002Fblog\u002Fcritical-css-inline",{"title":218,"description":314},"blog\u002Fcritical-css-inline",[320,321,322],"CSS","首屏","渲染阻塞","c-tCZfv_1AUt31w50m8PKisGInsNDJh5oIB0kZcXigI",1794088103883]