cs-seo-website

CodeSpring 网站 SEO 运营

用于 CodeSpring 营销网站相关工作：robots/sitemaps/canonicals、Search Console 导出、文档/教程、Vibe Code Library、产品列表、推荐链接和自然增长报告。

此技能适用于CodeSpring 网站代码仓库（VolkisAI/codespring-webinar），不适用于 CodeSpring 客户项目。目标是获取高质量的自然流量并促成转化，而不是追求虚荣的域名评级（DR）指标。

运营原则

第三方权威性指标可用于诊断，但它本身不会让网页获得排名。请按以下优先级处理：

1. 确保 Google 能抓取、编入索引并理解网页；
2. 确保网页比现有搜索结果更好地满足真实搜索意图；
3. 建立主题相关的内部链接和清晰的转化路径；
4. 获取真实提及、评价、集成和编辑引用；
5. 衡量非品牌展示次数、高质量访问量和注册量。

绝不承诺 DR/排名结果，也不购买或批量提交主要用于操纵排名的链接。即使提及带有 nofollow，只要能吸引合适的人群，仍然有价值。

分支和发布模型

先阅读网站代码仓库中的 AGENTS.md。它是操作规范，优先级高于此技能。

• main：线上分支，也是唯一允许修改共享 SEO 文件的分支，例如 app/sitemap.ts、app/robots.ts、app/layout.tsx、lib/site-links.ts、templates/ 和 docs/*.md。
• blog：仅限 app/blog/**、content/blog/** 和 public/blog/**。
• library：仅限 Vibe Code Library 所属路径。
• docs：仅限 docs 路由/组件路径。
• marketing：仅限 marketing 所属路径。

切勿重新创建 dev，切勿在网站代码仓库中使用临时的 fix/seo-* 分支，也切勿直接向 main 提交或推送。每个区域分支都从 origin/main 创建，保留一个指向 main 的草稿 PR，并在每次会话开始时先合并 origin/main，再进行任何修改。必要的共享 SEO 修改应通过单独、小范围、仅针对 main 的 PR 提交，供人工审查。

git fetch origin --prune
git switch blog  # or library, docs or marketing
git merge origin/main
git status --short --branch

如果某个新的区域分支尚不存在，请严格按照 AGENTS.md 的说明从 origin/main 创建。运行 npx tsc --noEmit、rm -rf .next out && npm run build 和 node --test tests/*.mjs；如果未修改的基线测试失败，请准确报告失败情况，不要声称完整测试套件已通过。推送后验证远程 SHA，再报告完成。

1. 技术 SEO 基线

在创建内容或争取产品列表收录前，检查 origin/main 上的线上路由及其实现：

• 统一使用一个规范主机，并在 CDN/托管层将其他主机永久重定向；
• /robots.txt 有效，返回 200 text/plain，并包含站点地图声明；
• /sitemap.xml 有效，返回 200 XML，且仅包含规范且有意编入索引的 URL；
• 标题、元描述、规范 URL 和有意义的正文内容均由服务器渲染；
• 对仅用于转化、预览、账户和重复内容的路由明确设置 noindex；
• 爬虫无需 JavaScript 即可跟随内部链接；
• 在适用时使用准确且仅反映可见内容的结构化数据；
• Search Console 网域资源已设置、站点地图已提交，并已通过 URL Inspection 检查。

对于静态 Next.js 导出，app/robots.ts 和 app/sitemap.ts 会生成公开文件。如果静态文件由 S3/CloudFront 提供服务，则仅修改 Next.js 源码无法实现主机重定向；请在交付层记录并应用该重定向。

生产部署后的验收测试：

curl -sSIL https://codespring.app/
curl -sSIL https://www.codespring.app/     # expect 301 to the matching bare-host URL
curl -sSI https://codespring.app/robots.txt
curl -sSI https://codespring.app/sitemap.xml
curl -sS https://codespring.app/robots.txt
curl -sS https://codespring.app/sitemap.xml

2. Search Console → 内容循环

将 Search Console 查询导出数据作为待办事项来源。不要仅根据通用关键词列表选择页面主题。

1. 导入导出数据，并保留查询、页面、点击次数、展示次数、CTR、平均排名、国家/地区和日期范围等列。
2. 按意图对查询进行分类：品牌、比较、教程/问题、产品/类别，以及支持/文档。
3. 优先考虑符合以下任一条件的词：
   • 展示次数可观，但 CTR/排名较弱；或
   • 具有明确的商业/问题意图，且与 CodeSpring 的产品相符；或
   • 已有页面，且有可信的改进机会。
4. 为每份页面简报定义：目标意图、读者要完成的任务、独特证据/示例、标题、H1、大纲、内链、CTA、结构化数据决策和成功指标。
5. 发布页面；仅在页面确实准备就绪时请求编入索引，然后在第 14/28/56 天进行复查。根据展示次数、CTR 和转化情况改进页面，而不是追求发布数量。

月度记分板：

非品牌展示次数 | 非品牌点击次数 | 排名前 20 的查询 | 已编入索引的 URL | 符合条件的自然流量会话 | 自然流量注册数 | 引荐域名 | 引荐注册数。

3. 主动式每日内容台

每个工作日开始时，运行一个创始人可审核的 SEO 工作台。目标产出是五篇各不相同、完整撰写的待审页面，而不是五份简报，更绝不自动发布五个 URL。每个页面都必须有独特的意图、原创价值、需求证据、不与其他页面争夺流量，并具备可信的转化路径。如果只有三四个页面能诚实地通过这些门槛，就提交这些完整页面，并说明为何暂缓其余名额。这样既能保护 CodeSpring 免受规模化内容和门页行为的影响，也能保持快速的制作节奏。

优先使用 Search Console，其次使用缓存的月度 DataForSEO 数据集，最后才对精简后的候选列表查询实时 SERP。将 Instagram、TikTok、YouTube 和销售通话作为了解用户措辞、问题和异议的定性来源，而不是将其视为每个视频都必须对应一个落地页的指令。只要现有规范页面已经满足该意图，就优先改进该页面。

每天早上：

1. 在商业比较、问题导向指南、实用工具/模板、规范页面更新，以及证据/文档/案例内容中，排出五个机会的优先级；
2. 最多完成五篇内容完整、易于阅读的页面；无法通过证据和内容门槛的名额一律暂缓；
3. 推送审核分支，并为每个页面提供一个已验证、可直接打开的 Vercel 路由——绝不使用 localhost；
4. 向 Sebastian 发送简洁的审核材料，列出目标查询、SERP 差距、原创价值、CodeSpring 的定位、CTA，以及一项需要明确决策的事项；
5. 选出一两个适合通过创始人 YouTube 视频显著增强证据或教学价值的页面；
6. 默认采用简单的视频演示：不涉及身份验证、数据库、后端、支付或部署；使用单屏工具、本地数据交互、单个工作流或当前界面对比；
7. 只有在页面和视频角度获批后，才制作缩略图候选方案；
8. 根据反馈进行修改、更新预览，并且只有在获得明确批准后才合并；AWS 生产部署需单独处理。

跟踪每个机会和页面的状态：

机会 → 已撰写简报 → 审核中 → 修改中 → 已批准 → 已合并 → 等待 AWS 部署 → 已上线 / 已验证 → 第 14/28/56 天复查。

如果没有远程审核 URL 或明确的访问障碍说明，早间流程就不算完成。绝不要将 Vercel 预览称为已发布或已上线。绝不要让页面配额凌驾于独特意图、实用性、原创证据或质量之上。

完整的筛选、构建、视频、索引和衡量工作流请参阅 references/daily-seo-content-desk.md。使用 templates/morning-seo-review.md 编写每日内容。

4. 内容系统

教程和文档

围绕产品确实能解决的问题编写教程：规划由 AI 构建的应用、将需求转化为 PRD、安排项目和任务的先后顺序、导入代码库，以及连接编码 Agent。先说明读者能实现什么，再提供真实的操作演示或示例，最后直接引导读者使用 CodeSpring。

不要写泛泛的 AI 内容，也不要堆砌几十个只有关键词略有不同的变体。一篇包含原创示例和内部链接的高质量教程，胜过一堆内容单薄的文章。

为初学者写作，但不要削弱原意

通俗易懂，不代表要把每个想法都拆成尽可能少的词。句子长度和阅读年级评分是检查指标，不是硬性要求。保留足够的上下文，让读者理解发生了什么变化、哪里出了问题，以及为什么这条经验很重要。

• 优先使用日常语言：说功能已经 done，不要说某人可以 call it finished。
• 清楚交代主语、动作和结果。避免使用 The main screen worked. The blank form, failed save or next step did not. 这种过于压缩的句子。应完整重写因果示例。
• 不要为了减少字数，把多个状态拼进一个句子。如果有三项或更多同级检查，应先作说明，再用项目符号列出。
• 按真实顺序叙述：构建了什么、最初哪些部分正常、后来发生了什么变化、哪里出了问题，以及哪项验收检查或测试能发现回归问题。
• 例如，说明 CSV 上传原本正常，后续的数据处理变更导致上传失败，而完成新工作后，原有上传测试仍应通过。
• 用段落解释内容，用项目符号列出并列的检查项、边缘情况、步骤或结果。大段密不透风的文字不适合初学者阅读。
• 把文案大声读出来。如果一个句子虽然语法上很短，但必须猜测缺失的逻辑关系才能理解，就应重写，而不是进一步缩短。
• 创始人第一人称分享的经验必须来自 Sebastian 的反馈、一手视频、通话记录或 CodeSpring 的真实记录。绝不要为了让页面听起来更个人化而编造经历。

编辑型对比与指南页面

将对比页面视为编辑型文章，而不是着陆页功能网格。

1. 先查看当前 SERP 示例。 检查排名靠前的页面，了解其结构、读者关心的问题以及缺失的证据。借鉴其做法，但不要复制文本、图片或缺乏依据的说法。
2. 从读者出发。 开篇说明读者面临的情境、问题和需要做出的决定。不要在回应对比意图之前介绍 CodeSpring。
3. 采用文章结构。 如果作者是 Sebastian，应展示作者署名和照片；还应注明更新日期和阅读时长。长篇文章应提供带链接的章节导航。
4. 为每款对比产品单独设立章节。 说明 Claude Code、Codex、Cursor 或其他产品的优势、适用人群，以及它仍需要哪些上下文。随后为 CodeSpring 单独设置章节，再通过公正的表格或决策路径总结选择。
5. 使用真实视觉素材，而非装饰性替代品。 对于每款第三方产品，使用从该产品官方公开页面或文档中获取的最新截图。在本地保存经过优化的图片，记录来源 URL 和日期，添加有意义的替代文本，并将图片说明链接到官方来源。有真实界面可用时，绝不要使用搜索结果缩略图、AI 重绘界面或通用文本框示意图。
6. 复用真实的 CodeSpring 产品素材。 在制作示意图之前，先检查当前主页和 public/ 素材库。优先使用网站上已获批准的真实思维导图、生成的 PRD、用户旅程／地图或 Kanban 看板截图。用相关产品界面替换占位架构框。
7. 让对比表易于浏览。 每款产品名称旁都应配上尺寸一致的官方／获批徽标。辅助文字应略小于文章正文，每个单元格应以简短的要点呈现，而不是密集段落。徽标用于识别产品，不代表认可。
8. 构建清晰的站内链接地图。 在读者需要了解产品定义时，将 CodeSpring 的提及链接到主页。将思维导图、PRD 和 Kanban 看板等主题词链接到对应的文档页面。链接应无需悬停即可清晰可见：使用对比鲜明且符合无障碍要求的颜色，并添加下划线；随后逐一验证目标页面。最终 CTA 应直截了当。第三方截图的说明和来源应链接到其官方页面。
9. 确保证据真实可靠。 除非记录了相同的任务、环境和评审方法，否则不要声称进行过实际基准测试。应说明页面是决策指南，而非性能基准测试。
10. 核验整篇文章。 确认截图以原始尺寸加载、徽标清晰可辨、章节锚点正常、移动端和桌面端布局易读、元数据／canonical／schema 正确，并且每项主张都有明确依据。

评审时，只要评审者确实能够访问，Vercel PR 预览即可接受。生产环境仍使用手动 AWS 工作流。将预览标记为 REVIEW，而不是 LIVE / VERIFIED；绝不要暗示 Vercel 预览更改了 AWS 生产环境。

Vibe Code Library

使用专用的 feat/codespring-vibe-code-library 分支和策略文档。应用页面只有在包含原创且范围明确的结论、真实可行的核心循环、明确的边界／排除项、功能分组、原创常见问题、来源／审核日期和有意义的相关链接时，才可编入索引。草稿页面不得出现在站点地图中。

该库的转化素材不是通用目录列表，而是用于构建范围明确替代方案的、真实可靠的计划／提示词／地图，并附有明确的 CTA 目标页面。

5. 列表收录与提及

使用任何目录之前，先创建一份产品资料包：

• 产品名称和规范 URL；
• 60 词和 160 字符的描述；
• 定位/类别；
• Logo、截图和获批的演示链接；
• 提交时真实有效的定价/支持/创始人信息；
• 添加 UTM 标记的引荐 URL；
• 负责人、审批状态和来源证据。

资格门槛

仅在至少满足以下一项时，才使用某个收录平台：

• 能触达相关买家/开发者社区；
• 是真实的评价/集成/合作伙伴资料页；
• 能带来编辑推荐流量或引荐流量；
• 是能获得真实社区响应的产品发布。

拒绝主要提供出售“dofollow backlinks”、批量交换链接、改写描述或大量低质量提交的网站。未经批准且未使用公司控制的凭证，绝不创建账号、付费购买展示位、发布声明或征求评价。

在台账中跟踪每个潜在平台：

source | relevance | reason | proposed URL | rel | cost | owner | approval | submitted | live listing | referral sessions | sign-ups | review date。

状态标签必须完全一致：DRAFT、AWAITING APPROVAL、SUBMITTED、LIVE 或 REJECTED。在核实公开收录页面和出站链接之前，不要将提交称为已上线的反向链接。

6. 审核与发布检查清单

• 首先检查线上版本和 origin/main 源码。
• 每个可编入索引的页面都有对应的搜索意图和原创证据。
• 每日审核目标是完成五篇评测页面；每篇页面都须独立通过避免关键词蚕食和原创价值门槛；未完成的名额须说明明确原因。
• 每篇完成的晨间页面都有可直接打开且已验证的 Vercel 评测路由，并附一项明确具体的创始人决策请求。
• 视频简报仅限一到两个高价值页面，范围刻意保持简单，且不得阻碍页面审核。
• 检查规范 URL、标题、描述、服务端渲染链接和站点地图收录情况。
• 新的 Vibe Code 页面通过内容门槛。
• 收录平台通过相关性/质量门槛并获得批准。
• 编辑页面采用文章结构，使用第一方截图、获批的 Logo、有据可查的图片来源和真实的 CodeSpring 产品素材。
• 对比表简洁易浏览；无需悬停即可看到内部链接，且链接指向相关首页或文档路由。
• 针对 UI 更改检查移动端/桌面端和主题。
• npx tsc --noEmit、npm run build 和 node --test tests/*.mjs 均通过；若存在未更改的基线失败，则须准确报告。
• 分支已推送，已核实远程 SHA，且草稿 PR 以 main 为目标分支。
• 分别报告审核预览和 AWS 生产状态。
• 获批并完成 AWS 验证后，提供站点地图/内部链接/Search Console 索引交接；绝不要暗示抓取请求能保证页面被编入索引。