为什么你的图片SEO只做Alt是不够的

图片SEO只写Alt远远不够：Alt只能帮助搜索引擎理解图片内容，但谷歌图片排名还依赖文件名、上下文内容、结构化数据、图片尺寸、加载速度等20+因素。例如研究显示，页面相关文本与图片主题匹配度可影响约30%的图片排名权重。只有同时优化Alt、文件名、压缩速度和页面语义，图片才更容易获得稳定流量。

页面语境比 Alt 更重要

Google 识别图片时，不只看 Alt；它会一起看页面正文、标题、图片附近文字，以及整页主题。 Google 官方文档写明，系统会结合 alt text、计算机视觉和 page contents 来理解图片内容；Alt 还要求“放在页面内容语境里”写，而不是单独堆词。

图片先属于“页面主题”

用户进入页面时，先接触到的通常不是图片的 Alt，而是搜索结果标题、URL、页面首屏文案、产品名、价格、参数、目录导航、图片前后的解释句。Google 对图片的理解也不是只读一个字段。Google Search Central 公开写明，系统会结合 alt text、computer vision algorithms、page contents 一起理解图片；Google 的技术写作文档也要求 Alt 必须放在页面语境里写。

把一张图单独拎出来看，信息量常常只有 10 到 25 个词；放回页面里，周围再加上标题、规格、图注、列表、对比数据，语义范围会一下扩到 100 到 300 个词。用户读图也是这个顺序：先知道页面在讲什么，再判断这张图在这一页里负责哪一部分说明。对搜索引擎也是一样，图片先被归到页面主题里，再被细分到图片描述层。

同一张图，放在不同页面里，搜索含义会变。一张黑色跑鞋侧面图，如果页面标题是 “best trail running shoes for wet weather”，正文里出现 4 mm lugs、heel drop 6 mm、grip on wet rock、tested over 120 km，那这张图会被理解为越野抓地和湿滑场景的一部分。

如果同一张图放到 “men’s black sneakers under $120”，周围文字改成 size 9–12、leather upper、office casual、free shipping，这张图就更接近商品样式、价格和穿搭用途。图没有变，页面主题变了，用户读到的用途也变了。

很多页面的问题不在 Alt 缺没缺，而在页面只给了图片 1 个弱提示，没有给出足够的上下文。常见情况是：H1 只有品牌名，首段只有 20 到 40 个词，图前后没有说明句，一页塞了 12 张图但没有单独对应的参数或场景描述。用户要靠猜，搜索引擎也要靠猜。Google 官方建议一直在强调：用文本帮助系统理解非文本内容，复杂图片要在 surrounding text 里补充说明。

页面里每个元素承担的任务并不一样，Alt 只负责其中一小部分。下面这种分工更贴近用户阅读路径：

• Title 往往控制在 50–60 个字符，先告诉用户这一页卖什么、测什么、比什么

• H1 再用 6–12 个词把主题说完整，比如型号、用途、场景、年份

• 图片前一句解释常见在 20–40 个词之间，负责交代这张图为什么放在这里

• 图注一般 8–20 个词，负责说明角度、部件、步骤编号、对比对象

• Alt 多数情况下 5–16 个词就够，负责替代图片本身，不负责承包整页信息

这样分开写，用户扫读 5 秒内就能抓到主题、对象、用途、参数位置。Google 文档也明确建议：Alt 要简洁；复杂图片的更多内容放在文档里，而不是全塞进 Alt。

看两个写法差别会更清楚。

页面 A：H1 是 “Summer Collection”，正文只有 “Our latest collection is here”，图片 Alt 写 “woman holding bag”。这一组信号里，用户只拿到季节、人物、包，缺少材质、尺寸、适用设备、价格带、闭合方式、肩带长度。

页面 B：H1 写 “Best leather tote bags for 15-inch laptops”，图片上方一句写 “Fits a 15-inch MacBook, 13 cm base width, full-grain leather, zip closure”，图注写 “Side view showing padded sleeve and opening width”，Alt 写 “brown leather tote bag with padded laptop sleeve”。用户在 3 到 4 处位置里一次读到 6 类信息，搜索引擎拿到的也是整页一致语义。

用户看商品图、评测图、步骤图、对比图时，想知道的内容很少会只靠一行 Alt 解决。更常见的是下面这几类问题：

• 这张图对应哪个型号，1 代还是 2 代

• 图里看到的是正面、侧面、背面，还是拆解状态

• 尺寸单位是 cm、inch 还是 liters

• 拍摄条件是什么，室内 300 lux 还是日光环境

• 图表的时间范围是 30 days、12 months 还是 5 years

• 样本量是多少，n=12、n=87 还是 3,000 reviews

上面任意一项没写，用户都得额外判断一次。把它们放进正文、图注、表格，比硬塞进 Alt 更符合阅读习惯。W3C 对复杂图片的建议也是两段式处理：短替代说明加长描述，长描述要写出数值、关系、图例、区域和趋势。

很多编辑在写图时会把 Alt 当成主战场，于是一行里塞进 20 到 35 个词，连续写颜色、材质、地点、用途、品牌、风格。结果用户看不到，屏幕阅读器体验也变差，搜索引擎得到的仍是一段脱离页面的短描述。Google 技术写作文档反而建议 Alt 应该围绕图在当前文档里的用途来写，避免重复 surrounding text，也不要把整张图的全部背景资料压进去。

更实用的做法，是先补页面语境，再写 Alt。顺序可以按下面来排：

• 先给每张重要图片前面补 1 句解释，控制在 20–40 个词

• 再补图注，写清角度、步骤号、比较对象、可见结构

• 再在段落里加 2 到 4 个硬信息，比如尺寸、重量、时间、价格、版本

• 最后再写 Alt，只保留用户在图片失效时最需要的替代信息

这套顺序对产品页、评测页、教程页都适用。因为用户先靠页面建立主题，再靠图片验证细节，不会反过来先靠 Alt 建立主题。下面这组信息放在页面里，比放在 Alt 里更合适：

• 规格：32 oz、1.2 kg、15-inch、IP68、3200 mAh

• 时间：tested for 14 days、2024 model、updated in January 2026

• 条件：room temperature 22°C、50% screen brightness、EU size 42

• 比较：12% lighter than previous model、2 cm wider opening、3 dB quieter

• 范围：available in sizes 7–13、map covers 5 boroughs、chart spans 2019–2025

用户看到数字后，理解速度会快很多，因为数字会把图片和页面主题锁到更具体的查询里。搜索引擎读取时也更容易把图和特定实体、规格、时间范围对应起来。Google 对 image SEO 的公开文档也提到，优化 image landing pages、让页面本身可理解，是图片出现在搜索结果里的重要部分。

一页里有多张图时，页面主题还会决定每张图的分工。

一篇 1,800 词的跑鞋评测，如果有 6 张图，合理分法通常是：1 张外观总览、1 张中底剖面、1 张鞋底纹路、1 张鞋楦宽度对比、1 张实跑场景、1 张重量或回弹图表。每张图前后各给 30 到 80 个词的解释，用户在整页里能建立连续阅读路线。

如果同样 6 张图没有顺序，只是图库式堆放，哪怕 6 条 Alt 都写满，页面也像被拆成 6 个孤立片段。

从无障碍角度看，页面语境也比单行 Alt 更贴近真实使用。Google、W3C、Section 508 的指导都在强调：装饰图可以用空 Alt，信息图和复杂图要提供文档内说明；否则用户只能听到一个短标签，却拿不到关系、数值和用途。对于带图表、地图、流程图的页面，周围正文写到 80–150 个词并不算多，很多时候这是最低可读量。

写作时可以做一个很简单的检查：临时忽略 Alt，只看图片前后 100 到 200 个词。如果用户还能回答出 3 个问题——这是什么图、它在解释哪件事、它和本页主题的关系是什么——页面语境通常就够用了。如果答不上来，优先补页面文字，不要先改 Alt。因为图片先被读成页面的一部分，之后才被读成一行描述。

页面元素分工

一张图片出现在页面里，用户读到的不是一个字段，而是一串排好的信息。搜索结果里先看到的常是 title link，进入页面后先读 H1、导语、目录、价格、规格，再看图片附近 20–80 词的说明，最后才轮到图片本身。Google 对页面的读取也不是单点识别。官方文档写明，图片理解会结合 alt text、computer vision algorithms、page contents；title link 也会从多个来源生成，用来帮助用户快速了解结果内容。

把页面元素拆开看，分工很清楚：title 负责把页面放进一个更大的主题框架里，H1 负责把主题说完整，正文负责交代场景和限制条件，图注负责说明这一张图在当前段落里承担什么信息，Alt 负责在图片不可见时补一条简洁替代说明。Google 的技术写作文档明确建议，Alt 应该简洁；复杂图片的更长解释应放在 surrounding text 里，而不是把所有背景资料塞进 Alt。W3C 对复杂图也采用两段式处理：短替代说明加页面内长描述。

