Community寫作與編輯github.com

jdevalk/skills

審查部落格文章草稿或頁面副本,進行內容層面的 SEO 稽核:搜尋意圖契合度、關鍵字放置、E-E-A-T 信號、實用性與原創性、內容新鮮度及內部連結。

skills 是什麼?

此技能用於對部落格文章或頁面草稿進行內容 SEO 稽核,判斷其是否有機會獲得排名,而非評估其可讀性。它專注於內容策略層面的問題,例如文章是否符合真實的搜尋意圖、是否使用了搜尋者慣用的詞語、是否展現了經驗與可信度,以及是否能讓搜尋者願意停留。稽核範圍包含六個面向:搜尋意圖契合度、焦點關鍵字放置、E-E-A-T 信號(經驗、專業、權威、信任)、實用性與原創性、內容新鮮度,以及內部連結與網站契合度。針對每個項目,都會提出具體問題、引用原文、解釋原因,並建議修正方式。最後會給出每個項目通過/需改進/有問題的狀態,以及整體結論:可直接發布、可修正,或內容與查詢不符。此技能支援多種平台,如 Claude Code、Cursor 等,透過明確的檢查與評分框架,協助內容創作者與 SEO 專家系統性地提升內容品質與搜尋表現。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/jdevalk/skills/tree/HEAD/content-seo

Installed? Explore more 寫作與編輯 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

內容 SEO 稽核

稽核文章或頁面草稿,判斷其是否有資格獲得排名——而非評估其可讀性。此技能涵蓋內容層面的問題:文章是否符合真實的搜尋意圖、是否使用了搜尋者慣用的詞語、是否展現了經驗與可信度,以及是否給搜尋者一個停留的理由。

這是寫作品質鏈中的第三道關卡。先執行 readability-check(評估文句可讀性),再執行 metadata-check(檢查標題與 Meta 描述),最後才對此技能進行稽核,判斷內容是否值得被點擊。技術性 SEO——網站地圖、結構化資料、標準連結、效能——則屬於 astro-seo 或 static-seo。

稽核前準備

你需要兩項資訊。如果使用者未提供,請自行推斷並說明你的假設——標記出錯誤的假設遠比默不作聲好:

  • 焦點關鍵字:這篇文章應為之排名的精確查詢,使用搜尋者會輸入的詞語。如果使用者無法指定一個,請根據標題與標題層級推斷出明顯的關鍵字——並將其作為第一個發現回報,因為沒有目標查詢的文章通常也無法服務任何查詢。
  • 目標受眾與他們的問題:誰會造訪這個頁面,以及他們在搜尋時想要解決什麼問題。

讀者決定何謂品質,而非作者。以下每個檢查都歸結為一個問題:此內容是否比已排名的內容更能服務輸入查詢的使用者?

檢查項目

閱讀整篇文章,然後針對以下每個標準進行回報。對於每個問題,請引用具體文字,標明其位置,解釋問題所在,並建議具體的修正方式。

1. 搜尋意圖契合度

搜尋者帶著四種意圖之一前來,內容類型必須與之匹配:

  • 資訊型(「X 如何運作」)——想要指南或解說,而非產品推銷。
  • 商業調查型(「最佳 Y 的 X」、「X 與 Z 比較」)——想要比較與誠實的取捨。
  • 交易型(「購買 X」、「X 價格」)——想要產品或類別頁面,並有明確的購買路徑。
  • 導航型(「X 登入」、品牌名稱)——想要特定頁面;不要用部落格文章攔截它。

檢查事項:

  • 指出該關鍵字的主要意圖,並驗證內容類型是否匹配。一個以資訊型查詢為目標的銷售頁面,會在第二段之前就失去訪客——他們想要答案,卻得到推銷。
  • 行動呼籲必須與意圖相符。資訊型頁面 → 軟性 CTA(相關閱讀、電子報);交易型頁面 → 直接導向產品的路徑。在資訊型文章上標記硬性推銷。
  • 搜尋者問題的答案應出現在文章開頭,而不是在 800 字的開場白之後。需要捲動才能找到答案的搜尋者會回到搜尋結果頁——而這種返回行為正是損害排名的負面信號。

