用 Grok 做 SEO，能直接上手的工作是：把 Search Console 匯出的查詢資料交給它分群與判讀、讓它讀既有文章找缺口並改寫、把爬蟲與伺服器資料丟給它比對技術問題。數字一律來自資料源，模型做的是分群、判讀與改寫。Grok SEO 的另一面，是讓 Grok 在回答別人問題時引用你的內容，兩種工作都會展開。
模型版本與方案的細節，站上的 Grok 完整介紹 講得更全；搜尋與 AI 的大框架，看 AI SEO 總覽 就好。
重點先看
差異軸是資料面與工作形態：Grok 搜尋時能讀 X 即時公開貼文，還有一層可排程的代理；跟 ChatGPT、Claude 是分工關係，不是排名。
關鍵字研究的分工：Search Console 出自家實績，Grok 做分群與判讀，市場搜尋量從 Keyword Planner 或 Ahrefs、Semrush 拿。
技術稽核可以交辦，結果分三級用：Confirmed 直接修，Possible 複查，Needs live verification 回 Search Console 或線上工具驗證。
讓 Grok 引用你的網站：通用可引用結構做得動，檢索與排序是黑箱，xAI 對此沒有官方說明。
費用三層：免費版跑得通研究與稽核的對話流程，訂閱買用量與代理，API 按 tokens 加工具呼叫計費。
今晚花 30 分鐘：匯出 GSC 查詢資料，跑一輪分群提示詞。週末花兩小時：Screaming Frog 免費版爬站，跑一輪稽核提示詞，拿第一份三級清單。
Grok 跟 ChatGPT、Claude 做 SEO，差別在哪裡？
差別在資料面與工作形態，不在能力排名。Grok 多了兩樣東西：搜尋時能讀 X 的即時公開貼文，以及從代理搜尋到雲端代理的一整層自動化。已經在用 ChatGPT 或 Claude 做 SEO 的人不需要換掉既有流程，三個模型讀得懂同樣的資料，實務上是並用；站上的 ChatGPT SEO 完整作法 與 Claude SEO 姊妹文 講的就是那兩條線。
並用的樣子具體是這樣：改寫與結構整理丟給你最順手的那個模型，需要 X 即時討論與真實問句的段落交給 Grok，每週固定要跑的稽核交給 Grok 的代理層。假設你要寫一篇工具比較文，爭議規格的查證可以開 DeepSearch 讓它自己搜自己對照，使用者的真實抱怨從 X 討論串挖，行文與潤稿交回你慣用的模型。工作拆得開，就沒有誰取代誰的問題。
資料面：即時 web 搜尋加 X 公開貼文
Grok 4.6 的知識截止日是 2026 年 2 月 1 日。xAI 的模型頁 寫明：模型對訓練資料之後的事沒有即時知識，要碰即時資料就開 server-side search tools。產品頁 對搜尋的描述是 web 加 X 即時搜尋，答案反映現在發生的事，引註來自一手來源。X 的說明中心再補一句：Grok 自己決定要不要搜 X 公開貼文、要不要做即時 web 搜尋，X 即時公開貼文是它獨家的資料面。
Introducing Grok 4.6.
— SpaceXAI (@SpaceXAI) August 12, 2026
It delivers frontier intelligence and is a significant improvement over Grok 4.5 at the same price. pic.twitter.com/RtTbpXcb3a
對 SEO 工作，這個資料面多給了幾樣原料：查演算法傳聞的當下討論、看真實使用者怎麼問問題、追一個新詞在 X 上的實際用法。搜尋量資料庫記錄的是已經發生的查詢，X 給的是正在形成的說法，兩者本來就不該互相替代。
用即時搜尋有個習慣要養成：回報裡的每個關鍵事實都點開引註看一眼。Grok 的引註標榜來自一手來源，但模型仍可能把兩個來源的說法接錯，引註核對這一步不能省，省了就是把查證工作交回給運氣。
從代理搜尋到多代理的工作形態
DeepSearch 是代理式搜尋，2025 年 2 月 20 日隨 Grok 3 推出時的官方定義是：快速綜合關鍵資訊、對相互衝突的事實與觀點推理、再從一團複雜的資料裡理出可用的結論。DeeperSearch 是它更深的變體，多次來回、更深的來源遍歷、更長的綜合階段；這一層只有第三方描述，xAI 沒有定義頁，用功能差異理解就夠。
產品頁還有多代理模式，多個代理並聯回答難題、每個代理顯示過程供檢查，這個能力與更高速率掛在 SuperGrok 方案層級。
實際用在 SEO 上，代理搜尋的價值是查證型工作：丟一個爭議說法給它，它自己搜、自己對照來源再回報。你仍然要看引註，但省掉的是自己開十幾個分頁交叉讀的時間。難題用多代理模式，幾個代理各查一個子問題、過程攤開給你檢查，比單次問答可靠，代價是時間與用量。
七種工具誰出數字、誰做關係
數字與判斷要拆開看。Ahrefs 在 2026 年 4 月 30 日更新的部落格說得最直接：沒接關鍵字資料庫的 LLM，自己生成的搜尋量、難度、SERP 數字都是虛構，模型是從你的資料工作，不是從活的資料庫工作。同一篇也給了出路：透過 MCP 接上活的關鍵字資料庫後，這些限制就消失。Ahrefs Keywords Explorer 與 Semrush 的關鍵字研究工具 就是兩個現成的資料庫。把七種工具放進同一張表，誰出數字、誰做關係就清楚了：
| 工具 | 最適合提供 | 拿來做什麼 | 不該單獨承擔 |
|---|---|---|---|
| Search Console | 自家網站的查詢、點擊、曝光、排名 | 查詢分群與衰退頁盤點 | 市場整體需求 |
| Keyword Planner | 市場搜尋量估計與預測 | 關鍵字擴充方向 | 自家網站的實際表現 |
| Ahrefs | 第三方搜尋量、難度、反向連結 | 競爭頁缺口比對 | 自家網站的實際表現 |
| Semrush | 第三方搜尋量與競品資料 | 競品策略整理 | 自家網站的實際表現 |
| Grok | X 即時輿論、真實問句、長文判讀 | 分群、稽核、改寫、排程代跑 | 搜尋量與排名數字的來源 |
| ChatGPT | 文字生成與結構整理 | 改寫、摘要、程式輔助 | 搜尋量與排名數字的來源 |
| Claude | 長文件理解與改寫 | 內容稽核、程式輔助 | 搜尋量與排名數字的來源 |
表裡七個位置不衝突。Search Console 告訴你自己的站發生什麼事，Keyword Planner 與兩個第三方資料庫告訴你市場長什麼樣，三個模型把資料變成判斷。說穿了，三個模型讀得懂同一份 CSV，差別只在誰能多拿一份 X 的即時語料、誰能自己排程跑。
怎麼用 Grok 做關鍵字研究
Grok 關鍵字研究的流程三段：Search Console 匯出真實查詢，Grok 做分群與判讀，需要市場數字時從 Keyword Planner 或第三方資料庫補。分群是關係型工作，不需要資料庫，只需要看得懂你給的資料；搜尋量是資料庫工作，交給資料庫，兩者不要混。
Grok 沒有搜尋量資料庫，數字從哪裡來
這是整條流程的起點。你直接叫模型給某個關鍵字的搜尋量，它會給一個格式正確的數字，但那個數字沒有來源，Ahrefs 給這種輸出的評語就一個詞：fabricated。講白了，跟模型要搜尋量，拿到的是猜測，只是長得像統計。
兩條正路。第一條，把資料餵給它：GSC 匯出的查詢、Keyword Planner 的估計、第三方工具的輸出，模型在這些資料上做分群與判讀。第二條，走 API 把資料庫接上，Ahrefs 那篇提到的 MCP 路線，接上之後模型查的是活的資料庫，數字有來源。多數人第一條就夠，第二條是量起來之後的事。
GSC 匯出前要先處理的細節
GSC 效能報告有四個指標，官方支援頁 的定義是：點擊是使用者從搜尋結果點進你網站的次數，曝光是你的網站出現在搜尋結果的次數，CTR 是點擊除以曝光，平均排名是你網站最上方結果的平均排名。匯出前有幾件事要先處理。
介面匯出上限是 1,000 列，查詢多的站要先縮日期或分批。報表裡顯示 ~ 或 – 的值，下載後會變成 0，這些 0 不是真的零，是沒有數字，分群前要標起來，否則模型會把「無資料」當成「沒人搜」，兩者的處置完全不同。最新的幾天資料是 preliminary，會變動，月初看報表時把最新幾天的數字排除在外；看上個月的完整資料，比看這個月還沒定案的資料安全。
還有一個容易誤判的地方：為保護隱私，兩三個月內沒有超過幾十人搜的查詢不會列入報表，所以表列查詢的加總一定小於總點擊，差的那一截是匿名查詢，不是資料掉了。GSC 介面能回溯約 16 個月，拉一整年的季節比較夠用。更多操作細節看 Search Console 完整教學。
GSC 查詢分群 Prompt，貼上就能跑
對話介面就能做：把查詢匯出成 CSV 直接上傳，Grok 有檔案與 PDF 分析，附件會自動轉成代理式工作流，它自己決定怎麼讀。走 API 的話，collections_search 支援對上傳的 CSV 知識庫做語意搜尋，說明頁 把它定位成 RAG 工作流的基礎，GSC 匯出檔建知識庫就是它的典型用法。提示詞長這樣：
你是 SEO 關鍵字分析師。我會附上一份 Search Console 的查詢匯出資料，欄位是：查詢、點擊、曝光、CTR、平均排名。
請做三件事：
1. 把查詢依搜尋意圖分群，每一群給一個中文群名，列出群內代表查詢與點擊合計。
2. 標出三種訊號：
- 點擊有、但平均排名在 10 名之後的查詢（有機會往上推）。
- 曝光高、點擊接近零的查詢（標題或意圖錯配）。
- 用字不同、意圖相同的查詢組（可評估整併成一篇）。
3. 對每一群給一句判斷：新增文章、整併、改標題，或放著觀察。
規則：
- 只使用我給的資料。禁止估計、補上或生成任何查詢的搜尋量、難度或趨勢數字；資料裡沒有的欄位，寫「資料未提供」。
- 點擊與曝光為 0 或空值的列，單獨放一區標為無效資料，不要混進分群。
- 輸出用表格：群名、代表查詢、點擊合計、訊號、建議動作。跑完之後人工做兩個檢查：群名與你的分類邏輯合不合，不合就帶著理由讓它重分，重分時把你已確認的群名直接釘給它；每群的代表查詢點得回原始列，點不回去的代表它在編。模型給得起格式，給不起來源。分群可驗、數字不可編，兩個檢查做過，這份輸出就能進你的內容計畫。分群結果還能當比較基準用：下個月同一份匯出再跑一次，群數、群名、各群點擊合計的變化，就是內容計畫有沒有打中的直接回饋，比單看總流量敏感得多。
X 需求探勘找的是問句，不是搜尋量
X 上的討論熱度對需求探勘有參考價值，但熱度不是搜尋量，兩者不能換算，這是使用 X 語料的第一條規則。實際操作：在 Grok 對話裡直接問「過去一個月，X 上關於某主題的討論裡最常出現的問題是什麼」，它搜的是公開貼文，你拿到的是真實問句的原話，不是關鍵字工具那種整理過的變體。走 API 的話，x_search 工具 支援關鍵字搜尋、語意搜尋、帳號搜尋與討論串抓取，參數能限定特定帳號、最多 20 個，能設日期區間，還能理解影片內容。
監看特定網域則用 web_search 工具 的 allowed_domains 與 excluded_domains 參數，各最多 5 個網域、同一請求不可並用；它不是寫在查詢詞裡的 site: 運算子，是分開的參數。兩個搜尋工具都會在回應的 citations 欄位回傳引用來源，可以逐一列出核對。日期區間在事件型查證特別好用，把範圍縮到傳聞出現的那一週，撈出的討論比漫無邊際的全期間搜尋乾淨。
挖回來的問句有兩個去處：進分群提示詞當「候選意圖」的側證，或直接當 FAQ 與段落標題的素材。問句的原話價值最高，使用者的用詞常常和站方想的不一樣，自己想像的 FAQ 寫不出這些。
Grok 關鍵字研究 Prompt
把上面的動作串成一個範本，就是下面的 Grok 關鍵字研究 Prompt。它分兩段：第一段到 X 挖真實問句，第二段貼 GSC 匯出對照，使用者講法與站方用詞的落差，表上直接看得到。這個範本離開 Grok 跑不動，第一段需要 X 即時搜尋。
你是 SEO 關鍵字研究助理，可以使用 X 即時搜尋。本次主題是「（填上你的主題）」。
第一段：到 X 上找真實問句
1. 搜尋過去 30 天 X 上關於此主題的公開討論，找出使用者真的在問的問題，保留原話。
2. 每個問句標出現場情境：求助、比較、抱怨還是推薦；討論強度用多、中、少描述，不要給任何數字。
3. 把同義問句歸群，每群給一個中文群名。
4. 標出 X 上大家真的在用、但正式文件不會出現的說法，俗稱、縮寫、錯字變體都算。
第二段：對照 Search Console 資料
我會附上一份 Search Console 查詢匯出（CSV），欄位是查詢、點擊、曝光、CTR、平均排名。請對照第一段的問句群：
5. 哪些問句群在 GSC 查詢裡已有對應字詞？列出對應關係。
6. 哪些問句群在 GSC 完全沒有對應查詢？標為「觀察名單」，這是搜尋端還沒接上的需求。
7. GSC 查詢裡哪些用詞跟 X 用語不同？指出值得換的用詞。
規則：
- 禁止估計、補上或生成任何搜尋量、難度、排名數字；討論強度只用多、中、少。
- 問句一律引原話，不改寫成通順中文。
- 搜尋結果或資料裡沒有的，標「查無」，不要推測。
輸出格式：
X 問句群（群名、代表原話、情境、強度、俗稱用法）
GSC 對照表（問句群、對應查詢、建議用詞）
觀察名單跑完先看觀察名單：那上面的問句群，到 Keyword Planner 查有沒有量，有量才排進內容計畫。已對應到 GSC 查詢的群，回頭檢查那個頁面有沒有用使用者的問法回答，沒有的話，改的是標題與段落開頭，不是再加一段。
從業者的用法可以參考但別放大。Single Grain 執行長 Eric Siu 公開說過，Grok 產長尾關鍵字的表現令他印象深刻；iPullRank 的 Chris Long 則提醒，用 ChatGPT 做關鍵字研究，輸出品質要接上真資料才成立。兩句都是個別從業者的說法，不是實測結果，但方向一致：模型出詞，資料庫出數字。
需要市場數字時找 Keyword Planner
自家實績之外要市場規模時，Keyword Planner 是免費選項，條件是完成 Google Ads 帳號設定、包含帳單資訊，不必真的下廣告。它的數字要會讀：搜尋量是四捨五入的估計、以 12 個月平均計，預測基於約一週的資料平均成每日預測，這些寫在搜尋量估計方式的說明頁。季節性強的詞，記得對照 12 個月區間再下判斷，單看某個月的預測會誤導內容排程。拿到數字後回頭丟給 Grok 做城市群與意圖判讀，等於市場量級與自家實績擺在同一張表上對照。
用 Grok 找內容缺口與改寫既有文章
內容端的交辦集中在幾個單元：拿分群結果對照既有文章找沒被回答的問句、找文章有但讀者不問的冗重段落、調整標題與段落結構。生成當草稿用，人審與第一手材料留在流程裡，這是效率與政策風險的平衡點。
稽核既有文章的切入單元
實際操作是把三樣東西一起給 Grok：文章全文、所屬查詢群的查詢清單、你希望它服務的主要問句。讓它輸出三張清單：查詢有而文章沒有的問句（缺口）、文章有而查詢群不問的段落（冗重）、標題給的期待與內文實際內容不一致的地方（錯配）。產品端的檔案分析、Canvas 與自訂指令都支援這種反覆工作；自訂指令可以把你的審稿標準固定下來，之後每篇都套同一套，這是把一次性稽核變成流程的方法。改寫的完整做法在 關鍵字最佳化指南。
三張清單的後續處理各有去處：缺口進新增或補寫清單，冗重進刪減評估，錯配先改標題再動內文，因為標題動一句的成本遠低於重寫一節。改寫後同一份資料再跑一輪，缺口收斂就代表方向對了，這是內容稽核少數能自我驗收的地方。人審看幾個點就夠：事實句有沒有支撐、例子是不是通用到誰都能寫、有沒有只有你才知道的細節。第三點最要緊，它是生成內容與你的內容之間真正的差別。
生成內容的政策邊界
Google 的立場有兩個錨點。2023 年 2 月 8 日，Danny Sullivan 與 Chris Nelson 在Google 搜尋與 AI 內容的部落格寫下「獎勵高品質內容，無論如何產製」這個章節，同文的 FAQ 直說：適當使用 AI 或自動化不違反指引，用 AI 不會帶來特別好處，它就只是內容。
Google Search Central 官方提醒：AI 生成內容仍應以實用、可靠、以讀者為先的品質原則檢視。
— Google Search Central (@googlesearchc) February 8, 2023
2025 年 12 月 10 日版的生成式 AI 內容指引補上操作面：生成式 AI 對研究主題與為原創內容加結構特別有用，大量產出零加值頁面則可能違反 scaled content abuse 政策，評估的重點是準確、品質與相關。
風險的實際形狀是規模，不是工具。2026 年 8 月上線的垃圾內容更新，常被拿來與 AI 內容一起討論，但 Google 沒有把這次更新與 scaled content abuse 的因果講死，時間線與官方說法整理在 2026 年 8 月垃圾內容更新。你能控制的是流程：每篇有人審、判斷有第一手材料、產出量與審查量成正比。
技術 SEO 稽核交給 Grok 跑，結果能不能信？
能信的範圍用一條規則切：Grok 從你給的資料裡指認得出的型樣可以直接用；它標為懷疑的要人工複查；索引與排序的現場，必須回 Search Console、Rich Results Test 或爬蟲工具確認。這條規則把「稽核結果能不能信」從感覺問題變成流程問題。
可以交辦給 Grok 的十種資料
模型不會爬你的站，它讀你給的東西，所以稽核品質的上限是餵什麼。入門的爬蟲工具用 Screaming Frog SEO Spider 免費版就能跑，上限 500 個 URL，多數小型站一遍爬完。可以交辦的資料有十種，各自的取得方式與期望發現：
| 資料 | 從哪裡拿 | 交辦後期望的發現 |
|---|---|---|
| 爬蟲匯出 CSV | Screaming Frog 等爬蟲工具 | 重複 title、description、轉址鏈、狀態碼異常 |
| HTTP 狀態碼清單 | 爬蟲或監控工具 | 4xx 與 5xx 的集中區域 |
| 轉址鏈 | 爬蟲匯出 | 鏈長異常與循環 |
| hreflang 對照表 | 爬蟲或手動整理 | 互惠連結缺漏 |
| 結構化資料輸出 | 爬蟲的 schema 報告 | 型樣異常與缺漏 |
| sitemap | 直接下載 | 與實際頁面清單的差異 |
| robots.txt | 直接下載 | 封鎖範圍是否誤傷 |
| 伺服器 log 檔 | 主機或 CDN 匯出 | 爬蟲實際抓了什麼 |
| Core Web Vitals 報表 | 實測資料彙整 | 需要關注的頁面群 |
| GSC 頁面層資料 | Search Console 匯出 | 曝光高排名低的技術候選 |
同一批資料裡，Grok 做得比試算表好的是跨檔關聯：例如把 sitemap 的網址清單對上爬蟲結果裡的狀態碼，再把 GSC 頁面層的曝光拉進來排優先順序，這種三方比對手工做很磨人，交給模型讀剛好。十種資料不用一次備齊，從爬蟲 CSV 加 GSC 頁面層資料開始，這兩份就夠跑出第一版清單；log 檔與 Core Web Vitals 等流程跑順了再補，清單會越來越厚，流程不會跟著變複雜。
Confirmed、Possible、Needs live verification 的三分法
三分法是工作流規則，不是官方分類。Confirmed 級放資料裡指認得到的問題：兩列出現同一個 title、description 大量重複、狀態碼 4xx 與 5xx 的清單、轉址鏈的每一跳，證據就是資料列本身，這級直接排進待修清單。Possible 級放型樣可疑但資料不足的問題：hreflang 的互惠缺漏、sitemap 與內部連結的不一致，模型給你懷疑的理由，你決定要不要人工核。Needs live verification 級放必須到現場的問題：索引狀態、canonical 的實際生效、結構化資料的有效性，回 Search Console、Rich Results Test 或爬蟲工具看過才算數。
提示詞把三級寫死在輸出格式裡：
你是技術 SEO 稽核助理。我會提供網站的爬蟲匯出資料（CSV），欄位包含網址、狀態碼、標題、description、轉址目標，可能附上 sitemap 與 robots.txt。
請把發現的每個問題分三級輸出：
- Confirmed：能在資料列直接指認證據的問題，附上涉及的網址與欄位值。
- Possible：型樣可疑但現有資料不足以定案，寫出懷疑理由與建議的複查方式。
- Needs live verification：需要回 Search Console、Rich Results Test 或爬蟲工具驗證的項目，寫清楚到哪個工具、看什麼欄位。
規則：
- 只使用我提供的資料，不要假設網站現況，不要推測索引量或流量數字。
- 每個問題一行：等級、問題描述、證據（網址與值）、建議動作。
- 沒有問題就說沒有問題，不要為了湊清單列出低信心項目。大型站分批跑：把網址按目錄切開，每批一個對話，各自出三級清單，合併後再除重。每季重跑一次、每次只修 Confirmed 與複查通過的項目，比一年一次大稽核更容易維持。
structured outputs 讓輸出直接進 pipeline
API 端把輸出格式釘死用 structured outputs：回應保證符合你定義的 JSON Schema，但僅限支援的 schema 子集，not、if-then 這類關鍵字官方明寫 accepted but not structurally enforced，建議自行驗證，說明頁有完整子集清單。稽核輸出的最小骨架長這樣：
{
"type": "object",
"properties": {
"issues": {
"type": "array",
"items": {
"type": "object",
"properties": {
"level": { "type": "string", "enum": ["confirmed", "possible", "needs_live_verification"] },
"description": { "type": "string" },
"evidence_urls": { "type": "array", "items": { "type": "string" } },
"action": { "type": "string" }
},
"required": ["level", "description", "action"]
}
}
},
"required": ["issues"]
}拿到結構化輸出後，直接接你自己的工單系統或試算表，Confirmed 自動開單、其餘兩級進人工佇列，稽核從一次性的報告變成每週跑的流水線。
用 Grok Bot 與 Grok Build 讓稽核固定跑
一次性稽核跑穩之後，接自動化。Grok Bot 在 2026 年 8 月 11 日進入 beta，推出公告定位它是可交辦真工作的 AI 隊友；總覽說明寫得更具體，每個 Bot 跑在一台持續存在的雲端電腦上，有瀏覽器、檔案系統與終端機，沒有乾淨 API 的網站就用 computer use 操作。
Introducing Grok Bot, now in early beta.
— Grok Bot (@bot) August 11, 2026
Bots are AI teammates that do real work for you. They sign in to your tools, use them just like you do, and come back with finished work. pic.twitter.com/uyfA97yo98
安全規則有兩條：同帳號的所有 Bot 共用同一台雲端電腦，官方明講不要把不同 Bot 當安全邊界；遇到 CAPTCHA、新登入或人工確認，Bot 該把步驟交還給你，不是繞過。FAQ 的建議是，發布、刪除、購買這類動作要設 Require Approval。
Grok Bot 的自動化積木是 skill 與 routine：skill 是可重複使用的任務指令集，routine 決定某個 Bot 何時執行，每個 Bot 最多 50 個 routines、保留最近 20 筆執行紀錄。skills 與 routines 的說明給了導入順序：先把一次性任務跑穩，存成 skill，之後才自動化。官方範例的終點是留草稿給你核准，不是自主行動。排程與應用的細節，站上的 Grok Bot 完整介紹 講得更全。
終端機版是另一條線。Grok Build 在 2026 年 5 月 25 日以 early beta 發布，是終端機裡的 coding agent，SuperGrok 與 X Premium Plus 訂戶可用、一行安裝，發布公告列了 headless 模式（-p）把 agent 放進腳本，支援 AGENTS.md、plugins、hooks、MCP servers、plan mode 與平行 subagents。
An early beta of Grok Build, an agentic CLI for coding, building apps, and automating workflows is now available for SuperGrok Heavy subscribers.
— SpaceXAI (@SpaceXAI) May 14, 2026
Through this early beta, we will improve the model and product based on your feedback.
Try it at https://t.co/bpTHpjivWD pic.twitter.com/Rlg4qMLkrv
名字要小心：Grok Build 這個名字有三個東西共用，終端機 CLI 之外，還有 5 月 29 日上架的 API 模型 grok-build-0.1，256k context，短 context 每 1M tokens 輸入 $1、輸出 $2。網頁版是 7 月 28 日以 Build Mode 之名上線 SuperGrok Heavy、8 月 19 日改名成 Grok Build on web and mobile，各方案都能用的建置介面。讀到 Grok Build 的任何資訊，都要確認講的是哪一個。
大規模的整站判讀還有 2026 年 7 月 23 日發布的 Workflows，用編排腳本把任務展開給數百個平行代理、驗證後一次回報。
怎麼讓 Grok 引用你的網站？
做得動的是通用可引用結構：直答句式、完整定義、帶日期與來源的數字、穩定的技術基礎。檢索與排序那一半是黑箱，能做的是把可控的部分做扎實。
通用可引用結構，借 Google 的基線
Google 回答過「要不要為 AI 做特別的事」：要，就是既有 SEO 基礎。2026 年 7 月 10 日更新的 AI 最佳化指南寫明，Google 的生成式 AI 功能根源於核心搜尋排序與品質系統；不需要為了出現在搜尋新建機器可讀檔案，llms.txt 之類 Google 會忽略；生成式搜尋不需要結構化資料、沒有專屬的 schema.org 標記；不要只是回收網路上已有的、或生成模型輕易產得出的內容。
這是 Google 的立場，搬到 Grok 是合理的類推：兩者都要先抓得到、讀得懂，才談得上引用。
GEO 的完整框架在站上的 GEO 完整指南，這裡聚焦 Grok 面能用什麼。從業者觀察可以當方向：Contently 在 2026 年 4 月 30 日彙整的建議，包括直答句式、資訊前置、頁面上看得到的更新時間、經營 X 帳號、比較表結構、固定查詢追蹤。這些全是實務推論，xAI 沒有背書，照做不等於會被引用；但不做的成本很低，挑合理的先做，例如把每個段落的核心句寫成能單獨理解的完整句，把更新時間放在頁面上看得到的位置。
句子層的練習更具體：把「提供多種解決方案」這類空話，換成「技術稽核的輸出分 Confirmed、Possible、Needs live verification 三級，各級對應不同處理」，後者能被單獨摘錄成答案，前者連人都抓不到重點。
爬蟲與排序的黑箱邊界
黑箱部分有明確的邊界。xAI 沒有官方爬蟲參考頁，沒有排名因素的官方說明，Web Search 的說明頁也不談索引來源。第三方爬蟲觀測單位回報過一個名稱裡帶 xAI 的搜尋爬蟲 UA，標註未經營運方驗證，trakkr.ai 明寫找不到 xAI 的營運方頁面；這個名字連當事實用都不夠格，更別說為它寫 robots.txt 規則。Grok 背後的索引規模、上游搜尋引擎，同樣沒有可查的官方說法，任何講得斬釘截鐵的轉述都要打折。
早期第一手觀察只有一組可用：Zeo 在 2025 年 1 月 24 日、Grok 2 時期的觀察提到，Grok 引用 web 來源有約 25 頁的上限，meta description 會原樣顯示、大約 320 字元，noindex 與 canonical 變動的偵測有延遲，內容更新偵測約 15 天，3XX 轉址沒有解析到最終 URL。這是 2025 年初、舊世代模型的數字，方向價值大於數字價值：Grok 的檢索層與 Google 不同步，你改了 noindex，它可能要一段時間才反應。
xAI 自己倒是示範了可引用結構長什麼樣：他們自家網站的 robots.txt 用 Content Signals 草案規範表達意圖，其中給指南文章的分區寫著這些指南是為了被引用而寫，並允許 answer-engine input。這是 xAI 對自家站的政策，不是 Grok 檢索器的對外規則。
用 log 檔看爬蟲實際行為
與其猜爬蟲行為，看 log。伺服器 log 檔分析是觀察爬蟲實際行為的公認方法，Search Engine Land 的指南把它列為即時暴露伺服器端與技術問題的手段；iPullRank 的 Chris Long 的講法是，log 檔告訴你真實故事，讓你看到 AI 在你站上的實際行為，而不是猜測。
本站自己在 Cloudflare 邊緣部署了 AI 爬蟲記錄 Worker，觀測報告裡有一個數字：一篇談實體 SEO 的單一頁面，七天內被 AI 爬蟲抓取超過 12,000 次。這是單頁七天的數字，不是全站總量，但它足夠說明 AI 爬蟲的拜訪量已經值得放進觀測清單。
觀測要回答的問題很具體：哪些 AI 爬蟲真的來、它們抓哪些頁面、多久來一次。答案直接決定下一步，某個爬蟲頻繁抓你的熱門頁，那些頁面的定義句與標題就值得整理；沒有任何 AI 爬蟲上門，該檢查的是技術層能不能被找到，而不是內容句式。
GSC 那邊有對應欄位，但要分清楚兩件事。2026 年 6 月 3 日上線、8 月 31 日已全面開放的 Search Generative AI 報告只有曝光、頁面、國家、裝置與日期維度，沒有點擊、沒有查詢字串；AI 流量計數的支援頁寫的是另一件事，AI Mode 裡點外部連結會計為一次點擊，AI Overviews 占結果單一位置、其中的連結共用同一個 position，追問視為新查詢。兩件事分開記，一個衡量 AI 功能裡的曝光，一個解釋點擊怎麼計，混在一起會得出錯的結論。
Grok 的費用結構：免費版、訂閱與 API
費用按用途拆三層看：對話流程、用量與代理、規模化。老實說，關鍵字研究與內容稽核這兩段，免費版就跑得通；錢花在刀刃上的意思是先確定流程，再決定升級。
免費版跑得到哪裡
訂閱方案頁上的免費方案是 $0/月，權益包含即時 web 與 X 搜尋（標示 Limited）、語音模式與 Connectors。對應到工作流：查詢分群（上傳 CSV）、內容稽核（貼全文）、X 需求探勘（對話提問），免費版都做得到，差別在用量。各方案的 DeepSearch 次數、檔案上傳大小，官方沒有公布逐方案數字，只能說免費版有限、付費版更高，重度使用前自己跑一輪就知道界線在哪。
訂閱怎麼選
方案層級有七個：Free、SuperGrok Lite、SuperGrok、SuperGrok Plus、SuperGrok Heavy、Business、Enterprise。對 SEO 工作有感的跳躍在 SuperGrok，$30/月買到 Grok 4.6 模型、Grok Bot access、Connectors、更高的速率限制、Expert mode、圖片與影片生成，多代理推理也在這一層。SuperGrok Plus 是 $100/月，加上 1080p 影片、各功能更高用量、尖峰優先與新功能早期存取。
Lite 與 Heavy 的月費以結帳頁為準，這裡不寫死；Business 與 Enterprise 的方案細節同樣以定價頁為準。Grok Bot 的適用方案在 8 月 26 日公告後持續擴大，同樣以定價頁現況為準。完整的方案比較交給 SuperGrok 訂閱完整比較，對 SEO 工作有感的層級，金額與權益直接對照：
| 訂閱層 | 月費 | 對 SEO 工作的意義 |
|---|---|---|
| Free | $0 | 對話、即時搜尋（限量）、檔案分析；分群與稽核跑得通 |
| SuperGrok | $30 | Grok 4.6、更高用量、多代理、Grok Bot access |
| SuperGrok Plus | $100 | 尖峰優先與早期存取；重度使用者 |
| SuperGrok Lite／Heavy | 以結帳頁為準 | 入門與最高階，差在用量與優先級 |
判斷順序可以反過來想：卡在靈感與判讀，免費版夠；卡在用量與速度，SuperGrok；卡在尖峰搶輸別人、或想早一步拿到新功能，才到 Plus。多數個人站長停在第二層就好，先讓流程跑出成果，再讓錢跟上需求。
API 成本怎麼估
API 的成本結構是兩條相加：tokens 與工具呼叫。2026 年 8 月 21 日更新的 API 定價頁上，grok-4.6 每 1M tokens 的價格是：prompt 低於 200k 時，輸入 $2.00、快取 $0.50、輸出 $6.00；prompt 一到 200k，整個請求的所有 tokens 改按長 context 計費，輸入 $4.00、快取 $1.00、輸出 $12.00。
門檻是整個請求一起跳，不是超過的段落才跳，長文件工作要先把 context 預算算好。速度敏感的工作可以開 fast variant，兩倍價，寫在 Grok 4.6 發布公告裡。
工具呼叫按次計費：web_search、x_search、code_execution 每千次 $5，attachment_search 每千次 $10，collections_search 每千次 $2.50；Remote MCP 與看圖只計 tokens，圖片搜尋併在 web_search 費率內不加價。定價頁把成本結構講得明白：代理自己決定呼叫幾次工具，成本隨查詢複雜度上升。
估預算的方式不是算單次，是先小量跑十筆看實際帳單結構，再放大。批次工作有折扣，Batch API 上 grok-4.3 與三個 grok-4.20 slug 打八折，多數 24 小時內完成、不占速率限制，整站 metadata 判讀這種不急的活丟這裡。舊的 Live Search 每千 sources 計費已從定價頁消失，搜尋成本全在工具計費段，手上還留著舊價格表的，以此為準。
做不到的事與還沒有答案的事
模型不能爬你的站、不能查索引、不能驗排名，這些事的共通點是都需要到現場，而模型只能讀你帶來的資料。判斷的方式很直接：需要現場的，買工具或自己看，不要問模型。
量化答案也不存在。Grok 能帶來多少流量、被引用的機率多高、排名會不會上升，沒有任何一方發布過可驗證的數字；遇到給你這種數字的建議，追來源，追不到就不要拿來當決策依據。
翻頁速度是另一個邊界。模型與價格更新很快，2026 年 5 月 15 日一批舊模型從 API 退役、呼叫舊 slug 會自動 redirect 到 grok-4.3，就是現成的例子；訂閱權益與 Bot 的適用方案也在變動。任何超過一個月的具體數字，動手前回官方頁面再確認一次。
下一步：今晚就能開始的兩個動作
今晚花 30 分鐘：打開 Search Console 的效能報告，匯出查詢資料，記得 1,000 列上限與 ~ 變 0 這兩個坑。開 Grok 對話，貼上分群提示詞、附上檔案，拿到第一版意圖分群與三種訊號清單，挑一個點擊有但排名在後面的查詢群，排進本週的內容計畫。
週末花兩小時：用 Screaming Frog 免費版把站爬一遍，500 個 URL 以內直接跑完，匯出 CSV，丟給 Grok 跑稽核提示詞。Confirmed 級的項目當週就修，Needs live verification 級排進驗證清單。有 Cloudflare 的站，順手把 AI 爬蟲觀測排進待辦，資料會自己累積。
兩個動作都不花錢。跑完你會拿到自己站的真實查詢樣貌、第一份可驗證的技術問題清單，還有 AI 爬蟲到底有沒有來的答案。之後要不要升級、要不要接 API，判斷的依據都在你自己手上。
關於 Grok SEO 的常見問題
Grok 有搜尋量資料嗎？可以直接叫它給關鍵字搜尋量嗎？
沒有，也不行。Grok 沒有關鍵字資料庫，你直接要搜尋量，它會生成一個格式正確但沒有來源的數字。真數字的路徑是：自家實績看 Search Console，市場估計看 Keyword Planner，第三方資料用 Ahrefs 或 Semrush。Grok 在這條流程裡做分群與判讀，數字進來之後它才開始有用。
Grok 跟 ChatGPT、Claude 做 SEO 差在哪？
差在資料面與工作形態。Grok 搜尋時能讀 X 即時公開貼文，多了代理搜尋與可排程的代理層；ChatGPT 與 Claude 適合既有的內容與程式工作。三個模型做分群、稽核、改寫都夠用，數字也都要外接資料源，所以結論是並用，看手上的工作挑工具，不是認定一個贏家。
Grok 跑出來的技術稽核結果能不能信？
分三級用就安全。資料裡指認得到的，像重複 title、狀態碼、轉址鏈，直接修；標為懷疑的，人工複查再動；索引狀態、canonical 實效、結構化資料有效性，回 Search Console、Rich Results Test 或爬蟲工具驗證過才算數。稽核品質的上限是餵給它的資料，不是模型本身。
用 Grok 寫內容會被 Google 降權嗎？
用 AI 本身不會。Google 從 2023 年就講獎勵高品質內容、無論如何產製，用 AI 不會帶來特別好處，也不會特別被罰，它就只是內容。會出事的是大量產出零加值頁面，那踩到 scaled content abuse 政策。生成當草稿、逐段人審、放進你自己的第一手材料，風險就控制在政策畫的線內。
免費版 Grok 夠不夠跑這些流程？
關鍵字分群與內容稽核夠用，免費版有即時 web 與 X 搜尋、檔案分析與 Connectors。需要更高用量、多代理推理或 Grok Bot 時，再考慮 SuperGrok 系列；重度使用前，先用免費額度摸出自己落在哪個量級，升級才有依據。
一定要學 API 嗎？
不用。對話介面加 CSV 就能跑完關鍵字研究與技術稽核的完整流程。API 的價值在規模化與自動化：structured outputs 釘住輸出格式、collections_search 建可搜尋的知識庫、排程代理固定跑週期工作。成本從 tokens 與工具呼叫兩邊長，接之前先小量試算。
Grok 會引用我的網站嗎？
沒有人能給你保證。能做的是把自己能控制的部分做好：直答、定義完整、日期與數字帶來源、技術基礎穩定。想看爬蟲有沒有真的來，log 檔與邊緣觀測比任何建議都實在。
X 貼文熱度等於搜尋量嗎？
不等於，也換算不了。X 的價值在即時輿論與真實問句，熱度反映討論強度，不是查詢次數。正確用法是把 X 當需求探勘的訊號源，挖到候選詞之後，搜尋量回 Keyword Planner 或第三方資料庫確認。
