边缘节点代做文本转换和程序自己出纯文本版本，建站时怎么选

建站时给智能体提供纯文本版本，有两条实现路径：一是边缘节点代做转换，源站不动、由中间层按需把网页转成文本；二是由程序自己输出纯文本版本。两者不是谁更先进，而是把控制权和成本放在了不同位置——代做省改造但受档位与体积限制，自建可控但多一份渲染与缓存成本。

两条路径各自做了什么

边缘代做的流程是：客户端带协商头表达偏好，边缘从源站拉原始网页、动态清理脚本样式导航后返回文本，源站不用改代码。有的托管平台对文档类域名默认开启、无需配置；有的要用户在控制台或规则里显式打开，并且限定在特定套餐档位。它的优点是零改造、覆盖全站，一条策略管所有页面。

程序自建转换则是源站自己按同一套协商逻辑，命中偏好时直接输出结构化的纯文本表示。内容给什么、留哪些字段、按什么层级组织，全在自己手里，代价是要多维护一份渲染逻辑与对应的缓存。

控制面差异：谁能决定给什么

这是两条路最本质的分水岭。代做路径里，清理范围由转换层定，源站只能被动接受；不过部分方案允许源站用自定义策略头覆盖默认，让「源站的策略才是权威」，从而绕过统一默认值——控制粒度就体现在这些响应头里。自建路径里，控制面完全在程序内，能精确决定每类内容对外呈现成什么样。

体积、缓存与一致性风险

代做有硬性体积上限——解压后的网页超过约六百万字节量级就可能转换失败，超大页面拿不到文本；这对内容密集的落地页是实际风险。自建路径同源渲染，输出与正文一致性更容易保证，但要多管一层缓存：文本版本和 HTML 版本要各自失效，否则会出现读者看到新版、智能体拿到旧版的错位。

一致性还有一层：地址不变、按偏好返回不同表示，是可取的设计。但一旦引入代做，安全头透传而实体标识、修改时间类头被移除，靠这些头做校验的链路要重新核对。

四类建站场景的选择建议

内容结构标准、以文章为主、不想改代码，选代做最省事。内容含大量自定义字段、需要精确规定给什么，走自建。已经用了托管边缘且套餐达标，代做几乎是免费增益。而部署方式会左右「改响应头有多容易」：如果站点是自托管、用 Docker 镜像或面板一键部署，源站在自己手里，自建一份纯文本输出、或给代做补上自定义策略头都不难；若完全托管、够不到源站配置，就只能依赖代做层给出的开关。GEO 侧别忘了两者都要配一份全站模型可读清单（llms.txt），它和单页文本转换互补——清单告诉抓取方整站有什么，转换负责单页按需呈现。

选型时该问的四个问题：这份能力要不要改代码、受不受托管档位限制、能不能精确控制输出内容、大页面会不会因体积上限失败。四个答案凑齐，路径自然就定了。

常见问题

问：完全托管、改不了源站，还有选择吗？ 答：基本只剩代做。能否开启、有没有档位门槛、支不支持自定义策略头，是这种情况下要确认的三点。

问：自建会不会和正文不一致？ 答：同源渲染时更可控，但要额外管好文本版本与 HTML 版本各自的缓存失效，避免新旧错配。

问：有了任一条路径，还要站点清单吗？ 答：要。单页文本转换管「这一页给纯文本」，全站模型可读清单管「整站有什么、从哪读」，两者对象不同，配合才完整。