网站 SEO/GEO 基础指南：从搜索可见性到 AI 搜索
一份面向个人站、内容站与企业网站的 SEO/GEO 入门实践指南，涵盖搜索意图、内容、抓取索引、URL、结构化数据与 AI 搜索。
SEO 并不是把网站的技术评分刷到满分，GEO 也不是给页面添加几段“专门写给 AI 的话”。两者最终都在解决同一个问题：让真正需要这些信息的人或系统能够发现、理解并信任你的内容。
这篇指南整理网站 SEO（Search Engine Optimization，搜索引擎优化）与 GEO（Generative Engine Optimization，生成式搜索优化）的基本工作方法，适用于个人博客、知识型网站、企业官网和产品网站。不同网站的商业目标不同，但内容可访问、主题清楚、证据可靠的原则是相通的。
本文重点区分三类事情：搜索引擎明确说明的规则、值得采用的工程实践，以及目前缺乏可靠证据的 GEO 传言。
一、先弄清 SEO 与 GEO 的目标
SEO 关注网页是否容易被搜索引擎发现、抓取、理解、索引，并在相关查询中获得展示机会。
GEO 关注内容在生成式搜索和 AI 问答环境中的可发现性、可理解性与可引用性。不过，不同 AI 搜索产品的抓取、索引和引用机制不一定相同，不能把某个平台的规则当成整个行业的统一规则。
一个实用的目标顺序是：
- 可访问：页面确实能够打开，重要正文可以被读取。
- 可理解：页面清楚说明自己解决什么问题，与站内其他页面分工明确。
- 可信任：信息准确，有可追溯的资料、经验、实验或案例支持。
- 有用：读者能得到答案、完成决策或采取下一步行动。
- 可衡量：通过真实搜索表现、用户行为或业务结果判断优化是否有效。
排名、点击率、AI 引用量都是观察指标，不是内容价值本身；任何单项指标提升都不自动等于网站成功。
二、搜索引擎首先要能读到内容
搜索引擎通常需要经过发现 URL、抓取页面、理解内容和建立索引等过程。但网站可抓取不代表一定会被收录，已收录也不代表一定有排名。
上线前至少核对下面几个项目：
| 项目 | 需要确认什么 |
|---|---|
| HTTP 响应 | 正式内容页能正常返回 200，不存在无意的登录墙或访问限制 |
| HTML 正文 | 主要内容能从页面获取，不能只依赖复杂交互后才显示 |
robots.txt |
没有意外禁止搜索引擎访问希望被发现的内容 |
noindex |
需要收录的页面未被错误标记为不索引 |
| Canonical | 页面指向正确、可访问的规范 URL |
| Sitemap | 站点地图列出希望搜索引擎发现的规范内容页 |
| 内部链接 | 重要页面能够从导航、列表或相关文章进入 |
这里有个经常被误解的区别：robots.txt 主要控制抓取，而 noindex 控制是否进入搜索索引。如果搜索引擎因为 robots 规则无法抓取页面，也就可能读不到页面里的 noindex。
同样，robots.txt 不是隐藏敏感内容的安全机制。
相关资料：Google 搜索技术要求、robots.txt 简介、noindex 使用说明。
三、先研究搜索意图，再决定写哪个页面
关键词研究的核心不是找出搜索量最大的词，而是理解搜索这个词的人希望完成什么任务。
同一个主题可能包含不同意图：
| 搜索意图 | 用户在找什么 | 通常适合的页面 |
|---|---|---|
| 了解概念 | 这是什么、为什么需要 | 入门文章、知识说明 |
| 学习方法 | 怎么做、如何排错 | 操作教程、技术文档 |
| 比较方案 | A 与 B 有什么区别 | 对比文章、选型指南 |
| 查看产品或服务 | 有哪些选项、是否适合 | 产品页、服务页、分类页 |
| 寻找品牌 | 官网、官方文档、联系方式 | 首页、About、Contact |
例如，“什么是静态网站生成器”和“如何部署静态网站”属于不同任务。它们可以互相链接，但不必把所有信息塞进一篇文章。
规划内容时，可以按这个顺序做：
- 用一句话写出目标读者真正的问题。
- 检查站内是否已有能回答它的页面。
- 比较现有页面的 Title、H1、正文与搜索意图，确定主要承接页面。
- 如果已有内容可以完善，优先更新；只有确有独立需求时再建新页。
- 发布后利用真实查询与用户行为调整。
没有 Search Console 或可靠第三方数据时，不要杜撰搜索量、关键词难度或预计流量。
四、信息架构要让页面各司其职
网站导航首先服务用户，也有助于搜索引擎发现内容。下面只是一种常见的信息架构示例，不是所有网站都必须采用的目录模板：
/
├── about/
├── services/
├── products/
├── blog/
│ └── example-article/
├── projects/
└── contact/每一种页面的职责可以很明确：
- 首页：告诉访问者这是什么网站，重点内容在哪里。
- 分类页：帮助读者缩小选择范围，理解同一主题或同一产品系列。
- 产品或服务页：说明具体对象、特点、适用边界和可采取的行动。
- 文章页：认真回答一个具体问题，提供方法、解释、证据和相关阅读。
- 项目或案例页：说明实际做过什么，哪些结果有证据支持。
- 联系页：提供明确、可用的联系路径。
网页路径中的目录名不是排名魔法。使用 /blog/article-name/ 可以让博客与其他页面分开管理；文章放在根目录并不会因此自动受到 Google 处罚。根据网站规模、现有路由和维护习惯，选择一种稳定、清晰的结构即可。
把文章放在 /blog/ 下有什么实际好处？
对于有产品、服务、项目和文章等多个内容类型的网站，/blog/{slug}/ 往往比在根目录直接使用 /{slug}/ 更容易长期管理：
- 减少路由冲突：文章名称不容易与
/about/、/services/等主要栏目撞名；但具体冲突仍取决于路由实现。 - 方便内容分析：可在 Search Console 中按
/blog/URL 路径筛选文章表现；在 GA4 中按页面路径建立内容组（需要自行配置）。 - 方便维护和迁移：内容列表、分页、重定向与缓存规则更容易按目录分类；不意味着必须增加缓存规则。
- 便于多语言扩展：例如
/en/blog/example/，前提是页面确实提供相应语言的完整内容。
这属于信息架构和运营管理的取舍，并不是 Google 规定“博客必须放在 /blog/ 才能排名”。已有稳定地址的内容不应只为统一格式就贸然改 URL。
五、Title、Meta Description 和标题层级
1. Title：明确告诉读者这页讲什么
每个重要页面都应该有与正文一致、能区分其他页面的 HTML Title。标题应自然、具体，不要机械堆砌关键词。
例如：
- 不够明确：
技术知识分享 | 首页 - 更明确：
GitHub Pages 部署教程：从仓库到网站上线
Google 没有规定所有 Title 必须少于 60 个字符。 60 字符可以作为某些团队的编辑参考值，但搜索结果标题还受像素宽度、设备、查询和 Google 自行生成标题等因素影响。
2. Meta Description：用一两句话描述页面价值
Description 应该概括页面能帮助读者完成什么。它可能影响搜索结果摘要的表达，但 Google 不保证原样展示，也不能把它当作直接排名按钮。
160 字符同样是常见的内部编辑目标，不是 Google 的统一强制限制。
3. H1、H2、H3：让文章按内容逻辑组织
通常使用一个清楚的主 H1，再以 H2、H3 分层组织正文。不要为了视觉字号而随意改变标题语义，也不要为了所谓 SEO 固定插入大量小节。
4. AI 生成元数据时，用代码核对长度
AI 适合提出候选文案，但不适合依赖目测准确统计字符。若网站自行采用 Title ≤60、Description ≤160 的编辑规范，可用 Python 做实际校验：
title = "GitHub Pages 部署教程：从仓库到网站上线"
description = "了解使用 GitHub Pages 部署静态网站的主要步骤，以及常见配置问题。"
title_limit = 60
description_limit = 160
assert len(title) <= title_limit, "请重新改写 Title"
assert len(description) <= description_limit, "请重新改写 Description"
print("Title:", len(title))
print("Description:", len(description))程序负责判断是否超限，作者负责保证文案准确自然；不要使用字符串切片生硬截断。模板可能自动添加站点名称，因此最终仍需核对生成 HTML 中的完整标题和描述。
另外，Python 的 len() 统计 Unicode 码位数量，和搜索结果的实际像素宽度、某些 Emoji 的视觉字符数不是一回事。
六、高质量内容不是关键词和字数的堆积
一篇有价值的文章至少应该回答五个问题：
- 读者究竟遇到了什么问题？
- 这篇文章写给谁？
- 最重要的结论是什么？
- 结论来自哪些资料、测试、观察或实际经验？
- 读者看完能够怎么做？
写技术教程时，最好交代适用版本、前提条件、执行步骤、容易失败的地方及验证方法；写对比文章时，最好明确比较条件，而不只是列出“优缺点”。
专业不等于复杂。 为了显得专业而增加大量术语、空泛段落和没有必要的表格，并不能帮助读者。
重复内容不等于自动处罚
不同页面出现相同的通用术语、规格或事实，不代表 Google 会对它们统一处罚。真正需要关注的是：多个 URL 是否在回答几乎相同的问题，是否让搜索引擎难以确定规范页面，是否给读者提供了实质新增价值。
优先修正文意图重叠、Canonical 不一致和站内链接混乱。不要为了“降重”而改写客观事实，更不能虚构数据。
AI 可以辅助创作，不能替代证据
可以用 AI 整理提纲、解释术语、寻找潜在反例或改善表达，但信息的准确性仍须由可靠资料与实际经验支持。
Google 关注的是内容是否有帮助、是否可靠、是否存在操纵搜索的滥用行为，并不因为内容使用过 AI 就一概处罚。相反，为占据搜索结果而规模化制造缺乏价值的页面，可能触及其垃圾内容政策。
七、GEO：先把内容做好，再讨论 AI 引用
Google 对 AI Overviews、AI Mode 等功能的说明没有要求网站额外安装某种“AI 专用 SEO 插件”。想让网站在 Google 的生成式搜索中获得出现机会，基本的搜索可访问性、索引资格和内容质量仍然重要。
实际可做的 GEO 工作，主要包括：
- 直答问题：在合适的位置尽早说明结论，再解释条件和依据。
- 信息具体：提供可核对的示例、数据、日期、测试条件和参考链接。
- 边界明确：解释适用于哪些情况，以及哪些结论还不能确定。
- 实体一致：名称、网址、作者信息、产品信息与结构化数据不相互矛盾。
- 页面可读：重要内容在正常网页中可访问，不刻意隐藏在复杂交互后。
- 持续验证：观察可辨识的 AI 来源访问与实际用户行为，不凭一次 AI 对话判断“引用率”。
几个常见 GEO 误区
| 流行说法 | 更准确的理解 |
|---|---|
上传 llms.txt 就能提高 Google AI 排名 |
Google 并未把 llms.txt 作为获得特殊搜索可见性的必要条件 |
| 添加 FAQ Schema 就能进入 AI Overview | 没有这种保证；FAQ 内容应首先服务读者 |
| 每段必须控制固定字数才能被 AI 引用 | 没有可靠的统一段落长度门槛 |
| Schema 验证通过就保证 AI 引用 | 结构化数据帮助机器理解内容，但不承诺展示或引用 |
| GEO 已经取代传统 SEO | 传统搜索基础依然重要，AI 产品之间还存在实现差异 |
可以关注新的 AI 搜索能力，但不必因为某项未经证实的“GEO 技巧”重做整个网站。
llms.txt、llms-full.txt 和单页 Markdown 分别是什么？
一些文档网站已经开始为 AI Agent 提供 Markdown 格式的内容。它们主要解决资料导航、按需读取和批量处理的问题，不等于搜索引擎排名优化。
| 文件或形式 | 主要用途 | 适合的场景 |
|---|---|---|
/llms.txt |
简短描述网站，并按主题列出重要页面或 Markdown 文档的链接 | 让 Agent 快速发现相关资料 |
/llms-full.txt |
将已公开的多页正文合并为一个较大的 Markdown 文件 | 离线索引、批量向量化、大上下文模型处理 |
单页 Markdown（例如 /docs/example/index.md） |
只提供一篇文章或一页文档的纯文本版本 | Agent 按需读取，减少 HTML 模板和不相关内容 |
Accept: text/markdown |
在服务器支持时，通过 HTTP 内容协商获取单页 Markdown | 同一内容提供 HTML 与 Markdown 两种读取方式 |
Cloudflare Docs for Agents 实际提供了这几种内容交付方式，包括 Workers 的 llms.txt 和 llms-full.txt。这是一个值得参考的工程实践案例，但不能据此推断其他网站一定会获得更多 AI 引用或搜索流量。
llms.txt v2 仍是开放社区提案，不是 Google 强制要求的网站标准。它侧重于一个精简的 Markdown 导航文件：使用 H1 写网站名称、简要描述，并在 H2 分类下提供文档链接；详细正文应尽量放到可按需读取的页面里。llms-full.txt 是部分网站采用的可选全文聚合实践，而不是每个站点必备的第二份 Sitemap。
Google Search 不要求网站添加 llms.txt 或 llms-full.txt 才能进入 AI Overviews 或 AI Mode。 对 Google 搜索而言，仍应优先保证网页可索引、内容有帮助、技术实现正确。其他 AI 产品是否读取这些文件，需要分别验证，不能笼统假设。
如果确实需要发布这些 Markdown 资源，建议遵守以下原则：
- 从已公开的唯一内容来源生成，不要人工复制维护第二份正文，也不要把草稿、内部文件、个人信息或客户敏感资料打包公开。
- 保留原页面的标题和规范 URL，清理页眉、导航、页脚等模板噪音；不要凭空补充页面没有的事实。
- 按需求决定粒度：少量重要资料可以只有
llms.txt；内容很多时优先让 Agent 按需读取单页，批处理确有需求时再考虑全文聚合。 - 检查文件大小、链接和更新同步，确保新增、更正、删除和 URL 改名后不会留下过期副本。文件越大，读取及上下文成本可能越高。
- 实际验证访问与内容：HTTP 状态、文本编码、Content-Type、链接有效性，以及公开权限。Markdown 能访问，不代表搜索引擎一定会使用或引用。
对于普通个人博客或规模不大的企业网站，先把原有 HTML 页面与内容做好，通常比专门开发一套 AI 文档系统更有价值。
八、URL、Slug、Canonical 与重定向
URL 首先应该稳定、可理解、便于维护。实际操作中重点处理几个问题。
1. 规范域名与 HTTPS
确定一个主要的 HTTPS 域名，将站内链接、Canonical 和 Sitemap 统一指向它。HTTP、WWW 等其他域名变体若需要合并，应采用合适的永久重定向，并检查最终 HTTP 响应。
2. Slug 使用清楚的词，而不是拼凑关键词
英文路径通常推荐小写单词加连字符，例如：
/blog/github-pages-deployment/Google 推荐使用连字符来分隔 URL 中的词语，但并不存在“所有 URL 都必须少于 75 个字符”或“所有文章只能在三层目录以内”这样的官方排名硬性要求。
Slug 要聚焦一件事，而不是把所有潜在关键词串起来。 可以把“尽量控制在 3～5 个有意义的英文单词以内”作为团队的编辑习惯，优先保留内容主题、必要的型号或区分词。例如 /blog/github-pages-deployment/ 比 /blog/github-pages-website-free-hosting-deployment-guide-tutorial/ 更清楚。
这里的词数只是可选的编辑标准，不是 Google 的排名门槛；没有证据表明每增加一个词，就会按固定比例稀释 URL 权重。比较词 vs、介词 for 或产品型号中的数字，只要确实影响含义，就不应为凑字数强行删除。清晰、准确、稳定比机械缩短更重要。
另外，URL 的目录层级不等于用户访问页面的点击深度。较深的路径并不意味着搜索引擎一定更难抓取；真正要检查的是清晰导航、正常 HTML 链接与实际可达性。
国际化 URL 也不是天然不允许。选择 ASCII Slug 还是本地语言 Slug，可以根据读者、内容和技术维护需求决定。
3. 尾斜杠要有统一规则
/blog/example 与 /blog/example/ 是不同 URL 形式。站点应选择一套规范形式，让内部链接、Canonical、Sitemap 及必要的重定向保持一致。Google 并没有规定博客必须带斜杠、产品页必须去掉斜杠。
4. Canonical 是提示，不是强制命令
对于参数变体或重复内容，使用正确的 rel="canonical" 说明首选 URL。搜索引擎会参考这个信号，但仍可能选择其他规范地址。
不要把所有分页内容都强行 canonical 到第一页，也不要不加区分地把所有带参数的地址指向首页。
5. URL 变更不能只改链接
如果旧文章从 /old-article/ 改到 /blog/new-article/，至少要同步考虑：
- 旧地址到相关新地址的一对一
301或308； - 正文中的内部链接；
- Canonical、Sitemap 和适用时的结构化数据 URL；
- 实际响应是否为预期的
200、301或404。
对已公开、已有访问或外链的页面，保持稳定地址通常比为了形式美观批量改名更重要。
6. 多语言与参数
存在真正独立的语言版本时，才需要规划不同语言的 URL，以及适用的 hreflang。不要把仅翻译导航菜单的页面当作完整本地化内容，也不要无条件把另一语言页面 canonical 到默认语言。
筛选、分页和跟踪参数应按其是否改变内容分别处理，不能一律删除或阻止抓取。
参考：Google URL 结构、规范化重复 URL、包含 URL 变化的网站迁移。
九、内部链接：帮助读者继续解决问题
站内链接不应只为了“增加 SEO 权重”而添加。好的内部链接能让读者自然从问题解释进入更具体的教程、文档、产品或案例。
例如，一篇 GitHub Pages 入门文章可以链接到部署步骤、域名配置和故障排查，而不是随机推荐几篇不相关的热门文章。
操作原则很简单：
- 用真实可抓取的 HTML 链接，例如
<a href="/blog/">Blog</a>。 - 锚文本描述目标内容，少用没有上下文的“点击这里”。
- 重要文章应从列表页、分类页或相关内容中可达。
- 内容有明确关联时再互相推荐，不为了满足链接数量而硬塞链接。
- 不要让有价值的文章只存在于 Sitemap 中，却没有正常的站内入口。
十、图片、视频与页面体验
图片和视频应先帮助用户理解内容，再考虑文件格式与加载策略。
- 有信息价值的图片应有清楚、准确的替代文本；纯装饰图可使用空
alt。 - 保留正确的图片比例与必要细节，不用模糊或误导性裁切制造视觉效果。
- 图片体积与尺寸适配设备；页面首屏的重要图片优先加载，其他内容按需要延迟加载。
- 视频应该提供实际有用的演示或解释，必要时添加文字说明。
- 移动端不能缺失桌面端的重要内容、导航或行动入口。
Core Web Vitals 常见的三项指标为：
| 指标 | 衡量内容 | 常用的良好体验参考目标 |
|---|---|---|
| LCP | 主要内容加载速度 | ≤ 2.5 秒 |
| INP | 用户交互响应 | ≤ 200 毫秒 |
| CLS | 页面布局视觉稳定性 | ≤ 0.1 |
这些目标通常使用真实用户数据的第 75 百分位来评估。单次 Lighthouse 测试与真实用户长期数据不是同一回事，也不能因为某一项指标合格就承诺排名提升。
参考：Core Web Vitals 与 Google 搜索、web.dev Web Vitals。
十一、结构化数据：描述真实内容，不是编造信息
Schema.org 的结构化数据可帮助搜索引擎识别某些内容类型。常见类型有：
| 类型 | 常见用途 |
|---|---|
Organization / WebSite |
描述组织或网站的真实身份 |
BreadcrumbList |
描述真实导航层级 |
Article |
描述文章标题、作者、日期等 |
Product |
描述真实产品及适用属性 |
FAQPage |
描述符合要求的问答内容，但不保证获得 FAQ 富结果 |
结构化数据应与网页上真正可见、能核对的信息一致。没有公开售价、评价或库存依据，就不要为了富结果虚构 Offer、Review 等字段。
可以使用 Google Rich Results Test 或 Schema Markup Validator 检查，但通过校验不等于保证富结果或 AI 引用。
十二、如何判断优化是否真的有效
不要只盯着收录量或 Lighthouse 分数。不同网站应该根据目标选择指标：
| 观察维度 | 可以看什么 |
|---|---|
| 搜索可见性 | Search Console 中的查询、展现、点击、CTR、平均排名 |
| 索引健康 | 正式内容页的索引情况、异常报告和 URL 检查 |
| 内容表现 | 哪些页面真正吸引匹配搜索意图的访问者 |
| 用户行为 | 阅读、继续访问、下载、联系等实际行动 |
| AI 搜索 | 能识别的 AI 来源流量、人工抽样观察及后续行为 |
页面出现问题时，优先按“能否访问 → 是否被索引 → 页面意图是否清楚 → 内容与证据是否充分 → 用户是否得到所需”的顺序定位，不要一上来就安装更多 SEO 插件。
用栏目和结果验证，而不是只看总流量
当网站有多个内容栏目时，可用 Search Console 按 URL 路径筛选，分别观察文章、产品、服务等页面的查询和点击；若使用 GA4，可配置内容组，了解不同类型内容如何影响实际阅读、注册或询盘。目录存在不会自动创建 GA4 内容组，也不能只凭搜索点击推算收益。
每次重要修改记录发布或更新日期、受影响 URL、调整内容和可观察指标。对比改动前后时注意季节、品牌活动和搜索需求等共同变化；一次排名波动不能直接证明某项 SEO 方法有效。
十三、发布前的简明检查清单
- 页面解决一个明确的用户问题，内容与标题一致。
- 事实、数据、截图和案例有可靠依据；推断与事实已区分。
- Title、Description、H1 具体且自然，没有刻意堆词。
- 页面在电脑和手机上都能完整阅读。
- 正文、图片、代码和相关链接显示正常。
- 规范 URL、Canonical、Sitemap 与站内链接互相一致。
- 希望被索引的页面没有意外抓取和索引限制。
- 有合适的相关内容入口，读者能够继续阅读。
- 如使用结构化数据，字段与网页实际信息一致。
- 对修改过的页面检查真实 HTTP 响应，而不只看源码。
- 如果改变 URL，检查旧地址的 301/308、新地址的 200，以及 Canonical、站内链接和 Sitemap 是否同步。
- 如果提供
llms.txt、Markdown 单页或全文聚合，确认来源已公开、链接有效、内容可同步更新；不要默认它们能提高排名。
结语
把 SEO 做好，不意味着每个技术指标都必须达到满分；把 GEO 做好，也不意味着要迎合所有有关 AI 抓取的传言。
对大多数网站来说，更值得优先投入的是：清楚的信息架构、可信的原创内容、可访问的 HTML、稳定的 URL、合理的内部链接，以及基于真实数据的持续改进。
技术让内容容易被找到，内容本身决定读者为什么愿意留下来。
延伸阅读
- Google Search Essentials
- Google SEO Starter Guide
- 创建以用户为中心的可靠内容
- Google 搜索垃圾内容政策
- Google 搜索标题链接建议
- Google Search Console 成效报告
- Google Search Console 页面筛选
- Google Analytics 内容组
- Cloudflare Docs for Agents：Markdown、llms.txt 与 llms-full.txt
- llms.txt v2 开放社区提案
本篇是通用实践指南，具体实施方式需要根据网站类型、技术框架、内容规模与实际目标调整；搜索引擎与 AI 产品的规则也可能更新。