下面这张表更适合落地页写作时对照。用户能看到什么、搜索引擎能读到什么、每个元素覆盖多大范围，差别都很明显：

Google 公开说明里提到，structured data 能帮助系统理解页面内容；title link 又是用户在结果页第一眼接触到的文字；图片页优化不仅包括图本身，也包括 image landing page。把这三件事放一起看，页面元素不是平行关系，而是有先后顺序：先让页面被理解，再让页面里的图片被细分理解。

对用户来说，title 和 H1 解决的是“我来对地方了吗”。对图片来说，图注和 Alt 解决的是“这张图具体在说什么”。

两类元素的信息密度不同，承担的任务也不同，混着写通常会出问题。比如一个商品页把 H1 写成 “Spring Edit”，图片 Alt 写成 “black leather tote bag with zipper, padded sleeve, 15-inch laptop compartment, gold hardware, adjustable strap, everyday commute use”。用户在结果页根本看不到 Alt，页面标题又没有说清商品类型、用途、尺寸兼容，结果主题入口很弱，Alt 再长也补不上前面的缺口。

如果把同一页改成另一种分工，信息会整齐很多。

<title> 写 “Best leather tote bags for 15-inch laptops | 2026 guideH1 写 “Leather tote bags that fit a 15-inch laptop”

图片前一句写 “The photo below shows the base width, zip opening, and padded sleeve clearance with a 15-inch MacBook.”

图注写 “Top opening and laptop sleeve depth”

Alt 写 “brown leather tote bag with zip opening and padded laptop sleeve”

用户在进入页面后的前 5–8 秒里，就能拿到用途、设备兼容、部件、拍摄角度 4 类信息。Google 的图片文档把这种做法归到页面内容与 surrounding text 的共同作用里。很多内容团队把页面元素用反了，最常见有 3 组问题：

• title 只有品牌名或栏目名，少了产品、用途、版本、年份

• H1 太宽，像 “Running Shoes” 或 “Travel Tips”，用户和搜索引擎都拿不到边界

• Alt 太长，像把图注、正文、参数、卖点全部折叠成一行

W3C 的 alt 指南强调，Alt 是“最简洁且能表达图像目的”的文本；如果超过短语或短句，就应该考虑把细节移到正文里。Google 的技术写作指南也给出相同方向，复杂图表、流程图、地图应在文档中解释图例、区域、步骤和上下文。

页面元素分工写得清楚，对不同内容类型的帮助很明显。下面按页面类型拆一下更方便：

• 商品页：title/H1 负责品类、型号、尺寸兼容；正文和表格负责材质、重量、价格区间、配送信息；图片前一句负责角度与用途；Alt 只保留图中可见对象和必要部件。

• 评测页：title/H1 负责测什么、测谁、时间版本；图表附近正文负责样本量、测试条件、单位；图注负责指标名；Alt 不承担完整测试方法。

• 教程页：H2 或步骤标题负责步骤序号；图片前一句负责“当前步骤在做什么”；图注负责工具或部件位置；Alt 只描述当前画面。

• 地图/信息图：标题负责区域和主题；正文负责时间范围、图例、数据来源；图注负责图层或颜色说明；Alt 只做简要说明，长描述必须写进页面。

• 新闻或事件页：title 负责对象、地点、日期；正文负责背景、时间线、数据点；图片前一句负责说明图与事件的关系。

Google 的图片文档把“optimize the image landing pages”列为单独一项，W3C 也把图表、地图、流程图归为 complex images，需要在页面中补全信息。页面元素如果不分工，复杂图最容易变成信息缺口。

用户扫读页面时，表格和列表往往比长段落更快。对图片 SEO 也是一样，很多信息更适合放进表格而不是 Alt：

Google 还单独提供 image metadata 指南，说明在 Google Images 中可以展示创作者、版权、许可等信息；结构化数据文档也说明这类标记可帮助系统理解页面内容。也就是说，页面元素不仅分“用户看得到”的文本，还分“系统读得到”的元信息。两边一起补，信息会更完整。

再往细一点看，某些元素承担的是“减少误解”的任务。例如 title 里加上年份 “2026 guide”，可以把旧版本和新版本分开；图表上方写 “battery test at 50% brightness, Wi-Fi on”，能避免用户把续航数字看成实验室极限值；图片前一句里写 “rear seat legroom with a 180 cm adult in the front seat”，能让车内空间图从“看起来挺大”变成有参照对象的说明。

这类信息通常只有 6 到 15 个词，但比把 Alt 从 12 词拉长到 28 词更有用。Google 与 W3C 都把“在页面中提供上下文”放在更靠前的位置。

从编辑流程看，写页面时更稳妥的顺序通常是：先写 title 和 H1，再补导语，再为每张重要图片写 1 句 20–40 词的前置说明，然后补图注和参数表，最后再写 Alt。这样做有两个好处。第一，Alt 不会被迫承担全页信息；第二，每张图都能和当前段落建立稳定关系。Google 的搜索文档把搜索友好内容定义为能帮助更相关用户找到页面的内容，title link 又承担结果页入口作用，把前面的主题框架搭好，后面的图像字段才不会漂在空中。

做检查时，可以把页面元素按“整页、段落、单图”三层来验收。整页层看 <title>、H1、导语，确认对象、用途、版本、年份是否齐全；段落层看图片前后的 40–120 词，确认场景、参数、限制条件是否写了；单图层看图注和 Alt，确认角度、部件、步骤号、可见对象是否够用。

如果一个问题本应由整页层解决，却被塞给 Alt，页面通常会读起来很挤，图也不容易被准确理解。Google 和 W3C 的公开文档给出的方向，都是把信息分配到最适合它的页面位置。

先补“语境缺口”，再写 Alt

很多页面把顺序写反了：先给每张图补一行 Alt，正文还是空的，图前后没有解释句，H1 也只写到大类词。Google Search Central 对图片的说明不是“只要写 Alt 就够”，而是会结合 alt text、computer vision algorithms、page contents 一起理解图片；Google 的技术写作文档也要求 Alt 要“放在上下文里解释”，复杂图片的更多信息应写在 surrounding text 里。W3C 对图表、地图、流程图的建议同样是两段式：短 Alt 加页面内长描述。

“语境缺口”通常出现在 4 个位置：页面标题太宽，首段太短，图片前没有一句说明，图片后没有参数或图注。用户进入页面后的前 5 到 8 秒，常先扫标题、导语、价格、目录、表格，再决定要不要看图；如果前面 80 到 150 个词没把对象、用途、限制条件写清，图片就像被单独扔在页面里。Alt 再完整，也只能补到图片本身，补不到页面为什么放这张图。Google 文档把 “optimize the image landing pages” 单列出来，原因就在这里。

先补语境时，最省力的一步，不是改 Alt，而是给每张重要图片前面加 1 句解释。
这一句控制在 20 到 40 个词，回答 3 个问题里的 1 个就够：

• 这张图展示哪一部分

• 这里为什么要放它

• 用户应该从图里看到什么

像 “The photo below shows heel collar padding and rear-foot lockdown.”或 “This chart compares annual energy cost across three 9 kW heat pump setups.”这类句子给用户的是用途和视角，给搜索引擎的是 surrounding text。Google 风格指南还建议在图片前用完整句子引入，而不是只扔一张图。

第二步是补图片附近的硬信息。如果页面里出现的是商品图，用户通常会找尺寸、重量、容量、兼容设备、材质、价格区间；如果是评测图，用户会找测试条件、样本量、单位、版本号、日期；如果是教程图，用户会找步骤号、工具、操作方向、前置条件。把其中 2 到 4 个数据点写在图前或图后，信息量会比把 Alt 从 10 个词拉到 28 个词更高。

W3C 的复杂图片教程要求，图表和地图要把数据关系、图例、区域说明写在页面里，不要指望一条短替代文本承载全部信息。

下面这张表适合拿来当写作顺序的模板：

Google 对 Alt 的建议是“helpful alt text”，不是“把所有相关词都写进去”；Google 技术写作文档也写得很清楚：复杂信息应该放在文档正文里。

按页面类型看，语境缺口出现的位置也不一样。商品页常缺型号、容量、兼容性；评测页常缺测试条件和样本范围；教程页常缺步骤顺序和工具名称；地图或信息图常缺图例、地理范围、时间区间。W3C 的 alt 决策树把“复杂信息图”单独拿出来，要求把图里的信息放到页面其他位置；Google 的可访问性课程也在讲同一件事：Alt 必须结合文档用途来写。

看一组写法差别，会更明显。

原稿写法：H1 是 “Winter Jackets”，图前没有说明，Alt 写 “black waterproof men’s jacket with hood and zipper pockets”。

补语境后的写法：H1 改成 “Men’s waterproof winter jackets for below-freezing commutes”，图前一句写 “The image below shows hem length, cuff seal, and front pocket depth in size M.”，图后列表补 3 项：10,000 mm waterproof rating、680 g in size M、fits layers up to 2.5 cm mid-layer thickness。

