技术适配：让机器抓得到、读得懂

22抓取可达性：robots、UA 策略与蜘蛛日志

所有 GEO 工作的前提，是对方的机器人能进得来、读得到。听起来像常识，但在实际审计中，超过一半的企业站点存在不同程度的抓取障碍——有的把 AI 爬虫挡在门外，有的让爬虫陷进无穷的筛选参数里，有的把正文藏进了脚本。

先弄清楚谁来过

做任何判断之前，先看日志。服务器访问日志里记录了每一次请求的用户代理（User-Agent）、路径、状态码与响应时间。我们要找的是几类常见标识：搜索引擎蜘蛛（如 Baiduspider、Googlebot、Bytespider）、AI 平台抓取器（如各家大模型产品的抓取标识）、以及通用抓取工具。

日志分析要回答四个问题：有没有来（目标爬虫是否出现）、来了多少（日均请求量）、抓了什么（是首页还是正文）、结果如何（200、301、403、404、5xx 的分布）。如果某个爬虫从未出现，先查 robots 与 CDN/WAF 规则；如果来了但只抓首页，查站点结构与内链；如果大量 403，查防火墙与反爬策略。

robots.txt 的三个常见错误

错误一：一刀切封禁。为了防采集，直接在 robots 里写 Disallow: /，结果把所有爬虫都挡了，包括本该欢迎的搜索引擎与 AI 抓取器。防采集应该用限流、验证码、日志封禁等更精细的手段，而不是自断入口。

