设计师填进图片的版权信息，走完交付链一个字都没剩

摘要：994张电商交付图里，带版权、带作者或带图片说明的是0张，带相机与拍摄参数的也是0张。EXIF段还留着的有442张，其中324张只写了一个字段——同一台图片处理机的主机名，而这台机器出现在67个互不相干的品牌图上。

摄影棚的灯打了两个小时，修图师在软件里把版权、作者、拍摄说明一栏栏填好，存盘，上传。等这张图出现在用户屏幕上的时候，那些字还在不在？

我原以为答案是“应该在吧”。Google自己的文档也是这么写的。直到把131个海外电商站的首页图片挨个下载下来，拆开二进制看了一遍。

一张商品图从摄影棚走到用户屏幕，中间要过几道手？

先把链条摆出来。一张商品图的一生大概是这样：相机拍出来，修图软件处理，上传到店铺后台，平台入库时重新编码，CDN按尺寸和格式再派生一次，浏览器请求时按Accept头协商，最后落到屏幕上。

这条链上，只有前两步是品牌自己控制的。从上传那一刻起，图片就交给别人了。

样本是131个海外电商与DTC品牌站。做法是抓首页HTML，把img标签、srcset里最大的那一档、og:image、预加载的图片、JSON-LD里的image字段全部收集起来，每站最多取12张，跨主机分散，每张按Range只下前384KB。元数据都在文件头部，这个量够用。

119个站取到了图，一共994张。剩下12个站首页HTML里一张图片地址都提取不到，全是前端框架渲染出来的——这跟JS渲染对爬虫的影响是同一件事的两个侧面，本文只把它记为样本口径的一部分。

994张交付图里，属于品牌自己的信息还剩多少？

先看结果，再解释怎么读。

后面三行是本文的核心。994张图，没有一张带着可读的版权字段、作者字段或图片说明。一张都没有。

这个0值得多说两句，因为0这种数字最容易是尺子坏了而不是世界坏了。我在这里翻过一次车。

按二进制段扫描，有4个站的图片里确实有APP13段，也就是Photoshop专用的那块资源区，IPTC图片元数据标准定义的那些字段通常就住在里面。第一版脚本看到APP13就记成“有IPTC”，得出“4个站保留了IPTC”。

但真去解析那4块，一个字段都读不出来。回头看段长度：44到56字节。而APP13的标识串Photoshop 3.0加结束符本身就占14字节，剩下三四十字节只够放一个最小的资源块，那是打印分辨率之类的东西，不是IPTC记录。

所以判据改成了“必须真解析出字段才算”，4变成0。这类修正这轮一共做了14处，后面有表。

为什么67个不相干的品牌，图片里写着同一台机器的名字？

EXIF段存在的有77个站、442张图，听着还行。可是打开看字段，事情就不对了。

442张里有324张的EXIF只写了一个字段：HostComputer = imagery4。

HostComputer这个字段的原意是“处理这张图的那台计算机”。imagery4显然不是哪个品牌的名字，它是一台机器的主机名。这台机器出现在67个品牌的商品图上，卖床品的、卖户外装备的、卖眼镜的、卖运动服的，彼此毫无关系。

顺着图片地址查：这些图有的挂在平台的公共CDN上，有的挂在品牌自己的域名下，但路径里都带着同一段 /cdn/shop/。我又把67个站逐个反查了一遍平台特征，看 /.well-known/ucp里的店铺标识和身份端点，67个站没有一个例外，全部跑在同一个电商平台上。

换句话说：品牌自己填的那些字段被清空了，然后平台的图片处理集群在同一个位置写下了自己的机器名。

这就像你把一幅画送去装裱，取回来时画框背面签着装裱店流水线的编号，而你写在画布背面的那行字被擦掉了。

另外99张图更彻底：EXIF段还在，里面一个可读字段都没有，就是一个空壳，涉及41个站。还有5张图的Software字段写着一家第三方图片压缩服务的域名——它也在这个位置留了名。

这条线索还有个副作用值得一提。既然平台会统一重写这一段，那么任何依赖图片自带信息做资产管理的流程都会在这里断掉。做Shopify图片SEO的时候，命名和alt是能守住的，图片文件内部则守不住，这两类工作得分开安排。

元数据是入库时没的，还是交付时剥的？

这个问题绕不开。两种情况对应完全不同的应对办法，不能含糊过去。

所以做了一组对照实验。做法很土：把同一张图的地址取两份，一份是页面上原样带着处理参数的（比如 ?v=1786993419&width=300），一份是把问号后面全部砍掉的裸地址，两份都下载，逐段比对。