用户从页面拿到的是用途、天气、尺码、可见部件、数值条件 5 类信息；Alt 只需保留 “black men’s waterproof hooded jacket with zip pockets”。Google 与 W3C 都建议用页面文本承载复杂说明。

再看图表页。原稿常写成：Alt = “chart showing battery life comparison”。这行字对用户几乎没帮助，因为少了设备、测试环境、亮度、网络状态、样本数量、时间单位。

更合适的页面写法是：图上方一句写 “Battery runtime test at 50% brightness, Wi-Fi on, room temperature 22°C.”，图下注明 “Average of 3 full runs per device.”，表格再列出 4 台设备与结果：12.4 h、11.1 h、9.8 h、8.7 h。Alt 只写 “bar chart comparing battery runtime across four phones”。

W3C 对复杂图的要求，正是把关系、数值、单位写到页面里。

实际改稿时，可以先查 3 个位置，不要先碰 Alt：

• 图片前 40 个词里，有没有说明“这一张图在展示哪一部分”

• 图片后 80 个词里，有没有至少 2 个数字、单位、时间或条件

• 同段落里，有没有实体词：品牌、型号、地点、版本、材料、尺寸

如果 3 项里只满足 0 到 1 项，页面多半存在语境缺口。Google Search Central 把帮助搜索引擎“理解内容”放在 SEO 基础文档里，非文本内容尤其依赖文本补充。不少编辑会把“语境补充”理解成再写一段泛泛的修饰句，结果字数增加了，信息还是薄。更有效的补法是把抽象词换成可验证信息。

把 “high performance outsole” 改成 “4 mm lugs with wider spacing for wet dirt and loose gravel”；
把 “spacious rear seat” 改成 “rear knee room shown with a 180 cm adult in the front seat”；
把 “large tote bag” 改成 “fits a 15-inch laptop, 13 cm base width, zip opening at 39 cm”。

装饰图与信息图还要分开处理。Google 风格指南写到，纯装饰图片可以用空 Alt；W3C 的决策树也给出同样判断。页面里如果有 12 张图，其中 4 张只是背景纹理、分隔线、氛围图，就不该给它们写 12 条冗长 Alt。把精力放到剩下 8 张真正承载信息的图片上，更符合可访问性写法，也更符合搜索引擎读取逻辑。

下面这一组内容，更适合优先补到页面语境里，而不是 Alt 里：

• 版本：2024 model、v2、third-generation、updated February 2026

• 条件：50% brightness、22°C、EU size 42、tested over 120 km

• 范围：sizes 7–13、map covers five boroughs、data from 2019–2025

• 对比：12% lighter、2 cm wider opening、3 dB quieter

• 来源：manufacturer spec sheet、lab run, n=24、retail list price on March 10, 2026

用户看见数字和条件，能更快判断图片是否与自己有关；搜索引擎也更容易把图和特定查询对应起来。W3C 把“完整文本等价物”用于复杂图片，Google 把“page contents”纳入图片理解范围，说的是同一套逻辑。

做检查时，可以临时把 Alt 蒙住，只看图片前后 100 到 200 个词。如果用户还能回答出 3 件事——图里是什么、它在说明哪一部分、这和本页主题是什么关系——语境通常已经补够。如果答不上来，优先补标题、解释句、图注、参数，不要先把 Alt 从 12 个词改成 26 个词。

图片可抓取与可索引

很多页面写了 Alt，图片还是没有进入图片搜索，问题通常不在文案，而在抓取链路。图片 URL 要能返回 200，HTML 里要有可解析的 <img src>，资源不能被 robots.txt 阻拦，重要图片不能等用户点击后才加载。Google 也说明了：它能从 <img> 的 src 发现图片，不会索引 CSS 背景图；图片站点地图可以补充发现路径，但提交后也只是提示，不等于一定收录。

解决“抓不到”

很多站点的问题不是图片质量差，而是搜索引擎一开始就没有发现图片文件。Google 的图片文档写得很明确：更容易被发现的是 HTML 里的 <img src>，而不是 CSS background-image；图片站点地图可以补充发现路径，尤其适合 JavaScript 才能触达的图片。也要注意，Google 不保证一定抓取、索引或展示某个资源，所以前面的发现路径越清楚，后面的处理越稳定。

先看页面结构。用户在浏览器里“看得到”，不代表抓取系统“找得到”。产品页首屏放了 6 张图，如果源码里只有 1 个 <img>，其余 5 张做成背景层、伪元素或点击后注入，搜索引擎一开始能拿到的通常只有那 1 张。Google 公开说明里提到，不要把重要文本放进图片里，同时也说明要用标准 HTML 图片元素帮助发现；反过来看，图片本身若都不在可解析结构里，Alt、标题、文件名都没有施展空间。

可以先按这组方式做首轮排查，10 分钟内就能发现大半问题：

• 查看源码，确认重要图片有真实 src

• 检查首屏前 3–5 张 图是否都在初始 HTML 中

• 抽查图片 URL，确认返回 200

• 看资源是不是走了 2 次以上 跳转

• 看图片域名是不是单独 CDN 子域

• 检查该子域是否也放了 robots.txt

• 抽 20 张图，看是否有 403、404、429、5xx

• 看图库、轮播、弹窗里的图是不是点开后才生成节点

这一轮做完后，下一步要看阻拦规则。robots.txt 控制的是“能不能抓”，不是“能不能索引页面”。Google 在 robots 文档里写明，robots.txt 用来告诉爬虫哪些 URL 可以访问；而如果要让页面不进入 Google，应该用 noindex 或权限控制，不是只靠 robots.txt。放到图片上也一样：图片文件被 robots.txt 拦住，Google 就拿不到资源；页面没被拦，也不代表图片能进图片搜索。

最容易漏的地方不是主站目录，而是图片实际托管位置。很多站把图片放在 cdn.example.com、对象存储域名，或第三方图像处理域名。页面本身的 robots.txt 没有限制，但图片子域的 robots.txt 却把 /media/、/uploads/、/img/ 封掉了。结果是页面 URL 正常被抓，图片 URL 一张都拿不到。排查时要记住一点：robots 规则看的是“图片实际所在主机”，不是文章页所在主机。

下面这张表更适合放进正文，用户读一眼就能知道先查哪里：

结构和规则查完后，还要看访问稳定性。很多图片 URL 并不是永久地址，而是带签名、带时间戳、带授权参数的临时链接，可能 30 分钟、2 小时、24 小时 后失效。用户第一次打开页面能看到，是因为当时签名还有效；Google 稍后重新抓取图片时，返回的可能已经是 403。页面抓取得再勤，也救不了会过期的图片地址。对商品图、案例图、教程步骤图，文件 URL 最好保持长期稳定，至少不要让主要图片依赖短期签名。

这里不需要猜，抽查 15–20 张重要图，看 URL 里有没有明显的 token=、expires=、signature=，通常就能判断。

这时再往下看服务器策略。Googlebot 文档说明，Google Search 主要有 Googlebot Smartphone 和 Googlebot Desktop 两类爬虫；如果站点按 User-Agent、地区、请求头、来源域来做限制，图片服务器有可能把正常浏览器放行、把搜索引擎请求挡住。文档还提醒站长，User-Agent 很容易被伪造，判断是否来自 Google 最稳的方式是反向 DNS 或匹配 Googlebot IP 范围。

可以把服务器侧问题压缩成两列来检查：

“页面可以打开” 和 “图片资源可被 Googlebot 访问” 不是一回事。
Google 建议验证 Googlebot 身份，而不是只凭 User-Agent 判断。

• 防盗链只允许浏览器，不允许搜索引擎

• WAF 把高频抓取当异常流量，返回 429 或 403

• 对象存储桶未公开读取

• 图片请求按国家或地区限制访问

• CDN 回源失败时返回空白占位图

• 图片响应头与真实格式不一致，处理链条出错

文件能访问之后，还要补发现入口。Google 在图片站点地图文档里写到，image sitemap 适合告诉 Google 那些“否则可能发现不到”的图片，尤其是通过 JavaScript 才能触达的资源；同时每个 <url> 节点最多可以包含 1,000 个 <image:image> 标签。对于产品变体页、案例图库页、房产列表页、旅游图库页，一页挂 20–80 张 图片很常见，只靠页面自然发现，漏图概率会升高；把重要图片写进 sitemap，至少多一条可追踪的提交路径。

这里也要控制预期。Google 的“搜索如何运作”文档说得很清楚：即使页面符合 Search Essentials，Google 也不保证一定抓取、索引或展示。Sitemap 的作用是帮助理解站点 URL 和更新时间，不是提交后立刻收录。

把前面内容落到用户最常见的 3 类页面，会更容易执行：

• 电商页：主图在 <img> 里，变体图、细节图、尺寸图也要有稳定 URL

• 案例页：不要只放轮播封面，至少让前 4–6 张 图在 HTML 中可见

