导读

本文基于 claude-seo 开源仓库中的 seo-page 技能定义，完整讲解如何对单个 URL进行纵深式 SEO 审计：从 on-page 元素、内容质量、技术元标签、Schema 结构化数据、图片优化到 Core Web Vitals 潜在风险的全维度检查清单，并给出标准化的 100 分制评分卡、优先级分级问题列表和可直接落地的 JSON-LD 建议。读完本文，你将掌握一条"输入 URL → 输出可执行修复清单"的单页审计完整链路，并能理解仓库中 parse_html.py、render_page.py 等底层脚本是如何支撑这些检查项的。

一、seo-page 技能定位：什么场景触发、分析什么

seo-page是 claude-seo 仓库中面向单页深度审计的核心技能。它与负责整站爬取的seo-audit（skills/seo-audit/SKILL.md）不同：当你只需要快速判断一个页面的 SEO 健康状况时，触发它即可。

从技能元数据（front-matter）可以确认其触发方式与适用范围：

• 典型触发语：analyze this page、check page SEO、single URL、check this page、page analysis，或直接给出单个 URL 要求审查；
• 参数提示：[url]，即一次调用输入一个待分析地址；
• 技能版本：2.2.0，属于seo分类。

该技能的分析对象不是整站拓扑，而是聚焦于一个页面的五个核心维度：On-Page SEO、内容质量、技术元素、Schema 标记、图片，外加Core Web Vitals 的"可观测风险"（注意：HTML 本身无法测量真实的 LCP/INP/CLS，只能做潜在问题标记）。

二、On-Page SEO 检查清单：标题、描述、标题层级与链接

单页分析的第一步是核对页面最基础的 on-page 元素。原技能定义给出了严格的判定标准，逐项展开如下。

2.1 Title 标签

对照仓库中的 quality-gates.md，还可补充更细的约束：Title 最短不低于 30 字符、最长不超过 60 字符（Google 大约在 60 字符处截断）；主关键词应尽量靠前，品牌名放结尾；每个页面必须拥有唯一标题。

2.2 Meta Description

• 长度 150–160 字符（quality-gates 补充：最短 120、最长 160，Google 大约在 155–160 处截断）；
• 文案要有吸引力（compelling），包含主关键词；
• 每个页面必须唯一，避免重复模板。

2.3 H1–H6 标题层级

• H1 恰好一个，匹配页面意图、包含主关键词；
• H2–H6 逻辑层级：不允许跳级（例如 H1 直接跳到 H4）；
• 各标题应具有描述性，方便读者和搜索引擎快速理解章节内容。

仓库实现佐证：parse_html.py会提取h1、h2、h3并统计数量（scripts/parse_html.py），还会标记"过短或纯数字"的可疑标题（如计数器/统计数字被误用为标题），这类标题会被额外写入hN_suspicious字段供审计参考。

2.4 URL 规范

• 短、描述性强、使用连字符分隔单词；
• 不含查询参数（避免?id=123这类无意义 URL）；
• 结合 quality-gates 的告诫：URL 中堆砌关键词（keyword-stuffed URLs）是 doorway page 的典型信号，应避免。

2.5 内部链接与外部链接

quality-gates.md 给出了更量化的内部链接目标：长文博客（1500+ 字）5–10 个内链、服务页 3–5 个、产品页 2–4 个、分类页链接到所有子页面；锚文本必须描述性（避免"点击这里"），且要变化、不能总是精确匹配关键词。

三、内容质量：字数门槛、可读性、关键词密度与 E-E-A-T

单页内容审计不只是数单词。seo-page 技能要求从五个角度评判内容健康度。

3.1 字数与页面类型门槛

对照 quality-gates.md 中的最低字数表：

重要提示（技能与 quality-gates 反复强调）：这些是"主题覆盖下限"，不是SEO 排名因子。Google 已确认字数不是直接排名因素——500 字但彻底回答问题的页面，可以胜过 2000 字却答非所问的页面。审计时应作为覆盖深度参考，而非硬性目标。

3.2 可读性

• Flesch Reading Ease：一般受众目标 60–70 分；
• 年级水平与目标受众匹配；
• 平均句长 15–20 词、段落 2–4 句。

