Name: App 落地頁 SEO — 商店資料 → 關鍵詞頁出貨
Author: Community

App Landing Page SEO

從應用程式商店列表轉換為高轉換率、SEO 優化的落地頁面與長尾指南頁面的端到端工作流程。預設技術棧：Vite + React 搭配建置時預渲染（架構詳見第三階段）。如果儲存庫已有網頁框架（Next.js、Astro），則在該框架內建置並調整輸出路徑。每個階段結束時皆需驗證。

此技能依賴於同一個儲存庫中獨立安裝的 gpt-image 技能。當需要指南圖片時，請載入該技能並遵循其說明。不要假設其輔助程式位於此技能的目錄內。

第一階段 — 擷取商店列表（事實來源）

從 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：身份表格、逐字描述、從列表+截圖衍生的功能列表、素材清單，以及後續的關鍵字研究（第二階段）與配置地圖。此檔案是後續所有工作的合約。

第二階段 — 轉換率導向的關鍵字研究

如果已連接 astro MCP 工具，請使用 get_keyword_suggestions 和 search_app_store 來確認 App Store 的熱門度/難度與當前排名。記錄 App 當前的排名位置。
使用網路搜尋來驗證 Google 端的長尾關鍵字（落地頁面要在 Google 上排名，而不是 App Store）。
在 app.md 中結構化輸出：
- 主要關鍵字（3–5 個核心詞）→ 標題標籤、H1、英雄區文案、Meta 描述
- 次要關鍵字 → 章節 H2、功能文案
- 長尾關鍵字（6–10 個問題/任務短語）→ 每個對應一個指南頁面
重要規則：
- 每個長尾關鍵字必須對應到 App 能實際解決的痛點 — 最好在截圖中可見。這樣才能讓流量轉換。
- 檢查每個核心詞的實際 SERP，跳過已被污染的詞（例如「股票追蹤」回傳股票市場 App；「庫存管理軟體」回傳企業供應商）。
- 在部落格排名高的地方，偏好「如何做」的措辭 — 一個帶有 HowTo/FAQ 結構化資料的 App 頁面可以擊敗它們。

第三階段 — 落地頁面的頁內 SEO

Vite + React SSG 架構（預設）

SPA 若無 JavaScript 渲染則對爬蟲不可見，因此需輸出預渲染的靜態 HTML。不需要 SSG 框架 — 一個約 30 行的預渲染腳本即可完成，且頁面通常完全不需要客戶端 JavaScript（常見問題手風琴使用原生 <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            # 僅開發用外殼：<div id="root"> + /src/entry-client.tsx
  public/               # style.css, assets/（直接複製到 dist/）
  src/
    data.ts             # 所有內容：常見問題條目、指南正文、標題、描述。單一事實來源。
    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          # ROUTES: [{ 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；根據 route 寫入 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 會發出警告。

頁面規則（任何技術棧）

區段：英雄區、下載區、截圖區、運作方式、指南區、常見問題區、行動呼籲區、頁尾。

僅一個 H1，包含主要關鍵字。章節標題為 H2（「可在以下平台取得」類型的標題不得為 H1）。
<title> ≈ 「品牌 — 目標族群的主要關鍵字」（≤60 個字元）。Meta 描述 ≤155 個字元，包含主要關鍵字 + 頂級差異化要素。
每個頁面有 Canonical URL、OG + Twitter 卡片、apple-itunes-app meta（智慧型應用程式橫幅）。在 Vite 設定中，這些位於 entry-server.tsx；Next.js：使用 metadataBase、alternates.canonical、title template、itunes.appId。
首頁的 JSON-LD：SoftwareApplication（含 offers、installUrl；少於約 50 則評分時跳過 aggregateRating）、FAQPage、WebSite。在 seo.ts 中從 data.ts 建構物件，使結構化資料與可見文案共用一個來源。
商店徽章/下載行動呼籲按鈕在首屏之上，並在頁面較低位置重複一個行動呼籲區段。
截圖需有包含關鍵字的 alt 文字，描述實際畫面。將商店 PNG（通常每張 1–2 MB）重新壓縮為 ≤200 KB 的 JPEG（sips -Z 1386 -s format jpeg -s formatOptions 80）；原始檔案保留在 public/assets/full/ 中。
常見問題：8–10 個問題，每個都是真實的搜尋查詢，以 2–3 句話回答，每個問題附有「了解更多 →」連結，指向對應的指南。FAQPage JSON-LD 必須包含與可見常見問題相同的問答文字 — 兩者都來自同一個 data.ts 陣列。
sitemap.xml + robots.txt：由 scripts/prerender.mjs 根據 ROUTES 列表生成，因此新增指南時會自動出現。

第四階段 — 指南頁面（每個長尾關鍵字一個頁面）

將指南內容儲存在單一資料模組（Vite 設定中為 src/data.ts；Next.js 中為 lib/guides.ts），並透過單一模板元件渲染，使結構化資料、卡片、頁尾連結和站點地圖都來自同一個列表。將每個指南建模為結構化資料，而非 HTML 區塊：{ slug, title, description, h1, intro, featureImage: { src, alt, width, height }, howto?, sections: [{ h2, paras, cta?, figure? }], faq, related } — 行動呼籲呼籲和圖形變成元件，段落保留為可搜尋的字串（透過 dangerouslySetInnerHTML 使用行內 <em> 層級的 HTML 是可以的）。