• 博客页：正文插图不要全做背景层，信息图、步骤图、前后对比图要能单独抓取

给一个更实用的判断方法。抽样 30 个 重要页面，如果其中 20% 以上 的图片 URL 返回非 200，或 30% 以上 的首屏图片不在源码里，图片“抓不到”通常已经不是单页问题，而是模板、CDN 或 robots 配置问题。先把这层修好，后面再改 Alt、文件名、标题，数据才更容易往前走。

解决“读不全”

很多页面里的图片不是“没有上传”，而是搜索引擎在渲染阶段没有读到完整资源。页面首屏看起来有图，源码里却只有占位容器；浏览器滚动后用户能看到第 2 张、第 3 张图，抓取系统却只拿到第 1 张。Google 处理页面时会先抓 HTML，再进入渲染队列，渲染不是无限执行，页面里每多一层脚本、多一次异步请求、多一个交互条件，图片被完整读取的概率就会下降。对图片页、产品页、案例页来说，前 3–8 张图通常决定图片搜索里能留下多少有效资产。 先看最常见的读取不完整场景。很多前端框架会把真实图片地址放在 data-src、data-original、data-lazy 里，而初始 src 只给一张 1×1 占位图，大小可能只有 43B 到 200B。用户滚动后脚本再替换成真实地址。浏览器能执行，用户也能看见，但如果抓取器拿到页面时还没有触发替换，索引层读到的只是占位资源。 还有一类页面会把图片放进轮播组件，首张图进 DOM，后面 5 张图等“下一张”按钮触发后才插入节点，结果页面明明有 6 张产品图，搜索引擎实际只看到 1 张。 可以先用这组检查方式判断页面是不是“读不全”：

• 打开页面源码，看首屏重要图片是否已有真实 img src
• 关闭 JavaScript 后刷新，看页面是否仍能看到前 1–3 张主图
• 检查图片标签里是否只保留占位地址，真实 URL 被塞进自定义属性
• 看轮播、瀑布流、图库组件是否要点击、切换、展开后才插入图片节点
• 查看首屏请求数量，首屏如果同时发出 80–150 个请求，渲染压力会明显上升
• 抽查图片 URL 返回码，确认不是 302 多跳转后才到文件

先把“用户能看到”和“源码里已存在”分开看，后面的排查才不会跑偏。页面展示正常，不等于抓取阶段已经读到全部图片。尤其是移动端，网络更慢、资源裁剪更多，同一页面在桌面端可读 8 张图，在移动端可能只读到 2–3 张。 读取不完整经常出现在懒加载配置上。懒加载本身没问题，问题在于把“延迟下载”做成了“延迟出现”。更稳的做法是：图片元素一开始就在 DOM 里，浏览器接近视口时再发起请求；风险更高的做法是滚动到某个位置后，脚本才新建整段 HTML，把图片节点插进去。前者是已有节点延后下载，后者是连节点都晚出现一步。对搜索引擎来说，差别不小。 下面这组情况更容易让图片读不全：

• 首屏主图使用懒加载，进入页面后 1–2 秒 仍未发起图片请求
• 图片依赖 IntersectionObserver，但触发阈值设得过晚，如滚动 800px 后才开始加载
• 轮播图后续图片按点击事件加载，不是按 DOM 预置
• 产品变体图切换颜色后才请求文件，默认状态只输出 1 个变体
• Masonry 或瀑布流列表滚到第 2 屏后，前端才一次性插入 20 张图
• 弹窗、灯箱、手风琴折叠区域里的图片，默认不进 DOM

而更容易被完整读取的写法通常长这样：

• 前 3–5 张重要图都在初始 HTML 里
• src 里放真实文件地址，loading="lazy" 只控制时机
• 轮播后续图片虽然屏幕未展示，但节点已存在
• 移动端和桌面端都输出同一套主图资源，不临时改路径
• 缩略图与大图关系清楚，避免一个点击动作才出现全部内容
• 图片附近有文字说明，不让页面变成“只有图层，没有语义”

懒加载之后，另一个影响读取完整度的点是资源优先级。浏览器同一时刻能并行处理的资源有限，页面如果先请求 10 个脚本、6 个字体、4 段追踪代码，再去请求首图，图片读取就会往后排。尤其在产品页首屏里，主图文件如果做到 400KB–900KB，同时还叠加 WebP 回退、变体切换、放大镜脚本，首次可读取时间会明显变长。页面性能报告里常见的 LCP 图片，很多就是这一张首图。 排查时可以把资源按优先顺序拆开看：

• 首图文件体积是否压到 100KB–250KB 区间内
• 首屏是否引用了 3 个以上外部脚本域名
• 字体、聊天插件、热图、A/B 测试脚本是否抢在图片前面执行
• CSS 是否阻塞了首图容器渲染
• 图片是否走了 2 次以上跳转，例如 CDN 签名跳转、尺寸适配跳转
• 同一屏里是否一次放了 12 张以上缩略图，挤占请求队列

当资源调度合理后，还要检查移动端是否给了另一套“简化版结构”。很多站点会在桌面端输出完整图库，移动端只保留 1 张主图，把其余图片放进滑动组件或折叠层。Google 以移动优先方式处理页面时，拿到的是移动端版本，桌面端那 8 张图写得再完整，也不能弥补移动端只给 1 张的缺口。实际项目里很常见的情况是：桌面端产品页有 6–10 张 细节图，移动端源码只保留 2 张，其余交给脚本动态追加。 可以把桌面端和移动端对照检查一遍：

检查项	桌面端常见表现	移动端常见问题
主图数量	4–8 张	只剩 1–2 张
节点输出	页面初始即存在	滑动后才插入
文件地址	固定 URL	改成临时参数 URL
图文关系	图下有型号、材质、尺寸	说明被折叠进标签页
变体图	默认输出全部缩略图	点击颜色后才加载

这一层处理完，还要看图片是不是被其他界面组件遮住了读取路径。常见例子包括标签页、折叠面板、评论弹窗、FAQ 手风琴、AJAX 加载分页。用户点一下可以展开更多内容，搜索引擎未必会模拟完整交互。页面设计里只要出现“点击后才出现”，都应该先假设该部分存在读取损耗，再决定要不要把重要图片放进去。产品细节图、安装步骤图、前后对比图，不适合全部塞进交互后区域。 下列组件要特别留意：

• 标签页：第 2、3 个 tab 内图片默认不渲染
• 手风琴：折叠状态不输出图片节点
• 弹窗图库：只在点击缩略图后创建大图
• 无限滚动：第 2 页内容不提供可分页 URL
• AJAX 分类筛选：切换条件后图片路径变化，但无稳定链接
• 评论区晒图：登录、点击“显示更多”后才请求图片

再往下看，文件本身也会造成“读不全”。文件格式受支持，不代表读取稳定。带签名的临时 URL 过期时间如果只有 5 分钟或 30 分钟，抓取后重新请求时可能已经失效；防盗链如果只允许浏览器来源，不允许搜索引擎抓取器来源，请求就会返回 403；某些图床会根据 User-Agent 返回不同内容，桌面浏览器看到的是正常图，抓取器拿到的却是空白文件或压缩失败版本。页面里写对了 img src，资源层照样会把读取截断。 针对文件层，建议至少检查下面 8 项：

• 返回码是否稳定为 200，而不是偶发 403、429、503
• 文件 URL 是否长期有效，不是几小时后过期的签名地址
• CDN 是否允许搜索引擎抓取，而不是只对白名单浏览器放行
• WebP、AVIF、JPEG 回退链条是否正常
• 响应头里的 Content-Type 是否与文件真实格式一致
• 图片请求是否被防盗链规则挡住
• 单张原图是否过大，超过 1MB 还未压缩
• 同一图片是否频繁换 URL，导致历史抓取记录失效

内容层也会影响读取后的处理结果。搜索引擎不是只下载文件，还会结合页面上下文判断这张图值不值得继续保留在索引候选里。图片周围如果没有商品名、部件名、使用场景、尺寸信息，系统即使读到了文件，也很难把它和页面主题稳定对上。一个产品页放 7 张图片，其中 5 张文件名是 IMG_001.webp、banner-2.jpg、new-photo-final.png，正文又只有 80 个词，后续处理就容易变弱。 页面里至少要把图和文字绑在一起：

• 主图旁边写清产品名、系列名、规格
• 细节图附近写材质、接口、尺寸、使用位置
• 步骤图配 1 句动作说明，不只放视觉画面
• 对比图标明前后版本、测试条件、时间范围
• 缩略图与大图使用一致的命名逻辑
• Alt 不要和标题、标题不要和正文完全断开

