48个站对手机系统声明我没有App，这句话不是他们写的

摘要：131个海外电商站里，有48个对着苹果和安卓系统给出了一模一样的一句话：我没有App，不授权任何应用。这句话不是他们写的，是建站平台默认摆在那儿的。同一批站里，2026年才出现的商业协议端点已经铺到49%，而2022年就定案的安全联系方式标准只有8.4%。

网站根目录下面有个叫 .well-known的文件夹。人几乎不会点进去，机器每天都在敲它的门。

这个目录是有正式身份的，专门用来放那些“机器需要在固定位置找到”的文件：安全联系方式放这儿，App深链授权放这儿，隐私偏好信号放这儿，最近连AI代理的接口描述也开始往这儿放。

我拿131个海外电商与DTC站，把16条常见路径挨个请求了一遍。想看的问题很简单：这些文件里写的东西，到底是谁的意思。

机器来敲门的时候，谁在替这个域名回答？

先说结果的形状，再说数字。

这些文件绝大多数不是品牌写的。是平台在开店那一刻默认铺好的，内容一个字节都不差地重复在几十个域名上，包括那些看起来像“品牌做过决定”的声明。

而这件事跟同一批站的另一个发现是同一回事：在商品图片的元数据里，品牌自己填的版权被清空、换成了平台图片处理机的主机名。一个是图片文件内部，一个是域名根目录，位置完全不同，性质是一样的：面向机器的那一层，署名权不在你手里。

先交代一下这个目录的身份，因为很多人只把它当成一个放杂物的地方。它是IETF正式登记的保留路径，注册表由IANA维护，任何组织想在这个目录下占一个文件名，都得走登记流程。换句话说，/.well-known/ 下面的每一个文件名都是有主的，含义是公开约定好的，不是谁想放什么就放什么。

这一点决定了本文的全部意义：既然含义是约定好的，那么这些文件里写的东西就是你对全世界的机器做出的正式回答。回答对不对，跟是不是你写的，是两个独立的问题。

这类“由平台代你决定”的地方比想象中多。哪些页面元素能改、哪些被平台锁死，之前专门盘过一次，那次盘的是页面上看得见的部分；这一次盘的是根目录里看不见的部分，而后者的默认值往往更强硬。

131个站的 .well-known里到底放了什么？

下面这张表的“有”，指的是真的返回了内容。返回200但里面装着错误页的不算，后面专门有一节说这个。

最后那一列是关键。73个站有App深链文件，但抹掉域名和应用标识之后，只剩27种内容；71个站有安卓授权文件，只剩24种。

这个“抹掉域名再比”的动作是必须做的。上一轮做子域名与托管方那一轮的时候栽过一次：不抹域名直接比字节，91份文件比出82种，看着像“每家都不一样”；抹掉之后立刻收敛成个位数。文件里带着自己的域名，天然就长得不一样，这跟内容有没有区别是两码事。

为什么48个品牌对手机系统说了同一句话？

苹果那份文件的内容，48个站一模一样，89个字节：

{"applinks":{"apps":[],"details":[]},"webcredentials":{"apps":[]},"appclips":{"apps":[]}}

安卓那份更干脆，48个站的内容就是两个字符：[]。

其中47个站是两份都空的。也就是说，131个站里有47个，同时对苹果和安卓两套系统声明了同一件事：这个域名不关联任何应用。

真的往里面填了App信息的，只有25个站。

这48个空壳不是谁偷懒忘了填。它们是建站平台在开店时统一投放的，内容由平台决定，商家后台里通常连这个入口都找不到。就像你租了个商铺，房东在门口统一挂了块牌子写着“本店不接受预约”——牌子是标准制式的，字是房东写的，路过的人以为是你的意思。

空数组和404，机器看到的是同一个答案吗？

这是本文真正想说的那件事。

在人的世界里，“没这个文件”和“文件里是空的”差不多，都等于没配。在机器读的世界里，这是两个完全不同的答案。

按安卓的数字资产链接规范，assetlinks.json的作用是声明“这个域名把哪些权限委派给了哪些应用”。文件不存在，系统的结论是“这个域名没有做过声明，状态未知”；文件存在而且是个空数组，系统的结论是“这个域名明确声明：我不向任何应用委派任何权限”。

苹果那边是同一个道理。关联域名的文档说得很清楚，details数组里列的是哪些应用可以接管这个域名下的链接。空的details就是“没有任何应用可以接管”。

