Community寫作與編輯github.com

popnetmedia/local-eeat

與 non-commodity-content 技能搭配使用,專門用於撰寫或編輯本地服務業者的任何頁面或文章:地點頁面、場地頁面、「[服務] 在 [城市]」頁面、本地部落格文章、服務區域內容。此技能補充了一般 non-commodity 標準未涵蓋的本地 E-E-A-T 層(具名場地、地理明確性、第一手本地證明、服務區域訊號),並包含語音捕捉與內部連結工作流程,以及九段式城市頁面結構與可程式化門檻,確保每個城市和服務區域頁面(無論手寫或生成)都符合此標準。非本地內容(一般指南、全國/全球主題)請跳過此技能,僅使用 non-commodity-content。

local-eeat 是什麼?

此技能是專為本地服務業者(如婚禮 DJ、RV 租賃等)設計的本地 E-E-A-T 內容標準擴充套件。它並非取代,而是疊加在 `non-commodity-content` 技能之上,為本地頁面增添地理特定性、第一手經驗證明與服務區域訊號。支援平台涵蓋所有需撰寫本地內容的網站,並適用於 Claude Code、Cursor、Codex 等 AI 代理人環境。其運作方式包括:要求內容必須包含具名場地、當地事件、原創在地照片等元素;提供九段式城市頁面結構,從標題、摘要、實際城市描述到真實行車路線與本地組織提及,並設有可程式化門檻以避免重複內容被視為門頁(doorway pages)。此外,技能還包含語音捕捉流程(確保文字聽起來像當地業主)、內部連結至現有群集(如場地頁面)及圖像處理原則(優先使用原創照片)。最終透過發布前檢查清單(七項)與交付核對清單,確保每篇本地內容皆為非商品化且具備高度專業性與真實性。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/popnetmedia/claude-seo-skills/tree/main/local-eeat

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

在你喜歡的 AI 中提問

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

說明文件

在地 E-E-A-T 內容標準

與 non-commodity-content 的關係

此技能是在地擴充套件,而非取代品。non-commodity-content 技能是品質門檻(獨特 + 具體 + 真實,五項提問檢查)。此技能則在其上疊加在地層級。任何在地頁面或貼文都必須同時執行兩者。

當此技能與舊版 SEO 指南衝突時,以 non-commodity-content 為準:

  1. 標題:請勿預設使用通用的提問式 H1。 舊版指南(以及一般部落格寫作技能)鼓吹「將 H1 設為使用者輸入的提問」(例如「在亨茨維爾請一位婚禮 DJ 要多少錢?」)。根據 non-commodity 標準,獨立存在的通用提問式標題屬於商品化內容。請改為使用具體的在地實例:

    • 商品化:「在亨茨維爾請一位婚禮 DJ 要多少錢?」
    • 非商品化:「我們去年六月在 The Ledges 為一場 180 位賓客的婚禮收費多少,以及為什麼」 唯有當內文提供第一手在地證明時,提問式標題才可接受。
  2. FAQ Schema 並非 AI 引用的槓桿。 在 FAQ 區塊確實能幫助讀者時保留它們,並套用 FAQPage Schema 以獲得豐富結果,但不要將 FAQ 區塊或「剛好 5 個 FAQ」視為獲得 AI 引用的關鍵。獲得引用的是第一手的在地特定性。(依據 Google 的 AI 最佳化指南。)

在地非商品化門檻

一個在地頁面只有在同城市的競爭者無法僅靠公開來源寫出的情況下才算通過。證明他們做不到了理由:你親身在場。

每一篇在地內容必須包含至少一項下列元素,且必須是原創而非改寫自他處:

  • 一個你實際工作過的具名場地或地點,並帶有只有在場者才知道的具體細節(「伯里頓山上的婚禮草坪在五月大約六點半時,陽光會消失在樹線後方,所以我們把第一支舞提前了」)。
  • 一個具名的在地活動或日期(「2025 年六月在 The Ledges 舉辦的 180 位賓客招待會」)。
  • 一張原創的現場照片:實際場地、你的實際佈置。不允許使用圖庫或場地本身的宣傳照。
  • 一個真實的在地客戶故事或引言,需註明來源與日期。
  • 一個特定於該區域的後勤/地理細節(Stovehouse 的裝卸貨方式、Stonehaven 的停車場、麥迪遜的噪音管制時間、從店面到迪凱特場地的車程時間)。

