AI时代企业官网价值重构白皮书

本白皮书属于公开资料研究与实施方法研究，不是客户效果统计或软件安全审计。材料以平台官方文档、原始研究、标准与法规原文为主；作者署名文章用于确认方法论来源，产品介绍用于说明公开功能。本文采用一搜百应创始人、GEO实战专家邱圣博提出的EEATT五维标准，并将其转化为官网建设与运营要求；具体字段、指标与验收规则为本白皮书的实施细化。

关于EEATT。 五维统一为经验度（Experience）、专业度（Expertise）、权威度（Authoritativeness）、信任度（Trustworthiness）和时间度（Timeliness）。邱圣博在公开署名文章中提出，在E-E-A-T基础上增设时间度，本稿据此采用这一框架。[27][28] Google官方名称仍为E-E-A-T；EEATT不是Google官方升级、出版认证或已经证明适用于所有AI平台的排名公式。[01]

关于证据。 平台文档仅直接说明该平台的公开规则；研究须结合样本与条件理解。采用EEATT框架，不等于验证其来源文章中的全部样本、效果数字或算法推测。本稿不据此推导固定权重、收录周期或引用保证；两个应用场景仍为实施推演，不是客户实绩。文内插图均为依据正文内容绘制的结构示意图，不包含正文之外的数据。

关于适用范围与时间。 平台规则应按市场、产品、联网状态和核验日期判断。本版日期为2026年9月9日；原有来源保留原核验口径，新增与复核来源见文末说明。修订日期不等于所有资料的重新核验日期。本稿未对各主流AI平台作覆盖性实测。

关于编制与责任。 本稿使用AI辅助资料整理、分析与写作，并核对所引公开来源；最终内容由一搜百应GEO研究院审定。关于商业关联：选题源于一搜百应GEO官网产品讨论，EEATT采用邱圣博公开论述，因此单列百应灵枢产品形态观察。方法引用不表示原作者参与了本稿审校，产品观察仅提供采购建议，不意味着这些治理要求只能通过该产品实施。

执行摘要

Executive Summary

核心判断
企业是否需要在AI时代重新投资官网，不能只看页面是否陈旧，也不能只看是否接入了AI写作或智能客服。更重要的问题是：企业能否持续提供可核验的信息，帮助外部系统和真实客户理解其业务，并把咨询需求转化为可跟进、可评价的服务过程。 Google已经将检索增强生成和查询扩展用于其生成式搜索体验；ChatGPT搜索也能够在回答中提供相关网页来源。在中国市场，豆包、DeepSeek、Kimi、腾讯元宝、通义千问、文心一言、纳米AI等国内平台同样是客户获取答案的主要入口，其引用行为需要以持续实测为主的框架单独观察（见第三章）。这表明，网页不仅是点击后的落地页，也可能成为答案生成的参考材料。但"可能被参考"并不等于"保证被推荐"。[03][05] 由此，本白皮书提出一个核心判断：企业官网应当从单一的展示项目，升级为企业能够持续维护的信息、信任与客户连接系统。这一变化并不否定传统官网的营销和服务价值，而是要求企业把过去容易分散在宣传册、销售聊天、产品文档和内部经验中的信息，整理为可使用、可更新、可追溯的数字内容。官网不是孤立的站点，而是"权威底座—专业纵深—场景覆盖"三层信源架构的第一方事实源头。官网应优先建设六项能力：可发现、可理解、可核验、可使用、可治理、可衡量。内容质量则采用EEATT五维标准检验：经验度、专业度、权威度、信任度、时间度。[27][28] 六项能力回答"官网应能做什么"，五维标准回答"内容是否经得起检验"，两者不能混为排名分数。建设工作的优先级也应发生变化。先澄清企业事实与客户问题，再设计内容和页面；先建立证据、审核和时间治理，再扩大AI辅助生产。时间度要求重要信息说明何时成立、当前是否适用、何时复核、变更后如何同步，而不只是展示一个最近日期。
首轮建设与验证周期	官网核心能力	EEATT 内容质量标准	附录 A 验收清单
90天	6项	5维	28项

不升级的代价。 在评估投入时，也应同时计算维持现状的代价：

1. 关键信息过期或出错仍在传播：AI可能持续引用旧价格、旧资质、旧承诺，而企业无人知晓、无从纠正；

2. 比较阶段的失位：竞品的专业内容先被AI采纳，客户在形成判断时看到的可能是对方的事实版本；

3. 线索承接依赖个人：咨询响应靠销售人员个人经验，人员一变动，过程与客户认知一起流失；

4. 资产不可迁移：内容、数据、权限长期无人盘点，真正需要改版时才发现无法完整导出与交接。

评估工作的重点，应从"发布多少篇文章"转向关键问题覆盖、事实与时间有效性、引用表现、有效需求及实际业务价值。浏览、提及、引用、推荐、询盘和成交属于不同事件；过期信息即使仍被引用，也不能自动计为合格成果。

本文建议以90天作为首轮建设和验证周期，交付核心页面、五维证据台账、时间治理规则、咨询闭环与试点评估报告。90天是项目管理建议，不是收录或增长承诺；持续复核是运营责任，也不意味着所有旧资料都应被重写。

最终需要重构的，不是官网的宣传语，而是企业对公开信息质量、数字资产和客户体验的责任方式。

第一章　官网为什么需要重新定位

本章回答一个前提问题：在AI参与客户决策的环境下，官网的角色应如何重新定义，以及哪些企业需要优先行动。

1.1 从展示入口，转向决策支持

一个以展示为主的网站，通常回答"我们是谁""我们有什么""如何联系我们"。本白皮书主张进一步回答：客户在什么条件下适合选择企业，作出选择需要哪些证据，实施过程中有哪些边界，以及发生问题后由谁负责。

例如，一家工业设备企业可以展示漂亮的产品图片，也可以进一步公开工作条件、参数定义、测试方法、维护要求和适配限制。前者有助于形成印象，后者使采购者能够判断设备是否适用。两者并不冲突，但只有前者时，官网无法独立完成充分的决策支持。

AI参与信息获取后，企业还应考虑一种可能的路径：客户先通过生成式回答建立初步认识，再访问官网核验关键事实。Google对AI搜索功能的说明包括对复杂比较问题的支持，以及通过相关子查询寻找参考网页的机制。该机制为上述路径提供了产品层面的依据，但不能推导出所有客户都会以同一种方式决策。[04]

因此，官网应同时服务两类任务：对已经访问网站的人，降低理解与行动的难度；对引用网站信息的外部系统，提供清楚、稳定、可核验的材料。两类任务应共用同一套事实，而不是分别制作互相矛盾的"用户版"和"机器版"。

1.2 自有官网与第三方平台不是替代关系

本文建议将企业的信息渠道分为三种角色。官网承担第一方事实的组织与解释；第三方媒体、评测、行业组织和客户反馈提供外部视角与交叉验证；社交、视频、电商及其他渠道承担触达、互动与交易等具体任务。

"官网是自有阵地"不意味着它天然比其他来源更可信。企业能够直接说明自己的地址、产品版本和服务流程，却不能仅凭自述证明"行业最好"或"客户满意度最高"。这些比较性和效果性主张，需要相应范围内的独立证据。Google质量评估指南也要求结合外部评价与利益冲突理解网站信誉，而不是只阅读网站的自我介绍。[02]

在长期GEO实践中，一搜百应GEO研究院将企业面向AI时代的外部信源进一步归纳为三层架构：权威底座（中央媒体与权威机构内容，承担品牌事实的权威背书）、专业纵深（行业头部与垂直媒体内容，承担专业深度的证明）、场景覆盖（围绕客户真实使用场景的长尾内容，承接具体问题的回答入口）。在这一架构下，官网的角色是第一方事实的总源头：三层信源中的专业主张，最终应能回溯到官网或其他第一方材料。只治理官网而不铺设外部信源，正确的事实会缺少交叉验证；只做外部投放而不治理官网，引用与转化会失去承接点。二者是配套关系，不是二选一。

官网的战略价值，不在于垄断关于企业的全部信息，而在于让企业对自己能够负责的信息保持清楚、完整、及时，并让外部证据可以被查找和检验。

1.3 官网投资应服从业务，而不是追逐标签

不是所有企业都需要立即重建官网。企业可以先判断三个问题：客户是否需要复杂的产品或方案比较；企业是否拥有尚未被清楚表达的专业内容；现有官网是否妨碍信息更新、咨询承接或资产管理。

对这些问题回答"是"的企业，更适合优先开展官网能力评估。以即时交易为主、业务范围简单或客户主要依赖线下关系的企业，也可能需要官网，但其第一阶段目标可以是准确展示主体、服务范围和联系方式，而不是建设庞大的内容系统。

网站规模应由业务复杂度与维护能力决定。一个信息真实、更新及时、联系方便的小型网站，可以比页面众多却无人负责的网站更符合企业当下的需要。

第二章　理解AI搜索，但不神化GEO

本章先厘清AI搜索相关的三组概念与三类误区，为后续章节的能力建设划定边界。

2.1 区分模型训练、实时检索与站内问答

讨论"让AI认识企业"时，应当区分三种不同工作。第一种是模型训练或更新参数；第二种是外部系统在回答时检索网页；第三种是企业在自己的官网内搭建知识库问答服务。

检索增强生成，即RAG，其基本思想是把生成模型与外部检索到的信息结合。原始研究将模型参数中的知识与可检索的外部记忆相结合，为回答提供额外材料。这个概念不意味着每一个生成式产品都以相同方式检索，也不意味着发布网页就完成了模型训练。[06]

OpenAI的文档对用途作出了具体区分：OAI-SearchBot用于搜索，GPTBot涉及可用于基础模型训练的内容抓取，二者可以分别配置。由此至少可以确定，在该平台的公开机制中，"允许用于搜索"与"允许用于训练"并不是同一项设置。[08]

企业采购时应要求供应商说清楚：优化对象究竟是官网页面、企业自己的问答系统，还是外部平台的可检索性。把这三者都称为"训练大模型"，会导致目标、交付和验收无法对齐。

2.2 SEO与GEO：共同基础，不同观察对象

本文将SEO理解为改善网站在搜索系统中的发现、理解与呈现条件的工作，将GEO作为观察和改善生成式回答中品牌及内容可见性的工作用语。两者可以在实践中协同，不应被刻意制造成必须二选一的对立关系。