同样要注意，seo-content 技能（skills/seo-content/SKILL.md）明确指出：Flesch 分数只是内容可访问性的代理指标，不是Google 直接排名因素（John Mueller 已确认），Yoast 也在 v19.3 中降低了 Flesch 分数权重。审计中作为内容质量信号而非可直接优化的 SEO 指标。

3.3 关键词密度与语义变体

• 主关键词出现在标题、H1、前 100 词内；
• 自然密度 1%–3%，且存在语义变体（同义词、相关词）；
• 严禁关键词堆砌。

3.4 E-E-A-T 信号

• 作者简介、资质证明、一手经验标记（first-hand experience markers）；
• 结合 eeat-framework.md：Experience（20%）、Expertise（25%）、Authoritativeness（25%）、Trustworthiness（30%）四个维度分别评分。Trustworthiness 权重最高，且 December 2025 Core Update 后 E-E-A-T 已扩展到所有竞争性查询，不再局限于 YMYL；
• 经验信号（Experience）是 AI 时代最有区分度的维度：一手叙述（"我测试过……"）、原创照片与截图、可验证的具体案例，因为 AI 可以生成"看起来专业"的内容，却无法伪造真实的亲身经验。

3.5 内容新鲜度

• 可见的发布日期（publication date）；
• 已修订内容要有最后更新日期（last updated date）；
• 对快速变化的主题，超过 12 个月未更新的内容应标记。

实现佐证：render_page.py内置了htmldate库用于从 HTML 中探测发布日期（scripts/render_page.py），单页审计可以直接拿到publication_date字段参与新鲜度判断。

四、技术元素：Canonical、Robots、社交元标签与 Hreflang

4.1 Canonical 标签

• 必须存在；
• 自引用（self-referencing）或指向正确的规范版本 URL；
• 防止重复内容稀释权重。

4.2 Meta Robots

• 默认应为index/follow，除非页面有意被屏蔽（noindex/nofollow 有明确业务理由）。

4.3 Open Graph 与 Twitter Card

parse_html.py会同时解析og:*与twitter:*元标签（scripts/parse_html.py），审计时可以直接比对哪些字段缺失。

4.4 Hreflang（多语言站点）

• 若站点存在多语言版本，检查 hreflang 实现是否正确；
• 完整校验规则参见 seo-hreflang 技能：每个页面必须自引用、关系必须双向（A→B 且 B→A）、必须存在且仅有一个x-default、语言码必须用 ISO 639-1（en而非eng、ja而非jp）、地区码必须用 ISO 3166-1 Alpha-2（en-GB而非en-uk）、hreflang 只能出现在 canonical URL 上、同一组 URL 必须协议一致（统一 HTTPS）。

parse_html.py通过link[rel="alternate"][hreflang]提取 hreflang 列表（scripts/parse_html.py），是单页 hreflang 检查的数据来源。

五、Schema Markup：检测、验证、机会识别与弃用类型红线

5.1 检测与格式偏好

• 扫描页面源码中的 JSON-LD<script type="application/ld+json">；
• 同时检查 Microdata（itemscope/itemprop）与 RDFa（typeof/property）；
• 始终优先推荐 JSON-LD，这是 Google 明确偏好的格式。

实现佐证：parse_html.py解析 JSON-LD 时会自动展平@graph容器，把每个@type拆成独立条目（scripts/parse_html.py），便于逐类型校验。

5.2 验证要点

• 必填属性是否齐全（按类型）；
• 对照 Google 支持的 rich result 类型；
• 常见错误逐项排查：缺少@context、@type无效、数据类型错误、占位文本、相对 URL（应为绝对 URL）、日期格式无效；
• 标记已弃用类型（见下）。

5.3 类型状态与弃用红线（截至 2026 年）

seo-page 技能给出了 2026 年的明确红线，仓库中的 schema-types.md 与 deprecated-types-2024-2026.md 提供完整对照表，要点如下：

