Name: App 落地页 SEO — 商店资料 → 关键词页出货
Author: Community

App 落地页 SEO

端到端工作流，将应用商店列表转化为高转化率、SEO 优化的落地页，并附带长尾指南页面。默认技术栈：Vite + React，采用构建时预渲染（架构见阶段 3）。如果仓库已有 Web 框架（Next.js、Astro），则在该框架内构建，并适配输出路径。每个阶段都以验证结束。

此技能依赖于同一仓库中单独安装的 gpt-image 技能。当需要指南图片时，加载该技能并遵循其说明。不要假设其辅助程序位于此技能目录内。

阶段 1 — 拉取应用商店列表（事实来源）

从 iTunes 查询 API 获取完整元数据（无需认证）：
```
curl -s "https://itunes.apple.com/lookup?id=<APP_ID>&country=us"
```
提取：名称、bundleId、描述、价格/IAP 条款、类别、评分数量、截图、图标、版本、卖家。同时检查 Google Play 列表（play.google.com/store/apps/details?id=<bundleId>）— 不要假定仅限 iOS。
通过重写 mzstatic 缩略图后缀，以高分辨率下载资源：
- 图标：将 512x512bb.jpg 替换为 1024x1024bb.png
- 截图：将 392x696bb.jpg 替换为 1284x2282bb.png（优雅降级；使用 file 验证）
使用读取工具读取每张截图。 说明文字、指南主题和落地页文案必须描述截图实际显示的内容。同时从中提取品牌调色板和字体样式。
在仓库根目录写入 app.md：身份表、逐字描述、从列表+截图派生的功能列表、资源清单，然后是关键词研究（阶段 2）和布局映射。此文件是后续所有内容的基础。

阶段 2 — 高转化率关键词研究

如果 astro MCP 工具已连接，使用 get_keyword_suggestions 和 search_app_store 获取 App Store 流行度/难度和当前排名。记录应用今天的排名。
使用 WebSearch 验证 Google 端的长尾词（落地页排名在 Google，而非 App Store）。
将输出结构化为 app.md：
- 主关键词（3–5 个头部词）→ 标题标签、H1、英雄区文案、元描述
- 次关键词 → 部分 H2、功能文案
- 长尾词（6–10 个问题/任务短语）→ 每个对应一个指南页面
重要的规则：
- 每个长尾词必须映射到应用能切实解决的问题——最好在截图中可见。这样才能将流量转化为转化。
- 检查每个头部词的实际搜索结果，跳过被污染的词（例如“股票追踪”返回股票市场应用；“库存管理软件”返回企业供应商）。
- 优先选择博客排名的“如何做”表述——一个带有 HowTo/FAQ 模式的应用页面可以击败它们。

阶段 3 — 落地页页面内 SEO

Vite + React SSG 架构（默认）

没有 JS 渲染的 SPA 对爬虫不可见，因此需提供预渲染的静态 HTML。无需 SSG 框架——一个约 30 行的预渲染脚本即可完成，页面通常无需客户端 JS（FAQ 手风琴是原生 <details>；不要水合无交互的内容）：

landing/
  package.json          # build: vite build --ssr src/entry-server.tsx --outDir dist-ssr && node scripts/prerender.mjs
  vite.config.ts        # plugins: [react()], ssr: { noExternal: true }  ← 将 react 打包进 dist-ssr，以便 prerender.mjs 独立导入
  index.html            # 仅开发环境 shell: <div id="root"> + /src/entry-client.tsx
  public/               # style.css, assets/（逐字复制到 dist/）
  src/
    data.ts             # 所有内容：FAQ 条目、指南正文、标题、描述。单一事实来源。
    seo.ts              # PageMeta 类型 + JSON-LD 构建器（homeJsonld、guideJsonld、breadcrumbJsonld），读取 data.ts
    components.tsx      # Header、Footer、StoreBadge、FaqItem、GuideCard、CtaCallout
    pages/              # Home.tsx、GuidePage.tsx、GuidesIndex.tsx
    routes.tsx          # 路由：[{ meta: PageMeta, element }] — 每个页面一个条目，指南从 data.ts 扩展
    entry-server.tsx    # renderRoute(route)：完整 HTML 文档字符串 — head 标签 + JSON-LD + renderToStaticMarkup(body)
    entry-client.tsx    # 仅开发环境：matchRoute(location.pathname) → createRoot().render()
  scripts/prerender.mjs # 导入 dist-ssr/entry-server.js；按路线写入 dist/<path>/index.html + sitemap.xml + robots.txt；cpSync public/ → dist/

此结构中预设的关键决策：

