site-launch-checklist

Name: site-launch-checklist
Author: samber

github.com/samber测试与质量2414.8k 次安装4 周前更新

代码仓库

关于 site-launch-checklist

用于审查和准备网站上线的交互式工作流，涵盖上线准备与站点设置检查，适合发布新网站的团队。内容侧重 Cloudflare DNS、Vercel 托管、PostHog 和法律事项，并通过逐项确认避免擅自假设。

主要功能

01交互式上线决策检查点
02SLC 上线准备门槛
03十阶段审查与验证流程
04按站点类型选择配套 Skill
05品牌语气与润色指导

适用场景

01评估网站是否达到上线条件
02规划新站点或域名迁移
03分阶段检查上线事项并安排修复
04选择适合项目的配套 Skill 子集

安装

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

$npx skills add https://github.com/samber/cc-skills --skill site-launch-checklist

安装后在 Claude Code 中输入/site-launch-checklist确认已加载。

包含的文件

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

assets/

weekly-seo-antigravity.md

weekly-seo-claude-code.md

weekly-seo-copilot-cli.md

weekly-seo-gemini-cli.md

weekly-seo-opencode.md

weekly-seo-vibe-prompt.md

weekly-seo-vibe.toml

evals/

evals.json

references/

decisions.md

directory-list.md

positioning-variations.md

submission-tracker-template.csv

templates.md

weekly-seo-agent.md

详细介绍

问题： 通过环境的提问工具向用户提问，绝不能以纯文本提问。每次只问一个问题，提供 2–4 个可点击选项，然后等待回答。如果环境没有提问工具，就用文本提供相同选项，每次只问一个问题。

网站上线检查清单

用于发布新网站的上线前审核与设置工作流。针对 Cloudflare DNS + Vercel 托管 + PostHog + 法律相关内容进行了定制。

交互方式（请先阅读）

此技能有意设计为交互式。要积极提问，不要擅自假设。用户会点击，而不是输入。

每次运行开始时都要询问以下问题（一次一个，按此顺序）：

网站类型：doc-site | marketing/lead-gen | SaaS-app | training/paid-course | personal-portfolio
迁移方式：greenfield-new-domain | migration-need-301-redirects | replacing-existing-on-same-domain
多语言：single-locale | en | fr+en | other-multi
PostHog 设置：hogpost.samber.dev | set-up-new-proxy | skip-PostHog
AI 爬虫策略：use-default-for-site-type | customize-per-bot | block-all
是否有可用的浏览器工具：claude-chrome-extension | playwright | neither-skip-browser-checks

在各阶段的每个决策点都要再次提问，包括：

是否安装 Sentry / BetterStack / Crisp（取决于网站类型，请明确询问）
首选 www 还是裸域名（大多数网站选择裸域名；仍要询问）
如果用户选择了 customize-per-bot，要询问允许哪些 AI 机器人
CSP 严格程度：strict-default-src-none | balanced-allow-self | permissive-for-marketing
是否完全跳过某个阶段（例如，非 FR 网站跳过第 3 阶段）

未经用户明确输入，绝不越过任何决策点。目标不是生成冗长但没有检查点的清单。

未经用户明确确认，绝不安装任何 MCP 服务或技能。 在运行 npx skills add、claude mcp add 或任何等效安装命令之前，务必通过提问工具征求用户同意——即使技能选择工作流推荐了精选子集，也不例外。

如何使用此技能

运行本次会话开始时的上述问题。
按顺序引导用户完成阶段 1–10。每个阶段：a. 列出事项，并询问是否有需要跳过的事项。b. 对每个剩余事项运行验证命令（见下方“验证工具”）。c. 报告通过/未通过。若未通过，询问用户要立即修复还是稍后处理。
最后按阶段分组报告状态，并明确区分阻碍项、建议修复项和可选改进项。

配套技能

有六个技能包适用于网站上线。绝不要安装完整的多技能包。实际安装哪些子集，要在调用时根据用户确认的网站类型决定。

技能包清单

技能包	涵盖内容	通常适用于
`AgriciDaniel/claude-seo`	SEO + GEO + schema + hreflang + 站点地图审核、并行子 Agent	所有网站类型
`addyosmani/web-quality-skills`	Lighthouse、Core Web Vitals、无障碍、性能、最佳实践	所有网站类型
`trailofbits/skills`	安全审计（OWASP、响应头、依赖项）	所有网站类型
`aaron-he-zhu/seo-geo-claude-skills`	20 项 SEO+GEO 技能、CORE-EEAT + CITE 框架、`/seo:` 斜杠命令	内容密集型网站、竞争激烈的细分领域
`coreyhaines31/marketingskills`	约 30 项营销技能（CRO、文案、广告、弹窗、邮件、付费墙等）	`marketing/lead-gen`、`SaaS-app`、`training/paid-course`
`jonathimer/devmarketing-skills`	33 项开发者营销技能（用户画像、文档营销、技术教程等）	`doc-site`、面向开发者的 `SaaS-app`

技能选择工作流（在会话开始时运行）

用户确认网站类型后，对于与该网站类型相关的每个技能包：

列出可用的子技能：npx skills add owner/repo --list
提出精选子集，根据网站类型和此技能将执行的阶段进行选择。将每个阶段的需求与列表返回的特定子技能对应起来。
与用户确认。 如果建议列表超过 3 项，使用多选；否则使用单选（install-as-proposed | let-me-modify | skip-this-pack）。
批量安装达成一致的子集：npx skills add owner/repo --skill A B C

规则：

