seo-playbook

SEO Playbook

此技能將 SEO 轉化為可重複執行的工程流程：找出網站能實際勝出的查詢、為每個頁面分配一個明確目標、將正確的文字放入正確的 HTML 元素、確保 Google 能爬取、渲染與索引結果、建立連結，然後衡量並迭代。

它萃取了在將年輕的 Next.js 工具網站從零帶到長尾查詢第一頁排名過程中，哪些方法有效（以及哪些悄然失敗）的經驗。這些教訓適用於任何技術棧。

五句話總結核心心態

1. 排名取決於可勝出性，而非期望。 今年一個年輕網域無法在「QR code generator」這類頭部詞語上進入前五名；但它可以在數週內為「free qr code generator no sign up」或「birthday wish link with name」獲得排名。先鎖定長尾詞，讓主題權威性日後將頭部詞語拉上來。
2. 一頁、一個搜尋意圖、一個主要關鍵字。 兩個頁面針對相同查詢會分散訊號（關鍵字自相殘殺）；一個頁面針對兩個意圖則兩者都無法滿足。
3. Google 排名的是它收到的 HTML，而非使用者看到的應用程式。 如果內容、H1、FAQ 答案或連結只在 JavaScript 執行後才出現，請假設它們不存在。每次都檢查原始的伺服器回應。
4. 可索引性問題比文案寫作更重要。 軟 404、錯誤的正規化標籤或從佈局繼承的 noindex 可以在沒有任何錯誤訊息的情況下抹去數月的內容工作。在你接觸的每種頁面類型上驗證狀態碼、正規化標籤和 robots。
5. 用 Search Console 衡量，而不是直覺。 位於第 8 到 20 位的曝光次數是最容易取得的勝利；第 50 位以上則表示存在權威性或意圖問題，僅靠頁面調整無法解決。

誠實地設定期望：長尾頁面的首次曝光通常需要 2 到 6 週；頭部詞語則需要數月和反向連結。「快速」SEO 意味著選擇網站能勝出的戰鬥。

先選擇深度

大多數 SEO 請求規模較小。在執行任何動作之前先選擇模式，因為完整工作流程所花費的時間和令牌數遠超過小型變更所需。

快速模式適用於修改一兩個頁面，且關鍵字已知或顯而易見的情況：重新命名頁面、撰寫 meta description、加入 FAQ、修正被標記的問題、或將頁面加入已有 SEO 模式可遵循的專案。在快速模式下：

• 不要讀取參考檔案，也不要研究即時 SERP，除非下列檢查失敗或你確實無法決定。
• 遵循專案現有的 SEO 模式：其 metadata helper、content config 和 schema components。
• 進行修改，然後對結果執行下方快速檢查清單。如果有建置後或已上線的 HTML，對它執行一次 scripts/seo_check.py。
• 用幾行文字回報。若注意到任何較大的事項，以一行「Also worth doing」提及，但不要深入調查。

快速檢查清單（僅針對修改的頁面）：

1. 標題是獨一無二的，以關鍵字開頭，長度 ≤ 60 個字元。Description 長度為 120–160 個字元，且只做真實陳述。
2. 恰好有一個 H1，且主要內文、H1 和 FAQ 答案存在於伺服器 HTML 中（非僅客戶端、非 opacity:0、非已卸載）。
3. 頁面設定自己的正規化標籤、可被索引，且存在於 Sitemap 中。隱藏頁面使用 noindex 且未在 robots.txt 中被禁止。
4. 3–5 個對外內部連結，以及至少一個連入該頁的內部連結。
5. 結構化資料與可見內容相符，且沒有非網站自身的評分。

完整模式是下列工作流程。在以下情況使用：

• 新的網站、頁面集合或主題群組
• 當正確目標不明確時選擇關鍵字
• 診斷「為何沒有排名」或「流量停滯」
• 上線前或全站稽核
• 站外計劃

快速檢查可能會發現全站性問題，例如繼承的正規化標籤、軟 404 模式或虛構的評分。不要悄悄地擴大工作範圍：完成要求的修改，將問題放在報告頂端，用一行說明為什麼重要，並提供完整稽核的選項。由使用者決定是否花費時間。例外情況是當要求修改的內容在沒有修正的情況下無法運作時，例如你要編輯的頁面沒有伺服器渲染的 H1。在這種情況下，修正最低限度的必要項目並說明原因。