Google明确表示，其生成式搜索仍建立在核心搜索排名与质量系统之上，从其自身视角看，针对生成式搜索体验的优化仍属于SEO。企业不能因此假定其他平台与Google相同，但也不应接受"传统技术基础已经无关紧要"的说法。[03]

GEO原始研究提出了生成式答案中的可见性评价与内容优化方法，并指出效果依赖领域，且须随引擎变化调整。研究中的实验效果不能直接外推为某家建站系统、某个行业或所有平台上的商业回报。[07]

2.3 不要把一条链路写成一个保证

为便于管理，本文把"网站信息产生业务贡献"的可能过程拆分为：发布、访问、检索、使用、客户行动与业务结果。它是管理上的观察链路，不是对所有平台内部架构的描述。

页面发布了，未必已被目标系统访问；被访问了，未必进入相关检索结果；进入结果了，未必被答案使用；被使用了，未必形成正向推荐；形成推荐了，未必带来有效咨询；产生咨询后，还取决于产品适配、响应质量和商业条件。

这一区分决定了采购合同不能用"收录成功"替代"引用成功"，也不能用"引用成功"替代"业务成功"。技术团队应对可控交付负责，运营团队应对内容与验证负责，销售团队应对需求跟进负责，而不是把所有结果都归结为某个技术标签。

2.4 三种不应成为建设前提的假设

第一种假设是"结构化标记越深，AI推荐越多"。第二种是"固定长度或特殊文件能够普遍触发AI引用"。第三种是"网站写得越像答案，就越容易被平台信任"。这些都不能作为未经验证的通用规律。

Google当前指南明确说明，不需要专门的AI文本文件、llms.txt或额外的特殊Schema来进入其生成式搜索体验。这一说明仅适用于Google，不能扩大为其他系统永远不会使用相关文件。[03]

更稳健的建设原则是：结构服务于内容表达，技术配置服从目标平台的公开要求，效果假设进入可复核的实验，而不是被写成既定事实。

第三章　国内生成式AI平台：公开信息与观察框架

3.1 为什么必须把国内平台纳入观察

国内客户与采购者日常获取答案的入口，主要是豆包、DeepSeek、Kimi、腾讯元宝、通义千问、文心一言、纳米AI等国内平台（业内常合称"8大AI平台"），以及微信、抖音、百度等生态内的AI问答入口。与Google、OpenAI相比，国内平台普遍呈现几个特点：官方公开的抓取与引用技术文档较少；产品与策略迭代快；回答质量与联网状态密切相关；并且普遍与自家内容生态（如公众号文章、百科、问答社区、自家搜索）深度绑定。

这意味着两件事。第一，不能把Google的公开规则直接套用到国内平台，第二章关于"不神化"的原则在这里更加重要。第二，国内平台的引用表现必须以持续实测为主、公开资料为辅。本章给出的是一搜百应GEO研究院在服务实践中使用的观察框架，不是平台规则汇编；各平台具体规则以官方文档与最新实测结果为准。

3.2 一个可执行的国内平台观察框架

建议企业按以下四步建立自己的观察台账：

1. 平台与入口清单：明确要观察的平台、入口（App、网页、生态内入口）、联网状态与语言地区，分别记录，不混成一个平均值。

2. 问题样本与轮次：沿用第十章的问题样本方法，从30—50个真实客户问题起步，固定周期重复观察，保留原始回答与引用。

3. 信源归类：对每次回答中出现的引用与提及，按T0—T3信源金字塔归类——T0央媒级权威、T1省级与行业头部、T2垂直媒体与协会、T3商业门户与自媒体——观察官网与各层信源在不同平台上的出现比例与变化趋势。

4. 官网可及性核查：定期检查各平台对官网的访问与引用情况，记录被引用页面、引用方式、回答中的表述是否准确，以及观测时间。

3.3 官网与三层信源架构的关系

如1.2节所述，一搜百应GEO研究院将企业外部信源归纳为"权威底座—专业纵深—场景覆盖"三层架构。在为国内平台做优化时，这一架构的用法是：

权威底座解决"信不信"：央媒与权威机构的内容为品牌事实提供背书，在多数国内平台的回答中占有较高权重；

专业纵深解决"懂不懂"：行业与垂直媒体内容证明企业在具体领域的专业积累；

场景覆盖解决"找不找得到"：围绕客户具体问题的长尾内容，让AI在处理细分问题时能够命中企业材料。

官网是三层信源的第一方事实源头。三层信源中的每一项专业主张，都应能回溯到官网、产品文档或其他第一方材料；官网上的关键事实，也应有外部信源的交叉验证。实践中的常见误区是只做其一：只铺外部内容而不治理官网，引用与转化失去承接点；只改官网而不铺外部信源，事实缺少被采信的外部证据。三层关系如图1所示。

图 1｜三层信源架构与官网位置（依据本章内容绘制的结构示意）

3.4 国内平台观察的三个注意点

第一，生态内容优先是普遍现象。 多数国内平台在回答中偏好引用自家生态内容或头部权威内容。企业应同步经营公众号文章、百科词条、权威媒体内容等站外信源，并保持其与官网事实一致——口径不一致的外部内容，比没有内容更糟。

第二，联网状态显著影响回答。 同一问题在联网与不联网状态下可能得到完全不同的回答。观察与验收必须分开记录联网状态，任何混合平均都可能掩盖真实表现。

第三，规则变化快，实测须常态化。 国内平台的抓取与引用机制更新频繁，任何一次实测结论都应标注观测时间、平台版本与联网条件，避免把某一时点的快照当成稳定规律。这正是第五章时间度方法论在平台观察上的直接应用。

第四章　AI时代官网的六项核心能力

六项能力用于官网立项、建设与验收；EEATT五维标准用于检验内容质量。时间度贯穿各项能力，既不是"第七项能力"，也不是AI权重分数。

能力	核心问题	建议形成的交付物
可发现	目标用户和允许访问的系统能否到达重要内容？	导航、页面清单、访问与索引状态记录
可理解	企业的业务、产品、对象与边界是否表达清楚？	统一事实表、内容模型、术语与关系说明
可核验	重要主张能否找到相应证据？	证据台账、真实案例、作者与审核信息
可使用	客户能否完成比较、咨询和服务任务？	场景页面、清晰表单、服务与转化路径
可治理	谁可以发布、修改、导出和恢复内容？	权限、版本、备份、变更与退出机制
可衡量	哪些活动产生了什么可观察结果？	基线、事件定义、线索状态、评估报告

六项能力的关系如图2所示：它们围绕同一官网资产协同工作，缺一项都会在AI引用或客户转化链路上留下断点。

图 2｜AI时代官网的六项核心能力（用于立项、建设与验收）

4.1 以完整业务事实为基础

企业需要受控的信息底稿，记录主体、品牌、产品版本、服务地区、交付方式和实际承诺，并给动态事实绑定生效时间、证据版本与责任人。知识库不是上传材料后静置的仓库，而是能够说明哪些事实在什么时间有效、由谁确认、影响哪些页面的受控记录。

例如，服务范围由"全国"调整为某些城市后，官网、客服知识库、销售资料和外部分发内容不能继续维持不同口径。单篇文章是否流畅只是表层质量，跨页面的一致性决定了企业能否对外稳定履约。

4.2 以客户任务组织信息，而不是照搬部门设置

公司组织架构适合内部管理，却未必适合客户寻找答案。采购者需要比较适用条件、实施成本与风险，未必关心某项内容归市场部还是技术部负责。

本文建议以"问题—方案—产品—证据—行动"为基本导航逻辑。它可以与品牌介绍、新闻和招聘页面并存，但核心业务页面应避免让客户在多个栏目间自行拼接关键事实。

4.3 让资产可持续，而不是只让上线可完成

完整的官网资产应至少包含内容与媒体、页面关系、业务配置、必要的权限记录和可迁移数据。源码是其中一种重要交付，但并不是全部资产；采用托管软件的企业，也应保有必要的域名控制、数据导出和退出安排。

建设验收应包含一次由企业人员实际完成的内容修改、一次线索处理和一次恢复演练。一个只有供应商才能修改、无法完整导出、无人能够恢复的网站，不应被视为已经完成了数字资产交付。

第五章　EEATT五维标准与时间治理

本章采用邱圣博提出的EEATT框架，以时间度补充原有四维。[27][28] 下述官网审核问题、台账与流程为本白皮书的场景化实施设计，不是对任何平台内部算法的还原。五维应分别留存证据，不能用近期发布日期抵消事实错误，也不能用历史声誉掩盖信息失效。五维结构如图3所示。

图 3｜EEATT五维模型

5.1 经验度：把"做过"变成可检查的过程

第一手经验的价值，在于说明内容产生于何种真实任务，而不是在文章开头添加"多年经验"。本文建议用项目记录、测试记录、操作过程、异常处理和复盘材料支持经验性陈述。

一篇设备维护文章，可以说明使用的型号、工况、观察时间、故障表现和实际排查步骤；一篇软件实施文章，可以说明系统版本、业务边界、迁移条件和曾出现的问题。能够公开的证据应尽可能公开；涉及客户保密的信息，可以脱敏，但不能脱敏到只剩下无法核验的赞誉。

尤其应当记录失败与限制。如果方案仅在特定负载或特定地区有效，必须保留这些条件。将一次试点写成普遍效果，或者把演示环境写成生产实绩，都会削弱经验材料本身的价值。

5.2 专业度：说明依据、方法与取舍

本文建议把专业性落实为四种表达：术语定义准确，方法可以复核，方案说明取舍，结论保留适用范围。

例如，建议采用服务端输出重要内容时，应说明它解决的是内容获取和兼容性问题，而不是宣称使用某个框架就获得AI优先权。讨论询盘转化率时，应说明有效线索的判定规则，而不是只展示表单数量。

专业审核也应针对具体风险。产品参数由产品或技术责任人核验，交付承诺由实际交付团队核验，法律或高风险行业表述由具备相应能力的专业人员审核。仅在页尾列出一位"专家"，却没有真实审查过程，不构成有效的专业治理。

5.3 权威度：分清独立证据与商业传播