差别落到实处是这样：文件缺失是个开放状态，以后补上就行；空数组是个已完成的否定，系统会把它缓存起来当作答案。等品牌真上了App，工程师去配深链，会发现有一份写好的文件正在明确地拒绝这件事——而这份文件是三年前开店那天平台放的。

还有个更实际的差别：这两份文件都会被系统缓存。缺失的文件，客户端下次还会再试；已经拿到的空数组，会作为一个有效答案被记住一段时间。所以改了之后不是立刻生效，得等缓存过期，这个时间窗口在排查故障时很容易被误读成“改了没用”。

更普遍的道理是：面向机器的接口，沉默和否认从来不是一回事。页面上写没写清楚，人还能猜；结构化数据里声明没声明页面类型也是同一种性质的问题，机器不会替你补上默认值，它只会照着你给的答案往下走。

同样的道理在爬虫规则上更常见。一条写给没人读的爬虫的robots规则等于没写，而一条写错了的规则会被认真执行；分组之间不继承这件事也是同一类陷阱——你以为的默认继承，在规范里根本不存在。机器读的东西没有“想当然”这一说。

那个隐私声明里的日期，是谁写的？

还有一份文件把这件事演示得更直白。

gpc.json是全局隐私控制的声明文件，用来告诉浏览器和监管方，这个站承认并遵守用户的“不要卖我的数据”信号。47个站有这份文件，内容基本就一行：

{"gpc":true,"version":1,"lastUpdate":"2025-10-06"}

注意最后那个字段，最后更新日期。24个站写的是同一天，2025年10月6日。

24个互不相干的品牌，不可能在同一天各自决定更新自己的隐私偏好声明。这个日期是平台推送那一版模板的日子。

剩下的23个站分散在二十来个不同日期上，其中有2个站是2025年10月7日，也就是那次推送的第二天。

这份文件在合规上是有分量的：它是一个公开的、可被监管方引用的声明，说“我承认这个信号”。而这句话，以及它标注的更新时间，是平台代笔的。

一个刚出生的商业协议，怎么比正式标准多了6倍？

把两个数字放一起看，这轮最刺眼的对比就出来了。

一个2026年8月25日才发布版本号的商业协议，采集那天它上线才5天，覆盖率已经是那份四年前定案的正式标准的近6倍。

原因当然不是商家更重视前者。原因是前者由平台批量部署，后者需要人去写一个文本文件。一份文件的普及速度，跟它有多重要基本无关，跟有没有人替你按下部署按钮高度相关。

这个规律对做AI可见性的人来说有实际意义。2026年8月27日，OpenAI宣布ChatGPT的内置浏览器开始支持WebMCP，网页可以把自己的功能注册成工具，让代理直接调用，而不用靠模拟点击去猜。这条路走通的前提，是网站那一侧真的有东西可调。

本轮实测里，站点自己部署的代理接口描述文件只有1个站有。其余的接口能力，全部来自平台统一铺的那套。这跟上一轮量到的结论对得上：代理只能靠猜来用你的站，因为绝大多数站压根没给出可调用的接口。

这个协议本身值不值得关注是另一回事。它试图把商品、库存、下单这些动作标准化成机器能直接调用的接口，方向上跟选品逻辑从关键词转向结构化商品数据那条线是一致的。眼下值得记住的只有一件事：它已经替你上线了，而你可能不知道。

身份端点那份文件也是同一个故事。55个站有openid-configuration，抹掉域名和店铺编号之后只剩4种，其中52个站共用同一份模板。也就是说，一半的站对外公开了自己的登录体系描述，而这份描述由平台生成、指向平台的认证服务。这不是问题，但它清楚地说明了这批站的身份系统归谁管。

顺带值得对照的是AI爬虫那一侧的数字。AI爬虫的抓取量已经超过传统搜索引擎爬虫数倍，而站点用来告诉它们“我这儿有什么”的正式接口，覆盖率是0.8%。供需两侧的差距就是这么大。

谁在自己写llms.txt，谁在用平台给的模板？

llms.txt和agents.md这两份文件，覆盖率看着挺可观：71个站和57个站。但把内容拆开看，情况就变了。

判定方法很直接：平台生成的那一批开头是同一句固定话术，格式、小节、行文完全一致，只有品牌名不同；自己写的那些格式五花八门，有的按产品线分节，有的写成一段品牌介绍。

agents.md这一列尤其说明问题：57个站里，只有2个是自己写的。换句话说，这份文件的覆盖率几乎完全是平台刷出来的。

