近年来,人工智能助理和大型语言模型(LLM)在检索网页内容并进行摘要或推断方面扮演着越来越重要的角色。传统网页通常以 HTML、CSS 与大量脚本返回,这对人类浏览器是必要的,但对 LLM 来说往往是多余的。HTML 中的标签、样式与脚本会消耗模型的上下文令牌,使得处理同样文本所需成本上升。基于此,通过内容协商根据 Accept 请求头向 LLM 返回精简的 Markdown,可以显著降低令牌使用量,提高爬取效率,并有助于网站在 AI 驱动的检索场景中获得更好曝光。 内容协商并不复杂。HTTP 有一个标准的 Accept 头,客户端可以通过它表明自己偏好的响应媒体类型。
当 Accept 头中把 text/plain 或 text/markdown 列在 text/html 之前时,服务器可以选择返回文本或 Markdown 而非完整的 HTML 页面。这个策略不会影响普通浏览器,因为浏览器通常会将 text/html 放在优先位置;但对于明确表示偏好的爬虫和 LLM 智能客户端,返回 Markdown 可以带来显著优势。 静态站点生成器(SSG)例如 Astro、Gatsby、Hugo 等已经把内容生成为静态 HTML 文件。由 HTML 转为 Markdown 的关键点在于自动化转换流程。市面上有成熟的工具可以将 HTML 转成语义化的 Markdown,例如 html-to-markdown 类的 CLI 工具。构建流程里加入一个后置步骤,把生成的 HTML 批量转换为 Markdown 并保存到一个独立目录中,就可以在运行时根据 Accept 头选择对应目录下的文件来返回。
在构建系统中加入转换逻辑时,保持目录结构一致尤为重要。建议把 HTML 文件输出到一个目录,Markdown 文件输出到另一个目录,保证同一路径在两种格式下能够对应。这样,反向代理或边缘脚本只需要根据请求路径切换前缀即可定位到正确的文件。自动化脚本可以在构建完成后遍历输出目录,将 .html 文件转换为 .md,并将图片、附件等静态资源路径相对化,以确保 Markdown 中的引用在边缘环境下可正确解析。 对于使用 Cloudflare Workers、边缘计算或自托管反向代理的站点,内容协商的实现各有差异。以 Cloudflare Workers 为例,可以在边缘脚本中读取 request.headers.get('accept'),解析出优先级顺序,再决定是从 ASSETS 命名空间返回 Markdown 文件还是 HTML 文件。
实现时要注意路径解析与默认页处理,例如对根路径应返回站点地图(sitemap)或 Markdown 的 index.md,而不是直接返回 HTML。这样的设计让爬虫能在访问主页时快速获取所有链接,从而提升抓取效果。 若采用传统反向代理如 Caddy 或 Nginx,规则通常更为直接。Caddyfile 或 Nginx 配置可以基于请求头匹配 Accept 的优先级,重写请求路径指向 markdown 目录或 html 目录。Caddy 对请求头的匹配与重写语法较为友好,适合快速部署;Nginx 也能通过 map 与 try_files 实现相同功能,但配置会相对复杂。无论采用哪种服务器,务必在测试环境中用 curl 等工具验证 Accept 的顺序对响应结果的影响,例如 curl -H "Accept: text/markdown" https://example.com 来确认返回的是 Markdown。
关于缓存与性能,建议为不同格式的响应设置适当的缓存头。Markdown 版本通常是静态的,适合较长的缓存时间(例如 public, max-age=3600 或更长),而 HTML 页面若包含动态组件或个性化内容,缓存策略可能不同。边缘缓存和 CDN 可以缓存经过内容协商后的响应,但要确保缓存键包含 Accept 类型或其它区分标识,否则可能会出现格式混淆的问题。在 Cloudflare Workers 中,可以通过设置不同的路径前缀(如 /markdown 和 /html)来天然区分缓存条目,从而避免额外的复杂缓存逻辑。 从 SEO 与生成引擎优化(GEO)的角度来看,向 LLM 和爬虫提供 Markdown 有多重好处。Markdown 更接近语义化纯文本,去除样式与脚本干扰后能更准确、更快速地被模型解析。
根据一些实际测试,Markdown 可以带来数倍的令牌降低,从而降低抓取成本并推动更多的爬取。对于以 API 或按令牌计费的模型,令牌效率直接关系到抓取频率和覆盖面,间接影响被纳入训练语料或被助手引用的概率。 在实施过程中,有若干细节值得注意,以避免对用户体验或搜索引擎造成负面影响。首先,确保普通用户的浏览器仍然获得完整的 HTML 页面,不要通过错误的内容协商影响视觉体验。其次,为所有版本的页面设置正确的 canonical 链接与 metadata,避免搜索引擎因多版本而产生索引混乱。再次,robots.txt 与 sitemap 应清晰地指示爬虫如何访问 Markdown 与 HTML 版本,尤其是当你把站点地图放到根路径并优先对代理返回时,要保证 sitemap 的可读性和可访问性。
安全与隐私同样重要。将 Markdown 作为对 LLM 的专用输出并不意味着可以无差别泄露内部信息。边缘代码在根据 Accept 头选择内容时,应当沿用现有的访问控制逻辑,避免对未授权请求泄露敏感内容。对于会员或基于角色的内容仍需维持认证与授权检查。在日志与监控方面,区分来自自动化代理与真实用户的流量非常有用,可以用来分析 GEO 策略对流量结构的影响,并及时调整。 为了便于开发者上手,推荐以下实践。
首先,在本地与 CI/CD 中加入 HTML 到 Markdown 的转换步骤,并将生成的 Markdown 保留在构建产物中。其次,测试 Accept 头优先级的边界情况,例如当 Accept 头同时包含 text/markdown 与 text/html 时的先后顺序。再次,监控模型客户端的抓取行为,记录返回的响应类型以评估是否达到预期的令牌节省效果。最后,维护一套回退策略,当某个 Markdown 文件缺失时应优雅地回退到 HTML 以保证可用性。 示例性的 curl 测试命令能够帮助验证部署是否生效。可以使用 curl -H "Accept: text/markdown" https://你的域名 来检验 Markdown 返回,使用 curl -H "Accept: text/html" https://你的域名 来检验 HTML 返回。
重复不同组合的 Accept 值并观察服务器响应头中的 Content-Type 可以帮助排查内容协商逻辑是否正确。 对于想把该方案推广到多个站点或在团队内标准化的组织,建议把转换与边缘路由逻辑封装为可复用的脚本或模块。这样可以在不同项目间共享同一套构建插件与边缘代码,同时保证一致的缓存策略与监控接入点。此外,可以考虑把 Markdown 作为可选输出的标准接口,配合变更日志与部署说明,让站点维护者在发布内容时明确两种输出格式的差异与注意事项。 最后,衡量成果至关重要。比较实施前后的抓取频率、爬虫覆盖率、模型调用的令牌消耗与相关成本,是判断该策略是否值得推广的关键指标。
关注来自智能助手的访问量变化、搜索引擎爬虫的抓取日志,以及站点在被引用或摘要的频率,都可以作为效果评估的依据。长期来看,更高效的文本表示不仅能节省直接成本,还能提高被 AI 驱动工具引用的概率,从而带来额外流量与发现机会。 将网站为 LLM 优化并不是要牺牲人类用户体验,而是为不同的消费者提供更合适的表现形式。通过 Accept 头实现内容协商并返回 Markdown,是一条平衡成本、可维护性与可访问性的可行路径。实践中要注重自动化、缓存隔离、路径映射与安全策略的统一,最终目标是在不改变前端体验的情况下,让智能代理更高效地理解与传播你的内容。尝试在一两个页面上先行试点,观察变化并逐步扩展到全站,将能以稳妥的方式将 GEO 思维融入既有的站点架构中。
。
