SEO建站技术的关键在于：在建站阶段就把搜索引擎能理解的结构做进代码骨架里。它要保证三件事：搜索引擎能不能发现页面（抓取）、能不能正确理解页面（渲染与内容解析）、会不会把页面当成独立有价值的结果（索引与去重）。这三件事在代码层面就基本定型了，后期只靠内容和外链很难补救。
下面我们按建站流程逐层拆解：URL 结构、抓取控制、渲染方式、canonical、结构化数据、Core Web Vitals 和内链结构。每一节都说明判断标准、实施方法和验证手段，并标注证据强度。
一、建站前：URL 结构与信息架构
URL 结构是建站阶段成本最低、后期改动代价最高的部分。分类层级、语言版本、参数规则一旦定下来，后面每次调整都意味着重定向和重新积累信号。
- 语义化：使用可读的路径，避免无意义的 ID 堆叠（如 /p/12873.html）。但语义化不等于关键词堆砌。
- 稳定优先：URL 一旦对外发布就尽量不要再改；如果必须改，就用 301 永久重定向，而不是 302 临时跳转。HTTP 状态码的语义见 MDN：HTTP 响应状态码。
- 层级扁平：重要页面尽量在 3 次点击内可达，层级过深会稀释抓取路径。
- 参数规划：筛选、排序、分页参数在建站时就要决定哪些允许被抓取、哪些用 canonical 或抓取规则处理。
信息架构要同步确定：谁是栏目页、谁是聚合页、谁只服务于站内搜索。站内搜索结果页和用户生成内容页通常不应该进入索引，正确做法是在模板层直接输出 noindex，而不是上线后再靠外部手段补救。
二、抓取层：robots.txt、XML Sitemap 与状态码
robots.txt 是抓取控制协议，不是索引控制工具。这是 SEO 从业者最常混淆的一点。Google 官方文档在介绍 robots.txt 时明确指出，如果目标是让页面不出现在搜索结果中，应使用 noindex 等机制；而被 robots.txt 阻止抓取的页面，爬虫也读不到页面上的 noindex 标记。详见 Google Search Central：robots.txt 简介。
XML Sitemap 是帮助搜索引擎发现 URL 的提示，不是收录保证。它解决的问题是「让爬虫更快知道哪些 URL 存在」，不能替代内链、也不能强制页面被索引。官方说明见 Google Search Central：Sitemap 概述。
- Sitemap 只放返回 200 状态、允许被抓取、且你希望出现在搜索结果中的 URL。
- 不要在 Sitemap 里混入 301、404、noindex 页面，这会削弱该文件的可信度。
- 站点规模变化时同步更新，并通过 Search Console 提交。
状态码层面的建站规范：已删除内容返回 404 或 410，永久迁移用 301，临时活动跳转用 302，站点维护期用 503。不要让不存在的页面返回 200 并渲染「内容不存在」的提示，这是最常见的索引质量问题之一。
三、渲染层：服务端渲染与客户端渲染的取舍
服务端渲染把完整 HTML 直接返回给爬虫和用户；客户端渲染则依赖 JavaScript 执行后才生成内容。Google 官方文档说明其抓取流程包含抓取与渲染两个阶段，由 JavaScript 生成的内容需要进入渲染队列处理，存在延迟与不确定性，详见 Google Search Central：JavaScript SEO 基础。
建站时的落地建议：
- 正文内容、title、meta robots、canonical、结构化数据、内链尽量出现在初始 HTML 中。
- 需要客户端渲染的部分，不要依赖点击、滚动或登录后触发。
- 用「查看网页源代码」和 Search Console 的网址检查工具，对比渲染前后 DOM 的差异。
- 对内容型站点，服务端渲染或静态生成通常是更稳妥的默认选择；纯后台系统类页面则无需为此付出成本。
四、索引层：canonical 与重复内容
canonical 是提示（hint），不是强制指令。Google 官方文档把 rel=canonical 描述为一种提示，搜索引擎会综合内链、Sitemap、重定向和内容相似度来判断首选版本，见 Google Search Central：规范化（Canonicalization）。
因此当 canonical 不生效时，只改 canonical 标签通常无效，需要同时排查：
- 站内链接和导航是否仍指向重复版本；
- Sitemap 中提交的是哪个 URL；
- 是否存在多跳重定向或重定向链；
- 两个版本的内容差异是否过大（差异过大时搜索引擎可能不合并）；
- hreflang 与 canonical 是否互相矛盾。
五、结构化数据：只做 Google 明确支持的类型
结构化数据（通常用 JSON-LD 实现）帮助搜索引擎理解页面上的实体。需要明确的是：Google 只对部分 schema.org 类型提供富媒体搜索结果展示，添加标记本身不保证出现富媒体结果，见 Google Search Central：结构化数据简介。
- 只标记页面上真实可见的内容，标记与可见内容不一致属于质量问题。
- 优先使用搜索中心文档中列出的功能类型（Article、Product、Breadcrumb、FAQ 等），不要为「覆盖更多类型」而堆砌。
- 用富媒体搜索结果测试和 Search Console 的增强功能报告做验证，而不是凭肉眼判断。
六、Core Web Vitals 与页面体验
Core Web Vitals 目前由 LCP、INP、CLS 三项指标构成，其中 INP 已在 2024 年 3 月取代 FID，指标定义与阈值见 web.dev：Web Vitals。建站阶段的可控点：
- LCP：首屏主图不要懒加载，预加载关键资源，避免首屏内容依赖 JS 注入。
- INP：减少长任务，拆分事件处理，限制第三方脚本占用主线程。
- CLS：为图片、广告位、嵌入内容预留固定尺寸，字体加载策略避免布局跳动。
需要区分事实与观点：Google 将页面体验描述为整体信号的一部分，但把 Core Web Vitals 直接等同于「做了就会提升排名」并不准确，也没有官方文档支持这种因果表述。
七、内链结构：让抓取路径可预测
内链结构决定两件事：爬虫能沿什么路径发现页面，以及页面之间传递的信号如何分布。建站阶段的规范做法包括：导航与面包屑使用真实可抓取的 a 标签而非 JS 跳转；重要页面从首页或栏目页有稳定入口；避免孤岛页面只靠 Sitemap 被发现；分页使用可抓取的链接序列。
可抓取链接的技术说明见 Google Search Central：链接可抓取性。
八、上线与迁移检查清单
- 关键模板的 title、meta description、canonical、meta robots 是否由程序正确生成；
- robots.txt 是否误拦截 CSS、JS 或整站路径；
- XML Sitemap 是否只包含可索引 URL；
- 旧 URL 是否已配置 301 且无重定向链；
- 是否有页面返回 200 但内容为空或为错误提示；
- 结构化数据是否通过校验；
- 移动端与桌面端渲染结果是否一致；
- Core Web Vitals 在真实用户数据中是否进入「良好」区间。
九、常见错误与排错顺序
排错应遵循「抓取 → 渲染 → 索引 → 展示」的顺序，而不是一上来就改内容：
- 页面没被收录：先看 robots.txt 与状态码，再看是否 noindex，最后看渲染结果是否包含正文。
- 索引了错误版本：先查 canonical 与内链指向，再查 Sitemap 与重定向。
- 流量突然下降：先排查技术层（误加 noindex、robots.txt 被改、服务器返回 5xx），再考虑算法更新。
站点级抓取异常的处理参考 Google Search Central：HTTP 网络错误。
十、常见问题
Q：建站时用静态生成还是动态渲染？
取决于内容更新频率与个性化程度。内容型站点用静态生成或服务端渲染能让首屏 HTML 直接包含正文，抓取与渲染路径最短；强个性化页面不在此列。
Q：robots.txt 里屏蔽页面，搜索结果里就不会出现吗？
不会。被 robots.txt 阻止抓取的页面无法被读取 noindex，仍可能以「无摘要」形式出现。索引控制要用 noindex。
Q：canonical 写了就一定会生效吗？
不会。它是提示而非指令，需要内链、Sitemap、重定向等信号一致配合。
Q：结构化数据越多越好吗？
不是。只标记 Google 明确支持且页面真实可见的内容，多余标记没有收益，还可能带来维护成本和一致性问题。