子技能名称属于技能包，而不在此 SKILL.md 中。始终使用 --list 查询当前状态。技能包内容会变动。
绝不在不带 --skill 的情况下运行 npx skills add owner/repo（这会安装全部内容）。
网站类型 → 技能包映射（需要枚举哪些技能包；子技能仍按工作流选择）：
- doc-site：claude-seo、web-quality-skills、trailofbits、seo-geo-claude-skills、devmarketing-skills
- marketing/lead-gen：claude-seo、web-quality-skills、trailofbits、seo-geo-claude-skills、marketingskills
- SaaS-app：全部六个
- training/paid-course：claude-seo、web-quality-skills、trailofbits、marketingskills
- personal-portfolio：claude-seo、web-quality-skills、trailofbits、seo-geo-claude-skills（轻量子集）
如果用户之后请求的阶段需要尚未安装的子技能，则针对该单个子技能重新运行此工作流，而不是重新安装整个子集。

这样可以避免导入用户不需要的 80 多项技能，避免子技能名称过时，也避免过度适配单个技能包版本。

在某个阶段进行委派时，不要重复此技能负责协调的工作。应为专家指定范围明确的任务（例如：“仅对 URL X 执行安全标头子审计”）。

阶段 0：发布准备度门槛

在执行任何其他阶段之前，先运行此项。 产品不会自我推广，但尚未准备就绪的产品也无法推广。只有当你要发布的产品值得发布时，发布机制才能发挥作用。

两种失败模式会从相反的方向扼杀发布：

隐身模式 — 发布得太晚。“穿着华丽西装的拖延症。”你一直私下打磨产品，等着它变得完美。它永远无法发布，也没人知道你的存在。
“再加一个功能” — 永远不发布。每个拟定的发布日期都会因为再加一项功能而推迟。范围不断膨胀，发布永远不会到来。

折中之道是 SLC — Simple, Lovable, Complete（Jason Cohen），它能避免发布一个精简却不讨喜的基础 MVP。不要发布没人想要的空壳，也不要等着打造一个臃肿的万能应用。一个可发布的 v1 应该：

简单 — 只做好一件事，而不是很多事都做得很差。明确一项任务，并把它做好。
讨喜 — 人们愿意使用它，而不只是勉强忍受。MVP 会让用户忍受精简版体验，“以便提供反馈”。SLC 则提供用户会主动选择的产品。如果没人会因失去它而感到难过，那它还不够讨喜。
完整 — 针对那一项任务，它是一种完整的体验，而不是一个有明显缺陷的空壳。它在选定的范围内是完整的，而不是更大承诺的预告。

门槛： 如果它还不够简单、讨喜且完整，那么只有在缺少的是新增范围时，你才属于“再加一个功能”的情况；否则你就是处于隐身模式，应该发布。缩小范围，直到有一项功能变得讨喜且完整，然后发布它。SLC 能让你现在就真正发布，而不是永远等待一次完美发布。

运行各阶段之前快速检查：

它是否只做好一件定义明确的事？（简单）
目标用户会 主动选择 使用它，而不只是忍受它吗？（讨喜）
这项功能是否提供完整体验，没有明显的空壳？（完整）
你是否已经打磨过了这个标准？→ 停下。你处于隐身模式。发布吧。
你是否还在往范围里添加新内容？→ 停下。你处于“再加一个功能”的状态。缩减范围，回到 SLC。

目录提交准备度（来自 directory-submissions skill）： 回答这 9 个问题。如果有任何一项回答“否”，就说明还没准备好——先帮助他们补齐缺失部分。

产品是否可公开访问（没有密码墙）？
是否有定价页面（即使写着“测试版期间免费”）？
隐私政策和服务条款是否已上线？
是否有 PNG、SVG、正方形图标和 favicon 格式的 Logo 资源？
是否有 5–8 张真实截图和 60–90 秒的演示视频？
落地页是否已为 GEO 做好准备（单个 H1、层级顺序合理、FAQ schema、结构化数据）？
是否至少有 3 个替代方案页面和 3 个用例页面已上线并被收录？
是否有模板库或获客资源（如果适用于该类别）？
是否至少有 20 位 Beta 版／早期用户可以在 G2 上留下评价？

第 1–7 项中任何一项回答“否”都是硬性阻碍。第 8–9 项回答“否”属于软性阻碍：你仍可发布，但会损失 Tier 2 评价价值和 Typeform 式的复利效应。

ORB 渠道策略（来自 launch skill）： 将发布营销规划为三类渠道。最终所有渠道都应导向自有渠道。

自有渠道

渠道归你所有（但受众不归你所有）。无需依赖算法或平台规则，即可直接触达。

邮件列表、博客、播客、自有品牌社群（Slack、Discord）、网站／产品
根据受众从 1–2 种渠道开始： 行业缺少优质内容 → 博客；人们希望直接获取更新 → 邮件；互动很重要 → 社群

租用渠道

提供曝光度但不受你控制的平台。算法会调整，规则会改变，付费推广的比重会增加。

社交媒体（Twitter/X、LinkedIn、Instagram）、应用商店、YouTube、Reddit
正确用法： 选择 1–2 个受众活跃的平台；用它们为自有渠道引流；不要把它们当作唯一策略

借力他人渠道

借助他人的受众，跳过最难的一步——让人注意到你。

嘉宾内容（博客文章、播客访谈、新闻简报专题）
合作（网络研讨会、联合营销、社交媒体账号接管）
演讲活动（会议、圆桌讨论、线上峰会）
网红合作
**主动出击：**列出受众关注的行业领袖 → 提出双赢的合作方案 → 使用 SparkToro 或 Listen Notes 等工具寻找受众重合点

通过关卡后，执行以下阶段。

文案语气与人性化润色

每个网站都有面向用户的营销文案（主视觉区、功能介绍、CTA、元描述、OG 描述、博客文章、404 页面文案）。上线前必须完成两层润色：

1. 为每个网站定义一次 `TONE.md`

询问用户：“这个网站已经有 TONE.md 吗？”（yes-already-exists | no-create-from-template | skip-use-default）。