企业官网可以是了解企业现行产品信息的重要来源，但不自动成为评价自身市场地位的独立来源。本文建议明确标记证据的性质：企业自测、客户确认、第三方检测、独立报道、付费传播或学术研究。

一份客户授权的项目复盘，与一篇未经核实的推广稿，不能因为都被称作"案例"就具有相同证明力。媒体出现品牌名称，也不等于该媒体对所有产品主张进行了调查或背书。

对于"领先""最优""高于同行"等比较性表达，应说明比较对象、范围、时间和方法。无法形成相应证据时，应该改写为具体、可核验的产品特点，而不是增加更多同义赞美词。

5.4 信任度：把准确、诚实与责任写入系统

在Google的E-E-A-T说明中，信任处于核心位置；本稿保留这一原则，避免其他维度掩盖错误事实。[01] EEATT中的信任度侧重来源、准确性与责任，时间度则单独检查这些内容在给定时间和版本下是否仍然适用。

在官网运营中，本文建议将可信度落实为完整的发布链条：事实有来源，编辑有责任，修改有记录，错误有纠正入口，客户有真实可用的联系渠道。收费与续费、交付范围、主要限制以及需要客户配合的条件，应当在合理位置清楚说明。

透明披露属于信任度的实施要求，包括真实署名、利益关联、AI参与方式和纠错入口；它不是EEATT的第二个T。第二个T明确对应时间度，必须有独立的字段、责任与复核记录。

5.5 时间度：让事实与证据保持时间有效

本白皮书将时间度操作化为：围绕客户当前或明确指定的历史时间，判断事实、证据和承诺是否适用，并通过版本、复核与变更记录保持可追溯。它不仅涉及"何时发布"，还要求回答"何时成立、适用至何时、何时核验、何时需要处理"。

时间度评价的是信息与任务时间的匹配，而不是年龄越短越好。一份旧的原始测试报告，仍可支持其对应版本和工况；一篇今天发布、却引用失效资质或旧价格的文章，也可能不合格。长期实践应作为可追溯经验保留，不能把经营年限直接换算为AI信任分数。

5.5.1 区分六类时间，不用一个日期包办

时间对象	需要记录什么	核查重点
发布与实质修订	首次公开时间、最后一次实质内容修订时间。	保留首发记录；不以阅读、转载或定时任务刷新日期。
事实与统计区间	事件发生时间、数据起止区间、资料截止日。	数据时间必须随结论出现；不能用文章日期替代统计周期。
生效与失效区间	价格、活动、资质、功能或承诺的有效起止。	尚未生效与已经失效的内容不得当作现行信息。
核验与复核安排	最近核验时间、核验人、下次检查日和触发事件。	复核无变化可记录 " 已核验 " ，不伪装为内容更新。
版本与替代关系	产品、文档和证据版本，以及新旧关系。	历史版标明适用条件；现行版与存档版可区分。
同步与观察记录	源事实变更、站内同步、通知及外部观测时间。	通知成功不等于外部平台已采用；观察须保留原始结果。

官网前台不必堆满所有时间字段。对客户最重要的适用版本、统计区间与有效期限应就近呈现，后台保留完整审计记录。技术标记、可见日期与实际变更须一致；文章发布时间不应被写成事件发生时间。[29]

5.5.2 按变化风险复核，而不是统一刷稿

建议采用"事件触发＋定期复核"双轨机制。业务变更、来源撤回、资质到期和客户报错，都触发检查；定期复核用于发现遗漏。下面的周期仅是启动项目的管理示例，须按业务波动与风险调整，不是邱圣博原文中的固定阈值，更不是平台引用周期。

内容类别	事件处理要求	示例复核安排
价格、活动、营业及服务状态	变更生效前同步；发现错误后先限制误导性展示。	可每周检查动态信息清单；高频业务按需加密。
产品功能、参数与交付边界	每次发布、停产、停售或承诺调整时复核。	可每月核对版本与页面、客服资料的一致性。
平台文档、规则与研究数据	来源更新或撤回时处理；重要应用前再次核验。	可每月检查来源变更，不把周期当作免责期限。
稳定方法、基础知识与历史案例	发现新证据、适用边界变化或纠错请求时复核。	可每半年检查适用性；无变化不必重写原文。

复核周期必须与责任、提醒和超期处理绑定。到期未核验的资料应标记待复核；涉及价格、履约或高风险建议的失效信息，应暂停作为现行依据。历史资料可以归档保留，但不能在当前推荐、报价或默认客服回答中继续被误用。

5.5.3 真实更新、历史留痕与同步闭环

Google明确反对仅为显得新鲜而更改日期；其站点地图指南要求lastmod反映重要更新，而非版权年份等无关变化。[01][30] 据此，本稿建议将"内容修订""核验无变化""转载发布"作为三类事件分开记录，不允许自动任务把它们统一改成今天。

跨渠道同步应统一事实版本，而不是强行统一发布时间。官网、知识库、销售资料及不同语言页面可以在不同时间发布，但应引用正确的生效区间与版本。对于无法直接修改的外部转载，记录纠正请求、回执和残留差异，不承诺企业能够控制第三方更新。

变更链条建议为：事实变更确认 → 受影响内容定位 → 审核与发布 → 缓存及知识库同步 → 结果复核 → 日志归档。历史错误需要纠正，历史正确但已不适用的内容需要标记，两者不能用同一种删除动作处理。

5.5.4 时间有效性与长期证据如何兼容

持续维护并不等于不断增加新文章。运营团队应把跨期项目、问题处理和修订记录组织为连续证据，使读者能够判断企业经验如何形成、承诺如何变化、错误如何纠正。这样的记录服务于客户与审计，不应被宣称为"持续若干月就必定被AI信任"的算法机制。

对历史问题，应选取历史有效版本；对当前采购问题，应优先使用现行版本。页面应明确区分事实发生、事实生效与本次核验三个时点，避免用事后更新覆盖历史情境，也避免让旧结论无条件延续到现在。

5.6 建立"主张—证据—条件—时间—责任"台账

对影响采购决策的重要陈述建立五要素台账：主张说明说了什么，证据说明依据，条件说明适用边界，时间说明生效区间与核验状态，责任说明谁有权发布和处理异常。字段至少包含主张编号、来源与版本、统计区间、有效起止、最近核验、下次复核、关联页面和责任人。

假设企业准备发布"某项功能缩短了处理时间"，台账必须回答：与什么基线相比，采用平均数还是中位数，统计了多少任务，是否排除了失败任务，是否更换了人员或流程。证据无法回答的问题，不应由文案自行补齐。

证据应同时记录使用状态与时间状态。使用状态区分可公开、限定使用和撤回；时间状态区分未生效、现行、待复核、已失效和历史存档。待复核不是默认有效，失效证据须定位关联页面、客服知识和销售资料，并记录处置结果。

可信内容的基本单位，是一项有来源、有条件、有时间边界、有人负责的主张。EEATT审核应逐维留存判断与证据；审核完成不等于获得平台认可。附录D提供五维检查表，便于编辑、运营与采购使用同一套核查语言。

第六章　官网信息架构与内容工程

信息架构回答"内容如何组织"：从客户决策问题出发，用页面类型承载任务，让每个信息单元可独立理解，并进入生命周期管理。

6.1 从客户决策问题出发

问题库应优先来自真实的销售咨询、客服记录、产品支持、招投标要求、站内搜索和客户访谈。没有这些记录时，可以先形成研究假设，但不能把AI生成的问题清单称为"真实用户需求数据"。

本文建议将问题区分为认识问题、判断适配、比较方案、实施采购和使用服务五类。相似问题可以合并，但有不同约束的问题不应被机械归为同一篇通用文章。

例如，"系统支持哪些功能"与"旧数据能否在不中断业务的情况下迁移"并不属于同一种信息需求。前者需要产品说明，后者需要迁移条件、停机边界、验证方式和回退安排。问题库的价值在于识别信息缺口，而不是无限扩张文章数量。

6.2 用页面类型承载不同任务

页面类型	应优先回答的问题	关键证据或业务要素
企业与品牌页	由谁负责，经营范围是什么？	主体、联系渠道、资质及其适用范围
产品或服务页	提供什么，适合谁，不适合谁？	版本、规格、交付、费用边界与限制
场景与方案页	特定问题如何解决，条件是什么？	场景前提、实施路径、风险与替代方案
案例与测试页	在何种条件下做过什么？	时间、方法、样本、结果与授权信息
知识与支持页	客户如何理解或完成一项任务？	解释、步骤、引用、故障与升级路径
咨询与服务页	下一步如何行动，谁来响应？	表单、预约、联系、隐私说明与响应方式

分类的目的不是要求每家企业都拥有六个栏目，而是避免把所有内容都塞入"新闻中心"。产品变更应关联产品页，案例应关联适用场景，服务承诺应与咨询和售后页面保持一致。

6.3 形成可独立理解的信息单元

重要信息单元应能在必要上下文内独立理解。本稿建议段落说明对象、结论、条件、证据和时间：产品功能附版本，数据结论附统计区间，服务承诺附适用期限。不要依赖页面底部的统一日期来补救正文缺失的时间条件。

这是一项编辑建议，不是某个固定字数的排名技巧。长内容仍然需要完整推理，短内容也可能承载关键事实。应以读者理解任务决定篇幅，而不是套用所谓通用的"AI最喜欢长度"。

数字、时间、单位和地域尤其需要与结论共同呈现。把"在特定材料、特定温度下通过测试"删成"性能稳定"，虽然更简洁，却损失了客户作出判断所需的信息。

6.4 从内容库存，转向内容生命周期

每个重要页面都应有业务负责人、最近核验记录和复核触发条件，使用第五章的时间分类安排维护。版本升级、价格变化、证书到期、来源撤回、服务区域变化或客户报错，均可触发复核；单纯"距离发布已久"不自动意味着必须重写。

对于内容重叠，建议判断是否真正解决不同问题。服务对象、实施条件与交付边界相同的页面，可以合并；仅为覆盖相似词语而重复改写的页面，不应成为扩张重点。

历史内容应区分修订、归档与删除。旧版本对老客户仍可能有价值，应注明历史属性、适用区间与替代版本；已失效的现行承诺应停止误导性展示。尚未生效的新规则可以提前介绍，但必须标明未来生效日，不得直接作为当前规则执行。

