用 Claude Code 做 SEO：全站健檢到內鏈自動化
Claude Code 是終端機裡的代理型 SEO 助手，能讀寫整個專案、執行指令、用 CLAUDE.md 記住規則，把技術性審計、主題叢集、內容品管與內部連結工程收斂成一條可重現、可審核的流程，採 API 用量計費，需自行控管批次成本。
作者：褚崇名（Sliven）
想像一下這個畫面：你開了一個新專案資料夾，丟進去一份關鍵字清單、一份競品網址、一份你過去三年寫過的所有文章索引。然後你對著終端機說一句「幫我把這個月要產的十篇文章排好、內鏈補齊、技術性問題掃一遍，產線跑完把報表給我」，轉身去泡咖啡。回來的時候，它真的做完了，而且每一步都附上它讀過哪些檔案、改了哪幾行、為什麼這樣判斷。
這不是單靠聊天視窗就能完成的工作。Claude Code 能在授權範圍內讀寫專案、執行指令與串接工具，適合把重複的 SEO 檢查整理成可執行流程。這篇談的是怎麼把它放進 SEO 工作流，而不是再列一份提示詞模板。
如果你只想記住一句話：Claude Code 真正的價值，是幫你把「分散在十個工具、二十個分頁裡的 SEO 工作」收斂成一條可重現、可審核、可擴充的流程，至於幫你寫更多內容，只是它最表面的那層能力。它最危險的用法，剛好也是最多人想拿它做的事：用它一口氣量產沒有第一手經驗的文章。我會在後面解釋為什麼這是自毀長城。
本篇精華：用 Claude Code 做 SEO 的 5 個核心判斷
- 它的殺手鐧是「能動你的檔案與指令」，這件事比「聊天品質比別家好」更關鍵。把它用在你本來就需要寫腳本、跑批次、跨檔案比對的場景。
- 把專案規則寫進 CLAUDE.md，等於給它一份長期記憶，它不會每次都把你的品牌語氣、內鏈規則、禁用詞忘掉。
- 技術性 SEO 審計是它最立即見效的戰場：broken link、缺 canonical、重複 title、結構化資料缺口，全部可以批次掃。
- 內容產線一定要配品質閘道（gate），用來擋 AI 量產文與來源不明的引用，否則你只是在加速製造垃圾。
- 它補不上的是 Experience。第一手經驗、真實數據、你對產業的判斷，這些才是 AI 代理拿不走的護城河。
先說明內容範圍。如果還沒用過 Claude Code，建議先讀Claude Code 是什麼，理解安裝與基本概念；如果想知道它跟 Claude.ai 網頁版的差別，可以搭配Claude AI 完整使用指南一起看。以下不重複入門，直接進入「怎麼把它放進 SEO 工作流程」。如果連 Cowork 也列入候選，可以先看Claude、Claude Code 與 Cowork 各自適合的工作，再決定從哪個介面開始。
Claude Code 與一般聊天介面的工作方式不同
很多人第一次聽到「用 AI 做 SEO」，腦袋浮現的畫面是：開一個聊天視窗，貼一段 prompt，AI 吐一篇文章或一份關鍵字建議出來。這個心智模型，會讓你完全用錯 Claude Code。
聊天介面的本質是「你問一句、它答一句，答完就忘」。它沒有檔案系統、沒有長期記憶、不能跑指令、不能改你硬碟裡的東西。所以你用它做 SEO 的時候，會陷入一種很累的迴圈：複製貼上、人工搬移、手動比對、手動檢查。它給你靈感，但所有落地動作都還是你自己做。換句話說，它放大的是「產出文字」的能力，而不是「執行工作流」的能力。前者讓你寫得快，後者才讓你做得對。SEO 工作流真正缺的，向來是後者。
Claude Code 走的是完全不同的路。它是一個跑在你終端機裡的代理（agent），原生具備三個聊天機器人沒有的能力：它能讀寫你本機的檔案、它能執行 shell 指令、它能透過一個叫做 CLAUDE.md 的專案檔案把規則長期記住。這三個能力疊起來，意思是它可以「真的去動你的專案」，不只給你一段文字叫你自己去動。
我用一個對比來講清楚差別。假設你想找出網站裡所有「指向已刪除頁面」的內部連結。用聊天機器人，你得先自己爬出一份網站地圖、自己匯出所有文章、貼進去問它，然後它可能還會算錯。用 Claude Code，你只要下一句「掃整個 content 目錄，列出所有 href 指向不存在檔案的內部連結，輸出成 csv」，它會自己 grep、自己比對、自己產檔。前者是顧問，後者是員工。SEO 工作流要的是員工。
| 維度 | 聊天型 AI（網頁版） | Claude Code（代理型） |
|---|---|---|
| 存取範圍 | 只有你貼進去的內容 | 整個專案資料夾＋終端機指令 |
| 記憶 | 單次對話，關掉就忘 | CLAUDE.md 長期記住專案規則 |
| 輸出 | 文字建議，落地靠你手動 | 可直接改檔、產檔、跑腳本 |
| 適合的 SEO 工作 | 單篇文章草稿、靈感、翻譯 | 批次審計、內鏈工程、產線品管 |
| 最大的風險 | 產出平庸、沒有經驗的內容 | 放大錯誤：批次做錯就是批次出包 |
這個差異解釋了為什麼我幾乎不再用聊天介面做任何「需要跨檔案、需要重複、需要可審核」的 SEO 工作。那些工作全部搬進 Claude Code 之後，我能把省下來的時間花在它永遠做不到的事：跟客戶深談、看真實數據、做第一手判斷。這也是這整篇文章的底層邏輯：把機器能跑的交給機器，把只有人能做的留給人。
一個能讀寫你整個專案的 SEO 助手，到底改變了什麼
要理解 Claude Code 為什麼能改變 SEO 工作流，得先看它手裡到底有哪些工具。它是一個能跟你專案深度耦合的代理，比一個「更聰明的聊天框」走得深得多。我把它的核心能力拆成三層，每一層都對應到一個 SEO 上本來很痛的問題。
第一層是檔案系統存取。它能讀你專案裡的每一個檔案，也能寫。對 SEO 來說，這代表你的文章清單、關鍵字表、內鏈索引、結構化資料範本、語氣指南，全部都能被它一次讀進來做整體判斷。你不用再把東西複製貼上到聊天框。它看到的是你專案的全貌，不是你挑給它的片段。
第二層是指令執行。它能在你的終端機跑shell 指令，也能跑你寫的 Python 或 Node 腳本。這一層的意義非常大：所有你本來得自己寫爬蟲、自己跑批次、自己匯出報表的工作，現在可以用自然語言驅動。你說「把這份 URL 清單逐一 curl 下來、抽出每頁的 title 跟 h1、比對有沒有重複」，它就會去組出對應的指令鏈並執行。
第三層，也是我認為最被低估的一層，是專案記憶。你可以在專案根目錄放一個 CLAUDE.md 檔案，把所有「這個專案永遠要遵守的規則」寫進去。對 SEO 專案，我會把這些東西寫進去：品牌的語氣規則、禁用的競品詞與 AI 套話、內部連結的錨點慣例、文章一定要有的結構化資料欄位、引用格式。Claude Code 每次啟動都會讀這個檔，於是它不會每次都把你的規則忘掉，也不會每次都重新發明輪子。
換句話說，這三層加起來，等於你僱了一個「記得你家規矩、能翻你家檔案、會操作你家工具」的助手。你給它的不再是「寫一篇關於 X 的文章」這種一次性指令，而是「依照我們家的規矩、用我們家的索引、跑我們家的品管流程，把這批工作做完」。這是從「點工」到「建制」的跳躍。
這個跳躍對 SEO 為什麼特別重要？因為 SEO 本質上是一個高度流程化、高度可重現、卻長期被碎片化工具拖累的工作。你做關鍵字研究，開一個工具；看搜尋意圖，開另一個；寫文章，開編輯器；檢查內鏈，開爬蟲；看排名，開 GSC。每換一個工具，你就得重新搬移脈絡。Claude Code 的價值，是讓這些動作有可能在同一個地方、用同一套記憶、跑同一條流程。它不一定取代每一個專業工具，但它能當那個把所有工具黏起來的膠水。
技術性 SEO 審計：用 Claude Code 執行檢查與品質閘道
如果要我選一個 Claude Code 在 SEO 上「立刻見效、ROI 最高」的應用，我會毫不猶豫選技術性審計。原因很實際：技術性 SEO 問題通常是批次性的、可程式化的、跨檔案的，正好是它最擅長的那類工作。而且這類問題往往藏在幾百幾千個檔案裡，人工根本掃不完，於是大家就放著不管，直到流量掉了才回來找。
先講為什麼技術性 SEO 值得你投資心力。Backlinko 分析了一千一百八十萬個 Google 搜尋結果（2025 年 4 月），發現排名前面的頁面有幾個共同特徵：技術基礎健康、內容深度夠、反向連結強。技術性問題不會直接把你推到第一名，但它會像漏水一樣，把你其他努力慢慢吃掉。一個被 noindex 封掉的分類頁、一條指向 404 的內部連結、一組重複的 title，每一個都是小小的排名漏損。你可以把這些當小事，但它們疊起來就是「為什麼我內容寫得比別人好，排名卻上不去」的常見答案。
那 Claude Code 具體能掃哪些東西？我把常用的審計任務列成一張表，每一項都是我自己實際跑過的：
| 審計任務 | 它實際做的事 | 對應的 SEO 風險 |
|---|---|---|
| 失效內部連結 | grep 所有 href，比對實際存在的檔案／路由，列出指向不存在目標的連結 | 爬蟲預算浪費、使用者體驗下降 |
| 重複或缺失的 title | 抽出每篇文章的 title 標籤，找重複、找過短、找沒設定的 | 關鍵字同類相殘、點閱率下滑 |
| 缺 canonical | 檢查每個頁面是否有 canonical 標籤、是否指向正確的自己 | 重複內容、版本稀釋 |
| 結構化資料缺口 | 比對頁面類型、可見內容與適用的 Schema.org 型別，找出缺漏或錯誤 | 可能失去適用搜尋外觀的資格；Article 沒有必填屬性，應優先補官方建議且真實可見的內容 |
| heading 層級錯亂 | 檢查 h1/h2/h3 順序，抓跳級、抓多個 h1、抓全空的 | 語意結構不清、可及性問題 |
| 孤兒頁面 | 比對「所有頁面」與「被任何內部連結指向的頁面」，找出沒有人連過去的 | 連結權重傳遞中斷、爬蟲找不到 |
這裡最特別的地方，是它做這些事的方式。它跑的不是你從 GitHub 抓來、看不懂的黑箱腳本，而是把你用自然語言描述的審計邏輯，現場組成可執行的指令與比對規則，跑完還能把結果整理成你能直接拿去修的清單。你看得懂它做了什麼，也改得了它做事的方法。這對 SEO 這種「方法論比工具更重要」的工作來說，是很大的差別。
我自己跑這類審計的時候，會要求它做一件額外的事：每一個被標出來的問題，都要附上「為什麼這是問題」跟「建議怎麼修」兩欄。這一步跟排版美觀無關。技術性 SEO 的真正價值，是把問題翻譯成開發者能直接動手的規格；光列出一堆警告卻沒有修法，跟沒審計一樣。關於技術性 SEO 的完整體系，建議搭配技術性 SEO 完整指南與Core Web Vitals SEO一起看，那邊講的是「要審計什麼」，這邊講的是「怎麼把審計自動化」。
技術性審計最怕假陽性太多，最後整份報告被丟掉。Claude Code 跑出的清單要先抽樣人工覆核，確認判斷邏輯與標準一致，再跑全量。不要在未驗證規則前批次修正；一旦把建議誤當事實，就可能動到原本正確的頁面。
關鍵字研究與主題叢集：從一次性查詢，升級成可重現的流程
關鍵字研究是 SEO 的地基，但它有一個長期的痛：每次做都像從頭來過。你開個試算表，丟幾個種子詞進工具，匯出一堆建議，挑一挑，寫成文章，然後檔案就塵封了。三個月後要做新一批，你又得重新想種子詞、重新匯出、重新挑，而且這次挑的跟上次挑的有沒有重複、有沒有互相搶排名，你根本沒有系統在追蹤。這正是 Claude Code 能介入的地方：它能把「一次性查詢」變成「一條有記憶、可重現的流程」。
我用的做法是這樣。我把網站現有的關鍵字佈局、已發文章的主題清單、每篇文章鎖定的主要關鍵字，全部整理成結構化檔案（JSON 或 CSV 都行），放進專案裡。這份檔案就是我的「主題地圖」。每次要擴充新內容，我不再是憑感覺想題目，而是讓 Claude Code 拿這份地圖當輸入，問它三個問題：哪些主題我們已經覆蓋但深度不夠、哪些相鄰主題完全空白、哪些新題目跟我們現有文章會造成同類相殘。它讀的是整份地圖，不是你這次貼進去的零散想法，所以它給的建議都站在你「已經有的內容資產」之上，每一步都找得到出處。
這裡的關鍵概念是主題叢集（Topic Cluster）。現代 SEO 早已跨過「一個關鍵字寫一篇文章」的單點遊戲，進入「一個主題寫成一群互相支撐的文章」的權威遊戲。你有一個支柱頁（pillar page）講大主題，下面輻射出十幾篇講子主題的群集內容（cluster content），彼此用內部連結串起來。這個結構讓搜尋引擎讀懂「這個網站在這個主題上是完整的、有系統的」，而不只是「剛好寫過一篇」。Claude Code 能幫你做的，是即時回答「我這個主題的叢集現在長怎樣、缺哪一角、哪幾篇該互連還沒連」這類需要綜觀全局才能回答的問題。
特別要提醒一個它特別擅長抓的東西：關鍵字同類相殘。當你網站上有兩篇文章鎖定的關鍵字太接近，Google 不知道該把哪一篇排上去，結果兩篇都排不好。這在內容一多的網站幾乎必然發生。你讓 Claude Code 拿你所有文章的主要關鍵字做交叉比對，它能立刻標出「這兩篇的搜尋意圖重疊度過高」，然後給你合併、差異化或加 canonical 的建議。這件工作人工做的話，文章超過一百篇就幾乎不可能做得完整，但它跑一輪就給你全圖。關於這個問題的完整解法，可以看關鍵字同類相殘怎麼修。
我自己的經驗是，把關鍵字研究從「事件」變成「流程」之後，最大的收穫不是省時間，而是決策品質變穩。以前決定寫什麼，憑的是當下靈感跟最近看到的一兩個數字，容易跟著演算法抖動追高殺低。現在我每次決定題目，都站在一份完整的主題地圖上，看得到缺口、看得到重疊、看得到機會成本。這份穩定感，是任何單次查詢的工具給不了的。
內容產線的品質控制：把 E-E-A-T 寫進工作流，而不是寫進祈禱文
這一節是整篇文章我最想講、也最反主流的地方。大多數人聽到「用 Claude Code 做 SEO」，第一個念頭是「太好了，我可以大量產文章了」。我要直接潑一盆冷水：如果你用它來大量產製沒有第一手經驗的內容，你不是在用 AI 加速 SEO，你是在用 AI 加速製造 Google 越來越不想要的東西。
HubSpot 的 2026 行銷報告顯示，AI 已廣泛進入內容產線。當團隊沿用相似的 prompt 結構與模板，產出容易出現同質化；真正的使用經驗、限制與判斷仍要由作者提供。E-E-A-T 是 Google 用來說明內容品質評估的重要概念，但不是可以單獨計算的排名分數。
所以 Claude Code 在內容產線裡，最值錢的角色不是「寫手」，而是「品管」。我用它做的，是把 E-E-A-T 從「寫文章時憑良心」變成「跑流程時被強制」。具體做法是：在 CLAUDE.md 裡寫死一份品質閘道清單，每一篇文章產出後，都必須通過這些檢查才能算完成。我把自己的閘道列出來給你參考：
- 來源可查核：任何數字、統計、研究結論，必須附上可點擊的公開來源，找不到來源的數字直接刪掉，不准用「根據國外研究」這種含糊說詞。
- 第一手痕跡：文章裡至少要有一處只有「真的做過這件事的人」才寫得出來的細節，可以是具體產業的操作觀察、一個非通用的判斷、一個小眾的踩坑。
- AI 套話清零：刪除模板化連接詞與制式收尾；判斷重點是語句是否僵硬重複，而不是機械式封鎖單一詞彙。
- 結構去模板化：每篇文章的 H2 數量、順序、子論點，不准跟上一篇雷同，避免整站讀起來像同一個模子刻的。
- 語氣一致性：用我自己的語氣資料庫當參考，偏離過多就退回重寫。
這套閘道真正的力量，在於它把品質標準固化成流程的一部分。以前品質靠人盯、靠靈感、靠當天心情，現在品質靠一條每次都會跑的檢查清單。你不用再祈禱寫手今天有良心，因為良心已經被寫進 gate 裡了。這是我認為 Claude Code 對內容產線最大的貢獻：它讓「堅持品質」從意志力問題，變成工程問題。
但我要誠實講它的極限。它能擋掉沒有來源的數字、能抓出 AI 套話、能強制結構多樣化，但它製造不出經驗。它不知道你上週跟客戶開會時客戶說了什麼、不知道你三年前那個專案到底卡在哪、不知道那個產業裡只有做過的人才會注意的眉角。這些東西只能你給。所以我的內容產線裡，Claude Code 負責骨架、負責品管、負責把我的經驗翻譯成結構化的文字，但每一篇文章裡那塊「只有我寫得出來」的肉，必須是我親自餵進去的。關於 E-E-A-T 怎麼在 AI 時代當成護城河來經營，E-E-A-T 完整指南有更系統的展開。
內部連結與內容地圖：讓 Claude Code 維護你網站的知識圖譜
內部連結大概是 SEO 裡最被低估、也最被怠忽的一塊。大家花一堆力氣衝外部反向連結，卻忘了網站內部那幾百條「自己能完全控制」的連結，根本沒接好。內部連結做對了，它能傳遞權重、能幫搜尋引擎理解頁面之間的關係、能引導使用者深入閱讀、能讓主題叢集的結構真正發揮作用。做錯了或沒做，等於你有一座圖書館，書都買齊了，卻沒有索引卡也沒有走道。
內部連結之所以長期被怠忽，原因是它太適合「每寫一篇就手動想一下要連去哪」這種臨場操作，也太容易在文章一多之後變成一團沒人管得動的線。你記不得三個月前那篇文章連過哪裡，也記不得現在這篇新文章到底該回連哪些舊文。於是大多數網站的內部連結結構，是隨機長出來的，不是設計出來的。
這正是 Claude Code 能接管的地方。我把網站的內容索引（每篇文章的 slug、標題、主題、主要關鍵字）整理成一份機器可讀的檔案，讓它把這份索引當成「內容地圖」。每次有新文章要上線，我做的是請它回答：「依據這份地圖，這篇新文章主題上跟哪些舊文最相關、應該雙向建立哪些內部連結、有沒有該連卻一直沒連的缺口。」它給的建議來自整份索引的系統性比對，背後有整份地圖撐著，不靠印象。
這個做法的好處會隨時間複利。每多一篇文章，你的內容地圖就更完整，它給的連結建議就更精準。而且因為每次建議都來自同一份地圖，你不會出現「A 連到 B，但 B 從來沒連回 A」這種單向斷層，也不會出現同一條連結在十篇文章裡重複出現到變成垃圾的問題。關於內部連結該怎麼從架構層面規劃，網站架構與 SEO講的是藍圖，這邊講的是怎麼讓藍圖被持續執行。
我也會讓它定期做一件「健康檢查」：把整個網站的內部連結結構跑一次分析，產出三份報表。第一份是「孤兒頁」，也就是沒有任何內部連結指向的頁面，這些頁面等於在你的網站裡失聯。第二份是「過度集中」，也就是被太多頁面連過去的單一頁面，這可能是重要的支柱頁（好事），也可能是某個被誤連的反覆目標（要清）。第三份是「錨點文字分布」，看你某個重要頁面被連過去的時候，錨點文字是不是太單一，還是有足夠的自然多樣性。這三份報表，人工做的話是幾天的工作量，它跑一輪就給你。
串接真實數據：用 MCP 把 Google Search Console 與 WordPress 接進來
到目前為止講的，大多是 Claude Code 操作本機檔案的能力。但 SEO 工作裡有很多關鍵資料在外部服務：搜尋曝光與點擊在 Google Search Console、文章在 WordPress 後台、反向連結則可能來自第三方資料供應商。透過可信任的 MCP server 或 API 串接後，才能在授權範圍內把這些資料放進同一條流程。
MCP（Model Context Protocol，模型脈絡協定）提供 AI 應用連接外部資料與工具的共通介面。若另行安裝可信任的 MCP Server、完成 Google Search Console、WordPress 或分析服務授權，並限制可用工具與權限，Claude Code 才能在核准範圍內查詢或操作；MCP 本身不會自動取得任何帳戶資料。
這個升級對 SEO 工作流的意義是什麼？我用一個具體場景說明。假設我想知道「過去三個月，哪些文章的曝光在成長、哪些在衰退，衰退的那些是不是因為被某個新主題搶走了排名」。在沒有 MCP 的時代，我得登入 GSC、設定篩選、匯出兩份報表、貼進試算表、樞紐分析、然後肉眼比對，做完可能半天過去了。接上 MCP 之後，我用一句自然語言描述這個需求，它就會去組對應的查詢、拉資料、做比對、回來給我一份有判斷的摘要。我花的時間從半天變成十分鐘，而且因為它能反覆跑，我會更願意每週都看一次，把檢視頻率從每季拉到每週。
跟 WordPress 的串接也很有價值。你的文章、分類、標籤、自訂欄位、結構化資料，全部住在 WordPress 資料庫裡。透過 MCP，Claude Code 可以直接讀寫這些東西，於是前面講的那些審計、內鏈工程、內容品管，都可以直接在你的真實 CMS 上操作，省去在離線副本做完再手動同步回去的麻煩。如果你是用 WordPress 架站，強烈建議把Claude Code 搭配 WordPress 的 MCP 實戰讀過，那篇講的是具體怎麼接、接了能做什麼。
這裡我要誠實標一個風險：MCP 等於是把 AI 代理的「手」伸進你真實的、有資料的、可能對外的系統裡。它不再是改你本機一個檔案這麼單純，它可能真的去發布一篇文、改掉一個 canonical、刪掉一個分類。所以我的鐵律是：所有透過 MCP 對生產環境的「寫入」動作，一律先開成草稿或預覽模式，由我人工看過再放行。讀取可以放手，寫入一定要過一道人眼。這不是不信任工具，這是對「批次錯誤」的基本敬畏。一批文章同時上錯，比一篇手動上錯，修起來痛太多了。如果你還想把它接上更多資料源，Claude Code Plugins 指南跟Claude Skills 指南會是下一步的擴充路線。
五個會讓你流血的地雷
工具越強，出錯的規模越大。Claude Code 在 SEO 上用錯方向，後果會比「沒效果」嚴重得多，它會主動傷害你的網站。我把看過、踩過、幫別人收拾過的地雷整理成五條，每一條都是我用真實代價換來的判斷。
第一個地雷：用它大量產製沒有經驗的內容。這是最常見、也最致命的誤用。模型越強、產線越順，你越會忍不住「既然能一天產十篇，那就產十篇」。但 Google 在 AI 時代抓的就是「量大但沒有經驗」的內容。你用 Claude Code 把產量放大十倍，等於把「被演算法判定為低價值內容」的風險也放大十倍。正確的用法是讓它放大你「品質控管」的能力；量是自然發生的結果，不要把它當成目標來追。
第二個地雷：放任它產生看不出處的引用。AI 模型有一個眾所皆知的毛病：它會「自信地編造」看起來很像真的、但其實不存在的來源。一個研究名稱、一個統計數字、一個專家姓名，它都可能憑空生得出來。如果你沒有用前面講的那道「來源可查核」閘道擋住，這些假引用就會上線，而它們一旦被讀者或競品抓到，你的可信度就崩了。SEO 是長期資產，可信度是地基，地基崩了一次，要花很久才能重建。所有數字與引用，上線前一定要回到原始來源核對一遍。
第三個地雷：把它用在黑帽自動化上。批次產製門戶頁（doorway pages）、自動生成一堆只為塞關鍵字的頁面、用程式化方式製造假外部連結，這些事 Claude Code 技術上做得到，而且因為它太方便，你會覺得「反正跑個腳本就好」。請把這條念三遍：黑帽在 AI 時代變得更危險，沒有變安全。因為以前黑帽還需要技術門檻，現在門檻被 AI 拆掉，大家都做得到，Google 的反制只會更狠、更自動化。一次手動犯規可能只波及幾頁，一次批次犯規可能讓整站被降權。關於黑帽為什麼是死路，黑帽 SEO 指南有完整的風險拆解。
第四個地雷：成本失控。Claude Code 跑起來是真的會燒錢的，尤其是當你讓它跑大批次的審計、或反覆重寫整批文章的時候。它每一個動作都在消耗 token，而你一旦把它設定成「自動跑到完成為止」，它可能在某個卡住的迴圈裡燒掉你預期十倍的費用。我的做法是：大批次任務一律先在小樣本上跑通、確認邏輯沒問題，再放全量；而且設定明確的「單次任務上限」，超過就停下來問我，不准自己無限重試。把它當成一個會不知不覺加班還報加班費的員工，你要主動設作息。
第五個地雷：把它當萬能的，忽略它的判斷盲點。Claude Code 很會「執行」，但它的「判斷」有明確的邊界。它不知道你這個產業的搜尋者真正在意什麼、不知道某個關鍵字的搜尋意圖在過去一年怎麼漂移、不知道你這篇文章的目標讀者跟另一篇其實不是同一群人。它給的建議，技術上常常是對的，但商業上可能是錯的。所以它產出的一切，特別是涉及「優先順序」與「策略取捨」的判斷，都要你這個懂產業的人最後拍板。它是超強的執行者，策略方向永遠是你握著方向盤。如果你還想知道常見的 SEO 策略錯誤有哪些，常見 SEO 錯誤是很好的對照清單。
現在就能跑起來的一套 Claude Code SEO 工作流
講了這麼多概念，我把它收斂成一套你今天就能照著跑的工作流。這不是理論，是我自己每天在用的順序。你可以先照抄，跑順了再依自己的專案調整。
- 把專案規則寫進 CLAUDE.md。把你網站的語氣規則、禁用詞清單、內部連結慣例、引用格式、結構化資料需求，全部寫進專案根目錄的 CLAUDE.md。這一步是地基，沒做，後面每一步都會打折。
- 整理一份機器可讀的內容地圖。把你所有已發文章的 slug、標題、主題、主要關鍵字、分類，整理成 JSON 或 CSV。這份地圖是後面所有判斷的輸入，越完整越有用。
- 先跑一次技術性審計。讓它掃整個專案，產出失效連結、重複 title、缺 canonical、結構化資料缺口、孤兒頁面的清單。抽樣覆核前幾項確認邏輯沒偏，再放手讓它修。
- 用內容地圖找主題缺口。讓它比對地圖，標出哪些主題已覆蓋但深度不足、哪些相鄰主題空白、哪些新題目會跟舊文同類相殘。把這份清單當成你下一季的內容計畫骨架。
- 建立內容品管閘道。在 CLAUDE.md 裡寫死品質檢查清單：來源可查核、第一手痕跡、AI 套話清零、結構去模板化、語氣一致。每一篇文章產出後都跑一遍才准上線。
- 接上 MCP 拉真實數據。把 Google Search Console 接進來，讓它每週幫你跑一次「曝光成長與衰退」的摘要。寫入動作一律先開草稿，過你人工這關再放行。
- 定期做內部連結健康檢查。每月跑一次孤兒頁、過度集中、錨點分布的三份報表，把該補的連結補上、該清的集中清掉。
這套流程的重點，在於這些步驟串起來形成一個有記憶的迴圈。你的內容地圖會越來越完整，品管閘道會越調越準，內部連結結構會越來越密實，而每一輪跑下來的判斷都會沉澱回 CLAUDE.md，讓下一輪起點更高。這才是把 Claude Code 用在 SEO 上真正的長期紅利：你不是在用一個工具，你是在養一套會越用越準的系統。
我也明白，這套流程一開始要投入不少設定心力，不是把 prompt 貼一貼就能見效的那種輕鬆。但 SEO 本來就不是一個「輕鬆就能贏」的賽局。它是一個長期的、複利的、獎勵系統化思考的賽局。你想清楚要的是一時的產量爆發，還是長期的資產累積，這個選擇會決定你到底該怎麼用這個工具。
我自己是把這個工具定位得很清楚：它是我的執行力放大器，不是我的判斷替代品。它幫我把那些本來會卡住我產能的機械性工作接走，讓我把省下來的精力，集中投資在它永遠做不到的事上，去跟真實的客戶深談、去看第一手的數據、去形成只有我能下的判斷。在 SEO 這一行，能把機械性產能交給機器、把判斷與第一手經驗留給自己的人，才走得長遠；這條分工線畫得越清楚，你的內容資產越不容易被複製。
如果你看完這篇，想先把 Claude Code 本身搞熟，從Claude Code 入門開始；想看它怎麼用在架站與內容工程，搭著用 Claude Code 架站實戰；想把 SEO 的全貌補齊，SEO 完整指南跟AI 搜尋時代的 SEO 全攻略是兩條主幹。工具會換、模型會更新，但「為真人寫作、為機器人優化、用系統把對的事重複做」這個核心，是不會變的。願你把這套工作流跑成屬於自己的節奏。