如果要创建：将其写入 .agents/TONE.md 或仓库根目录的 TONE.md。结构请参阅 references/templates.md（“TONE.md template”部分）。

TONE.md 规定：语气（简洁、反主流等）、禁用模式（例如“delve”、“crucial”、破折号、听起来像 AI 的开场白）、句子长度偏好、受众的阅读水平，以及用户本人写作中好句子和坏句子的示例。

2. 使用匹配的语言进行人性化润色

每次起草后（无论使用文案写作技能、手动撰写，还是由 Claude 直接撰写），都要使用人性化润色工具去除 AI 写作模式。

如果尚不清楚网站的主要受众使用哪种语言，请在会话开始时询问用户：

english-global → npx skills add https://github.com/blader/humanizer --skill humanizer
french → 使用 samber/cc-skills@humaniseur-fr（法语专用人性化润色工具）或同等的法语调优技能
other → 如果有可用的匹配语言人性化润色工具，则安装；否则，该技能会直接写出一份简短的语言专用反模式清单

对以下内容应用人性化润色：主视觉区文案、功能描述、CTA 按钮、元描述、OG/Twitter 卡片描述、博客文章、邮件订阅确认信息、404 页面文案。法律页面（mentions légales、CGV）措辞要求严格，无需处理。

3. 调用文案写作技能时始终引用 TONE.md

委派给任何文案写作或内容写作子技能时（在调用时根据技能选择工作流选定），请在提示上下文中包含 TONE.md。明确传达语气限制：“遵循 .agents/TONE.md。避免其中列出的模式。起草后进行人性化润色。”

浏览器交互偏好

许多检查都需要真实浏览器（运行 Lighthouse、安全头检查 securityheaders.com、验证 opengraph.xyz、Twitter 卡片验证器、移动视口、屏幕阅读器冒烟测试、检查 Network 标签页）。

**始终优先使用 Claude Chrome 扩展。**只有在 Chrome 扩展不可用时，才改用 Playwright。如果两者都不可用，询问用户是完全跳过浏览器检查，还是等到启用其中一种后再进行。

验证工具

大多数检查都可以通过命令行完成，无需第三方服务。每个阶段都要直接使用这些工具。不要只相信 Cloudflare/Vercel/Google 控制面板中的信息，要用 curl 验证。

DNS（阶段 1）：

dig +short A example.com                          # A record
dig +short AAAA example.com                       # AAAA (IPv6)
dig +short MX example.com                         # MX (mail)
dig +short TXT example.com                        # SPF + verification TXT
dig +short TXT _dmarc.example.com                 # DMARC
dig +short TXT default._domainkey.example.com     # DKIM (selector varies)
dig +short CAA example.com                        # CAA
dig +dnssec example.com | grep RRSIG              # DNSSEC active

TLS / HTTPS（阶段 1）：

curl -sIL https://example.com | head             # follow redirects
curl -sI https://www.example.com                 # check www handling
openssl s_client -showcerts -connect example.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates

标头（阶段 4）：

curl -sI https://example.com | grep -iE 'content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'
# Full header dump:
curl -sI https://example.com
# External graders:
curl -s "https://api.securityheaders.com/?q=https://example.com&followRedirects=on&hide=on" -I | grep -i 'x-grade'

SEO 文件（阶段 5）：

curl -s https://example.com/robots.txt
curl -sI https://example.com/sitemap.xml
curl -s https://example.com/sitemap.xml | head -40
curl -s https://example.com/llms.txt
# Schema (JSON-LD):
curl -s https://example.com/ | grep -A 50 'application/ld+json'
# hreflang:
curl -s https://example.com/ | grep -i hreflang

Open Graph 与社交媒体（阶段 6）：

curl -s https://example.com/page | grep -iE 'og:|twitter:|<title|name="description"'

网站图标与清单文件（阶段 7）：

curl -sI https://example.com/favicon.ico
curl -sI https://example.com/favicon.svg
curl -sI https://example.com/apple-touch-icon.png
curl -s https://example.com/manifest.json | jq .

404 / 500 / 重定向：

curl -sI https://example.com/this-does-not-exist
curl -sIL https://example.com/old-url     # verify 301 chain

始终运行相关命令，汇报时将输出粘贴给用户，然后询问是立即修复还是排入待办。

阶段 1：域名与基础设施

如果域名已托管在 Cloudflare 上，大部分设置都可以通过 Cloudflare 控制面板一键完成。

先询问：“该域名是否已在 Cloudflare 上，并采用之前上线时的标准配置？”（yes-standard | yes-needs-review | no-fresh-setup）

检查清单：

备份

如果上线时不配置备份，以后就永远不会配置。现在就做好。

询问用户：“此应用会写入哪些数据存储？”（database-only | database-plus-file-storage | file-storage-only | stateless-no-persistent-data）。如果是 stateless-no-persistent-data，则跳过本节。

数据库：

在提供商层面启用每日自动备份（Neon、Supabase、PlanetScale、Railway、RDS 均提供一键开关）。打开备份面板，确认最近一次备份的时间戳足够新，以此进行验证。
保留策略设为 ≥30 天
如果支持，启用时间点恢复（PITR）（Neon、Supabase、RDS 均支持）
异地副本：如果提供商将备份存储在与主数据相同的区域，请配置跨区域复制，或每晚导出到单独的存储账户（S3、R2、GCS）
上线前进行恢复演练：选择一份近期备份，恢复到预发布数据库，验证行数并执行一个示例查询。未经测试的备份不算备份。

文件存储（如适用——S3、R2、GCS、Cloudflare Images）：

在主存储桶上启用版本控制
配置跨区域复制，或定期同步到次级存储桶。Backblaze B2 是一种廉价、可靠的异地副本选项（费用显著低于 S3/GCS 出站流量）。使用 rclone 按每日 cron 任务将 S3/R2/GCS 同步到 B2。
生命周期规则：30 天后将旧版本转移到更便宜的存储，90 天后删除（根据成本承受能力调整）