使用 renderToStaticMarkup，而非 renderToString — 无水合标记，干净 HTML，因为不提供客户端包。
干净 URL：路由路径以 / 结尾（/guides/<slug>/），预渲染写入 <path>/index.html。内部链接为站内绝对路径（/guides/…/），这也能使开发服务器导航正常工作。
开发体验：vite 提供 entry-client.tsx，支持 HMR；客户端入口从不部署到生产环境。
在手动构建的 head 模板中对属性值使用 esc()；JSON-LD 通过 JSON.stringify（无转义问题）。
React 属性是 fetchPriority（驼峰式）——小写的 fetchpriority 会发出警告。

页面内规则（任何技术栈）

各部分：英雄区、下载、截图、工作原理、指南、常见问题、CTA、页脚。

恰好一个 H1，携带主关键词。部分标题为 H2（“可在以下平台获取”类标题不能是 H1）。
<title> ≈ “品牌 — 受众的主关键词”（≤60 字符）。元描述 ≤155 字符，包含主关键词和核心差异化优势。
每个页面的规范 URL、OG + Twitter 卡片、apple-itunes-app 元标签（智能应用横幅）。在 Vite 设置中，这些位于 entry-server.tsx；Next.js：metadataBase、alternates.canonical、标题 template、itunes.appId。
首页 JSON-LD：SoftwareApplication（包含 offers、installUrl；如果评分少于约 50 条，省略 aggregateRating）、FAQPage、WebSite。在 seo.ts 中从 data.ts 构建对象，使模式和可见文案共享同一个来源。
商店徽章/下载 CTA 在首屏上方，外加一个靠下的重复 CTA 区域。
截图需包含关键词的 alt 文本，描述实际屏幕内容。将商店 PNG（通常每个 1–2 MB）重新压缩为 ≤200 KB 的 JPEG（sips -Z 1386 -s format jpeg -s formatOptions 80）；将原始文件保留在 public/assets/full/。
FAQ：8–10 个问题，每个都是真实的搜索查询，用 2–3 句话回答，每个都带有“了解更多 →”链接到其对应的指南。FAQPage JSON-LD 必须包含与可见 FAQ 相同的 Q/A 文本——两者都从同一个 data.ts 数组渲染。
sitemap.xml + robots.txt：由 scripts/prerender.mjs 从 ROUTES 列表生成，因此新指南会自动出现。

阶段 4 — 指南页面（每个长尾关键词一个）

将指南内容存储在单一数据模块中（Vite 设置为 src/data.ts；Next.js 为 lib/guides.ts），并通过一个模板组件渲染，以便模式、卡片、页脚链接和 sitemap 都从同一个列表派生。将每个指南建模为结构化数据，而非 HTML 片段：{ slug, title, description, h1, intro, featureImage: { src, alt, width, height }, howto?, sections: [{ h2, paras, cta?, figure? }], faq, related }——CTA 提示和图形成为组件，段落保持为可搜索字符串（可通过 dangerouslySetInnerHTML 使用内联 <em> 级别 HTML）。

GPT Image 特色图片工作流

每篇指南文章都有其自己的横版特色图片。加载并使用 gpt-image 技能，该技能调用 OpenAI 的 gpt-image-2；除非用户明确要求，否则不要使用库存图片、CSS 渐变、截图或其他图片模型替代。如果 gpt-image 未安装，请在生成图片前停止，并告知用户从该仓库安装相邻技能。

在指南标题和 slug 确定后，根据每个指南的搜索意图、具体主题以及 app.md 中捕获的应用视觉身份，生成一个图片简介。概念必须具有实质性差异，而非同一构图的调色板互换。
提示词用于生成属于应用品牌调色板的编辑风格特色图片。描述主题、场景、构图、光线、材质、相机/视角，以及视觉呼吸空间应位于何处。每个提示词以以下内容结束：横版编辑风格特色图片，3:2 构图。绝对不要包含文字、词语、字母、数字、说明文字、水印、界面标签或标志。 不要要求模型渲染文章标题。
将 GPT_IMAGE_SKILL_DIR 解析为包含 gpt-image 技能 SKILL.md 的安装目录，然后以其确定性目标运行其生成器：
```
"$GPT_IMAGE_SKILL_DIR/scripts/generate_image.py" "<指南特定提示>" \
  --model gpt-image-2 \
  --aspect-ratio 3:2 \
  --quality high \
  --background opaque \
  --format webp \
  --output "<站点公共目录>/assets/guides/<slug>-feature.webp"
```
这将生成 1536×1024 横版来源。必要时先创建目标目录。保留生成的来源；使用框架的图片管道生成较小的响应式变体，而不是反复重新压缩。
在接入之前，全尺寸检查每张图片。检查是否有意外文字/字形、畸形物体、复制的应用 UI、意外标志、无关主题，以及在桌面和卡片宽高比下的裁剪安全性。只重新生成失败的图片，修改提示词以解决观察到的缺陷；同一指南重新生成两次失败后停止，并报告剩余问题，而不是无限期地花费时间。
将图片添加到指南的结构化记录中，包含 width: 1536、height: 1024，以及基于图片实际内容的简洁描述性 alt 文本。将其渲染为文章首屏特色图片、指南卡片缩略图，以及页面的 og:image/twitter:image。将其作为绝对 URL 添加到 JSON-LD 的 Article.image 中。当搜索关键词无法描述实际像素时，不要将其作为通用的 alt 文本。

