seo-audit-full

Name: seo-audit-full
Author: jeffli1993

github.com/jeffli1993营销与增长773506 次安装19 周前更新

代码仓库

关于 seo-audit-full

seo-audit-full 是面向需要深入单页 SEO 检查的技能，适用于技术审计和全面页面评估。它结合核心检查与 PageSpeed、社交标签等扩展项，并要求使用 API 密钥运行 PageSpeed。

主要功能

01检查网站与页面级 SEO 项
02验证 JSON-LD 结构化数据
03检查 PageSpeed 与 Lighthouse 指标
04验证 Open Graph 和 Twitter Card 标签
05生成并保存 HTML 审计报告

适用场景

01开展技术 SEO 和全面页面审计
02检查页面性能与社交分享元数据
03基于给定关键词评估页面相关性

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/jeffli1993/seo-audit-skill --skill seo-audit-full

安装后在 Claude Code 中输入/seo-audit-full确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/

report-template.html

references/

REFERENCE.md

scripts/

check-page.py

check-pagespeed.py

check-schema.py

check-site.py

check-social.py

fetch-page.py

详细介绍

seo-audit-full — 高级完整 SEO 审计

此技能会从 seo-audit-full 目录对单个页面执行完整的 SEO 审计。仅提供 URL 时，它不会转到 seo-audit。

何时使用此技能

当用户请求以下内容时，使用 seo-audit-full：

“seo-audit-full”
“完整 SEO 审计”
“高级 SEO 审计”
“技术 SEO 审计”
“深度审计”
“全面 SEO 审查”
“审计所有内容”

仅提供 URL 的请求也有效。如果未提供外部数据集，请执行完整的公开信号工作流，并在报告中明确说明缺少的数据源。

预期输入

输入	必需	备注
页面 URL	是	要审计的主要页面
主要关键词	建议提供	有助于提高内容相关性评分
PageSpeed API 密钥	是	完整审计的 PageSpeed 检查必需。请在开始时询问，未提供时不要运行 PageSpeed。
原始 HTML 或页面内容	可选	提供后可进行更准确的内容检查
GSC / 爬取 / 分析数据	可选	如有提供则纳入，否则标记为不可用
竞争对手基准数据	可选	如有提供则纳入

开始完整审计时，请向用户索取 PageSpeed Insights API 密钥：

For PageSpeed checks, please provide a Google PageSpeed Insights API key.
Get one here: https://developers.google.com/speed/docs/insights/v5/get-started
Open "Acquiring and using an API key" → "Get a Key".
If you do not provide one, I will stop before running the full audit because
PageSpeed is a required full-audit module.

如果未通过 --api-key、PAGESPEED_API_KEY 或 GOOGLE_PAGESPEED_API_KEY 提供 PageSpeed API 密钥，请勿运行 seo-audit-full 的 PageSpeed 检查。如果缺少密钥，请停止并要求用户进行配置，而不是在缺少 PageSpeed 数据的情况下生成完整报告。

架构：完整审计 = 核心 + 性能 + 高级

┌─────────────────────────────────────────────────────────────┐
│  seo-audit-full Workflow                                    │
│                                                             │
│  Phase 1: Run core scripts (./scripts/)                     │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  check-site.py      → robots.txt, sitemap, 404, URL  │   │
│  │  check-page.py      → title, H1, meta desc, slug     │   │
│  │  check-schema.py    → JSON-LD validation              │   │
│  │  fetch-page.py      → raw HTML for analysis           │   │
│  └──────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  Phase 2: Run performance + full-only scripts (./scripts/)  │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  check-pagespeed.py → Lighthouse scores + metrics     │   │
│  │  check-social.py    → OG Tags + Twitter Card          │   │
│  │  (more scripts added here as modules grow)            │   │
│  └──────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  Phase 3: LLM-only advanced checks                         │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  E-E-A-T content quality scoring                      │   │
│  │  Duplicate content signals                            │   │
│  │  Anchor text quality assessment                       │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

输出

通过填写 assets/report-template.html 中的模板，生成一份高级完整 SEO 审计报告，然后保存到文件中——切勿将原始 HTML 打印到终端。

文件命名： reports/<hostname>-<slug>-full-audit.html

https://example.com/blog/best-tools → reports/example-com-blog-best-tools-full-audit.html
https://example.com/                → reports/example-com-full-audit.html

保存后，告知用户：

✅ Full Report saved → reports/example-com-full-audit.html
   Open it now? (yes / no)

如果是 → 运行：open reports/example-com-full-audit.html

模板占位符——逐项填写：