密钥 / 环境变量：

记录所有环境变量，并将其存储在密钥管理器中（1Password、Doppler、Vault 或同类工具）。不要存放在某人笔记本电脑上的 .env 文件中。
验证：如果今晚每位工程师的电脑都被烧毁，新团队成员能否仅使用密钥管理器 + git 从头恢复生产环境？

监控：

如果每日备份任务失败，设置告警（电子邮件或 Slack）。大多数提供商原生支持此功能；关闭备份面板前完成配置。

阶段 2：分析与可观测性

大多数第三方集成都可通过 Cloudflare 或 Vercel 一键完成。

对于有条件启用的工具（Crisp、Sentry、BetterStack），请按站点类型询问用户确认。 可参阅 references/decisions.md 中的可观测性分级矩阵。

始终启用：

Google Analytics 4：已创建媒体资源、嵌入衡量 ID，并在 CNIL 同意机制后启用
PostHog：根据用户之前的回答：
- 如果选择 hogpost.samber.dev：将客户端配置为 api_host: "https://hogpost.samber.dev"，并确认 CORS 允许新域名（通过浏览器控制台测试，或运行 curl -H "Origin: https://newsite.com" -I https://hogpost.samber.dev/decide）
- 如果选择 set-up-new-proxy：在 next.config.js 中添加指向 us.i.posthog.com 和 us-assets.i.posthog.com 的路径重写，并将客户端初始化为 api_host: "/ingest"
- 如果选择 skip-PostHog：跳过
Google Search Console：已验证站点（DNS TXT 或 HTML 文件），已提交站点地图
Bing Webmaster Tools：已验证站点，已提交站点地图，根目录下的 /{key}.txt 中已有 IndexNow 密钥文件（通过 curl -sI https://example.com/{key}.txt 验证）
Ahrefs：已将站点添加到信息面板进行跟踪
将站点添加到内部统计电子表格（PostHog 媒体资源登记表，以及适用时的 GitHub Sponsors 跟踪表）

品牌监测（Google Alerts）：

为每条提醒使用以下设置：频率：每天一次 | 来源：自动 | 数量：所有结果 | 地区：任何地区

通过 alerts.google.com 为每个关键词设置一条提醒：

域名（例如，example.com）
品牌或产品名称（多词名称需加引号，例如，"My Brand"）
如果站点介绍的是某个项目，则添加关键功能或库名称
竞争对手品牌名称（可选——询问用户：yes-monitor-competitors | skip）

询问用户：“还要监测哪些关键词？”（product-name-only | domain-plus-brand | full-set-with-competitors | custom-list）

开发者社区监测（F5bot）——适用于面向开发者的 doc-site 和 SaaS-app：

F5bot（f5bot.com）会监测 Reddit、Hacker News 和 Lobste.rs 上的关键词提及，并发送电子邮件提醒。免费，无需 API。

在 f5bot.com/add 中每行设置一个关键词：

品牌或产品名称
域名（可捕捉链接分享）
关键功能或库名称
常见拼写错误（如适用）

竞争对手分析（仅适用于 marketing/lead-gen、SaaS-app、training/paid-course）：

在撰写文案、投放广告或规划内容之前，先进行竞争对手分析，了解市场中哪些做法已经奏效——包括定位、信息传达角度、CTA 模式、定价呈现方式和内容策略。

如果工具链中有可用的深度研究工具或竞争对手分析技能，请使用它。询问：

“你已经有要分析的竞争对手名称/URL 了吗？”（yes-provide-list | no-discover-for-me | skip）
如果选择 yes-provide-list：请用户粘贴 2-5 个名称或 URL（自由文本）
“我们想要提取哪些信息？”（positioning-and-messaging | pricing-strategy | content-and-seo | full-spectrum）

将分析结果用于：

阶段 5 的关键词策略（定位他们排名靠前，但你可以超越或侧翼竞争的查询词）
TONE.md 的语气校准（有意与该品类的主流语气形成差异）
阶段 6 的 OG 文案和 CTA 用语（借鉴已验证有效的表达框架，不要原样照搬）
后续调用的文案撰写子技能（将竞争对手概览作为上下文传入）

有条件启用（按 references/decisions.md 中各站点类型的默认设置询问用户）：

Crisp
Sentry
BetterStack

阶段 3：法律与合规（FR）

先询问：“此网站是否受法国法律管辖？”（yes-FR-operator-or-audience | no-EU-only | no-non-EU）。如果不受法国法律管辖，则询问是否适用 GDPR 或同等法规，并据此调整。

对于 FR 网站：

Mentions légales 页面（强制要求，每遗漏一项最高罚款 75k€）
如有商业活动，需提供 CGV（Conditions Générales de Vente）
隐私政策
服务条款
符合 CNIL 要求的 Cookie 同意机制，须在获得明确同意前阻止 GA4、PostHog、Crisp、Sentry 脚本加载（而不只是显示横幅，却始终加载跟踪器）。使用 CMP（Axeptio、Tarteaucitron 或自定义方案）。在浏览器 Network 标签页中验证：明确同意前不会触发任何跟踪器。

阶段 4：安全

将深度审计委托给 trailofbits/skills。以下项目是必须通过的检查清单。

先询问 CSP 严格程度级别（strict-default-src-none | balanced-allow-self | permissive-for-marketing）。各级别对应的 CSP 模板见 references/templates.md。

阶段 5：SEO 与 GEO

将完整审计委托给 AgriciDaniel/claude-seo。以下项目是编排清单。

robots.txt、llms.txt 和 manifest.json 的模板见 references/templates.md。按网站类型划分的 AI 爬虫策略矩阵见 references/decisions.md。

