外贸产品图 CDN 地址过期：稳定地址、过期响应与公开交付设计

产品图签名地址失效，应分别核对页面仍交付哪个地址、旧地址当前响应、新地址响应及 CDN 的实际失效记录。本文说明公开交付设计与过期诊断的区别，保留权限边界，并区分可访问、抓取、收录和排名，不承诺恢复时长。

先分清四件事：稳定地址、过期响应、抓取权限、浏览器缓存

产品图地址带过期时间戳，团队第一反应通常是“图片会不会被 Google 除名”。这个问题问早了，因为它把四件不同的事压成了一句话。

第一层是地址是否稳定可发现。Google 官方文档说明，Google 可以从 img 元素的 src 属性中发现图片，即使该 img 是 picture 等其他元素的子元素；Google 不索引 CSS 图片（来源：https://developers.google.com/search/docs/appearance/google-images）。所以“可发现”问的是：初始 HTML 里有没有一个可解析的图片来源，而不是这个来源的有效期有多长。

第二层是过期后服务器实际返回什么响应。这一层决定 Google 侧的处理方式。官方文档说明，Google 不使用返回 4xx 状态码的 URL 上的内容；若某 URL 此前被使用但现在返回 4xx，Google 系统会随时间停止使用该 URL；就 Google 搜索而言，Google 不收录返回 4xx 的 URL，已收录但返回 4xx 的 URL 会从索引中移除（来源：https://developers.google.com/search/docs/crawling-indexing/http-network-errors）。同一份文档还说明，除 429 外所有 4xx 错误被同样对待：Google 爬虫告知下一处理系统该内容不存在，新遇到的 404 页面不会被处理，抓取频率逐渐下降。

第三层是抓取权限。图片常与页面处于不同目录甚至不同子域，robots 规则、鉴权要求都可能单独作用于图片路径。私有媒体可能需要登录或鉴权头。应记录实际 HTTP 响应，不能只凭“签名过期”推定状态码或具体错误原因；权限规则和失效原因须结合所用 CDN 的配置核验。

第四层是浏览器缓存。这是客户端行为，与服务器响应和抓取处理不是同一层。官方文档讨论的是服务器返回什么状态码、Google 如何处理该响应，并未描述浏览器缓存对抓取的影响。因此“用户还能看到缓存里的图片”不能推出“Google 仍能抓到该图片”——这两条线各自独立，一条成立不构成另一条的证据。

把四层分开之后，本步的产出不是一句“图片有问题”，而是一张四栏状态记录：图片 URL、可发现来源（src / srcset）、当前响应状态、抓取记录。四栏分别填写，不要合并。差异本身就是线索：如果可发现来源正常、响应也正常，但抓取记录为空，还不能定位原因；记录缺失并不证明发现或权限失败。若响应已经是 4xx，先检查该地址的实际交付错误。

过期后返回客户端错误：按实测响应判断，不猜CDN原因

“签名过期后 CDN 返回 403 还是 404，对 Google 图片搜索的影响一样吗？”这是团队最常问、也最少被明确回答的问题。官方文档给出的答案很直接。

文档说明，除 429 外，所有 4xx 错误被同样对待：Google 爬虫告知下一处理系统该内容不存在；就 Google 搜索而言，如果该 URL 此前已被收录，索引流水线会把它从索引中移除；新遇到的 404 页面不会被处理；抓取频率逐渐下降（来源：https://developers.google.com/search/docs/crawling-indexing/http-network-errors）。

上述描述仅说明 Google 文档对该类响应的处理，不能用来断言不同 CDN 的签名失效原因、错误页内容或恢复措施相同。文档还专门提醒，不要用 401 和 403 来限制抓取速率。

同一份文档对 4xx 的整体表述是：Google 不使用返回 4xx 状态码的 URL 上的内容；若某 URL 此前被使用但现在返回 4xx，Google 系统会随时间停止使用该 URL；就 Google 搜索而言，Google 不收录返回 4xx 的 URL，已收录但返回 4xx 的 URL 会从索引中移除。

这里有一个必须区分的边界：上述结论针对的是“这个图片 URL 不再被使用”，不等于“产品页本身失去索引资格”。图片 URL 与承载它的产品页是两个不同的 URL，各自有各自的响应状态与索引状态。把两者混为一谈，会导致团队在图片地址失效时误以为整个产品页也出了问题，从而在错误的层级上做修复。