2. 焦點關鍵字放置

關鍵字向搜尋者——以及搜尋引擎——確認這個頁面回答了他們的查詢。它應該自然地出現在他們雙方最重視的位置:

  • 頁面標題與第一段。搜尋者應該在落地後的幾秒內就能辨識出他們的查詢。
  • 至少一個或兩個標題層級,在不彆扭的情況下自然融入。
  • 幾個核心句(段落的開頭第一句)。在結構良好且緊扣主題的文章中,這會自然發生——如果你必須強行置入,代表文章已偏離主題,而這才是真正的發現。
  • 使用搜尋者的詞語,而非內部行話。如果目標受眾搜尋「網站速度」,而文章全篇使用「效能最佳化」,那麼文章對其目標受眾來說是隱形的。

以及反向檢查:

  • 絕不強行置入。 如果關鍵字讓句子讀起來不順暢,句子優先。搜尋引擎能辨識同義詞與詞形變化;讀者則不會原諒彆扭的文句。
  • 多樣化表達。 機械式重複相同詞語對讀者與搜尋引擎而言都像是關鍵字堆砌。同義詞與相關詞組能涵蓋更多查詢,讀起來也更順暢。

3. E-E-A-T 信號

搜尋品質評估員會評估經驗、專業、權威與可信度。這些並非抽象的美德——每一項都可以在文本中看到(或看不到):

  • 經驗:文章是否展現了第一手的參與——只有真正做過的人才會知道的事?真實的數字、真實結果的截圖、出了什麼問題、作者感到驚訝的是什麼。一篇從其他文章拼湊而成的文章沒有這些,而且一看就知道。
  • 專業:作者的身份是否明確,且有理由相信他們在此主題上是可信的?主張是否有來源——是否連結到可靠的參考資料,而不是直接斷言?
  • 權威:文章是否引用或連結到該領域公認的來源?這對大多數網站來說是最薄弱的槓桿——如果不適用,請說明並加重其他三個的權重;不要偽造它。
  • 可信度:是否清楚誰對這個內容負責,以及如何聯繫他們?主張是否準確且時效性?對於 YMYL 主題——健康、金錢、安全、法律——對每個主張都應採取最嚴格的標準;未經來源佐證的醫療或財務主張應視為 ✗,而非 ⚠。

4. 實用性與原創性

以人為本的測試:如果沒有搜尋引擎,這篇文章還會存在嗎?

  • 文章是否增加了當前排名結果所沒有的東西——第一手數據、更犀利的觀點、實際的範例、誠實的限制?對已排名的內容進行稱職的改寫,不會給搜尋者任何偏好它的理由,也不會給搜尋引擎任何排名它的理由。
  • 答案是否完整?搜尋者不應該需要返回搜尋結果頁才能完成任務。標記文章提出但未回答的問題,以及提及但未解釋的步驟。
  • 讀者的問題是否被明確指出並在結尾解決?一篇「關於」某主題但沒有「解決」任何問題的文章,服務的是作者,而非讀者。

5. 新鮮度

  • 標記會隨著時間過時的內容:版本號碼、價格、UI 截圖、「去年」/「最近」等時間用語、對時事的引用。要麼讓它們永不過時,要麼明確標註日期,讓過時狀況一目瞭然。
  • 標記已經過時的內容:過時的事實、已棄用的工具、已被取代的建議。
  • 對於時效性強的主題,建議一個審查週期。一篇現在正確但六個月後就會錯的文章,需要的不是發布按鈕,而是日曆提醒。

6. 內部連結與網站契合度