再往前一步，站点如果图片很多，最好不要把“完整读取”完全交给页面发现。产品库、案例库、教程库里常见一个页面挂 20–60 张图，仅靠自然抓取路径不稳定。把重要图片放进 image sitemap，至少能给搜索引擎额外一条发现入口。对于图库页、SKU 变体页、案例集合页，这种补充比单纯补 Alt 更有效。因为 Alt 发生在“已发现图片”之后，而 sitemap 发生在“帮助发现图片”之前。 看一个更贴近日常运维的判断标准。抽 30 个重要页面，如果其中有 10 个页面的首屏主图在源码里不是最终 URL，有 8 个页面的轮播后续图要点击才出现，有 6 个页面的移动端主图数量少于桌面端一半，那图片“读不全”已经不是单页问题，而是模板问题。模板一改，几十页到几千页会一起改善；模板不改，只补单张图片的 Alt，页面外观看上去更新过，抓取结果通常不会同步变好。

解决“收不收”

图片被发现，也被读取，不代表一定会进入索引。Google 在“搜索如何运作”文档里写得很清楚：即使页面符合 Search Essentials，也不保证一定会被抓取、索引或展示。放到图片上也是同样逻辑，进入索引前还要经过处理、理解、去重、质量判断、页面语义匹配几层筛选。很多站点的问题就出在这里：文件能访问，页面也能打开，但图片仍然没有进入图片搜索候选。

先看页面和图片之间的关系。Google 在图片最佳实践里提到，搜索系统会从页面内容中提取图片主题信息，包括图片附近的文字、标题、说明、文件名、Alt 等信号，并建议把图片放在与图片主题相关的页面上。换句话说，一张图如果放在主题模糊、正文很短、附近没有说明的页面里，即使资源本身没问题，也更难被稳定理解。产品页里常见的情况是：页面只有 80–150 个词，图片文件名还是 IMG_2048.webp，图下没有型号、尺寸、材质，系统拿到的信息就很有限。

可以先按这组标准看页面质量信号是不是够用：

• 图片附近是否有商品名、部件名、场景词

• 页面标题是否和图片主题一致

• 文件名是否可读，而不是随机编号

• Alt 是否描述图片内容，而不是堆砌词

• 图下是否有 1 句以上说明

• 同页图片数量是否过多，出现 20–50 张 高度重复图

• 页面正文是否短到只有几行

• 图片是否出现在一个与主题不相关的聚合页里

页面语义看完后，要看重复度。Google 图片系统不会把站内每一张相似图都当成独立资产处理。一个商品有 12 张图，如果其中 8 张只是同角度、同背景、同尺寸裁切，系统更可能保留少数几张代表图，而不是把全部都放进索引。案例库、房源页、旅游图库、汽车目录页里很常见：同一组官方图在 5 个以上 URL 反复出现，页面标题变了，图本身没变。结果通常不是 5 个页面都各拿到完整图片可见性，而是搜索系统更偏向保留其中语义更清楚、权重更集中的那一版。

下面这个表，适合放进正文里做判断：

这一层之后，再看页面控制指令。Google 的 noindex 文档说明，noindex 用于阻止页面进入索引，而且要让爬虫能够访问到页面，Google 才能看到这条指令；如果页面被 robots.txt 挡住，Google 反而看不到 noindex。图片场景里经常出现两个误配：一类是页面带 noindex，站长却还希望该页图片参与图片搜索；另一类是页面开放索引，但图片目录被 robots.txt 拦住。前者会削弱页面整体进入索引的机会，后者会让资源本身拿不到。

可以把索引控制理解成这样：

“让页面不进索引”和“让图片不被抓取”是两套不同控制。
Google 说明，noindex 要在可访问前提下才生效；图片资源若被 robots 限制，搜索系统拿不到文件。

更细一点看，下面几种组合最容易出问题：

• 页面 noindex，图片还想进图片搜索

• 页面能索引，图片 CDN 被 robots 拦住

• 页面能抓，图片文件偶发 403/429

• 页面正文完整，但图片放在 iframe 或别的受限主机

• 页面改版后 URL 变了，旧图片路径全部失效

• sitemap 里还留着已删除图片链接

再往下是图片站点地图的作用边界。Google 的 image sitemap 文档写到，图片站点地图是告诉 Google 站内还有哪些图片，尤其是那些搜索系统“否则可能找不到”的图片，例如通过 JavaScript 才能到达的资源。文档还写明，每个 <url> 节点最多可放 1,000 个 <image:image> 标签。这条规则对大图库页、SKU 变体页、酒店图库页很有用，因为一页挂 30 张、80 张，甚至 200 张 图并不少见。

sitemap 能补发现入口，但它本身不等于收录保证，页面语义弱、重复度高、文件质量低的问题，sitemap 不会代替处理。

更适合执行的做法可以拆成两列：

• 把商品主图、案例主图、步骤图、对比图写进 image sitemap

• 让 sitemap 里的图片 URL 与页面实际输出一致

• 删除已下线资源，避免 sitemap 堆积失效链接

• 变体图很多时，优先提交有差异的图，不要把 20 张 几乎一样的图全塞进去

另一边也要同步处理：

• 同一图片不要在 10 个以上 URL 反复挂载

• 页面标题不要只写品牌词，缺少对象词

• 图集页不要只有图片墙，没有说明文字

• 首图和页面主题不要错位，比如正文讲 A，主图却是 B

然后要看图片本身是不是“值得留”。Google 图片最佳实践里建议使用高质量、清晰的图片，并让页面标题和描述能解释图片与查询的关系。这里的“高质量”不是只指分辨率大。站点里常见两种问题：一种是文件过小，缩略图只有 120px、160px、200px 宽，放大后信息量不足；另一种是文件虽然有 2000px，但水印过重、压缩过度、主体很小，图像本身可理解内容偏少。再加上同页重复图过多，系统就更可能只挑一两张。

在内容站、产品站、案例站里，更容易留下来的图片通常有这些特征：

• 主体明确，背景不抢信息

• 分辨率足够，但不是超大空白图

• 与页面主题一一对应

• 图旁有说明，不让搜索系统只看文件本身

• 同组图片在角度、部位、步骤上有差异

• 同一个对象不会只用 1 张模糊缩略图代表全部内容

还有一个经常被忽略的点，是页面是否真的提供“落地页价值”。Google 图片搜索展示的不是孤立文件，而是文件对应的网页结果。文档里提到页面标题、描述、结构化数据、图片周边文字都会帮助系统解释结果。也就是说，如果图片所在页面本身很薄，用户点击进去后只看到一张图和一行文字，系统对这类页面的保留意愿通常不会和内容完整的落地页一样。对产品页来说，至少要把型号、规格、材质、使用场景补齐；对教程页来说，步骤图最好一图一动作，旁边有说明；对案例页来说，前后对比、项目地点、施工类型、拍摄视角都要交代。

给一个更接近日常运维的筛查法。抽样 50 张 重要图片，分别看它们所在页面是否可索引、页面标题是否对得上图片主题、图旁是否有说明、同图是否在多个 URL 重复出现、该图片是否进了 image sitemap。如果其中有 15 张以上 出现在语义很弱的页面，有 10 张以上 属于重复图，有 8 张以上 不在 sitemap 里，图片“不收”通常就不是单个文件问题，而是模板、内容组织和资源管理一起造成的。

优化结构化数据

只写 Alt，搜索引擎通常只能知道“图里有什么”，但不容易判断这张图属于产品主图、文章首图、步骤图还是案例图。把 Product、Article、ImageObject、BreadcrumbList 等结构化数据补齐后，页面会多出品牌、价格、作者、发布时间、图片归属、层级路径这些机器可读信息，图片和页面主题的对应关系会更清楚，收录、图片匹配词、结果展示完整度也会更稳定。

把图片和页面类型对上

很多网站做图片SEO时，问题不在图片不清晰，也不在 Alt 没写，而在图片被放进了不合适的页面类型里。搜索引擎识别图片，不只看图像本身，还会看它所在页面属于产品页、文章页、教程页、案例页还是分类页。同一张 1600×1200 的图片，放在 Product 页面和放在 BlogPosting 页面，机器读取到的用途完全不同。 前者更容易被理解为商品主图，后者更容易被理解为内容配图。页面类型没对上，后面再补文件名、说明文字、ImageObject，也只是把错误页面里的图片描述得更详细。 先看一个最常见的误区。一个页面明明在卖产品，却套用了博客模板；首图很大，正文里有价格、参数、型号，但结构化数据输出的是 Article。用户读页面时能看出是产品介绍，搜索引擎读页面时却更像在读一篇资讯内容。这样一来，图片不会稳定地挂在商品实体上，而更像普通内容图。 反过来也一样，一篇安装教程如果套用 Product 标记，页面里 6 张步骤图、2 张工具图会被误读成商品配图，步骤关系会变淡。页面身份先错，图片角色就跟着偏。 可以先把常见页面类型和图片角色分开看：

页面类型	用户通常想看什么	图片更适合承担的角色	常见结构化数据
产品页	外观、细节、规格、是否可买	主图、细节图、尺寸图、包装图	Product、Offer
文章页	说明、对比、解读	首图、说明图、示意图	Article、BlogPosting
教程页	步骤、顺序、操作位置	步骤图、工具图、结果图	HowTo
案例页	项目场景、前后对比、应用环境	项目图、安装图、现场图	Article、ImageObject
分类页	某一类产品或主题的总览	分类代表图、导航图	CollectionPage、BreadcrumbList