占位符	内容
`{{summary_verdict}}`	用一句话说明运行的检查总数，以及失败、警告和通过的数量
`{{summary_critical_html}}`	每个严重问题对应一个 `<li>`，或使用 `<li class="summary-empty">None</li>`
`{{summary_warnings_html}}`	每个警告对应一个 `<li>`，或使用 `<li class="summary-empty">None</li>`
`{{summary_passing_html}}`	每项通过的检查对应一个 `<li>`，或使用 `<li class="summary-empty">None</li>`
`{{pagespeed_checks_html}}`	使用 `check-pagespeed.py` 输出生成完整的 PageSpeed 模块
`{{site_checks_html}}`	网站级检查表
`{{eeat_checks_html}}`	E-E-A-T 信任页面表
`{{page_checks_html}}`	页面级检查表，包括仅完整审计包含的项目
`{{priority_actions_html}}`	按优先级排序的操作列表
`{{insights_html}}`	可选的发现详情卡片

脚本

从此目录运行完整脚本。所有输出均为结构化 JSON——请直接将其用作证据。

依赖项： pip install requests

第 1 阶段：核心脚本

# 1. site-level checks (robots.txt + sitemap.xml + 404 + URL canonicalization)
python scripts/check-site.py https://example.com

# 2. page-level checks (H1, title, meta description, canonical, URL slug)
python scripts/check-page.py https://example.com --keyword "primary keyword"

# 3. fetch raw HTML for downstream scripts
python scripts/fetch-page.py https://example.com --output /tmp/page.html

# 4. JSON-LD schema validation
python scripts/check-schema.py --file /tmp/page.html

第 2 阶段：仅完整审计使用的脚本

# 5. PageSpeed / Lighthouse checks
python scripts/check-pagespeed.py https://example.com --strategy mobile --timeout 180 --api-key "USER_PROVIDED_KEY"
# If no key was provided, do not run this command. Ask the user to configure a PageSpeed API key first.

# 6. Social tags: OG + Twitter Card validation
python scripts/check-social.py --file /tmp/page.html
# Or directly from URL:
python scripts/check-social.py https://example.com

每个脚本的退出码为 0（全部通过或警告）或 1（存在任何失败或错误）。

PageSpeed 可能需要 200 秒。默认使用 180 秒超时。如果仍然超时，请将 Page Speed 模块标记为 error，并说明 PageSpeed API 已超时；不要将此视为已确认的页面性能失败。如果在提供密钥后，PageSpeed 因 Google 返回配额或 API 密钥错误而失败，请继续运行审计，并将 PageSpeed 模块标记为 error，同时附上以下说明： Get a PageSpeed API key at https://developers.google.com/speed/docs/insights/v5/get-started → "Acquiring and using an API key" → "Get a Key".

范围 — 完整审计检查白名单

完整审计会运行自己的核心检查，以及下方标记为 ★ 的仅完整审计项目。

站点级检查（在 `{{site_checks_html}}` 中）

核心检查：

Sitemap URL 清单 · Staging 子域名索引 · robots.txt · sitemap.xml · 404 处理 · URL 规范化 · i18n / hreflang

Staging 子域名索引规则：

检查 robots.txt 之前，先检查常见的 staging/test 主机：test.、staging.、dev.、preview.、beta.、uat.
如果某个 staging/test 子域名可公开访问、与生产站点高度相似，且未通过身份验证、noindex 或屏蔽性 robots.txt 进行保护，则判定为失败。
如果某个 staging/test 子域名可公开访问，但无法确认其相似程度或索引保护情况，则判定为警告。
如果未检测到公开的 staging/test 子域名，或检测到的 staging 主机受到身份验证、非 200 状态访问、noindex 或 Disallow: / 保护，则判定为通过。
说明其影响是产生可索引的重复页面：Google 可能会将 test.example.com 和 www.example.com 视为不同但几乎相同的 URL，导致排名信号分散，并与生产站点竞争。
建议的修复方法：首先添加 Basic Auth/密码保护；同时在 staging 主机上通过 User-agent: * + Disallow: / 阻止爬虫；如果页面仍可访问，则添加页面级 noindex。

Sitemap URL 清单规则：

将此模块放在 {{site_checks_html}} 中的第一个位置，置于 Crawlability 表格之前。
将其呈现为独立表格，列为：目录 · URL 数量 · 页面类型 · 示例页面。
使用 check-site.py 的 sitemap_inventory 输出，总结一级目录、URL 数量、推断的页面类型以及一个代表性示例 URL。
将其视为站点级地图，而不是针对单个页面的通过/失败 SEO 审核。
除非无法解析 sitemap URL，否则使用 info 状态；没有更深入的证据时，不要因某个目录中的 URL 过多或过少而扣分。
始终包含后续步骤说明：用户可以从 /blog/、/tools/、/alternatives/、/templates/ 或 /use-cases/ 等主要目录中选择有代表性的示例 URL，继续进行更深入的完整审核。