llms.txt好一点，21个站有自己的版本。这跟llms.txt到底有没有用那一轮的观察是一致的：真正在意这件事的站会自己写，其余的只是被动带上。做GEO落地的时候，光看“我们有没有这个文件”意义不大，得看这份文件是不是在说你想说的话。至于平台默认上线这类文件的意义，agents.md默认上线那次已经讨论过一轮，现在有了覆盖率数字，可以给出更确定的判断：默认上线解决的是有无问题，不解决内容问题。

那21份自己写的llms.txt也不都写得好。抽看下来，多数是把品牌介绍复制了一段进去，真正按“这个站有哪些板块、每个板块讲什么”组织的很少。链接指向哪里、路径是不是相对路径、有没有死链，这几件事更是没人查——校验器亮绿灯的时候链接可能全是死的，这个坑在自己写的版本里出现得更多，因为平台模板至少路径是程序拼的。

另外提醒一句，这些文件真被读到的证据一直是零散的。有过一个观察是浏览器的审计工具在悄悄查llms.txt，而搜索那一侧明确说过不需要。所以判断要分开：写它是为了让代理理解你，不是为了让搜索引擎给分。

那11份security.txt写得怎么样

只有11个站有安全联系方式文件。这11份的质量也参差不齐。

RFC 9116规定Expires字段是必填的，而且过期之后这份文件就不该再被使用。逐份查下来：

11份里有3份不合规：1份过期一年多，2份缺必填字段。还有1份把有效期写到8年后，虽然不违规，但这个字段的用意本来就是逼你定期回来确认联系方式还有效，写到2035年等于把这个机制关掉了。

另外有一份挺有意思：某个德国电商站的security.txt顶部用点阵字符画了一大幅ASCII艺术图。文件本身是合规的，内容也齐全，就是在一个纯给机器读的文件里塞了幅画给人看。这大概是本轮唯一一个能看出“有活人参与过”的痕迹。

UCP文件里为什么会有你没对外公布过的名字？

还有件事得单独提一句，因为它跟品牌形象直接相关。

那64份UCP文件里写着端点地址，而这些地址用的不是品牌的正式域名，是平台内部的店铺标识。53个站的内部标识跟自己的域名对不上。

能看到的形态大概有三类。一类是带着历史包袱的旧名字，比如某个鞋履品牌的内部标识是把品牌名前面加了个词，某个床品品牌后面跟着数字2。一类是纯随机字符串，六到八位，看不出跟品牌有任何关系。还有一类最尴尬，标识里带着dev、prod、admin、store这样的环境后缀，一眼能看出这个正式店铺是从哪个环境改过来的。

这些信息本来只在后台可见，现在通过一个公开路径原样输出。同一批站的域名验证记录那一轮也量到过类似的事——公开位置上留着当初随手写下的内部痕迹，只是那次是历史遗留，这次是平台正在实时输出。

要说清楚的是，这算不上安全漏洞。这些标识本来就不是密钥，知道了也做不了什么。但它确实构成一个信息面：任何人都能从公开路径判断出你用的什么平台、店铺开了多久、是不是从测试环境转正的。做第三方依赖排查的时候，这类路径值得一并列进清单。

返回200不代表有内容，这轮被挡下来的假阳性

这一节讲量具，因为不讲的话上面所有数字都不能信。

第一版跑完，某个眼镜品牌的16条路径里有15条返回200，看着像是把 .well-known建设得最好的站。点开一看，其中9条返回的是同一个172KB的前端框架错误页面——状态码200，内容是“页面不存在”。

另一个户外品牌更典型：8条路径返回200，内容全是同一段475字节的XML，写着对象存储的拒绝访问错误。也就是说，静态资源桶的权限配错了，本该是403的响应被包装成了200。

还有一个极端的：某相机品牌的 /.well-known/agent.json返回HTTP 200，响应体是 {"status":404,"error":"Not Found"}。状态码说有、正文说没有，两个答案由同一个响应给出。

所以判据分了三层：状态码必须是200；内容类型不能是HTML；正文里不能有自称404或访问被拒的结构。三层过完，“有内容”的数字才站得住。

还有一条容易漏的：请求必须跟随重定向。有两个站把所有 .well-known路径整体重定向到了区域子路径，一个跳到 /cn/，一个跳到 /global/。不跟随的话这两个站会被记成“什么都没有”，跟随之后才看得到真实情况。顺带说一句，把标准位置整体搬到区域路径下面，机器按规范去根目录找是找不到的，这本身就是个配置问题。