活跃类型（可自由推荐）：Organization、LocalBusiness、SoftwareApplication、WebApplication、Product、ProductGroup、Offer、Service、Article、BlogPosting、NewsArticle、Review、AggregateRating、BreadcrumbList、WebSite、WebPage、Person、ProfilePage、ContactPage、VideoObject、ImageObject、Event、JobPosting、Course、DiscussionForumPosting、QAPage 等。

已无富结果但保留有益（FAQPage）：

• Google 已于2026 年 5 月 7 日全面退役 FAQ 富结果（覆盖所有站点，取代 2023 年政府/健康限制）；
• 不要建议删除已有 FAQPage，也不要推荐为了 SERP 新增 FAQPage；
• 已有 FAQPage 标记为Info（非 Critical）优先级，因为它仍是 AI Mode / AI Overviews 做实体解析与引用验证的有用信号；
• 真正的用户提问+社区回答页面，应使用QAPage。

已弃用（绝不推荐）：HowTo（2023-09 移除富结果）、SpecialAnnouncement（2025-07-31 弃用）、CourseInfo/EstimatedSalary/LearningVideo/ClaimReview/VehicleListing（2025-06 退役）、Practice Problem 与 Dataset（2025 年末退役）。

重要边界：技能原文明确要求单页审计中NEVER推荐 HowTo 或 FAQ 用于富结果——这是 2026 年环境下容易踩坑的高频错误，必须遵守。

5.4 生成建议

• 根据页面类型选择合适类型；
• 生成含全部必填+推荐属性的合法 JSON-LD；
• 只包含真实、可验证的数据，占位符明确标注由用户填写；
• 输出前完成校验。

可直接参考 seo-schema 技能 中的 Organization、LocalBusiness、Article 三类现成模板，以及仓库 schema/templates.json 中的可复用 JSON-LD 模板。

六、图片审计：Alt、体积、格式、尺寸与懒加载识别

6.1 检查项概览

关于文件大小，seo-images 技能 给出了更细的三级阈值：缩略图目标 <50KB（>100KB 警告，>200KB 严重）、内容图目标 <100KB（>200KB 警告，>500KB 严重）、Hero 图目标 <200KB（>300KB 警告，>700KB 严重）。单页审计可据此分级标注。

6.2lazy_method：识别 JS 懒加载器，避免误报

这是 seo-page 技能中一个非常容易出错的细节，也是仓库源码重点实现的逻辑：

不要在检测到 JS 懒加载器（Perfmatters、EWWW、lazysizes 等）时把图片标记为"未懒加载"——这些插件会故意移除原生loading="lazy"属性，改用data-src占位符方案。

parse_html.py中的_detect_lazy_method()函数（scripts/parse_html.py）按固定优先级输出五类结果：

审计输出应同时报告lazy_method与loading属性，让用户明白：JS 懒加载站点上原生属性缺失不是回归，而是优化方案本身的设计。

6.3 图片优化补充建议（供修复阶段使用）

结合 seo-images 技能，单页审计发现问题后可直接落地这些修复：

• 用<picture>元素做格式渐进增强：AVIF 优先 → WebP 兜底 → JPEG 兜底；
• Hero/LCP 图严禁懒加载，可加fetchpriority="high"；仅折叠线以下图片使用loading="lazy"；
• 非 LCP 图片加decoding="async"防止解码阻塞主线程；
• 响应式图片使用srcset+sizes；
• 文件名描述性、小写、连字符（blue-running-shoes.webp而非IMG_1234.jpg）。

七、Core Web Vitals：HTML 可观测的风险标记（非实测）

单页审计无法仅凭 HTML 测出真实的 CWV 数据，因此技能将其定位为"参考层面"，只做潜在风险标记：

如果希望拿到真实字段数据（field data），需要走 seo-google 技能 的 CrUX API 路线；仓库还提供pagespeed_check.py、crux_history.py等脚本（scripts）用于更深度的性能取证。单页审计报告应明确区分"HTML 推断的风险"与"实测数据"。

八、输出规范：评分卡、问题分级与 Schema 建议

seo-page 技能定义了标准化的四段式输出，便于 Agent 与人工一致解读。

8.1 页面评分卡（Page Score Card）