GPT 圖片特徵圖片工作流程

每篇指南文章都有一張屬於自己的橫向特徵圖片。載入並使用 gpt-image 技能，該技能呼叫 OpenAI 的 gpt-image-2；除非使用者明確要求，否則不要使用庫存圖片、CSS 漸層、截圖或其他圖片模型。如果 gpt-image 未安裝，請在圖片生成前停止，並告知使用者安裝此儲存庫中的同級技能。

在指南標題和網址別名確定後，根據每個指南的搜尋意圖、具體主題以及 app.md 中記錄的應用視覺識別，為每個指南製作一份圖片簡報。這些概念必須有意義地不同，而不是同一構圖的調色盤交換。
提示使用應用品牌色板的編輯風格特徵圖片。描述主題、場景、構圖、光線、材質、攝影機/視角，以及視覺留白應放置的位置。每個提示結尾加上：Landscape editorial feature image, 3:2 composition. Absolutely no text, words, letters, numbers, captions, watermarks, interface labels, or logos. 不要要求模型渲染文章標題。
將 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 加入 Article.image JSON-LD。當搜尋關鍵字無法描述實際像素時，不要將其用作模板化的 alt 文字。

每個指南：

URL 別名 = 關鍵字（/guides/how-to-keep-track-of-inventory-small-business）
答案優先的開頭：第一段直接回答搜尋的問題（精選摘要誘餌），然後正文以應用程式為工具來教授任務 — 先教學，後推銷。
H2 包含關鍵字的次要措辭。600–900 字的實質內容，無填充。
一張相關的應用截圖，附有描述性說明文字；頁面中間的行動呼籲呼籲；以及該指南獨有的 2 題常見問題（不要重複首頁常見問題的問題 — 避免結構化資料重複）。
JSON-LD：Article + BreadcrumbList + FAQPage，若指南為步驟形式則加上 HowTo。
指南之間互相連結，並連結回首頁區段。
生成的 GPT 圖片特徵素材存在、是該文章獨有的，並已接入英雄區、卡片、社交元資料和 Article.image JSON-LD。使用響應式 srcset/框架圖片優化，並設定明確尺寸以防止佈局位移；首屏之上的特徵圖片不要延遲載入。

第五階段 — 去除文案中的 AI 痕跡（維基百科：AI 寫作跡象）

在交付前，對你撰寫的所有內容（指南、常見問題回答、英雄區/區段文案）執行此檢查。最明顯的跡象，按醒目程度排列：

Em 破折號 — 最明顯的跡象。預算：整個網站僅少數幾個，而不是每個段落都出現。用句號、逗號、冒號、括號取代。
否定平行結構 — 「不是 X，而是 Y」、「不只是 X 還有 Y」、「X，不是 Y」。全站最多一個，而且只有當它真的有必要時才保留。
三點一組 — 「沒有 A，沒有 B，沒有 C」、「形容詞，形容詞，形容詞」。分解成成對或真正的列表。
公式化結構 — 頁面間開頭相同（例如每篇指南都以相同的粗體主題模板開頭）。變化：直接回答、情境、直接主張。
統一的俐落節奏 — 連續的短句，句句是重點。變化句子長度；讓一些句子只是承載資訊。
詞彙黑名單：深入探究、織錦、見證、關鍵、至關重要、充滿活力、無縫、輕鬆、號稱、利用、提升、強大、一絲不苟、格局、強調、展示、培養、變革性、顛覆性、革新、賦能、簡化、「殺手級功能」、「單一事實來源」、「滿懷信心」、重複的「以下是」/「這是」。
避免繫詞 — 「作為」、「代表」，而「是」就夠了。使用「是」。
表面分析的分詞 — 句子結尾加上「……強調了」、「……突顯了」、「……反映了」等從屬子句。
用具體細節（價格、月份、命名的物件）取代格言。具體內容讀起來像人類寫的；概論讀起來像生成的。

機械檢查（調整路徑）：

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）會產生誤報；忽略這些。保留下來的內容必須經得起「忙碌的人類會寫出這個句子嗎？」這個問題的考驗。

在去除痕跡的同時保留：網址別名、標題/關鍵字、內部連結、結構化資料（從改寫後的來源重新生成結構化資料，以使可見文字和 JSON-LD 保持一致）。

第六階段 — 驗證

npm run build 必須通過，然後對 dist/**/index.html 執行腳本檢查：每個頁面只有一個 H1、有 canonical、每個 <script type="application/ld+json"> 都能解析、每個內部 href/src 都對應到 dist 中的一個檔案（將結尾斜線 URL 映射到 <path>/index.html）、站點地圖的每個 <loc> 都對應到一個真實檔案，且首頁的可見常見問題問題等於 FAQPage JSON-LD 的 name。
驗證每個指南記錄都有一張不同的橫向特徵圖片、每個檔案都存在於建置輸出中、內建尺寸寬大於高、HTML width/height 屬性與來源相符，且每個指南的 Open Graph、Twitter 和 Article.image URL 都解析為實際存在的圖片檔案。

[因翻譯而截斷]

App 落地頁 SEO — 商店資料 → 關鍵詞頁出貨