最后要明确本文的证据边界：请查阅所用 CDN 的签名过期处理说明，并直接请求该图片地址核对实际响应；本文不代替你的地址实测。本文能确定的是：无论核验结果是哪一个，只要落在“除 429 外的 4xx”范围内，Google 侧的处理方式相同。

如果过期后返回 5xx：比 4xx 更接近“临时”，但不是免死金牌

既然 4xx 会让图片 URL 走向不被使用，一个自然的想法是：那把过期地址改成返回 5xx，是不是就能保住已收录的图片？

官方文档对 5xx 的描述是：5xx 和 429 服务器错误会让 Google 爬虫暂时降低抓取速度；对 Google 搜索而言，已收录的 URL 会保留在索引中，但最终会被移除；返回 5xx 状态码的 URL 上的内容会被 Google 忽略（来源：https://developers.google.com/search/docs/crawling-indexing/http-network-errors）。

与 4xx 对比，差别在 Google 文档所述的处理方式，不代表所有客户端错误在服务器端都是同一种原因：鉴权失败与资源不存在需要分别诊断。前者让 Google 系统随时间停止使用该 URL，后者让已收录 URL 暂时保留在索引中。这就是“5xx 更接近临时”的由来。

但“最终会被移除”这句话必须被完整引用，不能只读前半句。文档写的是已收录 URL 保留在索引中，但最终会被移除。这个“最终”没有时间表——官方文档没有给出任何安全时长，本文也不提供阈值。所以 5xx 不是一张可以无限期持有的免死金牌，它只是把处理方式从“声明不存在”换成了“声明暂时不可用”。

还有一条容易被忽略的机制：文档说明，一旦服务器开始返回 2xx 状态码，Google 会逐步提高该站点的抓取速率。这解释了为什么恢复响应是修复动作的一部分，但它描述的是抓取速率的变化，不是收录保证。

把这一节落到决策上：不要为了延缓索引变化，就把真实的签名或鉴权失败伪装成服务器故障。若希望这张产品图公开可发现，应修复它的可用交付地址；若图片本来不允许公开，保留其访问控制。状态码应反映实际错误，而不是被当作保收录的手段。

公开图片交付设计：让地址稳定可发现，而不是靠延长签名有效期

前面三节说明的是“过期之后会发生什么”。这一节处理的是更前面的问题：产品图应该怎么交付，才能让地址稳定可发现。

需要先破除一个二选一的假设：源文件私有与交付地址公开，不是互斥的两个目标。如果这张产品图确实允许向公众展示，源文件可以保留在受控存储中，再由交付层提供允许公开访问的地址；不应把本来私有的媒体直接开放。这两件事可以同时成立，因为它们服务的是不同的访问者——前者服务内部与授权流程，后者服务浏览器与爬虫。

官方文档给出的可组合做法有四条。

第一，用 img 的 src 提供可发现来源。文档说明 Google 可以从 img 元素的 src 属性中发现图片，即使该 img 是 picture 等其他元素的子元素；Google 不索引 CSS 图片（来源：https://developers.google.com/search/docs/appearance/google-images）。

第二，使用 picture 或 srcset 时保留 src 回退 URL。文档明确说明，部分浏览器和爬虫不理解这些属性，因此建议始终用 src 属性指定一个回退 URL。这条对签名 URL 场景尤其重要：如果真实来源只存在于 srcset 候选里，而回退 src 缺失或指向占位图，可发现性就打了折扣。

第三，用图片站点地图暴露可能未被发现的图片 URL。文档说明，与普通站点地图不同，图片站点地图的 image:loc 元素可以包含其他域名的 URL，因此可以用 CDN 托管图片；如果使用 CDN，官方建议在 Search Console 中验证 CDN 域名的所有权，以便接收抓取错误通知。这条对“图片放在 CDN 子域”的站点是直接可用的：验证 CDN 域名所有权之后，Google 可以针对相应域名提供抓取错误通知；这不是说未验证时所有其他诊断渠道都不存在。

第四，用元数据声明首选图片。文档说明，Google 对图片预览的选择是完全自动化的，会综合多个来源决定展示哪张图片；可以通过 schema.org 的 primaryImageOfPage 属性、mainEntity / mainEntityOfPage 的 image 属性，或 og:image 元标签提供首选图片。这里要准确理解它的作用范围：声明是影响，不是决定。文档明确写了选择是完全自动化的，因此声明首选图片不等于该图片一定会被展示。

把四条合起来，公开图片交付的设计目标是：让页面初始 HTML 里就存在一个指向真实资源的、公开可抓取的图片地址，并让这个地址在站点地图与元数据中被一致地声明。至于签名有效期设多长，本文不给出数值——官方文档没有规定，本文也没有真实配置可依据。