这个对应关系处理好之后，搜索引擎在读图时，会先有一个“页面属于哪一类内容”的前提。没有这个前提，图片只能靠周边文本做猜测，稳定性会差不少。一个页面如果只有 500 到 900 个英文单词，图片却有 6 到 12 张，搜索系统能依赖的文字本来就不多，页面类型信息就更重要。 很多网站的问题出在模板复用。开发时为了省事，博客页、产品页、案例页共用同一套 schema 输出。结果站内 300 个 URL 可能都带着 Article，哪怕其中 120 个其实是产品页，40 个是项目页。这样做对用户界面影响不大，对图片理解影响会很明显。因为搜索引擎会先把页面归类，再给图片找角色。页面类型统一错位后，图片再清晰、再大，也容易被当成弱语义配图。 下面这个对比会更直观：

同一张图放置方式	搜索系统更可能如何理解
出现在 Product 页面首屏，并进入 Product.image	商品主图
出现在 BlogPosting 首屏，并进入 Article.image	文章首图
出现在 HowTo 第 3 步，并绑定步骤节点	第 3 步操作图
出现在分类页横幅区域，无实体对应	分类说明图或装饰图
出现在页面底部图库，无上下文说明	辅助图或弱相关图

所以处理顺序不该是“先把所有图都写 Alt”，而应该是先问一遍：这张图在这个页面里，到底是卖东西、解释内容、演示步骤，还是展示案例。不同答案，对应不同页面类型。 有些页面最容易混。比如“Best Portable Ice Bath Tub for Athletes”这种标题，看起来像文章，实际里面挂了 8 个具体产品、价格、购买按钮和评分模块。用户会把它当评测或导购页，搜索引擎则可能在 Article 和 Product 之间摇摆。如果站点没有清楚声明页面身份，图片也会出现角色漂移：首图像文章封面，中间 8 张图像商品图，页面里还插了 2 张对比表截图。此时至少要分清主身份，别让页面同时像 3 种页面。 可以把容易混淆的页面先列出来：

• 导购页：文章外壳，商品内容占比高
• 评测页：文章结构，但图像偏产品图
• 案例页：像博客，但图片更像项目实拍
• 分类页：像导航页，但塞了大量商品模块
• 教程页：有步骤，但也夹带产品推荐

这些页面不是不能做图片SEO，而是更需要把主类型定下来。例如导购页通常仍以 Article 或 BlogPosting 为主，商品图是内容的一部分；单一 SKU 的销售页才更适合 Product 作为页面主身份。教程页如果有 7 步安装流程，图片主要任务是把每一步讲清楚，那就更适合 HowTo，而不是把所有步骤图都当商品细节图处理。 再往里走一步，用户角度最容易理解的是“搜索词和页面类型要一致”。 有人搜 “carbon fiber kayak dimensions”，更像找产品信息； 有人搜 “how to install kayak seat straps”，更像找教程； 有人搜 “hotel lobby lighting retrofit project”，更像找案例。 如果页面类型和用户预期不一致，图片点击质量也会跟着变差。用户点进来想看安装顺序，结果页面是产品宣传；或者想看商品细节，点进去却是泛泛的博客。页面主题和图片角色对不上，不只影响识别，也影响后续停留和继续浏览。 下面这张表适合用来判断“页面身份是否选对”：

用户搜索意图	更合适的页面身份	图片应重点展示
看型号、价格、库存	产品页	主图、局部细节、尺寸图
看原理、区别、说明	文章页	示意图、对比图、首图
看安装顺序、使用方法	教程页	步骤图、工具图、结果图
看真实应用场景	案例页	项目图、现场图、前后对比
看某一类内容总览	分类页	分类代表图、导航图

如果网站中 1 个分类下有 30 个产品页和 12 篇文章，不建议所有页面都用同样的图片处理方式。分类页的代表图通常只需要传达类别，不需要抢产品主图角色；产品页的首图要服务单个实体；文章页首图更多承担主题引导；教程图则强调顺序和局部操作。把这些页面都混成一套，会让图片语义层次变平。 还有一个经常被忽略的点：页面中的图片数量，也会影响页面类型判断。 产品页常见是 4 到 10 张图片，围绕一个 SKU 展开； 教程页常见是 5 到 12 张步骤图，和编号步骤一一对应； 案例页常见是 6 到 20 张项目图，包含场景、细节、完工状态； 文章页则更常见 1 到 5 张说明图。 如果一个页面有 9 张图片，其中 7 张是按步骤排列的局部操作截图，结构上就更像教程，而不是普通文章。反过来，一个页面只有 1 张首图和 2 张示意图，正文主要在解释材料区别，它更接近文章页。很多站点在内容规划阶段没有分清，最后所有页面都长得差不多，搜索引擎也更难快速判断每张图的任务。 这里可以借一条很实用的检查思路： 先不看代码，只看页面前台，30 秒内判断“这页主要想让用户做什么”。如果是看产品，页面应围绕 1 个实体； 如果是学步骤，页面应有顺序结构；如果是读分析，页面应以段落和比较为主；如果是看项目，页面应强调地点、时间、应用环境。前台意图明确后，再让结构化数据和图片位置跟上，不容易偏。 一些页面会因为 CMS 或主题限制，把首图统一输出到同一位置，但这不代表它们属于同一页面类型。比如博客模板和案例模板都在顶部放大图，视觉上相似，但图片语义不同。博客首图更像文章主题图，案例首图更像项目证明图。对于案例页，图片旁边最好有地点、项目类型、施工时间、使用环境等信息；对于文章页，首图旁边更常见作者、发布日期、主题说明。 再看一个更具体的例子。 一个户外装备网站里，有 3 个 URL：

URL类型	页面内容组成	更适合的处理
/products/inflatable-paddle-board-x7	价格、参数、库存、8张产品图	Product
/blog/how-to-store-an-inflatable-paddle-board	7个步骤、6张步骤图	HowTo / Article
/projects/lake-tour-rental-fleet-upgrade	项目描述、现场图、设备使用图	Article / Case style

如果这 3 类页面都统一输出 BlogPosting，那么第一个页面的商品图就会丢掉商品身份，第二个页面的步骤图也不会被突出成操作图，第三个页面的项目图则更难和案例语义挂钩。图片本来都能被抓取，但“抓到”和“理解对”不是一回事。 为了减少这种错位，可以按页面模板建立一个很短的映射表，让编辑、开发、SEO 都按同一套规则执行：

• 单产品销售页 → Product
• 多步骤操作页 → HowTo
• 资讯、对比、测评页 → Article / BlogPosting
• 项目展示页 → Article + ImageObject
• 分类导航页 → CollectionPage + BreadcrumbList

这样做的好处是，后续写图片 Alt、caption、文件名时，方向更稳。产品页主图更强调型号、角度、材质、规格；教程页图片更强调动作、顺序、局部位置；案例页图片更强调场景、应用环境、前后变化。页面类型一旦定清楚，图片说明也不会写歪。 还可以再用一组细分点做人工复核：

如果页面有购买按钮、库存状态、SKU、价格区块，通常不该只当文章页处理。 如果页面有编号步骤、工具清单、过程截图，通常不该只当产品页处理。 如果页面首段写项目背景、地点、客户类型、交付时间，通常更接近案例页。 如果页面主要任务是把 12 个产品按某一主题归档展示，更接近分类页而不是单一产品页。

对图片SEO来说，先把图片和页面类型对上，能减少后面很多反复修补。因为图片不会脱离页面单独存在。它总要依附一个对象：商品、文章、步骤、项目或分类。这个对象选对以后，主图该放哪、说明该怎么写、结构化数据该选哪套，都会顺一些。

图片写完整

很多页面已经把图片放进了对的页面类型里，但图片本身的信息仍然偏少。最常见的情况是：页面有 1 张主图、4 张细节图、2 张场景图，HTML 里能看到，用户也能看懂，结构化数据里却只留下 1 个图片 URL，或者只在 Alt 里写一句很泛的描述。这样做之后，搜索引擎知道页面里“有图”，却不容易知道每张图分别展示什么、哪张更重要、哪张代表页面、哪张只是补充。对一页含 6 到 10 张图的商品页来说，图片信息只写 20% 到 30%，页面语义会空掉一大截。 先看一个简单对比。 同样是一张产品图，如果只保留文件地址，搜索系统读到的是资源存在；如果补上 caption、描述、尺寸、归属关系、代表属性，读到的就是一张可放进页面语义里的图片对象。图片SEO里，很多差距不是来自“有没有图”，而来自“这张图是否被写成完整对象”。一张 1600×1600 的图，和一张同样尺寸但带完整说明、实体关系、用途说明的图，后者的识别条件明显更多。 可以先把一张图片通常需要补的字段拆开看：