目标页面策略（来自 directory-submissions 技能）： 如果反向链接指向的是通用主页，目录就毫无用处。向目录提交前，先构建这些目标页面：

1. 竞品替代方案页面（投资回报率最高）

竞品替代方案页面的转化率可达 5–15%，对于漏斗底部的查询，转化率通常可达 15–30%。为每个主要竞品创建一个页面：

/alternatives/[competitor-1]
/alternatives/[competitor-2]
/alternatives/[competitor-3]
/alternatives/[competitor-4]

每个页面都需要：诚实的功能对比表、“何时选择 X 而不是我们”、“何时选择我们而不是 X”、价格对比、3–5 个用例示例，以及内容完善并带有 schema 的常见问题。**关键：**务必诚实。AI 引擎会交叉核对竞品功能声明，并降低虚假页面的排名。

2. 用例 / ICP 页面

为每种 ICP 创建专属落地页：

/for/[audience] — 教练、代理机构、电商、SaaS、顾问等。
/use-cases/[use-case] — 线索筛选、入门引导、产品推荐等。

3. 模板 / 资源库（如适用）

Typeform 的模板库带来了 30,000 个非品牌自然注册用户和每年 300 万美元的 LTV。其模式如下：

为每个模板创建一个可编入索引的页面，路径为 /templates/[slug]。
H1 中包含关键词，提供 150 个或更多词的描述、屏幕截图、“何时使用”和“使用此模板”CTA。
在每个页面底部列出相关模板（内部链接可产生 SEO 复利效应）。
第 30 天发布 100 个模板，第 90 天发布 300 个模板，这是现实的目标。

4. 自行撰写的“最佳”榜单文章

撰写关于自身类别的诚实汇总文章：/blog/best-[category]-tools-2026。列出自己的产品和 10 个竞品，并提供真实评价。这类文章既能在类别查询中获得排名，也能成为 AI 引擎引用的权威参考资料。

5. 集成页面（推出集成功能时）

每项集成都对应一个 /integrations/[partner] 落地页。遵循 Zapier 的做法：Zapier 通过程序化生成的集成页面，每月获得 约 260 万次自然访问（约占其自然流量总量的 15%）。

**GEO（生成式引擎优化）：**到 2026 年，30–50% 的“研究某个工具”类查询会在 ChatGPT、Claude、Perplexity 或 Google AI Overviews 中进行，而不会访问传统搜索页面。

让页面获得引用的策略

**每个页面只用一个 H1，并按顺序设置标题层级。**引用率高出 2.8 倍。87% 的获引用页面只使用一个 H1。
**内容信息密集、基于事实，并包含可引用的数据。**与模糊说法相比，AI 引擎更偏好具体数字（“比 X 快 3 倍”）。
**在每个落地页上添加 FAQ schema。**AI 引擎会高度看重用于提取答案的 FAQPage JSON-LD。
**使用对比表。**这类内容易于提取、结构清晰，正是 AI 回答所需的内容。
在前 100 个词中明确说明“这是什么”。
**争取在 Reddit 和 Hacker News 上获得引用。**Claude 和 Perplexity 会大量索引这些平台。在 r/SaaS 和 HN 上获得真实提及，可作为训练素材。
发布原创研究。“我们分析了 10,000 个[事物]，发现 X”会成为其他人撰写相关主题时的主要引用来源。
**认领 Crunchbase、LinkedIn 公司主页和 Wikidata 条目。**这三者都会为 AI 训练语料提供数据。
如适用，在 MCP 注册目录中以 A/B 等级上架（尤其是 Glama）。LLM 回答 MCP 相关问题时会从这些目录获取信息。

衡量

每月手动检查：向 ChatGPT、Claude 和 Perplexity 提问“最好的[类别]工具有哪些？”，并记录产品出现的位置。免费的 GEO 跟踪工具（GeoTracker、llmrefs）可以自动完成这项工作。

阶段 6：Open Graph 和社交媒体预览

使用以下命令验证所有 OG 和 Twitter 标签：curl -s URL | grep -iE 'og:|twitter:'

og:title、og:description、og:url、og:type、og:site_name
og:image 为 1200×630px，使用绝对 URL，声明 og:image:width 和 og:image:height，并设置 og:image:alt
每个页面都设置 og:image，而不是全站共用一张。对于文档站点：根据页面标题动态生成。对于博客文章：为每篇文章设置自定义图片。
如果支持多语言，为每种语言设置 og:locale 和 og:locale:alternate
Twitter Cards：twitter:card=summary_large_image、twitter:title、twitter:description、twitter:image、twitter:site（账号）
通过 Claude Chrome 扩展使用 opengraph.xyz 验证（涵盖 Facebook、LinkedIn、Slack、Discord、WhatsApp 的预览）
使用 Twitter 的卡片验证器进行验证
手动检查：将 URL 粘贴到 LinkedIn 私信、Slack 频道、Discord 和 iMessage 中。所有平台都必须正确显示预览。

阶段 7：网站图标和 Web 清单

manifest.json 模板请参见 references/templates.md。

使用 realfavicongenerator.net 或 favicon.io 从单张 1024×1024 源 PNG 生成。

现代网站的最低配置：

/favicon.ico（多分辨率 16/32/48）。使用 curl -sI https://example.com/favicon.ico 验证。
/favicon.svg，其中包含用于深色模式的嵌入式 <style>@media (prefers-color-scheme: dark) { ... }</style>。使用 curl -sI https://example.com/favicon.svg 验证。
/favicon-96x96.png（PNG 备用图标）
/apple-touch-icon.png，尺寸为 180×180px，不透明，带不透明背景。使用 curl -sI 验证。
/web-app-manifest-192x192.png（Android PWA 图标）
/web-app-manifest-512x512.png（Android 启动画面）
/manifest.json，引用这两个 PNG，并包含 theme_color、background_color、name、short_name、display。使用 curl -s https://example.com/manifest.json | jq . 验证。