6.5 知识图谱不等于必须采购图数据库

本文所说的品牌知识组织，首先是把企业、产品、人员、资质、场景与证据之间的关系表示清楚。对多数初期项目，统一命名、结构化字段、关联记录与内部链接就可以启动治理工作。

当业务确实存在复杂实体关系、权限要求或跨系统检索需求时，再评估图数据库、向量检索等技术。不要先采购复杂技术，再寻找必须使用它的理由。公开页面的关系组织，也不意味着外部平台已经将这些关系纳入其内部知识系统。

第七章　技术建设：解决可访问、可理解与可使用

技术建设的目标不是堆砌"AI友好"功能，而是解决可访问、可理解、可使用三类基础问题，让页面与标记服从真实内容。

7.1 抓取与呈现：先验证真实输出

技术验收应检查真实响应、状态码、重要正文、内部链接、移动端内容和访问限制，而不能只看管理后台的勾选项。建议对关键页面保留普通浏览器、基础HTTP获取以及适用平台检查工具的结果，确认页面实际输出与设计一致。

Google说明其能够处理JavaScript，但同时指出并非所有机器人都能运行JavaScript，服务端渲染或预渲染仍有价值。因此，对于依赖搜索发现的核心产品和知识页面，应优先保证重要内容能够稳定获取，而不是只在复杂交互完成后出现。[11]

这不意味着所有官网都必须更换技术栈。应根据现有架构、内容特点和维护成本选型，避免为了"AI友好"额外维护一套与用户页面不同步的内容。

7.2 区分抓取许可、展示控制与访问权限

robots.txt属于抓取协商机制。RFC 9309明确指出，这些规则不是访问授权机制。未公开的报价、个人信息、合同和后台资料，应依靠真正的身份验证与权限控制，而不是仅在robots.txt中写入禁止规则。[12]

针对Google，应检查页面的抓取与索引状态，以及Search Console中的生成式AI控制及其继承关系；当前文档提供包含、排除和继承等设置。针对OpenAI，应按搜索和训练用途分别评估机器人设置，并检查网络防护是否误拦截合法访问。[09][08]

企业还应记录哪些内容允许公开、哪些内容只向客户开放、哪些内容不得用于外部AI处理。这一决策应由业务、技术与数据责任人共同作出，而不是由建站模板默认决定。

7.3 结构化数据：与真实页面保持一致

结构化数据的作用是以约定格式表达页面信息，而不是为页面增加不存在的资质、评分或背书。Google要求标记准确、与可见内容一致；通过结构化数据检查不保证获得富媒体展示。[10]

建议从业务真实存在的主体、产品、文章、面包屑等信息开始，逐项核对适用类型及目标平台支持情况。不要因为某个类型在Schema词汇中存在，就假定每个平台都会把它用于展示或引用。

关键字段应尽量来自同一内容源，避免页面价格、标记价格和客服价格分别维护。验收除了检查语法，还应人工核对实体、版本、日期和内容代表性。

日期配置也是时间度验收的一部分。适用的文章标记可使用datePublished与dateModified，分别对应发布与实际修改；可见信息和标记保持一致，事件与业务生效时间另行表达。[29] 后台另设核验时间，不能把"检查后无需修改"自动转换成实质更新。

7.4 发现与更新：提交是通知，不是结果

网站应具备可维护的页面清单、内部链接和适用的站点地图。对支持IndexNow的搜索引擎，可以根据实际需求配置更新通知；IndexNow官方说明，提交URL只是通知内容发生变化，并不保证建立索引。[13]

更新工作还应避免无意义的重复推送。产品变更、内容修订、页面删除和URL迁移，应分别处理，并在日志中留下操作与处理状态，以便发现配置错误或无效提交。

站点地图lastmod应来自实际重要变更记录，而不是页面每次加载或全站定时刷新。[30] 企业还应检查页面缓存、内部搜索、知识库索引与客服答案缓存是否仍引用旧版本；外部提交成功只记为通知事件，不记为外部更新完成。

7.5 性能与无障碍：回到真实使用者

性能验收不应停留在一张测试工具截图。web.dev给出的Core Web Vitals良好阈值为：LCP不高于2.5秒、INP不高于200毫秒、CLS不高于0.1，并建议按真实访问的第75百分位判断，区分移动端与桌面端。[15]

这些是用户体验参考指标，不是AI推荐阈值。低流量新站可能暂时缺少足够现场数据，此时应明确使用了实验室测试，记录设备、网络和测试条件，不能把两类数据混用。

无障碍方面，可采用WCAG 2.2的相关要求建立检查基线，覆盖键盘操作、文本替代、表单标签、焦点可见性与错误提示等。自动化扫描只能完成部分检查，关键任务仍需人工验证。[16]

7.6 多语言与旧站迁移：避免在升级中损失资产

多语言官网不应只是逐句翻译。服务范围、计量单位、币种、联系时间、证据和当地表达需要分别核验。Google建议为不同语言版本使用独立URL，并通过hreflang说明适用关系；这不能替代本地化内容质量。[14]

旧站重建时，应先清点有价值的URL、外链落地页、文件和现有转化路径，建立新旧映射。Google的迁移指南强调URL映射、适当重定向以及迁移后的监测。不能把大量旧地址统一跳到首页，再宣称"迁移已经完成"。[25]

建议把迁移演练与回退预案写入项目范围，在发布窗口持续监控错误、访问和线索流转。视觉改版完成，不代表迁移风险已经解除。

第八章　AI辅助运营：扩大能力，不放大错误

AI应扩大团队产能而不是放大错误：本章给出有人负责的生产流程、按风险分级的发布权限与智能客服的边界。

8.1 建立有人负责的内容生产流程

建议采用"需求确定—事实与时间取证—辅助起草—EEATT五维审核—编辑发布—监测复核"的流程。AI可以整理与起草，但不应补造案例、引文、参数或更新时间；生成日期不能替代资料的观察时间、证据有效期或人工核验时间。

Google关于生成式AI内容的指导强调准确性、质量和相关性；其垃圾内容政策针对为了操纵排名而规模化生成、却缺少用户价值的页面，不论这些页面以何种方式制作。[17][18]

因此，运营绩效不应只按篇数计算。更适合检查的是关键问题覆盖率、事实错误数量、过期内容处理情况、证据补全情况，以及内容是否帮助客户完成真实任务。

8.2 发布权限与自动化应按风险分级

可将内容分为低风险说明、重要业务承诺和高风险专业建议。低风险内容可以在受控模板下提高自动化程度；价格、交付、合同边界和效果性主张应由业务责任人确认；涉及健康、安全、法律、财务等内容，应采用更严格的专业审核。

自动同步也需要变更范围与失败处理。一次知识库更新不应未经核验就覆盖全部产品页；删除记录后，应能够追踪关联内容；错误发布后，应支持下线、回退和通知责任人。

审核须分别记录五维判断：经验是否真实、方法是否专业、权威依据是否独立、陈述是否可信、时间是否适用。每项应有证据与责任；仅生成一个EEATT总分，或只检查语言是否流畅，不能替代实际审核。

8.3 智能客服必须知道自己的边界

官网智能客服建议优先承担事实查询、流程解释、资料定位和咨询分流。涉及个性化承诺、价格折扣、技术风险或尚未确认的信息，应转交相应人员，而不是生成看似完整的答案。

应向访客说明正在与AI系统交互，允许方便地转人工，并在必要时展示答案依据和适用版本。对于无法从有效资料中确认的问题，系统应明确表示需要核实，不应为了维持对话而补齐事实。

OWASP将提示注入列为大模型应用的重要风险，外部输入可能改变模型行为。因此，本文建议把网页、上传文件和用户消息视为不可信输入，不让客服仅凭对话文本改变权限、导出敏感数据或执行不可逆业务动作。[19]

对时间敏感问答，建议检索时按业务版本与有效区间筛选资料，明确历史查询与当前查询。失效资料不能作为默认现行答案；无法确认有效性时应说明需核验并转人工。功能验收应测试：价格到期、版本替换或来源撤回后，缓存和知识库是否仍输出旧承诺。

8.4 隐私、安全与内容标识

询盘表单应围绕明确目的收集必要信息。中国《个人信息保护法》第六条、第七条要求目的明确、最小必要和公开透明。由此，官网应说明收集用途、处理方式和必要范围，避免为了线索画像索取与当前咨询无关的信息。[20]

企业还应核对使用的模型、客服、统计与云服务涉及哪些数据处理方、数据保存期限和访问权限。公开网页本身与访客个人信息属于不同管理对象，不能因为官网公开，就把全部交互数据视作可以任意处理。

在中国适用场景下，应结合《人工智能生成合成内容标识办法》判断生成服务、传播服务及发布者各自的标识、声明或提示义务；具体适用性取决于服务形态与内容，不宜简单理解为"所有AI辅助编辑都完全一样"。相关上线方案应由法律与合规责任人确认。[21]

源码交付、本地部署或使用知名云服务，都不能单独替代隐私、安全和合规评估。建议至少落实最小权限、密钥隔离、备份恢复、日志脱敏、依赖维护和事件处理责任。

8.5 时间度治理：将维护责任落实到岗位

企业应明确一名时间治理协调责任人，可由内容运营或产品负责人兼任；不必为了新增概念增设管理层级。业务负责人确认事实变更，编辑负责页面与引用修订，技术负责调度、缓存和日志，客服与销售确认资料切换，协调人追踪未完成事项。

每次复核应保留对象、依据、结论、核验人和时间。未发现变化时记录核验完成；发现异常时生成修订或撤回任务。对停止服务或人员交接的场景，应同时转交复核日历和待办清单，避免网站仍在线而信息维护已经中断。

第九章　从被看见，到真正服务客户

被看见只是起点：本章讨论如何把曝光转化为真实的客户服务与转化能力，并按业务类型选择结果指标。

9.1 不把留资数量等同于转化能力

本文将"客户转化中心"定义为：官网能够帮助客户完成适配判断，选择合适的下一步，并让企业接续处理需求。它不意味着每个页面都必须弹出表单，也不意味着强制收集联系方式越多越好。

知识内容可以引导阅读适用方案；方案页面可以引导核对实施条件；产品页面可以提供演示、试用或报价入口。每一步都应与客户当前任务有关，而不是把所有访问统一导向"立即咨询"。