不落入商品化陷阱的地理特定性

  • 指名具體的地點,而不只是城市。「卡爾曼的 Stone Bridge Farms」優於「亨茨維爾附近的場地」。
  • 使用真實的在地實體:社區、地標、場地、季節、當地活動。這些是搜尋引擎和 AI 將你與所在地連結的實體訊號。
  • 當與真實案例相關時,將地點放在標題中,而不是作為事後加上的關鍵字。「……在 The Roundhouse」而不是「……在阿拉巴馬州亨茨維爾 | 最佳 DJ」。
  • 每個頁面一個主要城市/區域。不要為每個城鎮產生近乎重複的頁面(這是規模化內容濫用的垃圾郵件,請參閱 non-commodity-content)。真正不同的服務區域頁面需要真正不同的第一手內容。

城市頁面結構(適用於程式化產生的「[服務] 在 [城市]」頁面,每個網站都應遵守)

每個城市、鄉鎮和服務區域頁面(無論手寫或產生)的形狀。從上到下共九個部分。

  1. 標題:以關鍵字位置放置「服務 + 城市」。 租用RV 在坦帕 | <好處> | <品牌>,仍遵循「關鍵字 | 好處 | 品牌」的標題公式,60 字元以內。使用搜尋者的慣用名詞,而非業界術語。
  2. 頂端的項目符號摘要:說明何種服務、在何處提供、費用為何。這是區塊回答引擎會提取的內容。價格遵循 ai-search-readiness 行動 1:一個包含上下限的範圍、影響價格的因素以及測量日期,並在建置時從來源讀取。絕不能只是一個「起價」數字。若未發布價格,摘要應說明此事並指出獲取報價的管道。
  3. 寫關於實際的城市。 該頁面必須同時證明對服務的專業知識以及對該地方的了解,使用上方定義的「在地非商品化門檻」。內容需包含該城市特有、且網站上其他頁面未提及的事物。
  4. 真實的行車路線:從一個知名地標到服務發生地點(店面、公園、場地)的實際路線,沿途需指出道路和地標名稱。每條道路和地標都必須對照地圖確認,不可憑空捏造(僅在該地確實有一家 Home Depot 時才能說「在 Home Depot 附近」)。沒有公開地址的服務區域企業,應提供前往工作地點的路線,絕不能提供住家地址。若沒有任何真實地點可導航,則省略此部分。
  5. 刪除所有不相關的內容:使命宣言、創業故事和通用範例文字。每個區塊都必須關於「此城市中的此服務」,否則就刪除。
  6. 以搜尋者用語撰寫的城市 FAQ,例如「在坦帕月租 RV 要多少錢?」。從真實的客戶問題中提取(ai-search-readiness 行動 3),每個問題從來源回答,並將其標記為 FAQPage。僅將城市名稱替換而使用相同五個問題的模式,是此技能禁止的樣板化模式。
  7. 指名真實的在地組織:商會、曾使用的供應商、贊助的隊伍、合作過的公園或場地。僅限於實際存在的關係。絕不能暗示企業持有其未實際擁有的會員資格、贊助或合作關係,並在提及擁有的企業時揭露所有權。
  8. 聯絡表單與社交證明放在同一頁面。 僅限真實的評論和推薦,需註明來源、日期並連結至原始出處。沒有連結來源,就不能使用 aggregateRating。若沒有真實評論,則不應有評論區塊;絕不能編寫佔位符或偽造評論。
  9. 將反向連結指向此頁面,而非僅指向首頁。引用和獲得的連結應指向其所描述的特定城市頁面,錨點文字主要使用品牌名稱或原始網址,並謹慎使用完全比對詞。

可程式化門檻。 產生的城市頁面只有在資料通過網站設定的最低門檻時才會發布:包含真實的在地實體,以及該網站上其他城市頁面未提及的、該城市特有的內容。例如,一個公園目錄可能要求每個城市有三個經過驗證的公園。若低於門檻,則不產生該 URL:設為 dynamicParams = false,排除在 Sitemap 之外,並重新導向至最接近的真實頁面。根據 Google 的垃圾郵件政策,僅替換城市名的近乎重複頁面屬於門頁。其中任何一個都可能導致整個網站受到處罰。

