企业官网 SEO/GEO 基础体检清单：上线前必须检查的 30 个项目

这份清单适用于什么场景

企业官网新上线、域名迁移、整站改版、CMS 更换、批量发布文章或新增英文站时，都应执行一次完整体检。日常内容发布可以使用其中的页面级项目，月度或季度复盘则重点检查索引、模板、链接和数据变化。

SEO 关注搜索引擎能否抓取、索引并把页面匹配给相关查询；GEO 更关注企业事实是否以清楚、可核验、容易提取的方式出现在公开页面中。两者共享同一基础：可访问的页面、明确的实体、可靠的事实、稳定的 URL 和持续维护。任何检查都不能保证排名或 AI 引用，但可以减少明显的技术与内容障碍。

一、抓取与访问：项目 1—6

1. 核心 URL 返回正确状态码。 首页、产品页、方案页、案例页和文章页应直接返回 HTTP 200，不以伪 404 页面或多次跳转代替。
2. HTTP 到 HTTPS 只有一条规范跳转。 域名协议和主机名统一，避免 www、非 www、HTTP 与 HTTPS 同时形成多个可访问版本。
3. robots.txt 没有误封公开目录。 检查模板、脚本、样式和正文所在路径；不要因为测试规则遗留而阻止公开页面抓取。
4. 页面没有意外的 noindex。 核对 HTML meta robots 与 HTTP X-Robots-Tag，特别检查从预发布环境复制过来的模板。
5. 重要正文无需登录或交互才能出现。 产品参数、文章正文和联系信息应在公开页面中可读取，不能只存在于登录后接口或点击后才加载的不可访问区域。
6. JavaScript 页面有可验证的渲染结果。 查看浏览器最终 DOM，并确认主要标题、正文和链接在搜索引擎可执行环境中能够呈现；关键内容优先由服务端或静态 HTML 输出。

二、索引与 URL：项目 7—12

1. 每个主题有一个规范 URL。 参数、大小写、尾斜杠和重复路径有统一规则，重复版本通过跳转或 canonical 收敛。
2. canonical 指向真实可索引页面。 自引用 canonical 应与当前规范 URL 一致，不要把不同产品、语言或内容合并到无关页面。
3. Sitemap 只提交规范 URL。 XML Sitemap 中的地址应返回 200、允许索引并使用绝对 URL；删除、跳转或 noindex 页面不应长期保留。
4. 站内链接能够到达重要页面。 产品、方案、案例和知识文章不能成为只有 Sitemap 可发现的孤立页面。
5. 旧 URL 有明确迁移策略。 改版时建立旧地址到最相关新地址的一对一 301 映射；无法替代的内容返回 404 或 410，不全部跳向首页。
6. 分页、筛选和搜索结果有索引边界。 确定哪些组合具有独立价值，避免大量参数页、内部搜索页和空列表页进入索引。

三、页面表达：项目 13—18

1. 每页有唯一且准确的 title。 title 说明页面主体、用途和品牌，不复制整站模板，也不堆叠重复关键词。
2. meta description 对应页面内容。 描述用一两句话说明读者能获得什么；它影响搜索摘要表达，但不是排名或展示承诺。
3. 每页只有一个主要 H1。 H1 与页面任务一致，后续 H2、H3 按信息层级组织，不用字号代替语义结构。
4. 开头直接回答核心问题。 定义、结论、适用条件或关键步骤应尽早出现，让读者和机器无需在长篇背景中寻找答案。
5. 页面说明适用对象和边界。 产品能力、行业条件、实施前提、限制和不适用情形要写清楚，避免只保留宣传结论。
6. 行动入口与搜索意图一致。 信息型文章可以链接到相关指南、产品功能或咨询入口，但不应在每段强行插入销售按钮。

四、事实与 GEO 内容单元：项目 19—24