能够提前解释不适用条件，也是一种有效服务。减少明显不匹配的咨询，可能降低原始线索数量，却帮助双方节约后续判断成本。因此，评价转化时必须同时观察数量与质量。

9.2 把响应承诺连接到实际流程

表单提交后应提供明确反馈，说明下一步会发生什么。内部应有接收责任人、分配规则、异常提醒和处理状态，避免官网提交成功但线索无人跟进。

建议使用唯一线索编号连接表单、客服与客户关系管理系统，并为重复咨询建立合理合并规则。人员只应访问与其职责相关的数据；市场分析不需要暴露全部个人信息。

当企业无法履行某种响应速度时，不应写出"即时专业答复"。承诺应与值班、工作时间和服务能力相匹配，并允许客户通过其他渠道核实进度。

涉及限时价格、排期和优惠的咨询页面，应让客户看清适用日期、时区与必要条件；已过期入口应停止接受相应承诺。旧报价或旧服务页面可以保留查阅入口，但须与当前咨询流程区分，并提供核实渠道。

9.3 不同业务采用不同结果指标

复杂B2B业务，可以关注有效需求、演示预约、商机建立和最终合同；本地服务，可以关注服务范围匹配、预约确认和实际到店或履约；产品支持型网站，可以关注任务完成、问题解决和服务负担变化。

这些是本文提出的业务映射，不是行业统一绩效门槛。企业应先明确官网在销售与服务流程中的任务，再决定追踪哪些事件。把不同业务都压缩为"咨询量"，往往会遗漏官网本应承担的价值。

第十章　建立可复核的效果测量体系

没有测量就没有管理：本章给出分层观察口径、提及/引用/推荐的统计定义、问题样本方法与时间度指标。

10.1 将技术、可见性与经营结果分层

测量层	建议观察内容	不能直接得出的结论
技术与内容基础	可访问性、错误、内容完整性、证据状态	不能据此保证被引用
外部答案表现	提及、官网引用、推荐、事实准确性	不能据此证明真实用户覆盖
网站访问与任务	可识别访问、关键事件、咨询完成	不能把全部访问都归因于 AI
线索与经营	有效线索、商机、成交与贡献	不能仅凭同期增长证明因果

四层测量的关系如图4所示：下层是上层的必要条件而非充分条件，任何两层之间都不存在自动保证。

图 4｜四层测量体系（分层观察、逐层归因，不合成单一总分）

技术检查可以定位阻碍；答案抽样可以观察特定条件下的表现；网站分析可以记录部分真实行为；业务系统可以判断线索是否产生价值。四类数据相互补充，但不存在一个天然可以替代全部工作的"GEO总分"。

10.2 严格区分提及、引用与推荐

本文建议采用以下统计口径，并在每次报告中保持一致。

品牌提及率＝提及目标品牌的有效回答数÷有效回答总数。负面提及也属于提及，应另行标记，不能自动计为正向效果。

官网引用率＝包含可核验官网页面引用的有效回答数÷有效回答总数。同一回答引用官网多个页面，在这一指标中仍按一次计算；对二级域名、跳转链接和相似品牌的处理规则须预先固定。

推荐出现率＝在预先定义的采购或方案推荐任务中，明确推荐目标品牌的有效回答数÷该类任务的有效回答总数。定义解释类问题不应混入推荐率分母。

事实准确率＝核验正确的品牌事实主张数÷可核验品牌事实主张总数。核验须匹配问题要求的时间和业务版本：历史正确但已失效的信息，不能计为当前事实正确。没有可核验主张时记为"不适用"，无法确认的主张单列待核验，不能记为正确。

"首位推荐"仅在回答确实存在可解释顺序时单列；无排序答案不得强行赋予名次。某个回答提到了品牌、引用了官网，也不意味着其推荐理由正确，这需要独立核验。

10.3 固定问题样本与测试条件

作为小规模试点，本文建议可从30—50个不同意图的问题起步，按业务需求选择2—3个目标平台，在不同日期重复观察。该规模是便于执行的起点，不是具有总体代表性的统计样本。

例如，40个问题、3个平台、3轮观察构成360个计划观测单元。报告应保留计划数、成功返回数和失败数，而不是将超时、无法访问或未完成测试全部静默删除。联网与不联网、不同产品入口、不同语言和不同地区应分别报告，不宜直接混成一个平均值；正常返回但拒答、未联网或未引用来源的情况，应记录为明确状态，与技术失败区分。重复观察的统计处理与抽样方法细节见附录B.5。

10.4 使用真实平台数据，但尊重它的覆盖范围

按2026年9月核验记录，Google的生成式AI表现报告说明了AI Overviews和AI Mode的展示数据，并提示报告可用性与开放进度、展示量等条件有关。报告未出现，不等于企业在所有AI系统中都没有曝光；使用前应复核现行范围。[22]

Microsoft在2026年6月介绍了Bing Webmaster Tools的意图、主题、引用份额与时间比较预览功能。其中引用份额是观察指标，不是排名、质量分或流量份额。[23]

OpenAI发布者文档说明，ChatGPT搜索引荐链接包含utm_source=chatgpt.com，可用于识别部分引荐访问。没有识别到这类访问，不能反向证明没有人受到AI回答影响；用户也可能改用品牌搜索或其他渠道联系企业。[24]

第一方报告、访问分析与第三方答案抽样应分别保留口径。不能将自选问题中的引用率称为"全网AI推荐率"，也不能把某个平台的后台数据当作其他平台的表现。国内平台的观测口径按第三章的框架单独建立，不与海外平台混算。

10.5 用对照与变更记录减少归因错误

建议在改造前完成基线，选择相近但暂未改造的页面或问题组作观察对照，保持核心问题、平台与测试条件尽可能稳定。每次内容、模板、权限或推广变化，都应留下时间与范围记录。

在条件允许时，可以采用分批上线或随机分配，比较处理组与对照组的变化。简单的前后差异，只能说明变化同时发生；即使使用"处理组变化减去对照组变化"的差分，也依赖可比性、共同趋势等前提，不能自动消除季节性、品牌活动和平台更新的影响。

实验中应保留没有改善和出现退化的页面。选择性展示成功问题，会使报告失去采购和运营决策价值。

10.6 把商业回报建立在明确假设上

立项测算可以使用一个简化模型：预计新增毛利＝新增有效线索×商机形成率×成交率×每单毛利；项目净贡献＝预计新增毛利－项目总增量成本。它是情景分析，不是已实现收益。

例如，纯假设一个项目每月新增20条有效线索，其中30%形成商机、20%商机成交，每单毛利为1万元，则期望新增毛利为1.2万元。若当月分摊的建设、运营和相关销售增量成本合计1万元，情景下净贡献为2000元。这里没有使用任何企业真实业绩，期望值也不代表每月一定产生相同订单。

企业应再做低、中、高情景，处理成交延迟、退款、重复线索和原本就会发生的订单。没有可靠的增量识别时，应把结果称为"相关或可归属贡献"，而不是"因官网升级带来的全部收入"。

10.7 时间度指标：衡量维护质量与错时风险

以下为本白皮书提出的内部管理指标。统计前须固定页面清单、主张单位、必填字段、截止时点与业务时区，新增、移除和不适用对象留痕，不得为提高比例而删除超期项。各指标分开报告，不合成为AI推荐概率。

指标	统计口径	边界与核查
时间字段完整率	具备全部适用时间字段的受检对象数 ÷ 受检对象总数。	必填范围按内容类型预先固定；待填写记为未完整。
按期复核率	在截止前按期完成的到期复核任务数 ÷ 该期间应完成任务总数。	仅改时间戳不计完成；取消任务须说明原因。
时间有效性确认率	已核验且符合目标时间与版本的敏感主张数 ÷ 受检时间敏感主张总数。	失效和待核验均不得计入确认数；未知比例另列。
变更同步按期完成率	按约定时限完成全部受控触点同步的变更数 ÷ 到期应完成同步的变更总数。	站内、知识库与销售资料分别验收；外部请求另列状态。
错时主张发生率	把不适用时间或版本当作答案依据的主张数 ÷ 受检回答中的时间敏感主张总数。	同一主张在不同回答中按不同观测计；待核验另报。

各指标分母为零时记"不适用"，不记100%。错时主张应保留原始问题、完整回答、目标时间、引用版本及核验依据；正确回答历史问题不属于过期错误。另可记录从事实变更到站内修正的处理时长，并单列尚未完成的任务及其已等待时间。

官网已修正而外部答案仍未变化，说明链路中存在尚未完成的同步或采用，不可直接归因于某项算法。外部首次观察到新答案的日期，也不是平台实际完成更新的精确时间；未观察到变化应如实记录，不能推算虚构的更新时间。

第十一章　实施路径：先评估，再改造，后验证

实施应先评估、再改造、后验证：本章给出路径选择、90天首轮计划、投入量级参考与验收规则。

11.1 四种路径，而不是一律重建

路径	适用判断	优先工作
保留并维护	基础可靠，内容与咨询流程基本满足需要	修订事实、补充证据、明确责任
内容与体验优化	技术尚可，关键问题和转化信息不足	重构核心页面，完善任务与测量
局部技术改造	存在抓取、权限、结构或集成短板	定点修复，避免不必要迁移
整体重建	多项基础能力长期受限，改造成本不合理	新建与迁移并行，完整验收和回退

判断应基于实际评估与全生命周期成本，而不是仅根据"用了旧框架"或"没有AI按钮"。现有网站已经积累的页面、客户习惯和数据，也属于需要保护的资产。

11.2 一个90天的首轮计划

第1—15天：建立事实与基线。 明确业务目标与责任；盘点页面、权限、域名和咨询路径，开展EEATT分维诊断。记录内容版本、有效期、核验状态和历史错误，完成技术与答案样本基线，形成优先级而不是先批量发稿。

第16—30天：完成内容与系统设计。 建立"主张—证据—条件—时间—责任"台账；确定核心页面、审核流程和指标口径，设置时间字段、复核周期、事件触发与失效处理规则，分配跨部门维护责任。

