marketing

name	marketing
description	对营销站按一份 SEO/GEO/SEM 任务清单做全面扫描与自动整改——线上与源码双向核对，能在代码层解决的直接改好，改不了的输出带操作指引的人工待办。用法：/marketing <站点标识|all> [只扫描] [部署]。凡是用户要求给某个营销站做 SEO/GEO/SEM 检查、收录体检、营销扫描、新功能上线后的营销跟进、「看看 xx 站还缺什么营销动作」时，都用本技能，即使用户没有说出 /marketing 这个词。站点信息取自 ~/.config/zmh-marketing/sites.local.md（首次使用需按本技能 references/sites.md 模板填写）。

/marketing — 营销站 SEO/GEO/SEM 扫描与整改

把一份 SEO/GEO/SEM 任务清单变成可执行的例行动作：对指定站点逐条核对清单，自动完成代码层能做的整改，把剩余动作整理成带操作指引的人工待办。

输入解析

参数第一个词是站点标识（取值见站点档案里定义的站点），或 all（各站顺序跑，报告合并）。无法识别站点时列出档案里的可选项让用户确认，不要猜。

修饰词（可同时出现）：

• 只扫描 / --scan：只产出报告，不改任何文件。
• 部署：整改后把改动部署到生产（默认不部署，见「整改边界」）。

事实来源（每次现读，不要凭记忆）

1. 站点档案 —— 各站仓库路径、线上 URL、关键文件位置、内容来源、部署方式、收录渠道现状。按下面的顺序找，取第一个存在的：

   1. ~/.config/zmh-marketing/sites.local.md（推荐位置：在插件目录之外，插件升级不会丢）
   2. 本技能目录 references/sites.local.md（从仓库直接跑时用）

   两处都没有时不要猜测站点信息，让用户照 references/sites.md 模板填一份放到位置 ①。发现档案与仓库实际不符时，以仓库为准并顺手修正档案。

2. 清单：站点档案里指明的 SEO/GEO/SEM 任务清单文件 —— 逐条核对的依据。用户会持续修订这份清单，所以每次运行都要重新读，以文件现状为准。清单缺失时，按下面「核心检查面」自行组织检查项，并在报告里说明依据是什么。

3. 收录渠道现状：以站点档案「收录渠道」节为准（哪些引擎可用、哪些被挂起）。

工作流程

第 1 步：扫描（只读，线上 + 源码双向核对）

对清单里每个可检查项，同时看线上实态和仓库源码——线上是结果，源码是原因，两边都要有证据。核心检查面：

• 页面元素：TDK（title 主词前置）、canonical、OG 卡片、H1 需求词、hreflang 互指、JSON-LD（SoftwareApplication/Product/FAQPage）。线上用 curl -sL 抓 HTML 验证（SSR 框架的 metadata 在 HTML 里，直接可查）。
• 可摘取块（GEO）：开头定义句、FAQ、数据/对比表格是否存在且可被引用。
• 收录基建：sitemap.xml 可达且 lastmod 新鲜、robots.txt 正确、llms.txt 存在且覆盖新页面、changelog 有带时间戳条目。
• 站内链接：首页/产品页/定价页到功能页的内链数量。
• 埋点：转化事件与 UTM 规范是否符合档案里记录的衡量 ID 与事件参数约定。
• 收录状态：判断「提交过没有」之前必须先读档案里指明的提交台账（记录了哪轮提交覆盖了哪些 URL）——实测出现过没读台账就误报「未提交」的教训，误判会让用户重复劳动或漏做。台账之外再用 site:<域名>/<路径> 探测实际收录（curl 结果不可靠时注明以站长平台为准）。

站点页面多时可以并行开子代理分头扫（线上一路、源码一路），但每条结论必须带证据（URL+HTTP 状态、文件路径:行号），因为报告的可信度取决于此。

清单是底线不是天花板：逐项核对之余，保留一段自由探索，用工程师的怀疑精神找清单没写的问题。实测证明有产出的探针（不限于此）：