工作流程（完整模式）

對於新網站或頁面集合，依序執行各階段。對於單一頁面修改，至少執行階段 3、4 和 6。當你到達某個階段時，閱讀連結的參考檔案 — 每個檔案包含詳細的檢查清單和範本。

根據請求調整工作量。 頁面審查就是頁面審查；關鍵字映射就是關鍵字映射。徹底完成被要求的任務，並將鄰近的機會（關鍵字、站外想法）放在簡短的「Also worth doing」清單中，而不是產生沒人要求的完整額外計劃。額外的交付項目會稀釋使用者真正需要的內容，並浪費時間。

在斷言之前先驗證。 檢查你能確認的事實（即時 SERP、品牌名稱是否已被佔用、頁面實際包含什麼、功能實際做什麼）。當你無法檢查某些東西時（例如你僅知道 URL 的頁面、無法載入的網站、你沒看過的功能），請說是假設，並告訴使用者需要確認什麼。對他人網站做出自信的猜測是 SEO 建議最常見的出錯方式。

腳本是你自己用的。 你自己執行 scripts/*.py。在寫給使用者的指示中，用通俗的語言描述檢查內容，或給予他們不需要此技能就能執行的指令（curl、Search Console 步驟）。只有當你確定使用者已安裝該技能時，才參考技能的腳本路徑。

階段 1 — 情報搜集（在修改任何內容之前）

• 識別技術棧以及頁面如何渲染（SSR、SSG、SPA、混合）。關於框架陷阱，請閱讀 references/technical-seo.md 的相關章節（Next.js App Router 有自己的章節）。
• 盤點現有內容：metadata 如何設定、頁面內容存放位置、Sitemap 和 robots 的產生方式、結構化資料元件、分析工具。重複使用現有模式，而不是增加平行的模式。
• 以 Googlebot 身份擷取每種頁面類型的代表性頁面，並記錄基準： python3 <skill-dir>/scripts/seo_check.py <url> [<url> ...] 它會回報狀態、標題/description 長度、正規化標籤、robots meta 和 X-Robots-Tag、H1 計數、可見字數、JSON-LD 類型、OG image 以及紅旗標記（例如「Loading…」的主要元素）。
• 如果 Search Console 數據可用（匯出檔、API 助手，或已安裝的 seo-google 技能），提取 90 天的查詢+頁面資料行，然後執行 scripts/gsc_opportunities.py（見階段 6）。現有的曝光次數告訴你 Google 已經將哪些關聯到該網站。
• 尋找專案 SEO 文件或來自先前稽核的記憶體筆記，並在此基礎上繼續。

階段 2 — 關鍵字研究和關鍵字映射

閱讀 references/keyword-research.md。簡而言之：

1. 從產品中尋找種子：頁面做什麼、誰使用它、使用者想要確切功能時會輸入什麼詞語。
2. 使用免費訊號進行擴展：Google 自動完成和「People also ask」、相關搜尋、競爭者標題、GSC 查詢、Reddit/Quora 措辭。僅在專案有付費 API 時使用（例如已安裝的 seo-dataforseo 或 seo-ahrefs 技能）。
3. 分類意圖（do / know / go / buy）並檢視每個候選的即時 SERP。如果第一頁全是大型品牌或全是不同頁面類型（例如你的工具頁面對上清單文章），則該關鍵字對這個頁面來說還無法勝出。
4. 評分可勝出性：第一頁上較弱的競爭者（內容單薄的獨立網站、論壇、GitHub 儲存庫、*.vercel.app 網站）是最強的信號。
5. 檢查品牌名稱：搜尋其裸稱，加上相關的 npm/PyPI/GitHub/應用程式商店。如果已被佔用，建議一致使用網域形式（「Brand.app」）。
6. 產出關鍵字映射：每個 URL 一行，包含主要關鍵字、3–8 個次要/長尾詞語、意圖，以及每個詞語的放置位置（標題、H1、H2、引言、FAQ）。沒有主要關鍵字出現在兩行上，且表格中的每一行都有意圖。

沒有付費工具的情況下，搜尋量是方向性的等級（非常高 / 高 / 中 / 低）。在你的輸出中說清楚，而不是憑空創造數字。

階段 3 — 頁面實作

閱讀 references/on-page.md 以獲得完整的檢查清單和頁面內容模型。每個可索引頁面的要點：

• 標題：獨一無二，主要關鍵字在前，理想情況下 ≤ 60 個字元（包含任何品牌後綴），並且是為了贏得點擊而撰寫。
• Meta description：獨一無二，120–160 個字元，說明使用者獲得的好處和差異化優勢（「免費、無需註冊、在瀏覽器中執行」），但僅在陳述為真時使用。
• 在伺服器 HTML 中恰好有一個 H1，與頁面的主要意圖相符（標題的近似變體，而非複製）。
• 內文：在第一段回答查詢，然後增加競爭者頁面缺乏的深度：操作步驟、實作範例、常見問題與解決方案、限制、FAQ。每個段落存在的理由是因為搜尋者需要它，而不是為了達到字數。
• 在 HTML 中可見的 FAQ（不僅在摺疊、已卸載的摺疊面板中，也不僅在 JSON-LD 中），措辭應像真實的查詢。
• 內部連結：3–5 個脈絡相關的連結到相關頁面，以及至少一個從相關中心頁面或文章連入該頁的連結。沒有孤兒頁面。
• 符合可見內容的結構化資料：請參閱 references/structured-data.md，了解哪些類型仍能獲得豐富結果。
• 信任：真實的作者或組織、準確的陳述、內容變更時會隨之更新的上次審查日期、數據的來源。切勿發布虛構的推薦或評論——Google 會將其視為不實陳述。

將頁面 SEO 內容儲存為資料（型別化的 config 物件或 CMS 欄位），而不是將字串散落在 JSX 中。這樣可以使得唯一性檢查、長度測試和批量審查成為可能。

階段 4 — 技術關卡（不可跳過）

閱讀 references/technical-seo.md。在宣告任何頁面完成之前，請在建置後或已部署的 HTML 中確認：

• 真實頁面回傳狀態 200，未知 URL 回傳真正的 404（而非帶有「not found」文字的 200）。
• 自參考的絕對正規化標籤，且沒有意外從父層佈局繼承的正規化/robots。
• 可索引的頁面存在於 Sitemap 中，並帶有誠實的 lastmod；noindex 頁面則不在其中。
• 你想隱藏的頁面使用 noindex（meta 或 X-Robots-Tag），且未被 robots.txt 封鎖，否則 Google 永遠無法讀取 noindex。
• 主要內容、H1、FAQ 答案和內部連結存在於原始 HTML 中（seo_check.py 的字數和 H1 檢查）。
• 一個偏好的主機（https、www 或 apex），其他主機透過單次 301 轉址。
• Core Web Vitals 沒有退步（LCP ≤ 2.5 秒, INP ≤ 200 毫秒, CLS ≤ 0.1）。對於實地數據，使用 PageSpeed Insights / CrUX，或已安裝的 seo-performance / seo-google 技能。

階段 5 — 站外與發布

閱讀 references/off-page.md。頁面工作讓頁面有資格；連結和品牌需求決定它在競爭中的排名高度。規劃連結建立應與頁面同步進行，而非之後再補：

• 每個主題群組建立一個可獲得連結的資產（免費工具、範本儲存庫、數據表、原創指南）。
• 提交到少數符合受眾的目錄和發布平台，並撰寫成真實的貼文。
• 對於視覺類型的利基市場使用視覺平台（Pinterest、YouTube Shorts）；對於開發者受眾使用 GitHub。
• 設定 Bing Webmaster Tools 和 IndexNow（Bing 的索引提供 ChatGPT 搜尋和 Copilot 的資料）。
• 切勿購買連結、加入連結計劃，或大量提交到垃圾目錄。

當你無法自己執行站外工作時，為使用者產出一份可直接使用的工具包：目標清單、貼文草稿、推廣郵件草稿和時程表。

階段 6 — 驗證、上線、監控

閱讀 references/measurement.md。

• 對建置後或已部署的頁面重新執行 seo_check.py，並與階段 1 的基準進行比對。對於共用佈局或元件的變更，請比對每種頁面類型，而不僅是你編輯的那一種——全站變更可能悄悄改變已排名的頁面。
• 部署後：重新提交 Sitemap，僅對最重要的少數新 URL 請求索引，並 ping IndexNow。
• 2–4 週後：執行 python3 <skill-dir>/scripts/gsc_opportunities.py <gsc-export.json|csv> 來列出接近前十的查詢、低點擊率的頁面和關鍵字自相殘殺的情況，然後針對這些項目迭代標題、章節和內部連結。

從痛苦中學到的規則

這些規則來自真實的排名倒退。每一個在被發現之前都造成了排名或索引問題。

• 檢查爬蟲實際收到的內容。 路由層級的載入轉圈圖示、ssr: false 的動態導入，或從 opacity: 0 開始的淡入效果，可能導致伺服器 HTML 只包含「Loading…」，而瀏覽器畫面看起來完美。AI 爬蟲完全不執行 JavaScript。
• 進入動畫隱藏了主要內容區。 動畫庫（framer-motion initial={{ opacity: 0 }}、AOS、GSAP）會伺服器渲染它們的起始狀態，因此 H1 和引言在 hydration 之前會以看不見的形式傳送，延遲 LCP。對任何在首屏之上的內容使用 initial={false} 或純 CSS 動畫；在建置後的 HTML 中 grep opacity:0。
• CMS 內文會增加第二個 H1。 在頁面層級 H1 下方以 # Title 開頭的 Markdown 會重複 H1。在渲染器中將內文 H1 降級為 H2。
• 來自串流 SSR 的軟 404。 一旦串流回應開始，後續的 notFound() 無法改變 200 狀態碼。在渲染之前拒絕未知的 slug（使用靜態參數並關閉動態參數），或從 metadata 的 miss 分支明確回傳 noindex。
• 繼承的正規化標籤。 根佈局中的正規化標籤會洩漏到每個未設定自己正規化標籤的頁面。繼承該標籤的軟 404 頁面會變成真實頁面的可索引重複。
• 「API 掛掉」不等於「沒有結果」。 決定 notFound() 或 noindex 的程式碼必須區分失敗的資料擷取和空的結果，否則一次故障就會移除真實頁面的索引。
• 隱藏的內容。 卸載關閉面板的摺疊元件會從 HTML 中移除 FAQ 答案。保持它們已掛載（hidden="until-found" 或使用 CSS），以便爬蟲可爬取並可透過頁內搜尋找到。
• 共用元件是爆炸半徑。 當一個頁面排名良好時，將共用 SEO 元件的變更放在選擇性導入的 props 之後，並在變更前後比對其他頁面的建置 HTML。
• 虛構的社交證明會受到處罰。 Google 的評分呈現政策禁止虛構的星級評分。Schema 中的評分必須來自真實的、可驗證的評論。在 Review 和 AggregateRating 中使用來自真實使用者的內容。
• IndexNow 會立即反映你的錯誤。 一次錯誤的 Sitemap 提交或 404 的大量 ping 會迅速從索引中移除頁面。在更新 Sitemap 之前先暫存並驗證它。
• 預覽與現實。 在開發伺服器上看起來完美的東西如果缺少後端路徑或資料庫連線，在生產環境可能以 500 錯誤或空白頁面傳送。總是檢查真實的已部署 HTML。
• 沒有明確擁有人就沒有 SEO。 沒有被分配負責的頁面會累積上述所有問題。當你建立一個新頁面時，賦予某人對標題、H1 和 canonical 的最終決定權。

附錄

你能肯定的事情

你可以自己檢查這些是否正確：

• 即時 SERP 看起來像什麼（標題格式、片段類型、廣告數量、前一兩名是誰）
• 某個品牌名稱是否已被使用或存在於社群媒體
• 一個特定的 URL 是否回傳 200、301 或 404
• 頁面的原始 HTML 是否包含內容、H1、FAQ 和結構化資料
• 一個頁面是否存在於 Sitemap 中
• 某個特定功能是否實際按預期運作

不要猜測這些。如果你無法檢查，請提出問題。

你不能確定的事情

這些需要使用者提供數據或付費工具：

• 某個特定關鍵字的實際搜尋量（沒有 Subscription API）
• 該網站的 Search Console 或 Analytics 數據
• 你的變更對排名的實際影響（需要時間和對照組）
• 競爭者的內部數據

對於這些，給出方向性的建議並告訴他們如何獲取數據以供下次評估。

與其他技能的關係

此技能涵蓋了即使是初學者也能自己完成的 SEO 活動（腳本、檢查清單、參考檔案、本地檢查）。額外的技能可以在關鍵字研究數據、搜尋量、排名追蹤和 Core Web Vitals 分析方面提供協助——但此技能本身在沒有它們的情況下也能正常運作。