第31—60天：分批建设与内部验收。 完成核心页面和咨询链路，配置权限、日志与备份；验证真实日期、版本切换、复核提醒与过期处置。通过模拟价格失效、来源撤回和缓存滞后测试，核验知识库与页面是否一致。

第61—90天：发布、观察与调整。 按计划上线或迁移，重复问题样本观察；同时报告时间度指标、错时主张、未完成同步与业务结果。交付首轮报告、复核日历和待办清单，再决定扩张或调整范围。

这套周期可以因企业规模而缩短或延长。上线可以按日期安排，但收录、引用与成交不能以同一个日期作保证。四个阶段的衔接如图5所示。

图 5｜90天首轮实施计划（周期可按企业规模伸缩）

11.3 投入量级参考

不同规模的官网，首轮建设与持续运营的投入差异极大。下表仅提供数量级示意，帮助决策者判断"这件事大概要多大动静"，不构成任何报价；正式预算应以附录C决策表逐项测算为准。

项目规模	典型特征	首轮 90 天投入（示意）	持续运营（示意）
小型官网	页面少于 50 个，业务单一	1 名兼职业主＋ 1 名兼职编辑或外部支持	每周数小时的复核与更新
中型官网	页面 50—300 个，多条产品线	项目负责人＋编辑＋技术支持，约 0.5—1.5 个人力当量	每周固定复核，按月观察外部表现
复杂官网	多产品线、多语言、多角色协作	跨部门小组，含内容、技术、合规角色	常态化治理机制与定期评估

除人力外，还应预留：证据与案例授权的沟通成本、第三方监测或工具费用、AI接口与统计服务费用，以及（如需）改版建设费用。投入量级应与10.6节的回报模型配合使用，先有假设，再谈预算。

11.4 以治理成熟度决定扩张速度

治理成熟度可分为四阶段：基础事实正确；核心问题与版本边界清楚；五维证据、审核和咨询流程稳定；持续复核、失效处理与效果测量能够运行。时间度不是上线最后补填的日期字段，而是决定内容规模能否持续扩张的条件。

尚未形成事实审核机制的企业，不宜立即扩大自动发布规模。尚未建立线索处理流程的企业，也不宜把更多曝光作为唯一优先事项。扩张应建立在已有环节能够承接的基础上。四个阶段的递进关系如图6所示。

图 6｜治理成熟度四阶段（扩张速度由成熟度决定，而非由发布量决定）

11.5 验收不是截图，而是任务完成

上线前至少应当完成三类实际测试。客户任务测试，验证用户是否能找到适配条件、证据和下一步；运营任务测试，验证员工是否能更新、审核、回退和处理线索；恢复与退出测试，验证备份能否恢复，数据能否按约定完整交付。

建议把敏感信息暴露、关键业务事实错误、过期价格或资质被作为现行依据、核心表单失效、必要资产无法交接，以及无法恢复的高风险问题列为上线阻断项。阻断项不能被视觉设计、性能平均分或其他维度高分抵消。完整的验收清单见附录A。

第十二章　两类应用场景的实施推演

本章用于展示方法如何运用，均为虚构业务情境；没有对应的客户、测试记录或增长数据，不能摘录为成功案例。

12.1 工业设备企业：从参数展示到适配判断

假设一家设备企业已有官网，产品图片齐全，但核心信息分散在销售资料和工程师经验中。客户反复询问工作环境、产能条件、维护成本和系统兼容性，现有页面无法完成解释。

首轮工作不是批量生成行业文章，而是由产品与交付团队统一参数定义，明确不同型号的使用条件、测试范围、排除情形和配套要求。接着建立产品页、场景页、测试方法页和维护支持页，并把相关内容相互关联。

改造前后的典型差别，可以用同一批客户问题对照如下：

客户问题	改造前官网回答	改造后官网回答
这台设备适合我们吗	产品参数表加宣传语	适用工况、排除情形与适配限制，并链接测试方法页
产能到底能到多少	" 高效稳定 "	特定材料与工况下的测试数据，附统计区间与测试条件
后续维护要花多少	无内容，靠销售口头说明	维护周期、易损件与支持入口，标明适用版本
想进一步确认	表单留电话，等待回访	引导提交工况与需求，由技术人员按流程评估

对于"提高生产效率"这类主张，只有在证据允许时才展示效果，并保留基线、运行时长、任务条件和失败样本。对未实施过的场景，应明确说明需要评估，而不是让客服直接承诺。

咨询入口可以先帮助客户提供工况与需求，再由相应技术人员评估。首轮评价重点是客户是否能够正确理解适配条件、有效需求是否更容易进入评估流程，以及AI回答中的型号和限制是否准确，而不是单纯统计"设备品牌推荐"的次数。

时间度验收可设置一个虚构测试：新型号生效后，现行产品页、测试说明和客服应切换到正确版本；旧型号维护资料保留历史入口。核查重点是新旧适配关系与时间边界，不是删除全部旧内容后声称"全站已更新"。

12.2 专业服务企业：从服务口号到交付边界

假设一家企业服务机构主要通过销售沟通解释业务，官网只提供"专业、高效、一站式"等表述。不同销售人员对服务包含事项、客户配合条件和交付周期的解释存在差异。

首轮应建立清晰的服务说明：适用客户、交付物、工作步骤、客户责任、收费结构和不包含事项。改造前后的典型对照如下：

客户问题	改造前官网回答	改造后官网回答
你们的服务包含什么	" 专业、高效、一站式 "	适用客户、交付物清单、工作步骤与客户配合事项
多少钱	需电话咨询	收费结构说明与报价入口，标明报价有效期
你们不适合我们怎么办	未说明	明确不适用情形与替代建议
出了问题谁负责	未说明	责任边界、纠错渠道与响应方式

案例内容应区分实施动作与客户最终经营结果，不把没有证据的销售增长归为服务效果。

官网可以允许客户先进行不涉及敏感信息的基础自评，再选择预约沟通或获取资料。智能客服只能解释已经审核的流程，不应根据简短对话作出专业结论或保证特定结果。

首轮评价应关注咨询是否更符合服务范围、销售是否减少重复解释、客户是否更容易理解交付边界，以及签约前后的重要认知差异是否得到减少。相关指标需要企业实际记录后才能形成案例，不能在建设之前预先写出"提升百分比"。

时间度验收可再模拟服务范围与价格调整：生效前页面标明未来安排，生效后相关方案、报价和客服口径一致；旧合同客户仍可查看对应版本。历史成功交付不自动证明新服务范围已经获得同等经验支持。

第十三章　采购、系统选型与产品形态观察

采购的重点不是功能清单，而是责任清单：本章给出选型比较原则与可执行的合同附件建议。

13.1 从功能清单转向责任清单

企业采购的不只是页面或软件，还包括可维护的内容结构、工作流程和交付责任。建议把需求分为必需能力、可选能力与实验性能力，避免"具备某功能"成为模糊的验收语言。

例如，"支持AI写作"应继续问：使用哪些来源、能否引用证据、谁审核、如何控制费用与失败任务。"支持引用监测"应继续问：测试哪些平台、问题如何选择、是否提供原始回答、如何处理错误与重复。"支持自主可控"应继续问：企业能够控制哪些资产，第三方依赖有哪些，停止服务后哪些功能仍可运行。

采购对话的核心应是企业能够验证什么、接管什么和持续维护什么，而不只是演示中能够看到什么。

13.2 托管服务与源码部署各有责任边界

托管服务可以减少企业直接维护基础设施的工作，但应核对内容、媒体、配置与线索的导出能力，以及域名、账号、服务终止和迁移安排。源码部署可以增加企业的改造空间，但同时需要落实运维、安全修复、升级兼容和依赖管理责任。

源码交付不应被自动解释为所有第三方组件的知识产权转让；应逐项核验许可与合同。自行部署也不等于没有外部数据调用，AI接口、统计工具、远程日志和更新服务都需要单独核查。

本文不建议以"托管必然不安全"或"本地部署天然合规"作为选择依据。真正需要比较的是控制范围、人员能力、风险责任、数据流向和全生命周期成本。

13.3 百应灵枢：产品形态观察

按2026年9月核验记录，一搜百应公开产品页将EsoMind百应灵枢定位为源码交付、本地化部署的GEO官网系统，并列示知识库、内容生产与同步、结构化配置、引用监测和线索管理等能力。以上为厂商介绍，不是后台实测；采购时须复核当前版本。[26]

从产品组合看，这类方案尝试把建站、内容与运营工具放在同一交付中。其潜在管理价值在于减少系统间重复录入与责任分散；是否实际实现这一价值，应通过内容变更、审核、发布、监测与线索处理的连续任务验证，而不能仅凭模块数量判断。

针对百应灵枢或其他同类系统，应继续验证事实溯源、发布前审核、原始监测记录、数据传输和资产交接。按本稿的时间度要求，还应演示版本有效期、到期提醒、失效资料隔离、缓存更新及同步日志；这些是采购验证要求，不代表本文确认该产品已全部具备。

产品页中的效果数字、优先引用表述及案例概述，在没有原始样本、方法、基线和完整结果前，不应作为本文证明"结构化标记可以稳定提高AI引用"的依据。价格、套餐与具体交付条件也不纳入行业结论，以避免将阶段性商业信息当作白皮书的长期论据。

13.4 建议形成可执行的合同附件

合同附件应明确交付资产、页面、接口、审核、测试、培训、维护与退出机制，并加入时间治理责任：谁确认变更、何时完成受控触点同步、如何处理逾期、何种证据表示验收完成。外部转载纠正请求与平台实际采用分别记录，不能混成供应商可完全控制的承诺。

不宜接受"保证全平台优先推荐"这类无法具体执行的表述。更适合约定的是完成明确的技术修复、提供可复核的内容与测量交付，以及按预先定义的条件进行试点评估。

结语　让官网成为企业能够长期负责的信息系统

AI时代的官网升级，不是在旧网站上叠加宣传术语，而是重建对信息、专业证据、客户任务和数字资产的责任。EEATT把经验度、专业度、权威度、信任度与时间度共同纳入质量治理，使"曾经正确"与"现在适用"都能被分别检验。

当官网能够清楚解释业务，诚实说明限制，提供可核验的依据，帮助客户采取合适的行动，并在变化发生后持续更新，它就不再只是一个完成上线的项目，而是一项能够被长期维护和使用的经营能力。

