如果你是一家面向北美、欧洲和澳洲市场的 B2B SaaS 或专业服务企业，官网可能由 React、Vue、Headless CMS，或经过深度定制的 WordPress 搭建。用户打开产品页时，可以正常看到功能介绍、服务范围、FAQ、价格说明和行业解决方案，但当团队查看网页源代码、使用 curl 请求，或把页面交给文本提取工具时，拿到的却可能只有标题、页面容器、导航和页脚。
人能看到内容，不等于抓取系统能稳定获得内容。
我看到不少 B2B 出海企业在排查 GEO 问题时，会先去改文章、补关键词或增加页面数量。但当官网依赖 JavaScript 加载核心信息时，问题可能不在内容数量，而在内容能不能被稳定读取。对这种场景，我通常会先检查“用户可见内容”和“抓取可得内容”之间的差异，再决定是调整技术架构、页面模板，还是内容结构。
为什么页面显示正常，抓取结果却可能只有一个空壳
服务器首次返回的 HTML 不包含主要正文
用户访问一个网页时，浏览器首先向服务器请求 URL。理想情况下，服务器返回的 HTML 中已经包含产品定位、服务说明、FAQ 和关键结论。但在部分 React、Vue 或 Headless CMS 网站中，服务器返回的可能只有标题、空容器节点和 JavaScript 文件地址。
产品介绍、价格说明和服务范围，要等浏览器下载脚本、执行脚本并调用内容接口后，才会写入页面。普通浏览器通常能够完成这一过程，但部分抓取系统可能不会执行全部脚本，也可能不会等待所有异步请求完成。最终得到的页面，就只剩下外层框架。
内容依赖额外条件才会出现
有些页面虽然会加载正文，但内容出现需要额外条件。例如用户必须滚动到某个区域、点击标签、展开折叠模块，或者接受 Cookie 后，脚本才会继续请求内容。
页面还可能根据登录信息、本地存储、浏览器语言或地区判断返回不同内容。懒加载模块只有进入可视区域后才开始请求正文。如果抓取请求无法触发这些条件，就可能只能获得不完整内容。
安全配置让不同访问者得到不同结果
CDN、WAF 或 Bot 管理策略可能针对不同 User-Agent 返回不同页面。普通浏览器可以获得完整内容，但自动化请求可能收到验证码、挑战页面、空白响应、403 或 429 状态。
内容接口也可能存在跨域限制、鉴权要求、频率限制或地区规则。团队在自己的浏览器中测试正常，并不能证明无 Cookie、不同地区和不同 User-Agent 的请求也能获得相同正文。
需要注意的是，HTTP 状态码为 200，不代表正文已经成功返回。页面进入搜索索引，也不代表其中每一段内容都能被稳定提取。页面可以被访问，也不等于页面结构足以支持准确理解。
如果官网较少被 ChatGPT、Gemini、Google AI Mode、Perplexity 或 Google AI Overview 引用，可访问性可能是原因之一，但不能只凭引用变化判断技术问题。引用结果还会受到问题表达、页面质量、外部来源和平台更新等因素影响。
不要先改内容，要先确认内容在哪个环节消失
在我们的方法论里，这类问题通常按照以下顺序检查：服务器响应、原始 HTML、JavaScript 与 CSS 资源、渲染后 DOM、内容接口、安全策略和服务器日志。
重点不是判断网站用了什么框架，而是确认核心信息在哪个环节出现，又在哪个环节消失。只有把问题位置缩小，开发团队和 GEO 团队才能选择合适的改造方式。
判断一：内容有没有从服务器直接返回
先获取核心 URL 的原始响应，并搜索产品名称、服务类型、FAQ 问题或一段有辨识度的正文。
如果原始 HTML 已经包含主要内容，问题可能发生在文本解析、页面结构或安全配置，而不一定是客户端渲染。如果原始 HTML 中只有空容器，就需要继续检查 JavaScript 和内容接口。
判断二：内容能否在无交互条件下完成加载
新建无痕窗口，清除 Cookie，不登录、不滚动、不点击标签，也不展开弹窗，观察产品介绍、服务范围和 FAQ 是否仍会自动出现。
如果核心信息必须通过滚动、点击或 Cookie 授权才进入页面，那么抓取系统就可能无法稳定获得这些内容。需要优先调整内容的默认加载方式。
判断三：资源和接口有没有稳定返回
打开浏览器开发者工具，检查 JavaScript、CSS、字体、图片和内容 API。重点查看是否存在 4xx、5xx、跨域错误、请求超时或加载顺序异常。
还要确认内容接口是否要求 Token、Session、登录状态、特定请求头或本地存储信息。有些页面框架加载成功，但负责返回正文的接口没有响应，最终仍然只有空页面。
判断四：不同请求是否得到不同页面
使用不同 User-Agent、无 Cookie 环境，以及不同地区或网络条件请求同一个 URL，然后比较状态码、响应体大小、正文数量和资源请求数量。
如果普通浏览器获得的是完整页面，而自动化请求获得的是验证页面或明显较小的响应体，就要优先检查 CDN、WAF 和 Bot 管理规则。
判断五：技术可访问后，内容是否仍然值得引用
技术可访问只是基础条件。页面还需要清楚表达产品定位、服务范围、适用对象、地区范围、使用场景和差异点。
如果关键结论只存在于图片、Canvas、视频或交互组件中，抓取系统仍然可能无法理解。页面也需要有明确的标题、段落、列表、问答结构和实体信息，避免正文被导航、页脚和模板内容淹没。
五组排查与改造动作：从确认问题到恢复内容可提取性
动作一：对照原始 HTML、渲染后 DOM 与正文文本
对同一个 URL 生成三份结果：服务器首次返回的原始 HTML、浏览器执行脚本后的 DOM，以及去掉导航、样式和脚本后的正文文本。
原始 HTML 可以通过 curl、浏览器 View Source 或抓取工具保存。渲染后 DOM 可以在开发者工具的 Elements 面板中查看，也可以使用支持 JavaScript 的无头浏览器生成。正文文本则用于检查页面中的主要信息能否被连续提取。
三份结果需要搜索同一组识别点，例如产品名称、服务类型、FAQ 问题和关键结论。
如果原始 HTML 没有正文，但渲染后 DOM 有，说明内容主要由客户端生成。如果渲染后 DOM 已有正文，但文本提取结果仍缺失，问题可能在页面结构、隐藏属性或模板噪音。如果三份结果都没有内容，就要继续排查内容接口、权限和地区逻辑。
这种对照可以避免把“正文缺失”“脚本没有执行”和“正文结构不清楚”当成同一个问题。
动作二：检查 HTTP 响应与抓取控制指令
确认核心 URL 能稳定返回 200，并检查是否存在多次重定向、软 404、登录跳转、地区跳转或安全验证页面。
有些页面表面上能够打开，但自动化请求会被引导到另一个版本。例如访问者被跳转到地区选择页、Cookie 页面或账号登录页，最终获得的正文就会与普通用户不同。
随后检查 robots.txt 是否错误限制页面、脚本目录或接口路径，再检查页面中的 meta robots 和响应头中的 X-Robots-Tag。桌面端、移动端和无 Cookie 请求应分别测试，不能只验证一种环境。
这一动作主要用于定位抓取被阻止、请求被改写，或核心资源无法访问的问题。
动作三：排查 JavaScript、资源文件与内容接口
在 Network 面板中筛选 JS、Fetch 和 XHR 请求，查看正文依赖的脚本和接口是否能够稳定返回。
检查过程中，要记录 4xx、5xx、跨域错误和加载超时。暂停滚动、点击和 Cookie 授权，观察正文接口是否仍然会自动请求。使用较慢网络环境重新加载页面，也可以判断内容是否因为等待时间不足而缺失。
如果网站使用 Headless CMS 或自研内容接口，还要检查 API 是否要求登录状态、Token、Session 或特定请求头。部分网站在浏览器中能够正常显示，是因为用户此前已经留下 Cookie 或本地存储信息，但新的抓取请求并不具备这些条件。
还可以暂时关闭部分第三方脚本，观察是否有广告、追踪或聊天工具的报错阻断后续渲染。页面主体可能依赖多个资源，只要其中一个关键脚本失败，浏览器仍然可能显示页面框架，但正文不会出现。
动作四：把需要被理解的内容调整为服务器可输出形式
产品定位、服务范围、适用场景、FAQ、价格说明和关键结论，应尽量进入首次 HTML，或者通过稳定的渲染方式获得。
根据网站架构，可以选择服务端渲染、静态生成、增量静态生成或重点页面预渲染。使用 Headless CMS 的网站，可以设置能够直接输出到 HTML 的正文区域。如果网站不适合全面改造，可以先为重要产品页、服务页和 FAQ 页提供稳定的静态内容版本。
内容层面也要同步调整。不要把关键结论只放在图片、Canvas 或视频中，也不要把主要说明隐藏在必须点击的弹窗或标签页里。页面应使用清楚的 H1、H2、段落和列表。
FAQ 页面可以根据实际内容采用合适的结构化数据，但结构化标记不能代替页面正文。产品和服务页面也可以补充与真实内容相符的 Organization、Product、Service、Article 或 BreadcrumbList 等 Schema。
这样做的目的不是迎合某一个平台，而是让不同访问环境都能获得一致、可识别的核心信息。
动作五：检查 CDN、WAF 与服务器日志
使用不同 User-Agent、无 Cookie 和不同地区环境请求同一个页面，对比普通浏览器和自动化请求的状态码、响应体大小和正文数量。
重点检查是否出现验证码、挑战页面、403、429、空白响应或内容降级。随后进入 CDN 和 WAF 配置，核对 Bot 管理、频率限制、IP 规则和地区策略。
服务器日志可以进一步说明真实访问结果。检查请求时间、来源、User-Agent、状态码、响应大小和接口调用情况，可以判断抓取请求是否到达服务器、是否成功返回正文，以及是否在某个资源请求阶段失败。
对于确认属于正常访问的抓取请求，可以设置更合理的规则，但不建议为了提高可访问性直接关闭安全防护。更合适的做法是先明确哪些请求被错误拦截，再有针对性地调整。
技术改造完成后，不能只测试页面能不能打开
技术修复不是交付终点。完成调整后，需要分别监测页面响应、内容提取和 AI 引用三个层次。
第一层：页面响应监测
建议记录 HTTP 状态码、重定向次数、响应时间、HTML 响应体大小，以及主要脚本和接口的失败情况。同时比较不同 User-Agent、Cookie 状态和地区环境下的响应差异。
如果状态码正常，但响应体突然明显变小，或者关键接口开始出现超时，也可能说明页面正文再次缺失。
第二层：内容提取监测
为每个核心页面设置固定检查项，包括产品定位是否能被提取、服务范围是否完整、FAQ 问题和回答是否存在、标题层级是否清楚，以及正文是否被导航和模板内容淹没。
还需要比较首次 HTML 与渲染结果，确认两者的主要信息保持一致。可以每周抽查一组核心 URL，并在模板、CMS 或前端组件改动后进行回归测试。
第三层：AI 引用监测
围绕真实用户问题建立查询集，例如“某类 B2B SaaS 适合哪些企业”“某项专业服务包含哪些内容”“两类解决方案有什么区别”“选择供应商时应评估哪些条件”。
海外这边，可以分别观察 ChatGPT、Gemini、Google AI Mode、Perplexity 和 Google AI Overview 是否开始读取官网产品页、服务页、FAQ 页或行业解决方案页。
平台回答会受到问题表达、地区、时间和可用来源影响，因此监测重点应放在趋势、引用页面类型和内容缺口，而不是承诺固定出现。
如果 HTML 已完整但文本提取仍然较差，应调整标题、段落和正文结构。如果正文依赖接口，应优先处理接口权限和服务器输出。如果只有部分地区失败，需要检查 CDN 和地区规则。如果页面已经可以提取，但相关问题中仍然较少出现，就要补充问题型内容、比较说明、适用场景和事实依据。
这类技术问题修复后，可以观察哪些阶段性变化
下面的区间是基于行业技术实施过程进行的方法论推演，不代表固定结果。通常服务器响应和正文提取会先改善，AI 提及与页面引用的变化出现得更晚。
| 观察维度 | 优化前的典型状态 | 优化后的合理状态区间 | 常见观察周期 |
|---|---|---|---|
| 原始 HTML 内容 | 主要只有页面框架、标题或容器 | 主要产品、服务、FAQ 和场景说明可在首次 HTML 或稳定渲染结果中获得 | 1—4 周 |
| 页面响应稳定性 | 部分请求出现空页面、资源失败、安全验证或不同版本 | 核心页面较稳定地返回 200，异常响应和内容差异逐步减少 | 2—8 周 |
| 正文提取完整度 | 抓取结果以导航、页脚和通用模板为主 | 主要标题、服务说明、FAQ 和关键结论可以被连续提取 | 2—8 周 |
| AI 提及与页面引用 | 高相关查询中较少引用官网页面 | 部分相关问题开始引用产品页、服务页、FAQ 页或行业解决方案页 | 8—12 周或更长 |
| 团队排查效率 | 遇到问题后反复改内容或依赖单次测试 | 能根据服务器响应、HTML、资源、接口、安全策略和日志缩小问题范围 | 4—12 周持续改善 |
1—3 周通常用于完成抓取、渲染过程和服务器配置的系统检查。4—8 周通常用于完成核心模板的服务端渲染、静态生成或预渲染调整。8—12 周或更长时间用于观察内容提取稳定性和 AI 引用变化。
如果网站模板复杂、页面数量较多或涉及多地区部署，周期可能进一步延长。技术可访问性是必要条件，但不是引用结果的承诺。页面内容质量、问题相关性和外部信息一致性，也会影响后续表现。
B2B 出海网站渲染问题排查清单
- 使用 curl 或同类工具保存核心 URL 的原始 HTML，并搜索产品名称、服务描述和 FAQ 文本。
- 对照浏览器渲染后的 DOM，确认缺失内容由服务器返回，还是由客户端脚本生成。
- 在无 Cookie、未登录、不滚动和不点击的条件下重新测试页面。
- 检查页面、JavaScript、CSS 和内容接口是否存在 4xx、5xx、跨域错误或超时。
- 核对 robots.txt、meta robots 和 X-Robots-Tag，确认页面及主要资源没有被错误限制。
- 使用不同 User-Agent 和地区环境请求页面，比较状态码、响应大小和正文数量。
- 将产品定位、服务范围、FAQ 和关键结论放入首次 HTML 或稳定可渲染的正文区域。
- 检查 CDN、WAF 和服务器日志，确认正常抓取请求没有被验证码、频率规则或地区策略拦截。
- 为核心页面建立每周回归测试，记录响应状态、正文提取和 AI 引用页面变化。
- 技术修复后重新评估内容结构，补充问题型标题、明确回答、事实依据和适用场景。
当官网在浏览器中显示正常，但抓取工具只能获得页面框架时，继续增加文章不一定能解决问题。更合适的做法，是先选择 5—10 个核心产品页、服务页和 FAQ 页，确认内容在服务器响应、原始 HTML、资源加载、渲染结果、内容接口还是安全策略中出现了缺失。
如果你正在判断要不要做 GEO，先做一份基线诊断——自己手动测或用我们免费 Audit 都行。我们团队在 GEO 领域有多年实战经验，会从技术访问和内容可理解性两个方向整理问题清单，但不会对具体平台的引用结果作固定承诺。
相关问题
页面可以被 Google 收录，为什么 AI 工具仍可能抓不到正文？
收录通常只能说明页面曾被发现和处理，不代表所有正文都能在不同抓取环境中稳定获得。如果主要内容依赖 JavaScript、接口权限或交互触发，部分系统可能只能读取页面框架或不完整文本。
React 或 Vue 网站一定要改成服务端渲染吗？
不一定。需要先检查核心内容是否已经存在于原始 HTML、渲染是否稳定，以及接口和安全策略是否正常。只有确认客户端生成方式持续影响内容提取后，才需要评估服务端渲染、静态生成或预渲染。
为什么 curl 返回空内容，但浏览器里页面是完整的？
curl 默认不会像浏览器一样执行 JavaScript。如果服务器只返回页面容器，正文由脚本调用接口后生成，curl 得到的内容就可能很少。这说明需要继续检查渲染方式，但不能单凭一次请求判断整个页面无法抓取。
robots.txt 没有禁止抓取，为什么页面还是提取不完整？
robots.txt 只是一个检查点。页面还可能受到 meta robots、X-Robots-Tag、接口鉴权、跨域配置、懒加载、Cookie 条件、CDN 或 WAF 策略影响，需要结合资源请求和服务器日志排查。
修复 JavaScript 渲染后，多久可能看到 AI 引用变化？
技术访问和正文提取通常可以在 1—8 周内分阶段验证。AI 引用变化可能需要 8—12 周或更长时间，并受到问题相关性、页面质量、平台更新和其他可用来源影响，因此应观察趋势，而不是固定次数。
GEO 团队和开发团队应该怎样分工？
GEO 团队负责定义需要被提取的页面、关键内容和测试查询，并建立检测基线。开发团队负责检查服务器输出、资源请求、接口权限、渲染方式和安全配置，双方再根据监测结果共同安排模板和内容调整。
