cs-marketing-website

应用网站基础

当创始人已经有成熟或可信的产品，却无法可靠地记住网站每个页面的用途、下一步该构建什么，或哪些营销工作受阻时，请使用此技能。这是负责统筹的营销技能。它能将零散的网站和一系列想法转化为持续维护的页面清单和考虑依赖关系的工作看板。

不要用它来发布内容、进行生产环境变更、投放广告或声称某个页面已上线。这些操作需要使用适当的后续技能并获得批准。

所需输入

收集以下信息，或明确标记缺失项：

• 产品、买家和待完成的工作；
• 主要转化操作及其目标位置；
• 当前生产环境 URL 和源代码仓库（如有）；
• 已批准的证明材料：客户成果、屏幕截图、产品演示、评价或源数据；
• 分析工具和 Search Console 的访问状态；
• 创始人的可用时间、决策负责人和审核频率。

如果无法访问线上网站或代码仓库，请根据提供的信息创建 DRAFT 页面清单，并记录阻碍因素。不要推断技术状态。

第 1 步：检查、清点并整理网站

检查实际网站、路由、导航、站点地图和转化路径。使用 templates/page-inventory.csv 记录每个现有页面和所需页面。

记录每个页面的以下信息：URL、页面归属、父级路由、导航标签、页面类型、受众、待完成的工作、主要 CTA、证明材料、索引状态、负责人、状态、依赖项、成功指标、后续操作和审核日期。

默认使用以下页面归属：

页面用途	归属
产品/类别或用例转化	产品、解决方案或用例页面
常青型操作指南	/resources/guides/[slug]
工具/方案决策	/resources/comparisons/[slug]
实用模板、清单或生成器	/resources/tools/[slug]
已批准的客户案例	/resources/stories/[slug]
公司动态和产品发布	/blog/[slug]
产品帮助	/docs/[slug]

每个页面必须有一个主要目标。如果有多个目标，请拆分页面或明确优先级。

必需的页面架构

添加页面之前，先定义简洁的层级结构。只从产品确实能够支持的类别开始：

/                         # home: category, buyer, promise, primary CTA
/product or /solutions    # product/use-case conversion pages
/pricing                  # packaging and purchase path, if public
/resources                # resource hub; not a dumping ground
  /guides                 # evergreen how-to answers
  /comparisons            # decision pages
  /tools                  # useful templates, checklists, or generators
  /stories                # approved customer evidence
/docs                     # product help, not acquisition content
/blog                     # announcements and time-bound updates

• 导航中仅保留少量与买家相关的顶级目的地。资源子类型应归入各自的中心页，并从相关产品页面链接过去；不要将每篇文章都列为顶级导航项。
• 计划中的页面必须先确定父级页面/归属，再设置 slug。不要创建回答相同需求的重复指南、对比文章、博客文章和文档页面。
• 资源类别在拥有实用的中心页和至少一个完整原创页面之前，应从站点地图中排除并设置为 noindex。对于已停用或重复的页面，必须明确决定重定向或设置 noindex。
• 编写或构建任何新的重要页面之前，请使用 templates/page-brief.md。

完成标准： 页面清单涵盖买家、客户或爬虫关心的所有路由；每个页面都有归属和主要目标；缺失页面已在工作看板中排好顺序，而非临时创建。

第 2 步：确立事实与证明材料

在 templates/website-context.md 中记录产品的真实情况：

• 受众、问题和类别；
• 实际能够兑现的承诺；
• 产品不能做什么；
• 已批准的证明材料和证据缺口；
• 每个页面必须解决的转化操作和异议。

任何未经批准的客户名称、引述、指标或屏幕截图，都应标记为 BLOCKED/AWAITING APPROVAL。绝不要把轶事当作公开证明材料。

完成标准： 每个计划中的页面都能指向一个事实来源，或已明确标记为需要研究。

第 3 步：创建工作看板

将清单分类并整理到 templates/website-workboard.md：

• NOW：一组数量最少且不受阻的行动，用于改善出问题的转化路径、补齐缺失的重要产品页面，或回答高意向问题。
• NEXT：NOW 完成后就会变得有用的工作。
• LATER：值得做，但目前不会限制增长的工作。
• BLOCKED/AWAITING APPROVAL：等待创始人、客户同意、访问权限、文案审批、生产环境部署或证据的工作。

每个事项都必须注明负责人、具体的下一步行动、依赖项和完成证明。不要添加“改善 SEO”之类含糊的任务卡片。

完成标准： 创始人问“我们这周应该做什么？”时，能够得到一个明确的 NOW 事项，以及所需的阻碍事项或审批。

第 4 步：建立持久的营销体系

在客户端仓库或运营工作区中创建或确认以下记录：

1. 页面清单；
2. 营销背景简介；
3. NOW/NEXT/LATER/BLOCKED 工作看板；
4. 计划中的 Resources 页面内容登记表；
5. 客户故事流程，包含同意与审批跟踪；
6. 每周和每月的评审节奏。

严格使用 references/status-language.md。已提交或在本地构建的页面不算 LIVE。

交接

• 技术可抓取性、canonical、站点地图和 Search Console 设置 → cs-marketing-seo。
• 以答案为导向、有来源支撑的 Resources 内容 → cs-marketing-aeo-content。
• 定期简报、发布、评审和创始人更新 → cs-marketing-content。
• 客户访谈和经批准的故事制作 → 交由 cs-marketing-content 处理，直到专门的故事/视频技能得到验证。

常见错误

1. 把博客当作整个网站。 产品、资源、故事和文档页面承担不同的任务。
2. 发布空的资源栏目。 在有实用且完整的内容之前，将它们设为 noindex。
3. 制定计划时没有负责人或评审日期。 这样会让它变成档案，而不是运营体系。
4. 把本地完成误认为已上线。 部署后必须验证公开 URL。
5. 捏造证据。 未经批准的说法会摧毁本系统旨在建立的信任。

验证清单

• 页面清单中的每个重要路由和所需页面都有对应条目。
• 每个条目都注明页面归属、任务、受众、CTA、负责人、状态和下一步行动。
• 每个重要的新页面都有页面简介、父级路由、索引决策，以及在导航/内部链接计划中的位置。
• 产品事实和已批准的证据与研究空白明确区分。
• 工作看板包含 NOW、NEXT、LATER 和 BLOCKED 分区。
• 最高优先级的 NOW 事项已注明其依赖项和审批边界。
• 已记录下次每周跟进和每月评审的日期。