这种能力不依赖某个平台永远采用同一种机制，也不要求每次AI回答都出现企业名称。它的价值首先体现在企业是否能够减少信息错误、支持客户判断、承接真实需求，并把学习和改进留在自己的组织中。

企业应让客户与外部系统看清：自己确实做过什么，依据是否专业，证明来自何处，承诺由谁负责，以及这些信息在什么时间仍然适用。官网的长期价值，不在于日期始终最新，而在于重要事实始终有人核验、变化始终有迹可循。

下一步：从一次诊断开始

本白皮书给出的全部方法，都不需要等到"大改版"才能启动——正确的起点是一次低成本的评估。

一搜百应GEO研究院提供官网EEATT五维免费初诊：围绕第三章的国内平台观察框架与第五章的五维标准，对贵司官网给出一份分维诊断摘要、关键缺口清单与90天优先级建议。您也可以索取附录D《EEATT五维审核与时间度检查表》的可编辑版本，先行自查。

先评估，再改造，后验证——让每一次投入都有依据。

项目	联系方式
联系对象	一搜百应GEO项目组
电话	13691691391
官网	www.esobuy.com

附录A　官网升级验收清单

本清单为EEATT框架下的项目实施检查工具，不是平台官方认证。共28项，每项记录"通过、未通过、不适用、未测试"，附证据、责任人和复核日期；未测试不得视作通过，阻断项不能用其他项补偿。

编号	检查事项	建议留存的证据
A01	主体、品牌、产品版本与联系信息一致	事实表及关键页面核对记录
A02	核心产品和服务写明适用与不适用范围	业务责任人审核记录
A03	重要效果与比较性主张有对应证据	主张 — 证据 — 条件 — 时间 — 责任台账
A04	案例具备授权、条件、方法与限制	授权及脱敏后的原始资料
A05	作者、审核与 AI 参与方式如实说明	发布流程与责任记录
A06	内容有负责人、版本与复核触发条件	内容清单及变更日志
A07	核心页面能够稳定获取完整正文	响应、渲染与平台检查结果
A08	抓取、展示、训练与访问权限分别管理	配置表及实际验证记录
A09	结构化字段与可见内容一致	语法测试及人工对照记录
A10	内链、站点地图与必要更新通知正确	页面清单与错误检查记录
A11	移动性能与无障碍任务经过验证	现场或实验室条件、人工测试记录
A12	旧地址有合理映射，多语言关系准确	映射表、跳转与语言核验结果
A13	表单、预约与客服有明确反馈	从提交到处理的完整任务记录
A14	线索接收、分配、重复合并正常	业务系统状态及异常处理记录
A15	智能客服能够拒绝无依据承诺并转人工	边界与异常场景测试记录
A16	个人信息收集与第三方数据流向已审查	字段说明、隐私与处理方清单
A17	权限、密钥与依赖维护有责任人	权限表、更新与检查记录
A18	备份恢复及内容回退实际成功	恢复环境与结果记录
A19	核心资产能够按约定导出和交接	文件、结构、数量与可用性验收
A20	基线、指标、失败样本与归因边界完整	原始数据、字典与首轮评估报告
A21	EEATT 五维分别审核，不以总分替代证据	五维审核记录与缺陷清单
A22	发布、修订、核验、统计与有效时间可区分	页面、字段及日志对照
A23	日期、结构化标记与 lastmod 反映真实变化	实际修订与标记核对记录
A24	复核周期、触发事件与超期责任明确	复核日历、提醒及处理任务
A25	到期价格、活动、资质及旧承诺及时处置	到期模拟、下线或切换记录
A26	历史版、现行版与未生效版能正确区分	版本关系及客服问答测试
A27	受控渠道、缓存与知识库同步可追踪	触点清单、任务结果与失败日志
A28	时间度指标保留未知、超期和错时样本	统计字典、原始回答及复核依据

附录B　内容证据与AI表现记录规范

本附录定义三类最小记录规范，使EEATT审核与效果测量有据可查。

B.1 单篇专业内容的发布记录

单篇内容至少记录对象与问题、作者或编制责任人、专业审核人、事实来源、证据编号、适用条件、限制、AI参与方式，以及EEATT五维审核结论。时间字段分别记录发布、实质修订、最近核验、数据区间、生效与失效、版本关系、下次复核日和触发事件；不适用字段说明原因。

审核应分开记录事实准确性与表达质量。语言流畅不等于事实正确，引用存在不等于引用支持结论，作者有资历不等于每项主张都已经核验。

B.2 单次AI答案观察的最小记录

单次观察至少记录：编号、原始问题、意图、品牌词、平台与入口、可见模型信息、联网状态、观测时间与时区、语言地区、会话条件、完整回答、全部引用地址、执行状态，以及提及、引用、推荐和事实核验结果。新增目标时间、引用版本、时间敏感主张、错时与待核验标记及复核人。

没有显示的模型版本记为"未披露"，不可猜测；无法确认的事实标记"待核验"；品牌名相同但主体不同的结果应排除或单列，不能计为本品牌成功。

B.3 报告应保留的反面证据

至少保留：未改善的问题、负面提及、错误引用、张冠李戴、正常拒答、未联网结果、技术失败，以及由于样本或工具限制无法判断的部分。报告应同时说明计划观测数量与实际完成数量。

网站日志、截图和客户资料的留存应遵循授权、保密与最小必要原则。对外发布时保留足以理解方法的材料，不应为了展示可信度而泄露个人信息或商业秘密。

B.4 单次时间变更与复核记录

建议记录：变更或复核编号、事实对象、触发原因、原值与新值、证据及来源版本、事实生效时间、发现时间、负责人、完成期限、受影响触点、发布与缓存处理结果、外部纠正请求、复核结论、关闭时间，以及仍未解决的差异。核验无变化也需留下依据，但不改写原始发布时间。

示例仅作模板：某服务范围在指定日期调整，先关联产品页、FAQ、客服知识及销售说明，再分别记录切换结果。一个触点未完成时，变更任务不得被标记为"全部同步"；无法控制的第三方页面列为外部待处理，不隐去残留问题。

B.5 观察统计方法要点

重复观察同一问题具有相关性，不能把360次记录简单当作360个彼此独立的客户。优先按平台、意图和时间展示描述统计，报告样本量与波动范围；需要推断总体差异时，再由具备统计能力的人员设计分层或聚类分析。

联网与不联网、不同产品入口、不同语言和不同地区应分别报告；正常返回但拒答、未联网或未引用来源的情况记录为明确状态，技术失败与业务有效性另行区分。任何混合平均都可能掩盖真实表现，跨口径比较应在报告中显式说明。

附录C　立项与采购的一页决策表

决策问题	应形成的明确答案
为什么做？	哪项客户任务或业务问题目前没有被解决
先做什么？	第一阶段需要完善的核心页面、证据和流程
哪些不做？	暂不建设的功能、平台和内容范围
谁负责？	业务事实、专业审查、技术、安全、运营与销售责任
如何验收？	任务、条件、证据、阻断问题和签收人员
如何测量？	基线、样本、分母、原始记录和业务指标
要花多少？	建设、维护、内容、 AI 调用、集成、审查与退出总成本（可参考 11.3 节投入量级）
如何停止或迁移？	域名、内容、数据、配置、代码及依赖的交接安排

立项结论可以是重建，也可以是局部修复、内容优化或暂缓扩张。白皮书的价值，在于帮助企业作出有证据的决定，而不是让每一次评估都导向购买新系统。

附录D　EEATT五维审核与时间度检查表

本附录提供逐维检查表与时间度发布前检查，供编辑、运营与采购直接使用。

D.1 五维审核：每一维都要对应证据

框架名称与五维来源于邱圣博公开论述。[27][28] 下表的审核任务和证据要求是本白皮书面向企业官网的实施细化；既不表示作者亲自审核了本站，也不构成任何AI平台的认证。

维度	本稿审核要求	建议留存的证据
E · 经验度 Experience	案例与过程真实；说明条件、失败与限制；不虚构亲历。	项目、测试或操作原始记录及授权。
E · 专业度 Expertise	术语准确；方法可复核；解释取舍；专业人员真实审核。	方法说明、测试边界与审核记录。
A · 权威度 Authoritativeness	来源与主张匹配；区分自述、独立验证和付费传播。	原始来源、资质范围与利益关系说明。
T · 信任度 Trustworthiness	事实准确；利益与 AI 参与透明；承诺清楚；可联系与纠错。	证据台账、版本记录、责任与纠错入口。
T · 时间度 Timeliness	明确有效时间；按风险复核；失效可处理；变化可追溯。	时间字段、有效区间、复核与同步日志。

建议逐维记录"未建立—已有规则—已有执行证据—能够持续复核"四档成熟度，并附样本范围、发现、责任人和整改期限；未测试与不适用另列。不把五维机械相加为通用信任分数，也不把成熟度当作引用概率。

D.2 时间度的八项发布前检查

编号	检查内容
T01	文章日期、事实发生时间、数据周期与有效期没有混用。
T02	关键主张随文说明版本、地域和目标时间，避免无范围的 " 目前 "" 最新 " 。
T03	实质更新有内容差异；复核无变化、转载和模板变动分别记录。
T04	可见日期、 datePublished 、 dateModified 与 lastmod 各自符合真实事件。
T05	到期、撤回和版本替换会触发复核；高风险失效内容不继续支撑现行承诺。
T06	历史与未来生效内容明确标记；旧证据仍适用时可保留，不为显新而重写。
T07	页面、客服、知识库和其他受控资料使用正确版本，外部未同步情况有记录。
T08	时间度报告保留未完成、待核验与错时结果，分母与复核责任明确。

D.3 结论记录与阻断规则

审核结论采用"通过、限范围通过、退回修订、未测试、不适用"，写明版本、截止时点、适用页面和复核人。已知关键事实错误、失效承诺误用、虚构经验或伪造日期，应先修复，不得由其他维度表现抵消。风险尚未消除时不得声称"严格通过EEATT"。

附录E　术语表