• 换爬虫 UA（Googlebot/GPTBot/Baiduspider/Bingbot）对照 meta 是否都渲染在 head 里（Next 15 流式 metadata 对名单外爬虫会掉进 body）
• www/裸域、尾斜杠、http→https 是否归一；不存在的路径是否正确 404
• 社交/IM 分享卡片（og:image、twitter:card 有无图）
• 转化事件能否归因到具体 CTA/页面（label/source 参数是否断链）；结构化数据里的价格等硬编码值与后台数据会不会漂移
• sitemap lastmod 是否真实（new Date() 式全量刷新会让引擎不信任该字段）
• 只能在平台后台确认的事项（GA4 关键事件标记、关联 GSC、Rich Results Test）→ 归人工待办

清单外的发现单独放进报告的「🔍 清单之外的发现」节，别硬塞进清单判定里。

第 2 步：判定

把每条清单项归入四类：已达标（附证据）／可自动整改／需人工／不适用（说明为什么，比如 SEM 投放项对没有预算计划的站不适用）。判定要忠实于清单原文的意图，不要为了好看把「部分达标」记成达标。

第 3 步：整改（除非「只扫描」）

只做本地代码层的改动，一项一项来，改完自查（本地构建或 lint 能过）：

✅ 可以直接做：metadata/TDK/canonical/OG 补齐、JSON-LD 结构化数据、hreflang、sitemap.ts 补页面与 lastmod、llms.txt 创建或更新、FAQ/定义句等可摘取块的页面骨架、站内内链、robots 修正、埋点事件补齐。

⛔ 不要自动做（列入待办，附操作指引）：

• 生产部署——默认不部署。改动是本地的，报告里给出该站的部署命令（见站点档案）；用户带了 部署 修饰词才执行。
• 广告投放/预算类（SEM 全部）——只产出建议的关键词、广告组结构、落地页 URL。
• 第三方平台发布（知乎/公众号/Product Hunt 等）——只产出建议选题。
• CMS 里的正文文案——若档案写明该站文案来自 CMS/内容 API，仓库里的默认值只是接口不可达时的回退，改它不会改变线上文案。这类整改要么给出后台编辑路径，要么在用户明确要求时调对应的内容接口。
• 搜索引擎提交——IndexNow 可以直接 curl 推送（key 位置见档案）；站长平台（Google GSC / Bing Webmaster）要走浏览器，按用户约定的浏览器操作方式执行，不可用就写进待办；档案里标注为「挂起」的引擎不要尝试提交，只在待办里保留。

第 4 步：报告

固定用这个结构（用户靠它决定接下来做什么，别自由发挥）：

# {站点} SEO/GEO/SEM 扫描报告（YYYY-MM-DD）

## 总览
清单 N 项：已达标 a ｜ 本次整改 b ｜ 需人工 c ｜ 不适用 d

## ✅ 本次自动完成
（每条：做了什么 + 改动文件 + 如何验证）

## ⏳ 已就绪，等你确认
（本地改完未部署的改动 → 附部署命令；可一键执行的提交 → 附命令）

## 🙋 需要你人工处理
（按 SEO / GEO / SEM 分组；每条写清在哪操作、预计多久，参考清单原文的阶段标注）

## 🔍 清单之外的发现
（自由探索发现的问题/机会，注明严重度；没有就删掉本节）

## 📋 已达标项
（简列 + 证据，供复核）

整改量大（≥3 个文件或跨仓库）时，按该工作区的归档约定留一份工作记录。

注意事项

• 多站往往是不同的内容形态：有的页面数据来自自家后端，有的文案来自内容 API，只有页面骨架和 SEO 元素在各自仓库里。判断「这条整改改哪里」之前先想清楚内容归属，改错层白费功夫。
• 线上页面若配了 revalidate + stale-while-revalidate，改内容后要请求两次、按档案记录的时间才可见——验证整改效果时别把缓存误判成没生效。
• 改 sitemap/robots/llms.txt 这类收录敏感文件时保持克制：宁可少列不列错，错误的 URL 会浪费抓取配额。