跳过（已弃用）：

mstile-*.png（Windows 磁贴）
safari-pinned-tab.svg（自 macOS Big Sur 起已弃用）
favicon-16x16.png / favicon-32x32.png（已由 .ico 和 .svg 覆盖）

HTML head 验证：

curl -s https://example.com/ | grep -iE 'rel="icon"|rel="apple-touch-icon"|rel="manifest"'

阶段 8：质量门槛

委托给 addyosmani/web-quality-skills。该技能涵盖性能、无障碍、SEO 和最佳实践方面的 150 多项 Lighthouse 审计。

使用 Unlighthouse 爬取全站：npx unlighthouse --site {site} — 爬取所有页面并逐页运行 Lighthouse。在逐 URL 检查前，找出任一维度得分低于 90 的页面。
移动模式下 Lighthouse 的全部 4 个维度：每项目标 ≥90（性能、无障碍、最佳实践、SEO）
桌面模式下 Lighthouse 的全部 4 个维度：每项目标 ≥95
Core Web Vitals 实际用户数据（通过 PageSpeed Insights 获取 CrUX）：LCP < 2.5s、INP < 200ms、CLS < 0.1，移动端和桌面端均须达标
无障碍（通过 web-quality-skills 检查 WCAG 2.2 AA）：所有交互元素均可通过键盘操作，焦点环清晰可见，文本颜色对比度 ≥4.5:1，所有图片均有 alt，标题层级递进（H1 → H2 → H3），仅含图标的按钮带有 ARIA 标签
在真实移动设备上测试（不只是开发者工具模拟器）。在真实设备的移动视口中使用 Claude Chrome 扩展，或使用 BrowserStack。
跨浏览器冒烟测试：最新版稳定版 Chrome、Safari、Firefox
检查打印样式是否正常（Cmd+P 不应破坏布局）

阶段 9：生态系统交叉链接

在自有属性之间建立内部交叉链接。对于拥有多个域名的所有者来说，这是高杠杆的 SEO 行动。

询问用户：“请列出生态系统中与这个新网站主题相关的其他域名。”然后针对每个域名：

在现有网站（页脚／导航栏／“其他项目”板块）添加指向新网站的链接，前提是主题相关
如果对应的 GitHub 仓库文档介绍了一个库，则在该仓库的 README 中添加指向新网站的链接
验证互惠链接：在适当情况下，确保每个新增链接都能指回相应网站
如果新网站介绍的是 Go 库，则从相关库的文档添加链接

不要过度添加链接。只在主题相关时交叉链接。介绍日志库的文档网站不应该链接到介绍个人骑行经历的博客。

阶段 10：设置每周 SEO 维护子 Agent

网站上线后，设置一个定期运行的后台 Agent，例如 Hermes 或 Claude Cowork Routine，每周监控 SEO 健康状况并提出待办事项。

完整的 Agent 定义见 references/weekly-seo-agent.md，其中为每种运行环境都提供了具体的等效配置——将与运行环境匹配的代码块复制到指定位置，放在网站的仓库中（或专用的运维仓库中）。该 Agent 使用以下 MCP 连接器（或调用其等效 API）：

Ahrefs MCP（反向链接、排名、关键词）
PostHog MCP（分析关联、AI 机器人流量）
网络搜索（SERP 监控、竞争对手检查）
Google Search Console（通过社区 MCP，或使用服务账号凭据的 curl）

创建文件之前，通过提问工具询问：“现在设置每周 SEO Agent 吗？”（yes-create-agent-file | yes-but-defer | skip-for-now）。

如果无法使用 MCP，请使用 Claude for Chrome 扩展。

阶段 11：执行目录提交

执行 directory-submissions 技能中的目录提交工作流。这是分发的基础层——绝不是完整策略。

步骤 1：选择层级（参见 references/directory-list.md）

层级	时机	示例	典型数量
第 1 层 — 旗舰发布	仅限发布周	Product Hunt（主打）、BetaList、HN Show HN、Fazier、DevHunt	~15
第 2 层 — 初创公司／SaaS	第 1 周 + 持续进行	AlternativeTo、SaaSHub、G2、Capterra、F6S、SourceForge、Slashdot	~50
第 3 层 — AI 目录	第 1–3 周	TAAFT、Futurepedia、Toolify、Future Tools、aitools.inc、AIStage	~40
第 4 层 — Agent／MCP 注册库	第 1–3 周（如果使用 MCP）	Glama、APITracker、LF MCP Registry、AI Agents List	~10
第 5 层 — 无代码目录	第 1–3 周（如果采用无代码方案）	NoCodeFinder、No Code MBA、We Are No Code、MakerPad	~8
第 6 层 — “最佳榜单”文章	持续拓展	联系 DR 40+ 的博客文章作者	~10 次收录
第 7 层 — 集成市场	发布集成时	Zapier、HubSpot、Slack、Airtable、Notion	~5
第 8 层 — 个人资料和内容平台	持续进行	GitHub、WordPress.com、Substack、Dev.to、SlideShare、Behance	~50
第 9 层 — 本地商家目录	持续进行（如适用）	Manta、Hotfrog、Locanto、MerchantCircle	~20
第 10 层 — 论坛和社区	持续进行（先参与）	SitePoint、GrowthHackers、Warrior Forum、Designer News	~13
第 11 层 — 新闻稿和文章网站	发布时及重要里程碑	PRLog、PR.com、EzineArticles、Feedspot	~25
第 12 层 — 社交书签	持续进行	Scoop.it、Diigo、Pearltrees	~5
第 13 层 — 垂直领域细分目录	适合相关领域时	Justia（法律）、Porch（家居）、LandBook（设计）等	~20