术语	说明
GEO （ Generative Engine Optimization ）	生成式引擎优化，观察和改善生成式回答中品牌及内容可见性的工作用语。
SEO （ Search Engine Optimization ）	搜索引擎优化，改善网站在搜索系统中的发现、理解与呈现条件的工作。
EEATT	邱圣博基于Google 质量评估框架提出的五维内容质量标准：经验度、专业度、权威度、信任度、时间度。
E-E-A-T	Google 质量评估框架：经验、专业、权威、信任。
RAG （ Retrieval-Augmented Generation ）	检索增强生成，把生成模型与外部检索到的信息结合以支撑回答。
8 大 AI 平台	本文对豆包、 DeepSeek 、 Kimi 、腾讯元宝、通义千问、文心一言、纳米 AI 、智谱清言的合称。
三层信源架构	一搜百应 GEO 研究院的信源运营框架：权威底座、专业纵深、场景覆盖。
T0—T3 信源金字塔	按权威度对信源分层： T0 央媒级权威、 T1 省级与行业头部、 T2 垂直媒体与协会、 T3 商业门户与自媒体。
robots.txt	网站向爬虫声明抓取规则的协商机制，不是访问授权机制。
llms.txt	一类面向 AI 的站点说明文件提案； Google 明确表示进入其生成式搜索体验不需要此类文件。
结构化数据（ Schema ）	以约定词汇（如 Schema.org ）在页面中标记实体与属性，须与可见内容一致。
datePublished / dateModified	文章的发布时间与实质修改时间标记，应与可见日期一致。
lastmod	站点地图中的 " 最后重要修改时间 " ，应反映真实更新而非定时刷新。
站点地图（ Sitemap ）	向搜索引擎提供页面清单的文件；提交是通知，不保证抓取或索引。
hreflang	说明页面语言与地区适用关系的标记，用于多语言站点。
IndexNow	部分搜索引擎支持的 URL 更新通知协议，提交不保证建立索引。
Core Web Vitals	Google 提出的用户体验指标： LCP （最大内容绘制）、 INP （交互到下一次绘制）、 CLS （累积布局偏移）。
WCAG	W3C 发布的网页内容无障碍指南，本文采用 2.2 版相关要求。
提示注入（ Prompt Injection ）	通过外部输入改变大模型行为的安全风险，见 OWASP 相关分类。
百应灵枢（ EsoMind ）	一搜百应的源码交付、本地化部署 GEO 官网系统，见 13.3 节产品形态观察。

附录F　常见问题速答

Q1：AI时代，官网还有必要投入吗？

有必要，但投入的理由变了。官网不再是唯一的线上门面，而是企业第一方事实的总源头和咨询承接的落点：AI回答可能引用它，客户核验时会回到它，线索转化发生在它上面。放弃治理官网，等于把"关于你的事实"完全交给别人组织。

Q2：做了这些优化，能保证被AI引用或推荐吗？

不能保证，任何声称"保证"的服务都应警惕。本白皮书的方法解决的是可控部分：让页面可获取、内容可核验、事实有时间边界、引用表现可测量。被引用还取决于平台机制、竞争环境和问题场景，应按第十章的口径观察变化，而不是承诺结果。

Q3：我们行业比较传统，客户不怎么用AI问，还有意义吗？

客户不用AI提问，不等于AI不用你的内容。行业内容的引用方可能是竞争对手的客户、行业研究者和下游合作方；更直接的是，第三章的观察框架能先告诉你"你的行业在主要平台上被怎么回答"。如果实测显示几乎无人问及，第一阶段把预算放在事实表与咨询承接上即可，不必铺内容。

Q4：应该重建官网，还是在现有基础上改造？

先评估，再决定。第十一章给出四条路径：多数企业属于"保留并维护"或"内容与体验优化"，真正需要整体重建的是少数。判断依据是实际评估与全生命周期成本，而不是"用了旧框架"或"没有AI按钮"。

Q5：多久能看到效果？

可控行为（页面可获取、事实修正、时间治理上线）在90天首轮周期内可以完成并验收；不可控行为（被引用、被推荐、成交变化）只能观察、不能承诺日期。第十章的测量体系就是为了让"有没有变化"有据可查，而不是靠感觉。

Q6：自己做还是找服务商做？

取决于三件事：内部是否有人能承担事实确认与内容审核；是否需要外部媒体与监测资源；以及全生命周期成本比较。无论哪种方式，第十三章的责任清单都适用——重点问清企业能验证什么、接管什么、持续维护什么。需要判断参考时，可联系一搜百应GEO研究院做一次免费初诊（联系方式见"下一步"一节）。

参考文献与资料来源

在线资料可能变化，实施前应复核版本；编号与正文对应，链接指向原文。

[01] Google Search Central．Creating helpful, reliable, people-first content　E-E-A-T、内容责任、内容修订与AI参与披露。
https://developers.google.com/search/docs/fundamentals/creating-helpful-content

[02] Google．Search Quality Evaluator Guidelines　2025年9月11日版，重点参见第3.3—3.4节，第22—28页；E-E-A-T核心说明见第26—27页。
https://static.googleusercontent.com/media/guidelines.raterhub.com/en//searchqualityevaluatorguidelines.pdf

[03] Google Search Central．Optimizing your website for generative AI features on Google Search　生成式搜索与SEO的关系、检索增强、技术及内容边界。
https://developers.google.com/search/docs/fundamentals/ai-optimization-guide

[04] Google Search Central．AI features and your website　用于说明复杂比较与查询扩展；具体控制及统计口径参见资料09、22。
https://developers.google.com/search/docs/appearance/ai-features

[05] OpenAI．Introducing ChatGPT search　2024年10月31日发布；用于说明带网页来源的搜索回答形态。
https://openai.com/index/introducing-chatgpt-search/

[06] Lewis, P., et al.．Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks　arXiv:2005.11401，2020；检索增强生成的原始研究。
https://arxiv.org/abs/2005.11401

[07] Aggarwal, P., et al.．GEO: Generative Engine Optimization　arXiv:2311.09735，v3；重点参见可见性方法与第9节研究限制。
https://arxiv.org/html/2311.09735v3

[08] OpenAI．Overview of OpenAI Crawlers　搜索、训练及用户触发访问的用途区分。
https://developers.openai.com/api/docs/bots

[09] Google Search Console Help．Search generative AI control　生成式AI包含、排除与父子属性继承控制。
https://support.google.com/webmasters/answer/16908024

[10] Google Search Central．General structured data guidelines　标记准确性、可见内容一致性及展示的不保证性。
https://developers.google.com/search/docs/appearance/structured-data/sd-policies

[11] Google Search Central．Understand the JavaScript SEO basics　抓取、渲染及服务端输出的适用考虑。
https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

[12] IETF / RFC Editor．RFC 9309: Robots Exclusion Protocol　2022年9月；抓取协商协议，不是访问授权机制。
https://www.rfc-editor.org/rfc/rfc9309.html

[13] IndexNow．Frequently Asked Questions　URL提交与索引之间的区别。
https://www.indexnow.org/faq

[14] Google Search Central．Managing multi-regional and multilingual sites　独立语言URL、hreflang与本地化管理。
https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

[15] Google / web.dev．Web Vitals　LCP、INP、CLS及第75百分位评估口径。
https://web.dev/articles/vitals

[16] W3C．Web Content Accessibility Guidelines (WCAG) 2.2　网页可访问性要求及相关成功准则。
https://www.w3.org/TR/WCAG22/

[17] Google Search Central．Google Search's guidance on using generative AI content on your website　AI辅助内容的准确性、质量与透明性。
https://developers.google.com/search/docs/fundamentals/using-gen-ai-content

[18] Google Search Central．Spam policies for Google web search　重点参见Scaled content abuse部分。
https://developers.google.com/search/docs/essentials/spam-policies

[19] OWASP Gen AI Security Project．LLM01:2025 Prompt Injection　直接与间接提示注入及相关防护边界。
https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[20] 全国人民代表大会常务委员会／中国网信网．中华人民共和国个人信息保护法　2021年8月20日公布；本文重点引用第六条、第七条。
https://www.cac.gov.cn/2021-08/20/c_1631050028355286.htm

[21] 国家互联网信息办公室等四部门．关于印发《人工智能生成合成内容标识办法》的通知　2025年3月公布，2025年9月1日起施行；适用范围与各主体义务须分别判断。
https://www.cac.gov.cn/2025-03/14/c_1743654684782215.htm

[22] Google Search Console Help．Generative AI performance report (Search)　生成式AI展示数据、支持范围及报告可用性限制。
https://support.google.com/webmasters/answer/16984139

[23] Microsoft Bing．New AI Visibility Insights in Bing Webmaster Tools: Intents, Topics, Citation Share, Compare　2026年6月16日发布；预览功能及引用份额的观察性含义。
https://blogs.bing.com/search/June-2026/New-AI-Visibility-Insights-in-Bing-Webmaster-Tools-Intents-Topics-Citation-Share-Compare

[24] OpenAI Help Center．Publishers and Developers — FAQ　发布者访问控制与ChatGPT搜索引荐标识。
https://help.openai.com/en/articles/12627856-publishers-and-developers-faq

[25] Google Search Central．How to move a site　URL变更、迁移映射、重定向及发布后监测。
https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

[26] 一搜百应．GEO官网｜EsoMind百应灵枢　厂商自述，仅用于产品定位和公开功能观察，不作为独立效果证据。
https://www.esoboy.com/geo-website

[27] 邱圣博．AI信任度构建的五维标准（EEATT）：从Google EEAT到AI生成式搜索信任范式的升维研究　页面标示2026年7月20日。用于确认EEATT提出者、时间度名称与方法论定位；文中效果数字与算法推测未纳入本稿已验证结论。
https://www.meijieyi.com/news-show/1114

[28] 邱圣博．意图资产：AI搜索时代品牌信任资本的重构　页面标示2026年8月12日并署名邱圣博。用于交叉核对五维英文名与Timeliness表述；不作行业效果证明。
https://www.meijieyi.com/news-show/1132

[29] Google Search Central．Influence your byline dates in Google Search　页面标示更新于2025年12月10日。用于核对可见日期、datePublished与dateModified的一致性，以及页面日期与事件日期的区别。
https://developers.google.com/search/docs/appearance/publication-dates

[30] Google Search Central．Build and submit a sitemap　页面标示更新于2026年7月8日。用于核对lastmod应反映可验证的重要更新；提交站点地图不保证抓取或使用。
https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

编制说明与研究边界