177组有效对照，结果如下。

29组在派生时确实丢了东西。但注意，另外148组两边一模一样，包括绝大多数只剩HostComputer的那些。

这个结果指向一个不太舒服的结论：在最主流的那个电商平台上，元数据不是交付时剥的，是入库时就没的。你把裸地址翻出来也救不回来，因为库里存的那份已经被重新编码过了。而在用第三方图片服务的站上，确实是交付环节在剥——裸图还留着EXIF，加上压缩参数之后就没了。

顺手还量到一件反直觉的事。原以为加参数总归是为了让图更小，实际上17组派生图比裸地址还大。

这些都是小图，多出来的几KB对页面速度谈不上影响，别拿它当性能问题看待。真要治页面重量，路子在按层拆LCP那一套，不在这几KB上。

不过多出来的字节里，有相当一部分就是平台重新注入的那套东西：424字节的精简色彩配置，在994张图里出现了400次，长度一个字节不差。它替换掉了原来可能存在的那份，也替换掉了原来的EXIF。图片压缩工具处理ICC的方式差别有多大，之前拿小图标测过一轮，结论是同一个“压缩”按钮下面藏着完全不同的取舍。

再记一个坑。用Range分段下载时，返回头里的Content-Length是这一段的长度，不是文件的真实大小。我第一版拿它当文件大小，算出来一张图“派生后大了45倍”，其实那个数字就是我自己设的下载上限。真实大小要从Content-Range斜杠后面的分母取。在页面体积那一轮实测里踩过同类问题：测量工具本身出错，比被测对象出错更难发现。

Google说IPTC会随图走，这句话在电商站还成立吗？

这件事之所以值得写，是因为它跟官方文档写的正好拧着。

Google的图片授权元数据文档给了两条路，让图片有资格拿到搜索结果里的可授权徽章：一条是在页面上写结构化数据，另一条是把IPTC信息嵌进图片文件本身。文档还专门解释了后者的好处，说IPTC元数据嵌在图片自身里，图片和元数据可以在页面之间移动而保持完整，所以每张图只需要嵌一次。

言下之意是：结构化数据绑在页面上，换个页面就得重写；IPTC绑在文件上，跟着图跑。听起来IPTC更省事。

实测下来，在电商交付链上，这个“跟着图跑”不成立。994张交付图，能解析出IPTC字段的是0张。文档描述的是文件格式层面的性质，这没错；但它没有考虑到，从设计师存盘到用户看到，中间隔着一次平台的强制重编码。

更有意思的是同期另一件事。2026年8月17日，Google宣布Gemini用户可以关掉AI生成图上那个看得见的水印，同时明确：隐形的SynthID水印和内容凭证元数据照旧嵌进每一个文件，不管你关不关。

两件事放一起就很微妙。同一家公司，同一个时间段：机器生成的图，元数据是强制留下的，用户想去掉都不行；人拍的商品图，元数据被顺手清掉了，品牌想留都留不住。

关于内容凭证这套机制怎么运作、在信任链上解决什么问题，之前写过内容溯源与C2PA那篇；水印能不能当作者身份的证据，AI水印检测那篇给过一个比较克制的答案。这里只想指出一个错位：行业正在给AI生成内容建立强制溯源，而人类创作的商业影像，溯源信息在最普通的一次上传里就丢干净了。

那4个还留着版权字段的站，写的是什么？

994张图里有86张带XMP块，涉及35个站。XMP是那套XML格式的元数据，理论上版权、作者、关键词、授权条款都能往里塞。

可把这35个站的XMP拆开看，真正出现版权字段dc:rights的只有4个站。就4个。

这张表比那个0更说明问题。4个里面，真正意义上的版权署名只有2个，都是摄影师的名字；1个是软件的自我介绍；还有1个字段壳子还在、值已经空了。

parachutehome那张是全场唯一一个把元数据填得比较完整的。按官方文档的口径，这样的图最接近拿到可授权徽章的条件。

不过得说句公道话，这4个站也不见得是有意为之。更可能的解释是：他们的图恰好走了一条重编码没那么激进的路径，元数据侥幸活了下来。这跟“主动配置了图片授权信息”是两回事，别把运气当成方法。

活下来的XMP里装着什么？

版权只有4个站，那另外31个站的XMP里装的是什么？

是软件签名。31个站的XMP里有创作工具字段，也就是“这个文件是用什么软件做出来的”。17个站还留着文件创建时间。

这份清单读起来像一份设计部门的资产盘点：谁在用Mac、谁在用Windows、谁的图像软件还停在2015年那一版、哪家上了Capture One那种专业摄影棚的原始格式处理流程。