Overall Score: XX/100 On-Page SEO: XX/100 ████████░░ Content Quality: XX/100 ██████████ Technical: XX/100 ███████░░░ Schema: XX/100 █████░░░░░ Images: XX/100 ████████░░

六大维度分别打分并叠加总评，进度条直观展示强弱项。全站审计场景下可参考seo-audit的权重体系（Technical 22%、Content 23%、On-Page 20%、Schema 10%、Performance 10%、AI Search 10%、Images 5%）理解各维度相对重要性，但单页审计按上述五个维度呈现。

8.2 发现的问题（Issues Found）

按优先级组织：Critical → High → Medium → Low。优先级语义与全站审计一致：

• Critical：阻断索引或触发惩罚，立即修复；
• High：显著影响排名，一周内修复；
• Medium：优化机会，一个月内修复；
• Low：锦上添花，放入待办。

8.3 建议（Recommendations）

给出具体、可执行的改进措施，并说明预期影响（例如"将 12 张 JPEG 转为 WebP，预计节省 X KB 页面体积"）。

8.4 Schema 建议（Schema Suggestions）

针对检测到的机会，直接输出开箱即用的 JSON-LD 代码，用户复制即可上站。

九、DataForSEO 集成（可选增强）

如果环境中配置了 DataForSEO MCP 工具，单页审计可自动获得外部真实数据：

安装与配置方式见 extensions/dataforseo/docs/DATAFORSEO-SETUP.md，相关技能与成本说明见 seo-dataforseo 技能 及其 cost-tiers.md。

十、错误处理：不可达、鉴权与 JS 渲染页面

技能定义了一张明确的错误场景处理表，审计遇到异常时不得猜测页面内容：

实操应对：对第三类场景，仓库提供了 render_page.py 共享渲染器——支持--mode auto|always|never三种模式：

• auto：先做原始抓取，检测到 SPA 壳（<div id="root">、<div id="__next">、<div id="__nuxt">、<astro-island等签名）时才用 Playwright Chromium 渲染，默认最经济的正确做法；
• always：总是渲染（包括静态 HTML）；
• never：仅原始 HTML，等价于传统抓取。

典型用法：python3 scripts/render_page.py https://example.com --mode auto --json。渲染器还内置 SSRF 防护（URL 预检 + Playwright route 拦截解析到非公网 IP 的子资源），并顺带用trafilatura提取正文、用htmldate探测发布日期，恰好补齐单页审计需要的内容文本与新鲜度字段。

十一、单页审计的完整执行链路

将上述内容串起来，一次标准单页审计的执行链路是：

1. 取数：用render_page.py（SPA 感知）或parse_html.py（静态解析）拿到规范化数据，包含标题、描述、canonical、robots、OG/Twitter、hreflang、标题层级、图片（含lazy_method）、内外链、JSON-LD、正文字数；
2. 逐维打分：按第二至七章的标准，对 On-Page、Content、Technical、Schema、Images 五个维度分别打分并汇总总分；
3. 问题分级：按 Critical/High/Medium/Low 组织发现；
4. 给出建议：输出带预期影响的具体修复项；
5. 生成 Schema：对缺失的机会类型输出可直接使用的 JSON-LD；
6. 可选增强：DataForSEO 工具补充 SERP 排名与外链垃圾分数；
7. 异常兜底：按第十章错误表处理不可达、鉴权、JS 渲染等场景。

结语

单页面深度审计是整站 SEO 优化最基础也最频繁的单元操作。seo-page技能的价值在于把"一个页面该检查什么、合格线是什么、怎么输出"沉淀成一套可执行、可评分、可复现的规范，并随着 2025–2026 年 Google 的规则变化（FAQ 富结果退役、E-E-A-T 全面化、AI 引用信号崛起）持续更新红线。配合仓库中的 parse_html.py（结构化提取 +lazy_method识别）与 render_page.py（SPA 渲染 + 正文/日期提取），你可以把本文的每个检查项直接映射到可运行的取证脚本上，实现从"拿到 URL"到"输出分级修复清单"的完整闭环。如需整站级别的批量审计与并行子代理委派，可在此基础上进一步升级到 seo-audit 技能。