服務區域與實體一致性(網站層級,發布前檢查)

  • NAP 一致性:商家名稱、地址/服務區域和電話號碼在整個網站、頁尾、結構化資料和 Google 我的商家上必須完全一致。
  • 服務區域誠實:說明實際區域(根據專案統計資料為「僅限本地區域」)。不要暗示你涵蓋了你實際上未提供服務的城市。
  • LocalBusiness / Organization 結構化資料攜帶一致的 NAP,並連結至經過驗證的 GBP 和社交媒體檔案。一次性設定,每個頁面皆須強化。

語音捕捉(在起草在地貼文之前)

在地內容聽起來必須像實際在場的經營者所寫,而不是通用的 AI 內容。在起草之前,透過以下方式捕捉語音:

  • 範例:研究現有網站文案/過往貼文:句子節奏、正式程度、使用第一人稱「我」還是團隊「我們」、反覆出現的用語、他們避免使用的詞彙。用一句話總結你的發現並確認。
  • 快速訪談(若無範例):最多 4 個問題:他們如何與客戶交談、使用第一人稱還是「我們」、他們絕對不想聽起來像什麼、用他們自己的話用一句話說明為什麼這個主題很重要。

除非另有指示,否則預設使用網站文案中既定的品牌語調。

內部連結至現有群集(工作流程步驟,而非事後才想到)

大多數在地網站已經有群集:場地或地點頁面、位置頁面(/locations/[slug])和服務頁面。每篇在地貼文都必須與它們建立連結。

  1. 在起草之前,找出 3-5 個相關的現有頁面(提到的場地頁面、該城市的所在地頁面、相關的服務頁面)。
  2. 在內文中融入 3-5 個上下文相關的連結,使用描述性的錨點文字(場地名稱、服務名稱),絕不使用「按此處」,也絕不重複使用完全比對詞。
  3. 加入一個簡短的「相關」區塊,連結至同一個群集。
  4. 如果一篇貼文提到了某個場地,但網站上沒有該場地的頁面,則此缺口是一個建立訊號:標記建立一個新的場地頁面(根據 non-commodity-content 中的內容飛輪規則)。

圖像(特別針對在地篇章)

根據 non-commodity-content,每篇內容在規劃階段就應解決圖像問題。對於在地內容:

  • 優先使用原創現場照片(真實場地、真實佈置)。
  • 檔案名稱和替代文字需自然地包含場地 + 城市(360-photo-booth-the-ledges-huntsville.jpg,alt:「在亨茨維爾 The Ledges 的庭院中設置的 360 度拍照亭」)。
  • 如果以程式方式產生圖像,場地/設定必須合理,且不得誤導他人,讓人以為是你拍攝了某個真實的具名場地而實際上你並未拍攝。如果你無法展示真實地點,就不要暗示你做到了。

發布前在地檢查(除了 non-commodity 的五項提問檢查之外)

每個答案都必須是「是」:

  • 內容是否提及了一個與實際工作相關的特定在地場地、活動或地點?
  • 是否有該城市競爭者無法偽造的第一手在地證明?
  • 貼文:標題是否指明了一個特定的在地實例(而非通用的「城市 + 關鍵字」)? 城市頁面:標題是否依照城市頁面結構設定為「服務 + 城市」,且特定的在地實例包含在內文中?
  • 城市頁面:九個結構部分是否全部存在,或者誠實地省略(沒有真實路線就不提供路線,沒有真實評論就沒有評論區塊),且頁面是否通過了可程式化門檻?
  • 是否已連結至現有的場地 / 位置 / 服務群集?
  • NAP / 服務區域是否與網站其他部分及 Google 我的商家一致?
  • 圖像是否為原創或誠實,且檔案名稱和替代文字中是否包含場地 + 城市?

如果有任何一項為「否」,則屬於商品化在地內容。發布前需要重新修改。

發布者 / 交接核對清單(附加於每個在地交付物)

  • 設定 SEO 標題(關鍵字優先,包含所在地)和 Meta 描述(130-150 字元)。
  • 確認 LocalBusiness/Organization 結構化資料的 NAP 一致;僅在存在 FAQ 區塊且確實能幫助讀者時才使用 FAQPage 結構化資料。
  • 加入「最後更新:[月份 年份]」。
  • 取得現場照片;提供指定的替代文字和檔案名稱。
  • 確認內部群集連結都能正常運作。
  • 設定 6-12 個月的更新提醒:更新場地/價格/統計資料、確認連結、更新日期。

Individual skills in this repo

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

相關技能