错误二：误封静态资源。有的规则封了 /assets/ 或 /*.css，导致爬虫无法获取样式与脚本，页面渲染判断出错。即使正文是服务端渲染，资源被封也可能影响质量评估。

错误三：规则互相覆盖。多条 User-agent 段落叠加，自己也不清楚最终生效的是哪一条。建议保持精简：一段通配规则 + 少量针对性规则，改完用工具验证实际生效结果。

UA 策略：要不要欢迎 AI 爬虫

这是近两年最现实的决策题。一部分内容方选择全面封禁 AI 抓取，理由是内容被无偿使用；另一部分选择开放，理由是希望被引用、被推荐。两种选择都合理，但必须想清楚商业目标。

如果企业的核心诉求是“被 AI 推荐、获得品牌曝光”，那么封禁等于主动退出这个入口；如果核心资产是付费内容、独家数据，封禁或限流是合理保护。折中的做法是分层：营销页、知识页开放；深度报告、数据库只开放摘要，正文需授权。这样既保留曝光，也保护核心资产。

把抓取预算当资源管理

爬虫每天的抓取量是有限的。如果站点有大量无价值页面（筛选页、空列表、重复标签页），爬虫会把预算耗在这些地方，真正重要的内容反而抓得少。管理抓取预算的做法包括：用 noindex 标记无价值页面、合并重复 URL、减少无意义的参数、把重要内容放在浅层目录。

一个实用指标是“有效抓取率”：抓取到的页面中，有多少是真正希望被索引的。低于 30% 就说明预算被浪费了，需要清理结构。

23渲染方式：SSR、SSG 与客户端渲染的现实差距

很多企业的网站很漂亮，但在爬虫眼里是一张白纸。原因不复杂：内容由 JavaScript 在浏览器里生成，而抓取器拿到的是空的容器。渲染方式决定了你的内容能不能被读到，这是一个纯粹的工程问题。

三种渲染方式的差别

服务端渲染（SSR）。服务器把完整 HTML 返回给客户端，浏览器拿到即可显示。对爬虫最友好，首屏快，缺点是服务器压力大、缓存设计复杂。

静态生成（SSG）。构建时生成 HTML 文件，直接由 Web 服务器返回。对爬虫同样友好，性能极佳，缺点是内容更新需要重新构建，适合内容相对稳定的站点。

客户端渲染（CSR）。返回一个空壳，由浏览器执行 JavaScript 拉取数据并渲染。对用户可能很流畅，对爬虫则高度依赖其是否执行脚本、等待多久、以及接口是否可访问。

现实中大量站点是混合模式：首页静态、列表页 SSR、详情页 CSR。这种混合最容易出问题——恰恰是最需要被引用的详情页，成了最难被抓取的部分。

一个简单的自测方法

关掉浏览器的 JavaScript，刷新页面，看还能不能读到正文。如果只剩导航和“加载中”，说明内容依赖脚本。再看“查看网页源代码”，搜索正文里的一个独特句子，搜不到就说明它不在初始 HTML 里。

这个方法不完美（有些爬虫会执行脚本），但它给出了下限：如果连不执行脚本都读不到，你就在赌对方一定会渲染。把关键内容放进初始 HTML，是更稳妥的选择。

渐进增强的落地路径

不必推翻现有前端框架，可以按优先级改造：先改详情页（最需要被引用的页面），把标题、正文、关键信息做成服务端输出；再改列表页，保证分页链接是真实可访问的 a 标签；最后改交互组件，让评论、问答等次要内容按需加载。

如果短期内无法改造，退而求其次的做法是提供“静态镜像”：为重要内容生成一份纯 HTML 版本，通过 canonical 指向主版本，或在页面中提供“无脚本可读”的正文块。这不是最优解，但比完全没有好。

别忽略“首屏可读”

即使做了服务端渲染，如果正文被巨大的弹窗、Cookie 提示、广告位挤到第三屏，用户体验与抓取质量都会受影响。抓取器虽然不受视觉影响，但页面结构混乱会导致正文提取困难；用户则直接离开。

建议把核心内容放在 DOM 的前半部分，交互组件延后加载，避免用大量的 div 嵌套包裹正文。语义化标签（article、section、h1-h3）不仅有利于无障碍访问，也有利于内容提取。

24结构化数据：Organization、Article、FAQPage 与 Book

结构化数据是把“人看得懂的文字”翻译成“机器看得懂的字段”。它不会直接让你被引用，但能显著降低机器理解你的成本，尤其在实体识别、问答匹配与内容分类上。

四种最值得先做的类型

Organization。描述品牌主体：名称、别名、logo、成立时间、地址、联系方式、统一社会信用代码。它解决“你是谁”的问题，是实体识别的地基。建议放在首页与关于页。

Article。描述文章：标题、作者、发布时间、更新时间、摘要、配图。它帮助机器判断内容的时效与责任主体，是知识型页面的标配。

FAQPage。描述问答对。它让机器明确知道“问题是什么、答案是什么”，是提升问答匹配率最直接的类型。注意答案必须与页面可见内容一致。

Book。描述长篇作品：书名、作者、版本、章节。适合白皮书、电子书、系列课程讲义，能帮助机器理解内容的整体结构。

写法上的四条纪律

纪律一：只写页面上有的东西。结构化数据不是“隐藏信息通道”，写进代码但页面看不到的内容属于违规，一旦被识别会损害站点信任。

纪律二：字段要真实、可核验。成立时间、地址、电话必须与工商信息一致；价格必须与商城一致；作者必须是真实主体。错误的结构化数据比没有更糟。

纪律三：一个页面一个主类型。文章页用 Article，问答页用 FAQPage，不要在一个页面里塞五种互不相关的类型。类型混乱会让机器无法判断页面性质。

纪律四：保持更新。价格变了、作者换了、服务期调整了，结构化数据要同步改。过期的结构化数据会直接导致 AI 给出错误答案。

验证与维护

上线前用官方或通用工具做语法校验，确认没有解析错误；上线后抽查搜索结果或平台展示，看是否被正确读取。建议把结构化数据纳入发布流程：每次改价格、改服务、改作者，都要检查对应字段。

维护上有一个简单原则：结构化数据应当由系统生成，而不是手工维护。手工写的 JSON 迟早会与页面内容脱节，最好的做法是从内容管理系统里直接取值，页面改什么，字段就跟着变什么。

25llms.txt 与 AI 友好声明：写法与预期管理

过去两年，围绕“给 AI 看的站点说明文件”出现了不少讨论。有人把它当成新的 robots.txt，有人认为是噱头。理性的态度是：把它当成一份低成本的“自我介绍”，有用，但别指望它决定命运。

它是什么

llms.txt 是一份放在站点根目录的纯文本文件，用简洁的结构告诉抓取方：这个站点是谁、主要内容是什么、哪些页面是权威事实源、如何使用这些内容。它的形式接近一份“内容索引 + 使用说明”，而不是访问控制。

与传统 robots.txt 的区别在于：robots 管“能不能抓”，llms.txt 管“抓什么更有价值”。前者是门禁，后者是导览。

一份合格的 llms.txt 应当包含

• 品牌与主体信息：名称、全称、成立时间、业务范围、联系方式。
• 核心事实源：官网首页、关于页、价格页、常见问答、资质页的具体链接。
• 内容分层说明：哪些是权威口径、哪些是科普、哪些是案例。
• 使用声明：允许抓取与引用的范围，转载要求，联系方式。
• 更新时间：让抓取方判断内容新鲜度。

写法上要克制：用短句、分点、明确的链接，不要写成营销文案。它服务的是机器与研究者，不是普通消费者。

预期管理：它能做什么，不能做什么

目前并没有统一的行业标准强制各平台读取这个文件，不同产品的支持程度也不一样。因此，它不能保证被读取，更不能保证被引用。把 llms.txt 当成“必然生效的开关”，是对机制的误解。

但它仍有实际价值：一是成本极低，写一次几乎不需要维护；二是对愿意读取的抓取方，它降低了理解成本；三是它迫使企业内部把“事实源在哪里”想清楚，这个梳理过程本身就有价值。

与其他声明配合

除了 llms.txt，站点还应当有清晰的版权声明、隐私政策、内容授权说明。这些文件既是合规要求，也是“责任主体明确”的信号。对 AI 抓取方而言，一个能说清楚“我是谁、内容怎么用”的站点，比一个只有营销页的站点更值得信任。

如果企业提供开放接口或数据服务，也可以在 llms.txt 中说明调用方式与限制。这类信息对开发者与研究型用户尤其有用，能带来意想不到的长尾引用。

26站点结构：目录树、主题簇与内链权重

结构决定了爬虫如何理解你的站点，也决定了用户如何找到内容。一个清晰的目录树能让重要页面被更快发现；一个成簇的主题结构能让机器确认你在某个领域的专业纵深。

目录树的三条原则

浅层优先。重要页面应当在三次点击内可达。层级过深会让抓取频率下降，也让用户迷失。常见做法是把核心业务放在一级目录，支撑内容放在二级。

语义命名。URL 应当能读出内容，比如 /whitepaper/、/faq/、/case/，而不是 /p?id=123。语义化 URL 对用户、对机器都更友好，也便于分享与引用。

稳定不变。URL 一旦确定就不要随意修改。改版时要做好 301 跳转，并保留至少一年。频繁变动的 URL 会让已建立的索引关系全部失效。

主题簇：从单篇到体系

主题簇（topic cluster）是指围绕一个核心主题，建立一个枢纽页加若干支撑页的结构。枢纽页回答“全景问题”，支撑页回答“具体问题”，彼此通过内链连接。

以 GEO 为例：枢纽页可以是“GEO 完全指南”，支撑页包括“GEO 与 SEO 的区别”“GEO 多少钱”“GEO 多久见效”“GEO 工具推荐”等。这样的结构让机器清楚看到：这个站点在 GEO 领域有系统性的内容，而不是零散几篇。

簇的价值在于互相加权：支撑页为枢纽页提供长尾入口，枢纽页为支撑页提供权威背书。孤立的文章即使质量不错，也很难形成这种效果。

内链的三个作用

内链不只是导航，它承担三个功能：传递权重（把重要页面的重要性传递出去）、建立语义关联（让机器知道两篇内容相关）、延长停留（让用户继续阅读）。

写内链时要注意锚文本。用“点击这里”没有任何信息量，用“GEO 与 SEO 的区别”则同时告诉用户和机器目标页讲什么。锚文本应当自然、具体、与目标页主题一致，避免全站用同一个词堆链。

清理结构债

运营久的站点往往积累了大量结构债：重复的标签页、失效的分类、内容雷同的聚合页、指向 404 的内链。这些东西会稀释抓取预算，也稀释主题权重。建议每年做一次结构审计，按“保留、合并、重定向、删除”四类处理。

删除要谨慎：有外链、有排名的页面优先做 301；完全没有价值的页面可以直接 410，告诉引擎“永久消失”，比留着 404 更干净。

27性能与稳定性：被引用之前的及格线

性能不是 GEO 的核心议题，但它是门槛。一个经常打不开、加载十几秒、移动端错位的站点，连被完整抓取都困难，更谈不上被引用。及格线以下的努力，都是浪费。

三个关键指标

首字节时间（TTFB）。服务器响应速度的直接体现。超过 800 毫秒就需要排查：是数据库慢、缓存没命中，还是机房网络问题。

最大内容绘制（LCP）。衡量主要内容多久可见。移动端建议控制在 2.5 秒以内。图片过大、字体阻塞、脚本过多是最常见的原因。

累积布局偏移（CLS）。衡量页面加载过程中的跳动。广告位、图片未设尺寸、动态插入的内容都会造成偏移，影响阅读体验。

这三个指标不需要追求极致，但必须达到“可正常阅读”的水平。为了一个分数去做过度优化，性价比并不高。

稳定性比速度更重要

对抓取器而言，一个偶尔 502 的站点比一个稍慢但稳定的站点更糟。频繁的 5xx 会导致抓取频率下降，甚至被判定为不可用。常见的不稳定来源包括：数据库连接池耗尽、内存溢出导致进程重启、第三方接口超时拖垮主流程、发布时全量重建导致服务短暂不可用。

解决办法因场景而异，但方向一致：把非核心依赖降级（接口失败时返回缓存或占位）、把发布做成灰度（先小流量验证）、把监控做在前面（异常时告警，而不是等用户投诉）。

移动端是主战场

AI 产品的使用场景高度移动化，用户在手机上提问、在手机上读答案。如果你的页面在移动端需要反复缩放、按钮点不中、正文被广告遮住，即便被引用，转化也会流失。

移动端优化不需要复杂技术：正文字号不小于 16 像素、行高适中、点击区域不小于 44 像素、避免横向滚动、首屏不放大图。这些细节做到位，体验就会明显改善。

把性能纳入发布流程

性能问题往往不是一次性修好的，而是每次发版都可能退化。建议在发布流程里加一道检查：核心页面在移动网络下的加载时间、图片大小、脚本数量。超过阈值就不允许上线。这道检查花不了多少时间，却能避免“越改越慢”的恶性循环。