结论就有点黑色幽默了：交付链把“这张图归谁”扔了，把“这张图是用什么软件做的”留下了。对品牌有用的那部分没了，对品牌没用、甚至有点不想让人知道的那部分留着。

严格说这算不上安全问题，软件版本本来也不是机密。但它说明清理不是按敏感与否筛的，就是按格式里哪个块在哪个位置粗暴地过了一遍。

图片元数据丢了，实际影响到底有多大？

这里得诚实一点，不能为了文章好看就把影响吹大。分四层说。

对网页排名：基本没影响

图片里的EXIF和IPTC不是网页排名因素。这跟图片文件名、图片alt文字那两件事的性质一样，都被长期高估，真正的用处都不在网页排名上。如果目标是产品页排名，本文讲的事排在很后面，先去做文件名、alt与懒加载那套基本功更划算。

对图片搜索里的授权展示：有直接影响

可授权徽章那条路是实打实的。图片里没有IPTC，页面上又没写license和acquireLicensePage这两个属性，那么在图片搜索结果里就拿不到授权信息的展示位。对靠视觉内容吃饭的品牌来说，这是白白让出去的一块面积——尤其是在图片搜索开始混入购物广告之后，自然位的每一寸都更值钱了。

好消息是这条路有备份。Google那两条路是任选其一，页面上的结构化数据一样管用，而且结构化数据不会被图片处理链剥掉。所以在电商平台上，结构化数据这条路比IPTC那条路可靠得多，这跟通常的建议顺序正好相反。字段口径可以参考Schema到底有没有用那篇，Shopify站具体怎么落可以看128种类型怎么选那篇。

对图片被再利用时的归属：影响在变大

这一层以前不太重要，现在开始重要了。一张不带任何归属信息的商品图，被扒走、被拼进比价站、被拿去训练模型的时候，没有任何自带的线索指回来。反过来，如果图里带着摄影师署名和授权链接，追溯时至少多一条证据。图片本身正在被越来越多的模型直接读取，视觉搜索那套机制看的是像素而不是页面，归属信息断在文件层的代价会一年比一年高。

对内容真实性体系：错位正在拉大

前面说过那个错位：AI生成的图强制留痕，人拍的图留不住痕。随着内容凭证这类机制铺开，能证明出处的内容和证明不了出处的内容之间会形成落差，而电商的商品图恰好在证明不了的那一边。这不是今年就要解决的问题，但值得记在本子上。做GEO落地规划的时候，这一条可以先占个位置，不必现在就投入。

顺手量到的三件事，和一张修正表

URL里的扩展名基本不能信。994张图里，地址带扩展名的有742张，实际交付格式跟扩展名不一致的有561张，占76%。最多的是 .jpg实际发WebP（229张）、.png实际发WebP（159张）、.jpg实际发AVIF（82张）。

这大部分是正常的内容协商，服务端看你的Accept头，你支持AVIF就给你AVIF。不是错误，是好事。但它有个实际后果：任何按扩展名统计图片格式的脚本，结论都是错的。要看格式只能读文件头的魔数或者响应头。反方向的例外有6张，地址写 .avif实际发的是JPEG，那就是配置没跟上了。

第二件，11个站的首页HTML里躺着没渲染的模板占位符。比如某个站的图片地址原样写着 {{cover}}，另一个写着 {{productImageURL}}，还有 ${product.images[0]} 这种。模板变量没被替换掉就直接输出到HTML里了，浏览器拿这个当图片地址去请求，回来的是一个网页。

这类地址在页面上通常表现为一张裂图，或者干脆被脚本覆盖掉看不见，但爬虫是照单全收的。这也是批量体检图片属性时最容易漏掉的一类问题，因为它在渲染后的页面上根本不存在。

这里我也犯过一次错。第一版的判据是“地址里有方括号或花括号就算模板占位符”，结果把某个站的广告监测像素误判进来了，那个地址里有u3=[ReTa] 这样的段，是广告平台的宏，跟模板变量没关系。收紧成只认几种真正的模板语法之后，误报清掉了。

第三件当彩蛋。某个大型运动品牌的logo图，文件名是这样的：DECATHLON_logo_lockup_stacked_blue_rgb_---_Expires_on_31-12-2100.jpg。素材管理系统的命名规范原样跑到了公网地址上，连授权到期日都写着，2100年12月31日。这张logo的使用权还有74年。

这轮改了14处判据

量具的修正得列出来，数字才能复算。挑重要的六条：