1. 公司实体信息一致。 公司名称、品牌名、地址、联系方式、官网域名和业务说明在首页、关于页、页脚与结构化数据中保持一致。
2. 产品名称和术语统一。 建立正式名称、简称、型号和各语言译名，避免同一对象被写成多个无法关联的名称。
3. 参数包含单位、条件和版本。 不能只写一个数字；应说明测试或适用条件、范围、单位、数据日期以及是否为选配。
4. 步骤具有可执行顺序。 流程内容写出输入、动作、输出、责任人和异常处理，不以“轻松完成”等模糊表达替代方法。
5. 对比使用统一维度。 产品、方案或方法比较必须采用相同口径，并说明信息来源和适用条件，不能选择性隐藏不利差异。
6. 证据能够追溯。 数据、认证、案例、客户评价和研究结论要保留来源、授权、日期及适用范围；缺少证据时应删除或改为条件性建议。

五、多语言与结构化数据：项目 25—28

1. 每种语言使用独立 URL。 中文和英文页面分别可访问、可索引，并由目标市场人员审核术语和搜索意图，而不是只替换界面文字。
2. hreflang 双向且完整。 每组语言页面互相声明，并包含自身；可根据站点策略设置 x-default。canonical 通常保持各语言自引用。
3. Schema 类型与页面任务匹配。 企业身份使用 Organization，真实产品页使用 Product，文章使用 Article，层级导航使用 BreadcrumbList；不要在文章页伪装 Product。
4. 结构化数据与可见正文一致。 名称、日期、作者、参数、FAQ 和面包屑不能只写在 JSON-LD 中，也不能与页面显示内容冲突。

六、监测与发布控制：项目 29—30

1. 上线后有测量基线。 记录 Search Console 的索引与展示数据、分析工具中的访问与转化事件，以及企业对“有效询盘”的明确判定规则。不同系统口径不同，不要求数值完全相等。
2. 发布有版本、备份、验证和回滚。 保存发布前文件与哈希，先在独立版本目录预览，再原子切换；上线后检查状态码、正文、元数据、Schema、Sitemap 和核心转化入口。

怎样把检查结果转成整改任务

体检表至少包含 URL、检查项、检查方法、当前证据、严重程度、负责人、目标日期和复验结果。严重程度可以按影响划分：阻止访问或索引的问题优先；大面积模板错误其次；单页表达和增强项随后处理。

不要只写“SEO 有问题”。例如，“/product-a 的 HTTP meta 含 noindex，2026-08-31 用 curl 复现，负责人为网站运维，修复后需重新请求索引”就是可以验收的任务。

GrowSiteX 可用于把企业资料、关键词、标题、文章、审核和 CMS 发布组织成持续工作流。技术体检仍需结合实际站点、服务器、模板和搜索平台数据执行；系统不能替代事实确认、工程验证或搜索平台的索引决定。

建议的检查频率

• 每次发布：状态码、title、H1、canonical、正文、内部链接、Schema 和 Sitemap。
• 每周：新页面索引状态、抓取异常、404、发布失败和重要询盘路径。
• 每月：查询与页面表现、主题覆盖、内容过期、内部链接和模板一致性。
• 每次改版或迁移：完整执行 30 项，并保留发布前后证据。

参考资料

• Google Search Central：抓取和编入索引
• Google Search Central：构建和提交 Sitemap
• Google Search Central：JavaScript SEO 基础
• Google Search Central：AI 搜索体验中的网站优化指南
• GrowSiteX 产品功能

常见问题

30 项全部通过就能获得排名或 AI 引用吗？

不能。这份清单用于减少抓取、索引、结构和事实表达方面的障碍。实际结果还取决于需求、竞争、内容价值、网站历史和持续运营，搜索或 AI 平台保留最终选择权。

小型企业需要一次完成所有项目吗？

应先完成阻止访问、索引和事实准确性的项目，再按影响处理模板、多语言、Schema 和增强项。可以分批修复，但必须记录未完成项和风险。

GEO 是否需要单独制作一套页面？

通常不需要。清楚的实体信息、直接回答、可追溯证据、稳定 URL 和结构化内容同时服务读者、搜索引擎与 AI 检索。只有目标受众或意图不同，才应建立独立页面。

SEO 表现、AI 引用、自然流量、询盘与成交会受到网站基础、市场竞争、内容质量和持续运营等因素影响，不承诺具体结果。