页面速度检查（在 `{{pagespeed_checks_html}}` 中）

仅限完整检查：

Lighthouse 类别评分：Performance · Accessibility · Best Practices · SEO
实验室指标：FCP · LCP · TBT · CLS · Speed Index
最终 URL 和截图可用性

E-E-A-T 检查（位于 `{{eeat_checks_html}}` 中）

核心检查：

关于我们 · 联系方式 · 隐私政策 · 服务条款 · 媒体／合作伙伴（仅在存在时检查）

联系方式判断逻辑（仅限“联系方式”行）：

不要求必须有专门的 /contact 页面
若可通过以下任一方式联系，即通过：专门的联系页面（HTTP 200）· 关于我们页面提供联系方式 · 页脚／导航中的 mailto、电子邮箱、社交链接或联系表单
仅当整个网站上都没有任何联系途径时才判定为不通过
如果关于我们页面或页脚／导航中已提供联系方式，仅缺少 /contact 页面不算不通过

E-E-A-T 基础设施规则——每个信任页面分为两层：

第 1 层——存在： 信任页面 URL 返回 HTTP 200（联系方式按上述专属规则判断）
第 2 层——可访问： 页面通过页脚或主导航链接

页面	必需
关于我们	是
联系方式	是——专门的联系页面为可选；关于我们页面或页脚／导航中的联系方式满足要求
隐私政策	是
服务条款	是
媒体／合作伙伴	否——仅在存在时纳入

状态规则（关于我们、隐私政策、服务条款、媒体／合作伙伴）：

页面缺失（非 200）→ 不通过
页面存在，但未从页脚／导航链接 → 警告
页面存在，且从页脚／导航链接 → 通过
可选页面缺失 → 跳过，不纳入行

联系方式专属规则：

尝试常见路径（/contact、/contact-us）——HTTP 200 视为存在
如果没有联系页面，则检查关于我们页面正文中是否提供电子邮箱、社交媒体或联系方式
还要扫描首页页脚和导航中的 mailto:、可见电子邮箱、社交链接或联系表单
只要找到任一联系途径，存在性检查即通过
仅当任何地方都找不到联系方式时，存在性检查才不通过
如果页脚／导航中有联系页面链接或联系方式，可访问性检查即通过
如果只能通过关于我们页面内容联系，而页脚／导航中没有直接入口，可访问性检查为警告
如果关于我们页面或页脚已提供联系方式，不要建议创建 /contact

页面级检查（位于 `{{page_checks_html}}` 中），按以下确切顺序输出：

核心检查： URL Slug · 标题标签 · Meta 描述 · H1 标签 · Canonical 标签 · 图片替代文本 · 字数 · 关键词布局 · 标题结构 · 内部链接 · Schema（JSON-LD）

Schema（JSON-LD）规则：

将 Schema 视为质量检查，而不只是检查是否存在。
验证 JSON-LD 是否可解析、@type 是否符合预期、必需字段、推荐的富媒体搜索结果字段、嵌套字段以及主类型冲突。
JSON-LD 无效、缺少预期的 Schema 类型、缺少必需字段，或本地化 Schema 明确指向错误语言／URL 时，判定为不通过。
缺少推荐字段、嵌套字段不完整、多语言页面缺少 inLanguage，或无法完全确认本地化 Schema 时，判定为警告。
仅当存在预期的 Schema 类型、包含必需字段、未发现冲突，且适用时本地化 Schema 与当前页面的语言／URL 匹配，才判定为通过。
对于多语言页面，每种语言版本都应有自己的 Schema，其中 inLanguage 与对应语言匹配；如有语言专属标题／描述，也应与对应语言匹配；url／mainEntityOfPage 应指向当前本地化的规范 URL。

★ 仅完整版本增加：

OG 标签——检查 og:title、og:description、og:image、og:type、og:url 是否存在且有效
Twitter Card——检查 twitter:card 类型、标题／描述／图片（并检测是否回退使用 OG 标签）

如何使用脚本 JSON 输出

所有完整审计模块均遵循相同规则——将每个字段的 status 直接映射到报告检查表：

status → pass / warn / fail / error → 报告中的徽章
detail → Evidence 行的起点
除非有其他可观察到的证据，否则不要与脚本输出相矛盾

对于 check-site.py 输出：