需要再次强调：以上是设计依据，不是收录保证。官方文档在讨论 2xx 时明确说明，对 Google 搜索而言，HTTP 2xx（成功）状态码并不保证被收录。

核验签名过期：比较旧地址、新地址与实际失效记录

若尚未完成一般图片发现检查，先参考《Google图片SEO：发现、索引、语义与性能验收》。这里不重复 src、懒加载和 robots 的通用清单，而是判断旧签名地址为什么失效、页面是否仍在交付它。

先固定比较对象。 在有权限的测试记录中保存同一图片的旧地址、首次取得时间、当前页面提供的新地址，以及两次直接请求的时间和响应。分享记录时隐藏签名参数及私有路径；不要让诊断文档变成访问凭据公开入口。不要假定所有 CDN 都采用同一有效期或过期状态码。

再找失效依据。 查看自己使用的 CDN 的实际签名配置或日志，核对旧地址请求时间与失效记录。旧地址失败、新地址成功，只能说明两次请求结果不同；还要核对资源标识、权限和有效期记录，才能判断是否确为签名到期。旧地址和新地址都失败时，先检查共同的资源或权限问题，不要直接归因于旧签名。若缺少相关记录，将失效原因标为未确认。

区分缓存显示与直接响应。 浏览器仍显示图片时，也应记录对旧地址的实际网络请求结果；没有发生新的请求，不能把屏幕截图当作当前服务器响应。此处是诊断建议，不代表已测过你的 CDN。

检查替换是否真正生效。 若决定采用稳定公开交付地址，核对当前页面、图片站点地图与所管理的 CDN 域名实际使用的地址是否一致。仅更新图片文件、不更新仍指向旧签名的页面，不能证明用户和爬虫已使用新地址。若媒体不允许公开，不应为了抓取而撤销访问控制。

以下文档说明发现与响应的处理范围，不负责判断具体签名原因：

官方文档说明 Google 从 img 的 src 发现图片。

官方文档建议在使用 picture 或 srcset 时始终用 src 指定回退 URL，因为部分浏览器和爬虫不理解这些属性。

按官方文档的描述，该 URL 会走向不被使用。

按文档描述，已收录 URL 会暂时保留在索引中但最终会被移除。

这套核验只记录观察时刻的状态，不能预测下次抓取时间。 保留请求时间、观察结果、配置或日志依据以及尚未确认的原因；有依据的判断与原始观察分栏记录，不填写未经核验的恢复日期。

相关交付层问题可另读网站 CDN 缓存策略。

官方文档没有承诺的事：重新抓取间隔、收录与排名

修好图片地址之后，团队最想问的三个问题是：多久能恢复？排名会不会回来？用 301 把旧地址指到新地址行不行？这一节把官方文档确实回答了的和没有回答的分开列。

没有回答的第一件事：重新抓取间隔。官方文档只说明，一旦服务器开始返回 2xx 状态码，Google 会逐步提高该站点的抓取速率。这是速率变化，不是时间承诺，文档没有给出图片重新抓取的具体间隔。

没有回答的第二件事：收录与排名。官方文档明确说明，对 Google 搜索而言，HTTP 2xx（成功）状态码并不保证被收录。因此“地址修好了”只能推出“现在可以正常响应”，不能推出“已被收录”，更不能推出“排名会回来”。

关于 301，文档确实给出了机制层面的说明：Google 会跟随重定向，且 Google 系统把该重定向作为应处理重定向目标的强信号；同时，Google 会忽略从重定向 URL 收到的任何内容，转而处理最终目标 URL 的内容。因此 301 在机制上可以用于把旧图片地址指向新的稳定地址。但文档没有承诺重定向目标会被收录或展示——强信号描述的是“应处理”，不是“已收录”。

还有一条容易被忽略的核验陷阱：文档说明 Google 爬虫默认最多跟随 10 次重定向跳转，但具体产品的爬虫可能有不同限制；Googlebot 抓取一般网页内容时通常跟随 10 次跳转，而 Google Inspection Tools 不跟随重定向。这意味着用自查工具检查重定向链时，看到的可能不是爬虫实际看到的结果，需要把这一点写进核验记录。

最后，把四件事分开：可访问、已抓取、已收录、有排名。官方文档支持的是“2xx 时 Google 会考虑处理该内容”，以及“2xx 不保证收录”。把前一件当作后一件的证据，是这类问题里最常见的误判。