这类“看起来正常其实不正常”的响应，在robots那一轮也遇到过：规则写着允许、实际交付却进不去，声明和行为对不上。查任何面向机器的东西，都得把“它说什么”和“它实际给什么”分开测。

这轮判据一共改了6处，方向都是让数字变小：

最后一条是这轮最容易犯的错。第一版为了把内容归一化得干净，顺手把日期也替换成占位符了，结果gpc.json从22种收敛成2种，看着很漂亮，却正好把“24个站写着同一天”这个最有意思的发现抹掉了。归一化过度会把信号当噪音一起洗掉，这个度只能靠回头看具体样本来把握。

该怎么查，查完怎么办？

自查很快，十分钟够了。

第一步，把这几条路径在浏览器里挨个打开：/.well-known/security.txt、/.well-known/assetlinks.json、/.well-known/apple-app-site-association、/.well-known/gpc.json、/llms.txt、/agents.md。别只看有没有报错，要看内容。

第二步，判断每一份是谁写的。方法是拿同平台的另外两三个品牌站对一下同一条路径。内容一字不差就是平台的，不一样才是你的。

第三步，按下面这张表决定动不动。

保哥带的一个站上个月刚踩过第二行那个坑：App上线三个月，运营一直说站内链接分享到微信之外的渠道点开不进App，前端查了两轮没查出来。最后是在 /.well-known/apple-app-site-association里看到那份89字节的空壳——平台建站时铺的，App团队根本不知道有这么个文件，自然也没人去改。补上真实的应用标识和路径规则之后，深链当天就通了。

这件事的教训不在于哪个文件填错了，而在于：你域名下有一批你没写过的文件，正在替你回答问题，而且答的还挺肯定。做技术盘点的时候，把 .well-known加进清单，比多查十条meta标签有用。这类“不做也不报错、出问题时最难想到”的配置，正是建站第一年最容易隐性失分的典型形态。

还有两件事顺手提一下。一是隐私声明那份文件涉及合规表述，改之前最好让法务看一眼，别自己把日期一改了事——这类需要法务一起定口径的动作拆出来单独走流程更稳妥。二是如果你正在考虑要不要对AI爬虫收费或者设限，那么先把这套文件理清楚再谈，因为按次抓取那类方案的前提是你清楚谁在以什么身份访问你，而这批文件正是身份声明的一部分。

常见问题解答

.well-known里的文件会影响SEO排名吗

直接影响排名的没有。它影响的是另外几件事：App深链能不能用、安全研究者能不能找到你、隐私合规声明是否成立、AI代理能拿到什么样的接口描述。这些都不进排名算法，但都会影响真实的转化路径和风险敞口。

平台默认铺的那些文件，我能改吗

看平台和文件。App授权文件多数平台允许在后台或主题文件里覆盖；身份端点和商业协议端点通常锁死，改不了也不该改；llms.txt和agents.md大多可以自己覆盖。判断方法是先在后台搜文件名，搜不到就查平台文档，还是没有就说明锁死了。

assetlinks.json是空数组，会有什么实际后果

如果公司没有安卓应用，没后果。如果有，后果是安卓的应用链接功能不生效：用户点你的网页链接不会跳进App，密码自动填充的跨应用共享也不成立。更麻烦的是排查方向容易跑偏，因为文件是存在且返回200的，看起来不像故障。

为什么某个商业协议端点的覆盖率比正式安全标准还高

因为部署方式不同。前者是平台在所有店铺上统一开启的，商家不需要做任何事；后者需要有人写一个文本文件传上去。这个对比说明的是部署路径的差别，不说明哪个更重要。

security.txt值得补吗

值得，性价比很高。内容就是几行文本：联系方式、有效期、可选的策略页面和致谢页面地址，放到 /.well-known/security.txt就行。它的作用是在有人发现你的站有漏洞时，让对方知道该联系谁。没有这份文件，善意的报告经常最后石沉大海。要注意Expires是必填的，且别写太远。

怎么判断一份文件是平台给的还是自己写的

拿同平台的另外两三个品牌站对一下同一条路径。把域名和品牌名抹掉之后内容完全一致，就是平台的。这个“抹掉再比”的动作不能省，因为文件里几乎都带着自己的域名，不抹的话每份看起来都不一样。

返回200就算这个文件存在吗

不算。这轮实测里，每条路径都有8到15个站返回200但内容是前端框架的错误页，还有整站把对象存储的拒绝访问响应包装成200的，甚至有状态码200而正文写着404的。判据至少要三层：状态码、内容类型、正文里有没有错误结构。

权威参考资料