筛选规则： 只在产品确实适合的目录中提交。硬把产品塞进不合适的类别会浪费首次提交的优势，还会被版主拒绝。

第 2 步：为每个层级准备素材变体

针对每个层级，准备一个独特的描述变体（参见 references/positioning-variations.md）：

标语：少于 10 个词
简短描述：60 个字符
详细描述：150 个词
5–8 个分类标签
Logo 素材
截图 + 演示视频 URL
创始人故事（2–3 句话）

**重要：**不要把同一段详细描述复制粘贴到每个目录中。针对不同层级调整开头句、功能重点和受众定位。AI 引擎会交叉比对重复内容，并降低其权重。

第 3 步：使用跟踪表格批量提交

设置跟踪表格（references/submission-tracker-template.csv）。从左到右依次处理。每批用时 2–3 小时比较现实。

每次提交：

复制适合该层级的定位变体。
填写表单。
上传素材。
提交。
记录：日期、URL、状态、审核者备注。
上线后，确认反向链接存在且为 dofollow：curl -sIL https://directory.com/your-listing | grep -i rel=。如果没有该字段，则链接为 dofollow。

阶段 12：深入了解 Product Hunt（关键活动）

Product Hunt 是杠杆效应最高的单次提交，但也最容易白费功夫。2026 年的 PH 算法更看重评论质量而非点赞数——一篇获得 50 个赞和 30 条真实评论的帖子，排名会高于一篇获得 200 个赞和 5 条评论的帖子。80% 的失败发布都是因为在没有积累受众的情况下发布，或是请求点赞而非征求反馈。

为期 3 周的准备时间表

**第 -21 至 -14 天：**活跃猎手账号。每天给 3 个发布点赞并认真评论。关注 100 多位活跃创作者。积累账号历史，让算法认为你的账号真实可信。
**第 -14 天：**在 PH 上创建“即将发布”页面。为其引流，收集“发布时通知我”的订阅者。
第 -10 天：（可选）邀请一位猎手。不要付现金，可以交换功能、宣传或引荐。知名猎手能为首日势头增加约 15%，但并非必需。
**第 -7 天：**起草发布当天的素材：图库图片（1270×760）、标语、260 字符的描述、你自己的第一条评论，以及一位客户的第一条评论。
**第 -3 天：**为邮件列表预热。“我们周二发布。这是你可以期待的内容。如果想提前知道，请回复。”
**第 -1 天：**最终检查——产品在无痕模式下运行正常、视频自动播放、CTA 指向注册页面，PH 发布页面预览正常。

发布当天的执行

**在太平洋时间凌晨 12:01 发布。**仅限周二、周三或周四——周末发布获得的流量会少 60–70%。太平洋时间凌晨 12:01 开始发布，可最大限度地利用 24 小时窗口。
**前 2 小时至关重要。**前 2 小时需要 50 多位支持者，才能触发算法分发。
亲自发布第一条评论，讲述故事：为什么要开发它、它有何不同、应该先尝试什么。
**在 30 分钟内回复每一条评论。**PH 会衡量创作者的响应速度。
**分享链接至：**Twitter/X 主题帖、LinkedIn 长文、个人 Slack/Discord 社区、邮件列表、Indie Hackers，以及通过私信联系每一位重度用户。
绝不要请求点赞。请求反馈。“很希望听听你对这个定位的真实看法”比“请支持我们！”的转化率高 3 倍，也不会触发算法的反操纵过滤机制。
**不要给陌生人发消息。**社区会举报这种行为，版主也会隐藏你的帖子。

发布后

撰写一篇发布复盘博客，包含数据和经验教训。坦诚分享，不要炫耀。第 2 天发布。
将复盘文章同步发布到 Indie Hackers 和 r/SaaS（允许推广的地方）。
只有在你有技术角度可以分享（架构、DSL、新颖方法）时，才向 Show HN 投稿。泛泛地发一篇“我们发布了一款 SaaS”的帖子会被疯狂举报。

阶段 13：评论攻略（G2 / Capterra / TrustRadius）

没有评论的 G2 和 Capterra（截至 2026 年 2 月现归 G2 所有）页面毫无价值。达到 10 条评论，才有资格出现在 Grid 中。请在发布月份执行“30 天内获得 10 条评论”方案。

10 天内获取 30 条评价策略

上线第 1 天： 找出 20 位已使用产品完成有意义操作的用户。
给每位用户发送个性化邮件，附上直接评价链接（可将操作阻力降低约 70%）。不使用表单或落地页——直接提供链接。
提供适度的感谢礼。 G2 和 TrustRadius 明确允许提供小额奖励，例如价值 25 美元的 Amazon 礼品卡。
5 天后跟进一次。 不要跟进两次——这会让人厌烦，并损害关系。
目标： 转化率达到 50% → 向 20 人征求评价，获得 10 条评价。

关键截止日期

G2 夏季报告： 截止日期约为 4 月 28 日。规划评价征集活动，确保在此之前完成。
G2 秋季报告： 截止日期约为 7 月 28 日。
错过截止日期意味着要等 3 个月才能更新下一期榜单。

徽章和付费计划

“Users Love Us”徽章仍然免费：需获得 20 条评价，且平均评分达到 4.0 以上。
Grid、Momentum、Index 和 Award 徽章需要付费的 G2 计划（从 2025 年夏季起，每年 2,999 美元以上）。
第一年不要为 G2 付费。 免费产品页面加上 Users Love Us 徽章就足够了。

跨平台

TrustRadius 的机制类似，但规模较小。
在某些类别中，Capterra 会从 Gartner Digital Markets 自动同步信息——即使不采取直接行动，也可能会显示内容。

阶段 14：上线后的持续发展