信息项	作用	常见缺失情况
URL	让系统知道具体资源地址	写成缩略图、旧地址、临时参数图
Alt	描述图中内容	过短、过泛、重复率高
caption	说明图片用途或场景	大多数页面未填写
宽高	帮助识别规格与代表性	未声明或与实际不符
文件名	提供基础语义线索	使用 IMG_2048、DSC0031 之类命名
归属关系	说明属于产品、文章、步骤还是案例	只放图，不绑定实体

很多网站会把 8 张图都写成类似 “industrial machine”“product image”“outdoor gear” 这样的 Alt。对于用户来说，浏览页面时还能靠上下文区分；对于搜索引擎来说，8 张图几乎在重复同一句话。这样会出现两个问题：一是图片区别度不足，二是主图和辅图权重接近。页面明明有一张正面主图、一张尺寸图、一张接口特写、一张应用场景图，但系统读到的是 4 张“机器图片”。 所以，写完整不只是“补几行文字”，而是把每张图的角色拉开。例如一款便携式设备页面有 6 张图，可以这样区分：

• 主图：整机正面图，白底，展示完整外观
• 细节图：控制面板特写
• 细节图：接口与按键布局
• 尺寸图：长宽高标注
• 场景图：设备在酒店房间使用
• 包装图：运输箱与配件清单

如果 6 张图都只有同一种写法，页面图片层就很平。如果每张图都能说明角度、部位、场景、用途，搜索系统更容易把这些图分配给不同查询。 下面这张表适合用来判断“图片信息是不是还太粗”：

图片类型	不够用的写法	更完整的写法方向
主图	portable oxygen device	型号 + 角度 + 主体外观
细节图	control panel	控制面板 + 显示区域 + 按键布局
尺寸图	product dimensions	长宽高尺寸示意图
场景图	product in use	使用场景 + 地点/环境
包装图	package	包装箱 + 随机配件展示

这时就能看出，图片本身写完整，至少包含两个层面：一层是图里有什么；另一层是这张图在页面里干什么。很多页面只写到了第一层，没有写第二层。 接着要处理的，是主图和辅图之间的区别。 一个商品页里常见 5 到 12 张图，不需要每张都承担“代表页面”的任务。通常只有 1 张主图，最多 2 张备用主图，剩余图片用于补充。结构化数据如果把所有图片一股脑塞进同样的位置，或者完全不标明主次，搜索系统就更难判断哪张图应优先和页面主题绑定。对于单个 SKU 页面来说，主图最好满足几个条件：尺寸够大、主体完整、背景干净、与页面标题和实体名称一致、在首屏可见。 可以用一组简单规则划分：

类型	建议数量	页面中的位置
主图	1 张	首屏主视觉区
备用主图	1 到 2 张	主图轮播或主图区相邻位置
细节图	2 到 5 张	参数、卖点、细节模块
场景图	1 到 3 张	使用说明、案例、生活化区域
说明图	1 到 4 张	安装、步骤、尺寸说明区

一旦把主次分开，caption 和描述也会更好写。主图强调实体整体，细节图强调局部，场景图强调环境，说明图强调关系。这样处理以后，页面里 8 张图不会像 8 次重复，而更像 8 条分工明确的信息。 除了文本描述，图片资源本身也要写得更规整。最容易被忽略的是文件名。很多站点上传图片时保留相机原名、设计稿导出名或系统流水号，比如：

• IMG_4821.jpg
• DSC_0093.webp
• final-banner-02.png
• new-product-last-v3.jpg

这些名字对用户没影响，对搜索系统帮助也有限。更适合的命名通常更接近实体和图像内容，例如：

• portable-oxygen-concentrator-x200-front-view.webp
• kayak-seat-strap-install-step-3.webp
• hotel-lobby-lighting-retrofit-before-after.jpg

文件名不是主字段，但它和 Alt、caption、页面主题一起出现时，会形成更稳定的线索。尤其是一页 10 张图里有 4 张图未写 caption 时，文件名至少能补一点识别信息。 然后还要检查尺寸、比例和资源版本。如果页面首屏显示的是 1440px 宽主图，结构化数据里引用的却是 320px 缩略图，信息会不对称。如果页面主图是 WebP，schema 里却填了旧的 JPG 地址，表示资源版本没有同步。如果首图已经更新到 2026 年新包装，JSON-LD 仍在引用 2024 年旧包装图，搜索结果中就可能出现前台与抓取结果不一致的情况。 这类问题可以按下面的方式排一遍：

检查项	建议状态
主图宽度	与页面展示图接近，通常不低于 1200px
资源可访问	返回 200
地址稳定	不频繁切换目录和参数
格式统一	WebP / JPEG / PNG 按页面方案统一
图片版本同步	页面展示图与 schema 图一致
裁剪逻辑一致	不用头像比例图片充当横版主图

图片写完整，还包括把说明文字放在靠近图片的位置。虽然结构化数据是机器读的，但页面可见说明同样影响理解。举个例子，一篇 1800 字的文章里有 4 张图，如果其中 3 张图下方都没有 caption，系统只能从前后段落推断用途；如果每张图下方有 12 到 25 个字的短说明，图与段落的对应关系会清楚很多。对教程页尤其明显。第 2 步和第 3 步如果都配图，但图下没有任何说明，用户要来回对照，搜索系统也更难知道它们对应哪一段。 可以把可见说明控制在较短范围内，例如：

• 12 到 20 个字：适合产品细节图
• 15 到 30 个字：适合场景图
• 10 到 18 个字：适合步骤图
• 20 到 35 个字：适合案例说明图

说明不需要写成长句，也不用堆词。只要把主体、部位、场景、动作写清楚，信息密度就已经比空白强很多。 再往下看，图片归属关系也要明确。一张图可能属于产品，也可能属于文章，也可能属于 HowTo 某一步。如果页面里既有作者头像，又有主图，又有品牌 logo，又有内嵌对比表截图，就更需要分清每张图在结构化数据中的位置。常见做法是：

• 产品页主图进入 Product.image
• 文章页首图进入 Article.image
• 步骤图与 HowToStep 对应
• 品牌 logo 放在 Organization.logo
• 作者头像放在 Person.image

这样处理后，页面里 5 类不同用途的图片不会挤在一个字段里。如果把 logo、头像、主图都混进同一个 image 数组，页面代表图会变得模糊。 这一点可以用下面这张表快速分辨：

图片对象	更适合放的位置
商品主图	Product.image
文章封面图	Article.image / BlogPosting.image
步骤图	HowToStep.image
公司标志	Organization.logo
作者头像	Person.image

很多页面还会漏掉版权和作者信息，尤其是原创拍摄图、案例图、信息图。如果一张图来自站点自制内容，写明作者、发布者、版权声明，会让图片来源更完整。对于新闻站、案例站、专业博客，这一点尤其有用，因为页面往往不只展示“物品长什么样”，还展示“这张图是谁拍的、属于哪个机构、发表于什么时间”。一张图片如果同时带有发布时间、作者、归属页面、说明文字、正式地址，搜索系统能利用的信息会比只有一个 URL 丰富很多。 再看一个对比：

图片信息程度	页面效果通常会怎样
只有 URL	知道有资源，但语义薄
URL + Alt	有基础内容识别
URL + Alt + caption	图和上下文关系更清楚
URL + Alt + caption + 实体归属	图更容易服务具体查询
再加作者、版权、尺寸	信息完整度更高

对于含图较多的页面，建议至少给前 3 张最重要的图补完整信息。原因很简单：用户最常看到的是首屏主图和前几张说明图，搜索引擎也更容易优先处理页面前部资源。一个产品页有 9 张图，不一定要求 9 张都一样详细，但前 1 到 3 张最好不要只剩下“图片存在”这一层信息。 如果首图、首个细节图、尺寸图都写完整，页面图片语义的骨架就已经搭起来了。可以用这组短清单做最后核对：

• 主图是否有标准文件名
• Alt 是否写出主体而不是泛词
• caption 是否说明角度、部位或场景
• schema 是否使用正式资源地址
• 图片尺寸是否与前台一致
• logo、头像、主图是否分开放置
• 细节图和尺寸图是否有区别化描述
• 原创图是否补作者或版权信息

图片本身写完整，并不是把一张图塞满字段，而是让搜索系统知道：这张图是什么、显示哪个部位、是否代表页面、属于哪个实体、与正文哪部分对应、资源地址是不是正式版本。做到这一层后，图片不再只是“页面上的附件”，而是页面信息的一部分。

处理字段准确性

很多页面不是没加结构化数据，而是加了以后，字段之间对不上。搜索引擎读取页面时，通常会同时看 HTML 标题、首屏正文、图片 Alt、JSON-LD、面包屑、Open Graph、图片文件名，有时一页会出现 6 到 10 组可对照信息。只要其中 2 到 3 组出现明显偏差，页面主题就会变散，图片也容易被当成普通配图，而不是商品主图、文章首图或步骤图。字段不一致，影响的不只是富结果，还会影响图片与查询词的对应精度。

