On-Page 要让页面容易理解

On-Page 检查的目标是让用户、浏览器和搜索系统快速理解页面。它可以从以下几项开始：

• 页面 title 能准确、简洁地区分内容；
• 搜索摘要所需信息能在正文和 Meta description 中找到；
• H1 表达页面主任务，H2／H3 形成可扫描层级；
• URL 稳定、可读，并与站点结构一致；
• 图片有描述信息用途的 alt，不把关键词堆入替代文本；
• 重要页面通过导航、目录、面包屑或正文内链可达；
• 作者、组织、发布日期、更新时间和证据在需要时可见；
• CTA 与页面任务相关，不遮挡主要内容。

Google 当前的 SEO Starter Guide 说明，搜索中的 title link 可能参考 <title>、页面标题和其他文字，摘要有时来自 Meta description，也可能来自页面内容。^[1] 因此，Title 不能被当成唯一标题来源，Meta description 也不是固定显示的广告位。

历史案例中出现过 Title 60 字符、一个 H1、约 1% 关键词密度等检查值。它们可以提醒编辑控制可读性与主题清晰度，不属于统一排名门槛。页面是否需要一个或多个 H1，应以 HTML 语义、组件和阅读结构判断；关键词自然出现在必要位置即可，不需要计算密度或反复使用同一词形。^[2][3][4]

CTR、停留时间、跳出率和页面互动对产品体验有直接意义，也能帮助发现承诺与内容是否匹配。现有材料不足以把它们写成可以操纵的单一排名开关。优化应回到查询、标题、摘要、页面任务和使用体验，而非制造点击或拖延停留。

技术 SEO 检查最终公开输出

使用 React、Vue、Next.js、WordPress 或建站工具，本身不能决定搜索结果。需要检查的是公开 URL 最终返回什么：主要内容是否稳定可见，HTTP 状态是否正确，移动端能否使用，页面关系是否清楚。^[2][5]

一份早期技术清单可以覆盖：

访问与索引控制

• HTTPS 与稳定的 200、301、404 等状态；
• robots.txt 是否误挡重要资源或页面；
• 需要排除索引的页面是否使用合适的 noindex 或访问控制；
• Sitemap 只包含希望公开和规范化的 URL；
• 登录、预览、测试和参数页面不会意外进入搜索。

robots.txt 用于控制抓取，不适合单独承担从搜索中移除页面的任务。需要保护的私有内容应有真正访问控制，不能把「爬虫看不到」当成保密。^[6]

URL 与重复页面

• Canonical 是否指向希望保留的代表版本；
• HTTP／HTTPS、www／非 www、尾斜杠和大小写规则是否一致；
• 筛选、排序、追踪参数和打印页是否制造大量重复；
• 301 是否用于已永久移动的内容，内部链接是否更新；
• 404 页面和失效链接是否可发现、可处理。

渲染与语义

• 服务器响应或渲染后 HTML 中能否获得主要内容；
• JavaScript 错误、延迟请求和 Hydration 不会让正文长期空白；
• 标题、导航、表单、图片和链接使用清楚语义；
• 结构化数据与页面可见内容一致，并通过适用测试；
• 图片尺寸、格式、懒加载和 alt 不损害使用。

结构化数据可以帮助搜索系统理解页面并获得特定搜索外观资格，不保证一定展示 Rich Result，也不单独保证排名。Google 当前要求标记反映页面真实可见内容，避免虚假评价、过期、隐藏或误导性信息。^[7]

性能与移动体验

• 首屏主要内容能及时出现；
• 图片、字体、脚本和第三方组件不会造成明显阻塞；
• 页面交互后能及时响应；
• 布局不会在加载时大幅移动；
• 手机上的字号、导航、表单和 CTA 可用。

Search Console 的 Core Web Vitals 报告目前依据真实使用数据，用 LCP、INP 和 CLS 对 URL 组进行状态判断；新站或流量不足时可能没有数据，报告也不是全部索引 URL 的清单。^[8] 实验室工具适合定位问题，真实用户数据适合观察实际体验，两者都不构成收录或排名保证。

多语言 SEO 从当地查询重新研究

翻译中文页面并替换语言代码，无法保证当地用户用相同方式描述问题。词序、术语、单位、法规、支付、竞品和结果页类型都可能变化。多语言页面应从目标国家和语言的查询、SERP、用户对话和产品使用重新建立页面地图。^[2][3]

执行时可以依次处理：

1. 选择明确市场与语言，不把「全球英文」当成单一受众；
2. 研究当地查询、竞品、页面类型和商业条件；
3. 由熟悉市场的人核对术语、例子、价格、法规和自然表达；
4. 决定子目录、子域名或 ccTLD，并评估品牌资产、技术边界和维护能力；
5. 为各语言版本设置可访问 URL、语言导航、Canonical 与 hreflang 关系；
6. 分别观察 query、country、page、产品行为和支持成本。

Google 的国际化文档目前建议网站明确不同语言或地区版本，hreflang 可帮助 Google 理解这些页面之间的本地化关系；根据访问者位置或浏览器语言动态返回内容的页面，可能无法让爬虫发现所有地区版本。^[9] 因此，每个重要版本最好有稳定可访问的 URL，用户也能主动切换。

子目录、子域名和 ccTLD 没有脱离项目条件的绝对优劣。已有域名资产、团队权限、部署方式、本地品牌要求、内容差异和长期维护成本更重要。新语言上线前要先确认有人持续更新，避免一批过期翻译长期存在。

AI 可以提效，发布责任仍需落实

AI 工具适合整理用户问题、归类查询、生成候选结构、提取需要核对的事实、制作初稿和检查重复。它也会生成不存在的人名、数字、链接和案例，或者把多个来源重新拼接成流畅但没有独立价值的页面。^[5][10]

一份发布前的人审流程可以包括：

• 打开原始来源，确认数字、日期、人物、产品和引用；
• 区分官方事实、项目经验、第三方估算和编辑判断；
• 添加真实测试、截图、数据、失败情形或专业经验；
• 检查页面是否完整完成搜索任务；
• 删除模板化开头、重复段落和没有信息的结论；
• 核对标题、描述、结构化数据、图片 alt 和链接；
• 高风险医疗、法律、财务和安全内容由适当专业人士复核；
• 记录负责人、来源、更新时间和更正方式。

Google 当前对生成式 AI 内容的公开说明把重点放在准确、质量和相关性，生成方式本身不自动决定好坏；使用生成工具批量制作、却没有为用户增加价值，可能违反 Scaled Content Abuse 政策。^[11][12] 同一边界也适用于人工外包、抓取拼接和自动翻译。问题在页面价值与操纵目的，不在是否使用某一种工具。

规模化之前先发布一小批可审核页面。观察它们能否被抓取和索引、出现哪些 Query、是否获得点击、页面是否被使用、事实与模板哪里出错。单个页面任务成立、数据链路正确且维护能力存在，再决定是否扩大。每天几篇、几千个页面都不能作为安全线。