文章不是獨立排名的——它是作為網站的一部分來排名的:

  • 文章應連結到同一網站上的相關內容,尤其是該主題的基石文章,並使用描述性的錨點文字(「我們關於關鍵字研究的指南」,永遠不要用「點擊這裡」)。
  • 相關文章應回連到這篇文章。一篇沒有任何內部入站連結的新文章是孤兒——請標記它,並指出哪些既有文章應該連結到它(如果使用者已授權你存取該網站或其內容庫)。
  • 檢查關鍵字自相殘殺:同一網站上是否已有一篇針對此關鍵字的既有文章?兩篇文章競爭同一個查詢會削弱它們的整體力量;建議合併、區分或重新定位其中一篇。

評分

各類別狀態——針對上述 6 項檢查,分別賦予:

  • ✓ 通過——沒有重大問題。
  • ⚠ 需要改進——有少數可修正的問題;如下所列。
  • ✗ 有問題——整個文章中存在系統性問題。

整體結論——三者之一:

  • 可發布——按現狀發布;僅有次要問題。
  • 可修正——內容符合查詢,但列出的問題阻礙了表現。
  • 內容與查詢不符——意圖不匹配或原創性差距無法透過編輯解決;文章需要不同的切入點或不同的目標關鍵字。如果情況屬實,請直接說出來——潤飾一篇針對錯誤查詢的文章只會浪費作者的時間。

輸出格式

## 內容 SEO 稽核:[文章標題]

### 目標
- 焦點關鍵字:[詞語]([使用者提供 / 推斷——假設])
- 意圖:[資訊型 / 商業調查型 / 交易型 / 導航型]
- 結論:[可發布 / 可修正 / 內容與查詢不符]
- 各類別:1. ✓  2. ⚠  3. ✓  4. ✗  5. ✓  6. ⚠

### 總結
[一個段落:這篇文章服務哪個查詢、服務得如何,以及最能改善它的一兩項變更。]

### 發現的問題
[按類別分組。每個問題:位置、引用文字、為何是問題、具體修正方式。]

### 表現良好的部分
[具體有助於排名的元素——一個真正的第一手範例、一個放在開頭的完整答案、一個良好連結的基石參考。引用它們,以便作者可以調整。]

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

jdevalk/skills

Sets up GitHub Actions CI/CD workflows for Astro sites — `astro check` (TypeScript + content schema), ESLint, Prettier, build verification, Vitest testing, Lighthouse CI, link checking, npm audit, and automated deployment to GitHub Pages, Cloudflare Pages, Netlify, or Vercel. ALWAYS use this skill when a user wants to create, add, set up, or configure GitHub Actions, CI/CD, automated checks, or deployment workflows for an Astro site — even if they don't use the exact phrase "GitHub Actions". This includes any request to: add automated type-checking or linting to an Astro repo; set up `astro check` in CI; add Lighthouse or accessibility checks to PRs; configure Vitest in CI for an Astro project; auto-deploy an Astro site to GitHub Pages, Cloudflare Pages, Netlify, or Vercel from GitHub; add link checking or broken-link detection; add security scanning to an Astro pipeline; or generally "add CI", "add automated checks", "set up workflows", or "automate" anything related to an Astro site's GitHub repository. ...

jdevalk/skills

Audits and improves SEO for Astro sites. Use when the user asks to audit, set up, or improve SEO on an Astro site, or mentions head metadata, structured data, JSON-LD, sitemaps, IndexNow, Open Graph images, schema endpoints, NLWeb, hreflang, or search engine indexing in an Astro project. Produces drop-in code routed through `@jdevalk/astro-seo-graph` and chains into `metadata-check` for generated SEO strings.

jdevalk/skills

Audits and improves SEO for static HTML sites. Use when the user asks to audit, set up, or improve SEO on a static site (Hugo, Jekyll, 11ty, Gatsby, Next.js static export, hand-rolled HTML, or `wp-static-clone` output), or mentions head metadata, structured data, JSON-LD, sitemaps, IndexNow, Open Graph images, schema endpoints, NLWeb, hreflang, or search engine indexing for a static site. For Astro projects, use `astro-seo` instead — its recipes produce less hand-rolled boilerplate by routing through `@jdevalk/astro-seo-graph`.

相關技能