staging_subdomains.status → Staging Subdomain Indexation 行状态
staging_subdomains.detail → Staging Subdomain Indexation 行详情
staging_subdomains.public_hosts → 公共预发布/测试主机的证据
staging_subdomains.similar_hosts → 与生产环境相似的预发布重复项的失败证据
robots.status → robots.txt 行状态
sitemap.status → sitemap.xml 行状态
sitemap_inventory.status → Sitemap URL Inventory 模块状态
sitemap_inventory.directories[] → 包含 path、url_count、page_type 和 example_url 的表格行
sitemap_inventory.detail → 清单表格下方的简短说明

对于 check-schema.py 输出：

status → Schema (JSON-LD) 行状态
detail → Schema (JSON-LD) 行详情
parse_errors → JSON-LD 格式错误的失败证据
schemas[].fields_missing → 缺少必需 Schema 字段的失败证据
schemas[].recommended_missing 和 schemas[].nested_issues → 警告证据
localized_schema.status → 多语言 Schema 的语言/URL 对齐状态
localized_schema.issues → Schema 语言或 URL 不匹配的证据

对于 check-social.py 输出：

og.status → OG Tags 行状态
twitter_card.status → Twitter Card 行状态
og.fields.* → 详情单元格中的各字段详情
twitter_card.fields.* → 各字段详情，并注明回退字段

对于 check-pagespeed.py 输出：

status → 整体 Page Speed 状态
category_status → Lighthouse Scores 徽章状态
metric_status → Core Lab Metrics 徽章状态
final_url → Final URL 行
categories.performance.score → Performance 评分
categories.accessibility.score → Accessibility 评分
categories["best-practices"].score → Best Practices 评分
categories.seo.score → SEO 评分
compact_metrics.fcp.display_value → FCP
compact_metrics.lcp.display_value → LCP
compact_metrics.tbt.display_value → TBT
compact_metrics.cls.display_value → CLS
compact_metrics.si.display_value → Speed Index
screenshot 为真值 → 截图可用

不要将整体 status 用于 Lighthouse Scores 徽章。类别评分使用 Lighthouse 阈值：90–100 为 pass，50–89 为 warn，0–49 为 fail。示例：Performance 为 60、Accessibility 为 84、Best Practices 为 100、SEO 为 100 时，category_status 为 warn。如果 LCP 或 Speed Index 未通过，metric_status 和整体 status 可能为 fail，而 Lighthouse Scores 面板仍为 warn。

在 {{pagespeed_checks_html}} 中，在评分/指标卡片后添加简短的 Priority Actions 列表。根据未通过或警告的 PageSpeed 字段列出 2–4 项简洁措施：

LCP 较慢 → 优化主视觉媒体、预加载关键图片、减少阻塞渲染的 CSS
Speed Index 较慢 → 延迟非关键脚本，并减少首屏区域的 JS/CSS
TBT 较高 → 拆分长任务并延迟第三方标签
Performance 评分为警告/失败 → 优先处理影响最大的 Lighthouse 改进项

始终包含官方诊断链接： https://pagespeed.web.dev/

LLM 审查说明

核心 LLM 审查

撰写报告前，解决所有 llm_review_required: true 字段：H1 语义判断、Title 关键词位置、URL Slug 评估和 Meta Description 质量都必须给出明确判断。

仅完整审查时进行的 LLM 检查

OG Tags 质量（始终审查）：

og:title   : Does it differ meaningfully from <title>? It should be optimized for social sharing.
og:description : Is it compelling for social feeds? Different focus than meta description is OK.
og:image   : Is the URL an actual image path (not a page URL)?

Twitter Card 完整性：

If twitter:card is "summary_large_image", twitter:image (or og:image fallback) must be
at least 300x157px. Flag if the image URL looks like a small icon or favicon.

报告详情编写规则

严格遵循以下格式：

通过 → 一个简短短语。不使用列表，不展开说明。

警告 → 一个 <div class="detail-issue">，最多含 2 个项目符号。一个 <div class="detail-fix">。

失败 → 与警告相同。以确切的失败内容开头。

强制要求的发现格式

**Finding: [Finding Title]**

- **Evidence:** [Observable fact, data point, or marked assumption]
- **Impact:** [SEO / UX consequence]
- **Fix:** [Actionable recommendation with example]

对于优先行动项，添加工作量/影响标签：

1. [High Impact / Low Effort] Fix og:image — social shares currently show no preview.

参考文件

详细审计模块和字段定义：references/REFERENCE.md
最终 HTML 报告模板：assets/report-template.html
PageSpeed 验证脚本：scripts/check-pagespeed.py
社交标签验证脚本：scripts/check-social.py
核心脚本：scripts/（check-site、check-page、check-schema、fetch-page）

支持 Markdown

登录后评论

基本信息

作者: jeffli1993
仓库: jeffli1993/seo-audit-skill
分类: 营销与增长
安装次数: 506
GitHub Stars: 773

报告问题