先看一个常见页面。标题写的是 “Portable Oxygen Concentrator for Travel”，正文首段写成 “lightweight home oxygen machine”，Product.name 又写成 “Mini O2 Device X200”，主图 Alt 写 “medical breathing unit”，文件名是 portable-oxygen-concentrator-front-view.webp。

用户读起来大概能明白是同一类产品，但搜索系统读到的是 4 组命名口径。语义没有完全断开，但集中度会下降。页面本来想覆盖 “portable oxygen concentrator” 这一类词，结果图片、商品实体、正文说明分散到多个近义表达里，匹配会变宽，展示会变乱。

可以先把最容易出错的位置列出来，做页级排查：

先把页面名称统一，再去看图片字段，会更省时间。因为图片本身通常依附在页面实体上，实体名称乱，图片很难稳。

很多站点会在改版后留下两套信息。比如 2024 年的旧产品名还留在 JSON-LD，2025 年页面正文已经换成新命名，主图却沿用旧文件名。再过几个月，编辑又改了 H1，没有同步结构化数据。1 页里累计 3 次修改，最后出现 5 个版本的叫法。用户一般不会回头比对，但搜索引擎会按代码逐项读取。

对于 100 个产品页的网站，只要 20% 页面出现类似问题，整体图片和产品实体的稳定度都会下降。

这时最实用的做法不是先加更多字段，而是先收口字段版本。可以按下面一组去核对：

• 页面主名称保留 1 个标准写法

• 型号写法前后一致，例如 X200 不要一会儿写 X-200、一会儿写 X 200

• 单位统一，例如 20L、20 L、20-L 不要混用 3 种

• 复数和单数尽量统一，尤其是分类页和产品页之间

• 品牌名大小写统一，例如 AquaPro、AQUAPRO、aqua pro 不要交替出现

命名统一后，再看图片地址是否和页面展示一致。很多页面的问题不在文本，而在图片资源引用。页面首屏展示的是 1600×1600 的正式主图，但结构化数据里的 image 却填了 300×300 的缩略图，甚至是 CDN 生成的裁剪版。搜索系统当然能读取到图片，但更容易把它当成辅助资源，而不是页面代表图。对于商品页、文章首图页、案例页，image 优先填正式展示图会更稳，尤其是宽度大于 1200px 的资源更适合做代表图。

图片字段还常出现“路径已变，标记没改”的问题。
例如：

• 页面展示图：/images/product/x200-main.webp

• JSON-LD：/uploads/2024/08/x200-main.jpg

• Open Graph：/cdn/cache/x200-thumb.png

3 个地址都能打开时，问题还不算太大；如果其中 1 个返回 404，或者 1 个被 noindex、robots、鉴权限制住，系统会读取到冲突资源。对于一张主图来说，最好保持 1 个主地址，必要时再做尺寸派生，而不是让多个版本并列承担“代表图”身份。

下面这组位置，建议固定做交叉检查：

当这些位置统一后，搜索系统对页面的主对象判断会顺很多。然后再看结构化数据内部是否有字段逻辑错误。很多页面已经加了 Product、Article、ImageObject，但字段之间关系没有写明。例如商品页把 Product.image 填好了，却又单独放一个 ImageObject，里面的 caption 写成教程内容；文章页是 BlogPosting，但 image 指向的是作者头像而不是文章首图。

用户能区分“头像”和“封面图”，搜索系统需要靠字段关系来判断，没有写清楚就会混。

这类问题可以分成 3 组看：

• 实体和图片是否属于同一个对象

• 页面主图和辅助图是否被分清

• 字段内容是否和页面真实展示一致

如果一个文章页有 7 张图，首图、步骤图、作者头像、品牌 logo 都在页面里，那么代表页面主题的通常只有 1 张，最多 2 张。结构化数据里的主 image 不需要把所有图片都塞进去，更不要把 logo 当成首图。对于用户阅读来说，logo 几乎没人会当作正文图片；对于搜索系统也是一样。logo 可以单独存在于 Organization 标记里，不要抢 Article.image 的位置。

有些站会把多个 schema 混在一起写：JSON-LD 一套、Microdata 一套、插件又自动生成一套。表面看字段很全，实际上容易出现互相覆盖。比如 JSON-LD 里价格是 149.00，Microdata 里还是旧价格 129.00；Article 的发布日期一个写 2025-11-04，一个写 2024-09-19。富结果系统看到这种差异后，通常不会替你猜哪一个更可信。对图片SEO也一样，页面主图、发布时间、作者、产品名这些信息如果成双成套地打架，整体识别就不稳。

可以按下面这 3 组去减错，每组控制在几分钟内完成一次页面审核。

第一组，先对名称、型号、图片角色：

• Title、H1、schema 名称用同一套主叫法

• 型号格式固定成 1 种，不混空格和连字符

• 主图只保留 1 张代表图，不让 logo、头像、横幅混进去

• Alt 写图像内容，不拿营销句替代

• 文件名尽量与实体名接近，例如 carbon-fiber-kayak-side-view.webp

• 商品页主图优先对应 Product.image

• 文章首图优先对应 Article.image

完成这一组后，页面主题会先收紧。接下来再查链接与资源状态，因为字段写对了，资源打不开也没有意义。

第二组，再对地址、状态码、尺寸、版本：

• 主图地址返回 200，不跳到临时参数页

• 不使用占位图、懒加载空白图作为 schema 图片

• 宽高与首屏展示图接近，别用 150×150 缩略图顶替

• 图片 MIME 类型正常，例如 image/webp、image/jpeg

• 图片地址不要今天 .jpg 明天 .png 频繁切换

• CDN 路径更新后，同步更新 JSON-LD

• Canonical 指向正式 URL，不让图片所在页出现重复版本

很多网站上线新 CDN 后，首屏图片已经走新域名，但结构化数据还停在旧域名。3 个月内如果旧地址逐步失效，图片字段就会慢慢空转。对于 500 页以上的网站，最好导出一份 image 字段清单，批量检测状态码。抽样 50 页往往就能发现问题分布，命中率不低。

然后再往里走一步，处理页面真实内容和结构化数据是否同步。这里最容易被忽略的是时间、作者、价格、库存、面包屑层级。虽然它们不是“图片参数”，但会影响图片所属页面实体是否被稳定识别。比如文章页页面顶部写“Updated January 2026”，JSON-LD 的 dateModified 仍是 2024-07-18；产品页页面显示 “Out of stock”，Offer 里却还是 InStock。用户看的是页面前台，搜索系统会把前台和 schema 一起比对，差异太大时，字段可信度会下降。

这部分可以按业务类型拆开查。

第三组，最后对时间、作者、价格、层级、页面可见内容：

• 页面显示的价格和 Offer.price 一致

• 库存状态和 availability 一致

• 页面更新时间和 dateModified 一致

• 作者名与作者页、署名区一致

• 面包屑路径与实际目录一致

• 页面上看不到的信息，不要硬写进 schema

• 已下线内容及时移除，不保留旧型号、旧评价、旧价格

一旦页面可见内容和结构化数据同步，搜索系统读取页面时，文本层和数据层会更接近。对于商品图、首图、案例图，这种一致性能减少误判。比如一个案例页标题是 “Hotel Lobby Lighting Retrofit in Manchester”，主图是完工照片，正文首段说明项目地点、时间、施工范围，Article 或 Case Study 类 schema 再把 headline、image、author、datePublished、breadcrumb 对齐，图片就更容易和案例型查询匹配，而不会被当作普通图库图像。

再看一个细节，很多页面会在不同位置使用不同语言或不同单位。英国页面正文写 “colour”，schema 里写 “color”；规格页标题用 “mm”，正文表格写 “inch”；文章首段写 “guide”，schema headline 写成 “tutorial”。这些差异不一定导致错误，但当页面原本信息就不多时，会增加离散度。对于单页只有 400 到 700 字正文、3 到 5 张图的小型页面，字段一致性更需要收紧，因为可供搜索引擎判断的线索本来就少。

还有一个容易被忽略的情况：模板字段把分类页、产品页、文章页混成一套输出。结果分类页也带 Offer，文章页也带 Product，教程页还保留 AggregateRating 占位值。这样的页面并不少见，尤其是用主题模板或插件自动生成 schema 时。处理方式不是把所有字段全删，而是按页面类型保留最匹配的一套，避免一个页面同时声明 3 种主身份。页面身份一旦清楚，图片角色也会跟着清楚。

如果站点规模不大，几十个 URL 就够做一次人工抽检；如果站点超过 300 页，建议按页面类型抽样：

产品页抽 30 页，文章页抽 20 页，分类页抽 15 页，案例页抽 10 页。每页看 8 个位置：Title、H1、首段、首图、Alt、JSON-LD、Breadcrumb、OG。这样一轮大约能覆盖 600 到 900 个字段点位，通常已经能定位主要问题分布。