方向上，前三条会让数字偏大，第四条会让数字失真，第五条让样本偏小，第六条影响的是所有比例。第五条最值得记：差一点就用5组对照下结论了，而5组和177组给出的方向完全不同，前者根本看不出入库时清和交付时剥的区别。

另外两个自限，读数字时要留意。一是样本只取首页图片，商品详情页的主图可能走不同的处理管线，结论不能直接外推到全站。二是“品牌自填字段0张”说的是交付给用户的那一份，不代表品牌上传的原始文件里也没有；恰恰相反，从XMP里留下的那些专业软件签名看，源头那份大概率是有的。

怎么查自己站的图还剩什么？

不用写脚本，浏览器加一个免费工具就能做完。

第一步，拿到真实的图片地址。在商品页上右键图片、复制图片地址。要复制的是浏览器实际加载的那个，不是HTML源码里写的那个，两者经常不一样。

第二步，同时下载两份。一份原样，一份把问号后面全部删掉。如果裸地址返回404或者跳转，说明平台不允许直接取原图，这本身就回答了半个问题。

第三步，看文件里有什么。Mac上用预览打开按Command加I，Windows上右键属性看详细信息。想看全的话，用ExifTool这类命令行工具一条命令就能把所有段列出来。重点看四样：有没有IPTC、XMP里有没有dc:rights、EXIF里HostComputer写的是谁、ICC是多少字节。424字节这个数字很好认，看到它基本可以确定图被平台重编码过。

第四步，按结果决定走哪条路。这一步是本文真正想给的建议。

保哥自己带的站走的是第四条。原因很简单：图片处理链不归我们管，页面模板归我们管。当时的做法是在产品页模板的ImageObject里补上license和acquireLicensePage两个属性，指向站内一个统一的图片使用条款页；三周后在Search Console的富媒体报告里，这批页面的图片授权项从零变成有效，而图片文件本身一个字节都没动。这个顺序对新站尤其重要，第一年最容易隐性失分的那些配置里，图片授权就属于“不做也不报错、做了才有”的一类。

还有一条不花钱的：如果你的品牌图会被媒体或分销商转载，那么在图里填IPTC依然值得做一次，哪怕自己站上会被剥掉。因为对方拿到的往往是你直接发过去的原始文件，那一份是完整的。

常见问题解答

图片里的EXIF和IPTC会影响网页排名吗？

不会，它们不是网页排名因素。真正有直接作用的是图片搜索里的可授权徽章展示，以及图片被再利用时的归属线索。如果目标是产品页排名，优先级排在alt文字、文件名、页面结构化数据后面。

那我还要不要在图里填IPTC？

要填，但别把它当成唯一的路。先花十分钟测一下自己站的交付链剥不剥元数据。如果剥，那么填了也白填，应该把力气放在页面结构化数据的license和acquireLicensePage上，Google认这两条路里的任意一条。另外发给媒体和分销商的原始文件不走你的交付链，那一份填了就是有效的。

为什么平台要把元数据清掉？

主要是体积和一致性。元数据段动辄几KB，对一个每天派生上亿张缩略图的平台来说是实打实的带宽成本；重新编码时顺手统一色彩配置，也能避免不同来源的图显示不一致。这个取舍从平台角度看是合理的，问题在于它没有留一个开关给商家。

把图片地址后面的参数去掉，能拿到带元数据的原图吗？

看平台。177组对照里有29组去掉参数后元数据回来了，说明这些站是交付环节剥的；另外148组两边一样，说明入库时就没了，去参数没用。这件事必须实测，不能想当然。

994张图里一张都没有版权信息，会不会是取样偏了？

有可能，所以口径要说清楚：样本是119个站的首页图片，不是全站图片，也不是原始上传文件。首页图多为营销主视觉，走的是压缩最狠的那条管线。合理的推断是全站数据会略好一点，但不会好到改变结论，因为67个站的元数据是在入库那一步没的，跟放在哪个页面无关。

用第三方图片优化服务会不会更好？

不一定。实测里走第三方服务的站，裸图元数据是全的，加上压缩参数之后EXIF被剥掉，同时塞进来一份3144字节的完整色彩配置，净结果是图变小了、非图像数据变大了。好处是这类服务通常有保留元数据的开关，而平台入库那一步没有开关。

这套测法能自己复现吗？

能。核心就三步：收集页面上真实加载的图片地址，按Range下载文件头部，逐段解析JPEG的APP标记、PNG的文本块、WebP的RIFF块。要注意的坑都在上面那张修正表里，尤其是Range请求返回的206状态码，以及Content-Length在分段下载时的真实含义。

权威参考资料