发布公告并不意味着上线工作已经结束。接下来要着手提升采用率和留存率。不要依赖单次上线活动。定期更新和推出功能有助于维持用户参与度。

上线后立即采取的行动

引导新用户： 设置自动化引导邮件序列，介绍关键功能和使用场景。
强化上线宣传： 在每周／每两周／每月的邮件汇总中加入公告，让错过公告的人也能看到。
与竞争对手形成差异： 发布对比页面，突出说明为什么你显然是更好的选择。
更新网页： 在你的网站中添加专门介绍新功能／产品的版块。
提供上手体验： 创建免代码交互式演示（使用 Navattic 等工具），让访客可以在注册前进行探索。

如何确定公告的优先级

使用此矩阵，确定每次更新值得投入多少营销资源：

重大更新（新功能、产品全面改版）：

通过多个渠道开展完整营销活动
博客文章、邮件营销活动、应用内消息、社交媒体
最大限度地扩大曝光

中等更新（新集成、UI 改进）：

有针对性地发布公告
向相关细分用户发送邮件、发布应用内横幅
不需要大张旗鼓地宣传

小幅更新（错误修复、小改动）：

更新日志和版本说明
表明产品在不断改进
不要让这类更新占据营销重点

公告策略

错开发布： 不要一次性发布所有内容，而应分批发布公告，以保持发展势头。
复用效果好的策略： 如果之前的公告反响不错，就把这些经验应用到今后的更新中。
持续互动： 继续通过邮件、社交媒体和应用内消息宣传改进内容。
展现积极开发： 即使是小幅更新更新日志，也能提醒客户产品在不断发展。这有助于提升留存率和口碑——客户会更有信心，认为你会持续运营下去。

KPI 和跟踪仪表板

每周跟踪。如果某项指标没有变化，就进行调查——不要只是提交到更多目录。

指标	第 0 天	第 30 天目标	第 90 天目标
域名评级（DR）	0	20	30+
引荐域名	0	30	80+
已编入索引的页面	—	50	200+
每日自然点击量	0	30	200+
已上线的目录列表	0	50	70+
G2 评价	0	10	25
Capterra 评价	0	5	15
AI 引用（人工检查）	0	3	15+
来自目录引荐的注册量	0	50	300
来自替代方案／用例页面的注册量	0	20	300

不要做的事

不要为目录提交服务付费（$60–$200 的套餐）。这些目录本来就是免费的。花一个下午复制粘贴就行。
不要提交到垃圾目录（DR 低于 10、没有流量、缺乏编辑质量）。它们会稀释你的反向链接档案，Google 的垃圾信息检测也可能因此惩罚你。
不要用错误的定位提交。 按层级重新阅读定位表。通用描述会浪费目录列表。
不要把目录当作整个 GTM。 目录只是基础。真正促成转化的是内容、社区和评价。
不要跳过 G2/Capterra 上的评价。 零评价的列表毫无生气。执行「30 天 10 条」计划，否则就不要提交。
不要在 Product Hunt 上索要赞成票。 2026 年的算法会对此进行惩罚。请索要反馈。
不要每周修改旧目录列表。 提交一次，每季度检查一次。
在目标页面尚不存在时不要提交。 链接权重需要有目标页面承接。
不要在不同目录中重复使用描述。 AI 引擎会惩罚重复内容。
不要在对比页面上说谎。 AI 引擎会交叉核对，并降低谎言的排名。
不要过度关注发布当天的流量峰值。 飞轮靠的是模板、替代方案、评价和持续的内容，而不是 PH 的一天。
不要忘记 Crunchbase、LinkedIn 公司页面和 Wikidata。 它们会为 AI 训练语料提供数据，对 GEO 很重要。
SLC 门槛通过前不要发布。 隐身模式和「再加一个功能」都会扼杀发布。
不要跳过营销文案的人性化润色。 主视觉、CTA、元描述和 OG 描述中的 AI 痕迹会严重损害可信度。
不要以为分析工具会「自动正常工作」。 发布前用 curl 验证每项集成——GA4、PostHog、GSC、Bing、Ahrefs。
不要忽略备份演练。 未经测试的备份不算备份。发布前先恢复到预发布环境。

输出格式

完整运行结束时，按阶段分组输出状态报告：

Phase 1: Domain & Infrastructure  [9/10 pass]
  ✓ Cloudflare proxy on
  ✓ DNS records configured
  ...
  ✗ DMARC missing. Fix: add TXT record at _dmarc.example.com with policy v=DMARC1; p=quarantine;...

Phase 2: Analytics & Observability  [6/7 pass]
  ...

然后按顺序列出以下三项：

阻碍项（发布前必须修复）
建议修复项（宣布前应修复）
可选改进项（发布后处理）

最后询问：「你想接下来处理哪一项列表？」（blockers | recommended | optional | done-for-now）。

参考资料

references/decisions.md：按网站类型划分的 AI 抓取策略矩阵、可观测性层级矩阵
references/templates.md：按严格程度划分的 robots.txt、llms.txt、manifest.json、CSP 模板，以及安全标头参考
references/weekly-seo-agent.md：每周 SEO 维护子 Agent 的完整定义（MCP、任务、输出格式）
assets/weekly-seo-*.md、assets/weekly-seo-vibe.toml：由 references/weekly-seo-agent.md 链接的各类运行环境 Agent 定义文件——复制与你的运行环境匹配的文件
references/directory-list.md：包含提交时间、示例和数量的 13 层目录目录
references/positioning-variations.md：按目录层级划分的定位变体库（标语、简短/详细描述、类别标签）
references/submission-tracker-template.csv：用于记录目录提交情况的提交跟踪表格模板

支持 Markdown

登录后评论

基本信息

作者: samber
仓库: samber/cc-skills
分类: 测试与质量
安装次数: 4,766
GitHub Stars: 241

报告问题