每个指南：

URL slug = 关键词（/guides/how-to-keep-track-of-inventory-small-business）
答案优先开头：第一段直接回答搜索的问题（吸引精选片段），然后正文教授任务，将应用作为工具融入其中——先教学，后推销。
H2 携带关键词的次要表述。600–900 字实质内容，无填充。
一张相关的应用截图，附有描述性说明文字、页面中部的一个 CTA 提示，以及该指南独有的 2 个问题 FAQ（不要重复首页 FAQ 问题——避免模式重复）。
JSON-LD：Article + BreadcrumbList + FAQPage，如果指南步骤明确，则加上 HowTo。
指南之间相互链接，并链接回首页部分。
生成的 GPT Image 特色资源已存在，文章独有，并接入英雄区、卡片、社交元数据和 Article.image JSON-LD。使用响应式 srcset/框架图片优化，并设置显式尺寸以防止布局偏移；不要对首屏特色图片使用懒加载。

阶段 5 — 去 AI 化文案（维基百科：AI 写作迹象）

在发布前，对您编写的所有内容（指南答案、FAQ 回答、英雄区/部分文案）进行此检查。信号按强度排序：

破折号 — 最常见的信号。预算：整个站点少量使用，而非每段都用。替换为句号、逗号、冒号、括号。
否定平行结构 — “不是 X，而是 Y”、“不仅是 X 更是 Y”、“X，而非 Y”。全站最多一个，且只在确有必要时使用。
三连结构 — “没有 A，没有 B，没有 C”、“adj1、adj2、adj3”。拆分成对或真实列表。
公式化结构 — 页面间开头相同（例如每篇指南都从相同的粗体论点模板开始）。变化：直接答案、场景、直白声明。
统一有力的节奏 — 句子一个接一个短促有力。变化句子长度；让一些句子只传递信息。
词汇黑名单：深入探讨、锦囊、见证、关键、关键之处、充满活力的、无缝的、毫不费力的、拥有、利用、提升、稳健的、一丝不苟的、格局、强调、展示、培养、变革性的、改变游戏规则的、彻底革命的、赋能、简化、“杀手功能”、“单一事实来源”、“充满信心”、“这里是如何 / 这里是”等重复句式。
避免系动词 — 使用“是”即可，却用“充当”、“代表”。用“是”。
浅显分析的分词结构 — 在句子末尾附加“...强调”、“...突出”、“...反映”等从句。
用具体细节（价格、月份、命名对象）替换格言。具体内容读起来像人写的；泛泛之谈读起来像生成的。

机械检查（适配路径）：

grep -o "—" <内容文件> | wc -l   # 目标：全站个位数
grep -inE "delve|tapestry|testament|pivotal|crucial|vibrant|seamless|effortless|boasts|leverage|elevate|robust|meticulous|landscape|underscore|showcas|foster|transformativ|game.chang|revolutioniz|empower|streamlin|serves as|stands as|it's not just|isn't just|not only" <内容文件>

CSS 类名（例如 transition-transform）可能会误报；忽略这些。保留的内容必须经得起“忙碌的人会写这个句子吗？”的考验。

在去 AI 化过程中保持完好：slug、标题/关键词、内部链接、模式（从重写的来源重新生成模式，使可见文本和 JSON-LD 保持一致）。

阶段 6 — 验证

npm run build 必须通过，然后对 dist/**/index.html 运行脚本检查：每页恰好一个 H1、规范 URL 存在、每个 <script type="application/ld+json"> 可解析、每个内部 href/src 都解析到 dist 中的文件（将尾部斜杠 URL 映射到 <path>/index.html）、每个 sitemap <loc> 映射到一个真实文件，并且首页的可见 FAQ 问题与 FAQPage JSON-LD 的 name 相等。
验证每个指南记录都有独特的横版特色图片、每个文件都存在于构建输出中、内在尺寸宽大于高、HTML 的 width/height 属性与来源匹配，以及每个指南的 Open Graph、Twitter 和 Article.image URL 正确解析。

App 落地页 SEO — 商店资料 → 关键词页出货