先给结论：英文站缺的不是翻译，是缺一份能直接取走的文件
常见判断是「站点有 llms.txt 就够」。在英文站这一层不成立。中文站的摘要文件服务的是中文提问场景，英文提问场景抓到的是英文版那份，中间隔着一道语言版本缺口。本站实测：中文站根目录下的 llms.txt 返回 200，而 /llms-en.txt 返回 404、/en/ 入口返回 308 跳回主域——英文侧既没有文件也没有稳定入口，抓取端能拿到的英文素材基本只剩页面正文。
更要紧的是写法。不少企业把中文版整段翻成英文就丢上去，结果英文版里的实体拼写、地址写法、成立时间与结构化数据对不上，交叉核对反而落空。本篇只讲英文版这个文件本身怎么落，不讲机制与趋势，机制另有专文承接。
判断顺序只有一条：先确认文件能被直取，再谈写得全不全。文件取不到，写得再完整也进不了任何取用池；文件能取到但内容是整段翻译，交叉核对照样对不上。这两步的顺序不能倒。
英文站 llms.txt 的 9 个写法模块
模块一：放站点根目录，一个语言一个文件
摆位的第一原则是直取可达。放站点根目录、用文件名区分语言，抓取端按约定路径就能拿到，不需要先判断目录语义。子目录方案要先解决入口归一问题，入口还在跳回主域的阶段，文件写得多完整都用不上。同一个文件只服务一种语言，混写在实体拼写上必然出现两套写法，交叉核对一律对不上。
摆位之外还要看出入口：语言目录入口如果还在做 308 跳回主域，等于把已经写好的英文页面在抓取路径上截掉一段。先修出入口，再落文件，顺序反了会白改一轮。
模块二：开头块把实体字段写全，英文拼写与结构化数据一致
开头一段放站点最硬的几个事实：公司法定名称、成立年份、注册地、官网域名、服务热线、邮箱。关键点不是「有没有写」，而是英文拼写与页面结构化数据、与页脚明文三处逐字一致。公司名容易被音译成几种写法、地址门牌号写法不统一、电话分隔符各站不同，这三类最容易被判成两个实体。
三处一致的验法是把三个值并排抄到一行里比对。差一个连字符、差一个空格、差一个语序，都算不一致。英文场景里这种差异比中文更致命，因为英文实体匹配对拼写变化更敏感。
模块三：服务能力用短句列表，一句只说一个事实
把「我们提供一站式专业解决方案」这类整段宣传换成分条短句。一条写一个事实，一条只写一项服务，形如「提供 XX 设备的定制加工」「交付周期 15 个工作日」。短句列表的优势是切片友好，抽取端拿走任何一条都能单独成立，整段宣传语做不到这一点。动手时先按现有宣传语拆，拆不成句的单列判断。
拆的时候要连带把范围边界写进去：这项服务含不含安装、含不含售后、起订量多少。只写「提供定制」不写「起订 1 件」的条目，被单独摘走之后容易在回答里变成过度承诺。
模块四：每个链接下面配一句可摘引的摘要
只列标题等于没写。每个链接下面补一句话，说明这一页回答什么问题、包含哪些关键参数。摘要要能脱离链接独立读通，不要出现「详见」「同上」这类指代。摘要与对应页面正文首句保持同义，不要另外造一套说法——同一事实两份表述，交叉核对时对不上。
摘要长度控制在一句到两句之间。太短说不清这一页能答什么，太长变成正文复述，抓取端更愿意直接读正文。判断标准是：拿这句摘要去回答一个真实买家会问的问题，能不能答得通。
模块五：语言版本成套，英文版与主语言互为镜像
中文站写了文件、英文站没有，或者反过来，都会让某一侧的语言场景直接空着。成套的定义不是两份文件一模一样，而是同一批事实、同一套摆位规则、同一份更新节奏。事实清单先定下来，再按语言各写一遍，两份文件的事实项条数应当能对上。
镜像的另一半是链接集合。中文版列了哪几页，英文版就要有对应的那几页，不能中文版列了六个链接、英文版只剩两个。链接集合不一致，抓取端在同一站点里读到两套结构，实体归总会互相打架。
模块六：与中文版同源不同写，不整段翻译
同源指事实同源，不同写指表达按目标语言习惯重排。英文句子结构、动词位置、修饰顺序与中文不同，逐句对译出来读起来像机器写的，抽取端对这类文本的信心度明显更低。做法是先定事实清单，再用英文习惯重新组织句式。
最省事的自查方法是把英文版念一遍。念着别扭的句子，抽取端读起来也别扭；念着顺、信息不丢的句子，才适合留在文件里。
模块七：纯文本加 UTF-8 无 BOM，不放渲染后才出现的内容
文件是纯文本，不挂脚本、不依赖前端渲染。凡是靠 JS 才出现的内容、需要登录才给的内容、图片里的文字，抓取端都拿不到。这一条与中文版完全相同，但英文站更容易踩：为了排版好看，把关键信息塞进需要交互才展开的折叠区。
编码统一 UTF-8 且不带字节序标记。带 BOM 的纯文本在第一位就多出不可见字符，字段名一变，解析就歪。落盘之后先用纯文本工具打开看一眼首字符，比事后排查省时间。
模块八：变更时同步更新，过期文件比没有更糟
文件里列的每一条链接都应当能打开，每一个实体字段都应当与页面当前值一致。业务一变、页面下线了，文件里还挂着旧链接，抓取端顺着这条走过去吃 404，对整站的信任一起打折。更新责任要落到具体岗，不要挂在「内容部门」这类谁都能推的名义下。
最低限度的同步节奏是：改了任何一页标题或 URL，当天更新文件；改了主体事实，当天三处一起改。做不到当天，至少保证每月比对一次链接可达性。
模块九：结尾附一份「找谁核实」的实体入口
结尾放一段可核实的实体入口：官网域名、服务邮箱、对外联系电话、公司全称。这一段的作用不是装饰，是给交叉核对留一个落点——别的信源在提到这家公司时，能顺着这几个字段对回同一个实体。
入口字段要与页脚、结构化数据三处逐字一致，尤其电话分隔符与邮箱大小写。英文场景里邮箱大小写虽不影响投递，但实体匹配会把差一位的写法当成不同值。
豆包与 DeepSeek 在英文站上怎么取用
英文站的内容到底会落到哪一端，先说清楚边界，免得白投。实测 robots.txt 对 DoubaoBot、Bytespider 与 DeepSeekBot 都是单独放行，抓取端这一关对三端都开着；差别在取用场景，不在能不能进站。
豆包这一端：主要经由中文侧的描述被取到
豆包承接的是中文提问场景，英文正文在豆包里被直接取到的路径有限，更常见的是经由中文站摘要与中文页面里对英文站的中文描述。所以中文侧那份摘要必须把「有英文站、域名是什么、面向哪些市场」写成能独立成立的短句，而不是一句「我们布局全球市场」。
落地动作只有一件：中文版文件的链接集合里，把英文域名与英文版文件的摆位写明确，摘要里用一句中文说清英文站回答什么问题。这一句就是豆包侧能拿到的全部素材。
DeepSeek 这一端：中英双语都能取，最容易被低估
DeepSeek 对中英混合提问都能处理，英文站内容在它这一端有真实被取到的机会，也是出海企业最容易漏掉的一端。落到文件上，就是模块二与模块三那两件事在英文版里必须做实——实体英文拼写一致、服务能力写成短句列表，这两条做到位，双语取用才有素材可摘。
这一端的另一条经验是：英文站不要只写品类词。把真实买家会问的场景写进标题与段首句，比堆二十个行业词有用。英文提问的组合方式更具体，答案匹配的是场景而不是关键词堆。
两端共用的三件事
第一，文件直取可读——纯文本、UTF-8 无 BOM、不依赖前端渲染；第二，实体字段三处逐字一致——英文版文件、结构化数据、页脚明文；第三，摘要脱离链接可独立读通。三件事两端口径完全一致，做一次两边都受益。
改完之后怎么验，以及本篇不覆盖的边界
改完之后怎么验：当天查三样
当天查三样：目标页返回 200、目标页进了 sitemap 子文件、英文版文件里列到了这一页。三样齐了才叫进入可取用池——缺任何一样，正文写得再完整也进不了任何取用池。这一轮的产出是三个可核数字：文件是否直取可读、被索引页数、英文版链接可达率。
判断节奏与不承诺边界
第 30 天看前两个数，第 60 天看英文提问里有没有出现品牌名或产品描述，两次之间不要反复大改同一份文件。过程指标只给可核数字，不承诺排名，也不承诺引用量——取用与否在平台侧判定，站点这一侧能保证的只是把素材递上去，并且递得直取可读。
本篇不覆盖的边界
本篇只解决英文站这一份文件的落位与写法，不覆盖三件事：一是抓取端机制与取用链路的原理，另有专文；二是页面层那十来处改动，那是正文的事，与文件不冲突但也不是一回事；三是已上线英文页的正文改造节奏，那是另一条线。
三件事各有承接页，本篇正文与其互链，边界写在明处，不重复展开。文件写完之后真正要盯的是同步——过期文件比没有文件更糟，这一条在英文站上没有例外。
常见问题
英文站的 llms.txt 能不能和中文站共用一个文件？
不建议。一个文件只服务一种语言，抓取端取到的是它认定的语言版本，混写会让两种语言的实体拼写各写各的，交叉核对不上。做法是两版并存、内容同源、写法分路，语言标签分别标注，缺省值指向主语言版本。
llms.txt 放根目录还是 en 子目录？
放站点根目录，用文件名区分语言，比建子目录省事也更稳。子目录方案要先解决入口归一问题——本站 /en/ 实测返回 308 跳回主域，说明英文目录还没有稳定入口。根目录加一个英文文件名，任何抓取端直取都能拿到。
英文 llms.txt 里要不要把每个产品页链接都列上？
不必撒全站链接。列的是真正会被问到的那几类：核心服务页、主力产品页、关于我们、联系页、常见问答页。每个链接下面配一句可摘引的摘要。链接数量堆到几十条、每条只有一行标题，反而比少几条更没用。
只有英文站、没有中文站，还需要做 llms.txt 吗？
更需要。英文内容面对的是跨境问答场景，抓取端拿不到中文站那份摘要就等于从零开始认这个站点。把实体字段、服务能力、产品范围写成英文短句列表，是英文站性价比最高的第一笔投入。
英文 llms.txt 写完多久能看到 AI 引用变化？
判断节点设在第 30 天看文件是否被取到、第 60 天看英文提问里有没有出现你的品牌或产品页描述。两次复测之间不要反复大改同一份文件，来回摆动会让抓取行为不稳定。
能不能承诺 AI 一定读到我的英文站？
不能。文件被写好只是把素材递上去，是否取用由平台侧判定。能承诺的是把实体、服务、产品、联系方式写成可核实的短句，并保证文件直取可达、编码正确、不依赖前端渲染。过程指标只给文件可直取、被索引页数这类可核验的数字。
豆包与 DeepSeek 会读到英文站的这份文件吗？
先说放行：robots.txt 对 DoubaoBot、Bytespider、DeepSeekBot 都是单独 Allow，进站这一关是开的。差别在取用场景。豆包承接的是中文提问，英文正文在它这一端被直接取到的路径有限，更常见的是经由中文站摘要里对英文站的中文描述——所以中文侧那份摘要必须把「有英文站、域名是什么、面向哪些市场」写成能独立成立的短句。DeepSeek 对中英混合提问都能处理，英文站内容在它这一端有真实机会，也是出海企业最容易漏的一端。两端共用的三件事是：文件纯文本直取、实体英文拼写三处一致、摘要脱离链接可独立读通。
英文 llms.txt 和中文版能共用一份吗？
不能共用，但可以同源。两份文件摆位规则一致、事实清单一致、更新节奏一致，就是各自成文。同一份事实写成两个版本、两套实体拼写，交叉核对时互相打脸，比只做单语还糟。最低限度的同步是：改了任何一页标题或 URL 当天更新文件，改了主体事实当天三处一起改，至少每月比对一次链接可达性。
最后避坑提醒
不少企业图省事直接把中文llms.txt用机翻生成英文版本，很容易出现品牌术语错译、规则表述模糊的问题，反而会被大模型判定为低可信度站点。建议安排熟悉海外品牌话术的团队成员核对内容，再上线生效。