分類: Uncategorized

重點摘要：想讓內容出現在 AI Overview、ChatGPT、Perplexity 的答案裡，第一步不是寫得多好，而是先確認 AI 爬蟲「抓得到」你的網站。這些爬蟲分兩種——「檢索／引用型」決定你會不會被引用，「訓練型」決定內容會不會被拿去訓練模型。想要 AI 曝光就別擋前者；想控制版權與伺服器成本，可以只擋後者。而最容易踩的坑往往不是 robots.txt 寫錯，而是主機邊緣或 Cloudflare 規則在你不知情的狀況下，把 AI 爬蟲整批擋在門外。

一、AI 爬蟲是什麼？有哪些？

AI 爬蟲是各家 AI 公司用來抓取網頁的自動程式，運作方式和 Googlebot 一樣：讀你的 HTML、依 robots.txt 決定能不能抓。差別在「用途」。同一家公司往往派出好幾支爬蟲，分別負責「訓練模型」與「即時檢索／引用」，這個分別是後面所有決策的關鍵。

User-agent	來自	類型	用途
GPTBot	OpenAI	訓練型	抓取內容供模型訓練
OAI-SearchBot	OpenAI	檢索／引用型	供 ChatGPT search 顯示與引用連結
ChatGPT-User	OpenAI	使用者觸發	使用者在 ChatGPT 中要求即時瀏覽某頁
ClaudeBot	Anthropic	訓練型	抓取內容供模型訓練
PerplexityBot	Perplexity	檢索／引用型	建立索引供 Perplexity 引用
Googlebot	Google	檢索／引用型	一般搜尋索引；AI Overview 也是用這個索引
Google-Extended	Google	訓練型	控制內容是否用於 Gemini／Vertex AI 訓練（不影響搜尋與 AI Overview）
CCBot	Common Crawl	訓練型	公開語料，許多 LLM 訓練資料的來源

關鍵觀念：「被 AI 引用」和「被拿去訓練」是兩件事，用的是不同爬蟲。想被答案引擎引用，要放行的是檢索／引用型爬蟲（OAI-SearchBot、PerplexityBot、Googlebot）；擔心內容被訓練，才需要處理訓練型爬蟲（GPTBot、ClaudeBot、CCBot、Google-Extended）。把兩者混為一談，常導致「為了防訓練，連 AI 曝光一起殺掉」。

二、該讓 AI 爬蟲抓，還是該擋？

該放行的理由：AI 曝光

AI Overview、ChatGPT search、Perplexity 這類答案引擎，只能引用它們抓得到的內容。爬蟲被擋在門外，你的網站在 AI 生成的答案裡就不會被列為來源——等於在新的搜尋介面上隱形。對想靠內容獲客的 B2B 網站，這是實打實的曝光損失。特別提醒：Google 的 AI Overview 用的是一般搜尋索引（Googlebot），不是另一支專用爬蟲，所以只要你正常被 Google 收錄，就具備進 AI Overview 的資格，不必額外「開通」什麼。

該擋的理由：版權與成本

反過來，若你的內容是付費資產（會員內容、原創資料庫），或不希望被拿去訓練商業模型，可以選擇擋掉訓練型爬蟲。另外，密集抓取確實會吃伺服器資源，流量大的站可對特別激進的爬蟲設限。重點是——這是一個商業選擇，該逐一決定要放行或封鎖哪一支，而不是一刀切全擋或全放。

三、robots.txt 怎麼設（含範例）

robots.txt 放在網站根目錄，用 User-agent 指定對象、Disallow 與 Allow 控制路徑。最保守、也最推薦的基準，是只擋後台、其餘全放行：

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://richers.co/sitemap.xml

如果你的政策是「歡迎被引用、但拒絕訓練」，可以針對個別爬蟲分組設定：

# 放行檢索／引用型（想被 AI 答案引擎引用就別擋）
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

# 只擋訓練型（不影響 AI 引用曝光）
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: *
Disallow: /wp-admin/
Sitemap: https://richers.co/sitemap.xml

兩個容易誤解的細節：其一，多數合規爬蟲只會讀最符合自己的那一組指令，不會把 User-agent: * 那組再加進來，所以針對特定爬蟲的設定要寫完整、別漏了 Disallow 或 Allow。其二，Google-Extended 只控制內容是否用於 Gemini／Vertex AI 的訓練與接地，不影響 Google 搜尋收錄，也不影響 AI Overview——想擋訓練又保留 AI Overview 曝光，這正是該用的旋鈕。

還要記得：robots.txt 是「君子協定」。OpenAI、Anthropic、Perplexity、Google、Common Crawl 等主流爬蟲會遵守，但惡意爬蟲不會；真要強制阻擋，得靠防火牆或 CDN 邊緣規則——而下一段的坑，也正出在這裡。

四、最常見的坑：以為沒擋，其實擋在你看不到的地方

實務上，robots.txt 寫得再乾淨，AI 爬蟲仍可能抓不到，因為擋的動作發生在網站程式碼之外：

• Cloudflare 一鍵封鎖 AI 爬蟲：Cloudflare 有「Block AI Scrapers and Crawlers」與 AI Crawl Control 這類開關，還有 Bot Fight Mode／WAF 規則會對非瀏覽器的 user-agent 發出 JS 挑戰。AI 爬蟲通不過挑戰，等於被擋——而且 robots.txt 完全正常，從後台看不出問題。2025 年起 Cloudflare 甚至對部分新網域預設封鎖 AI 爬蟲。
• 主機／CDN 的邊緣層覆寫：某些 managed 主機會在邊緣層直接回一份和源站不同的 robots.txt，你在後台改的檔案根本沒送到 Google 面前。
• WAF 依 user-agent 封鎖：資安規則把陌生 user-agent 一律擋掉，順手也把 AI 爬蟲一起擋了。

一個真實案例：我們接手管理的一個網站，從主機內部看 robots.txt 完全正確（只擋後台），但對外——包含 Google 看到的——拿到的卻是 User-agent: * / Disallow: /，全站封鎖。追查後發現，是 managed 主機的邊緣層把「尚未正式上線」的站硬回一份全站封鎖的 robots.txt，而且它只攔精確的 /robots.txt 路徑。我們的做法是在邊緣前加一條規則，把 /robots.txt 改寫成 /robots.txt?x=1（並部署一支輕量 Worker 動態向源站取回正確檔案），邊緣不再攔截，Google 當天就拿到正確版本。根本解仍是請主機商解除封鎖，但這條繞道讓我們不必乾等索引恢復——這就是「擋在你看不到的地方」最典型的樣子。

五、怎麼驗證有沒有被擋？

不要只用瀏覽器測，因為瀏覽器的 user-agent 和 AI 爬蟲不同，看到 200 不代表爬蟲也拿得到。正確做法是用指令帶上爬蟲的 user-agent，直接看回應碼是不是 200：

# 測首頁對 GPTBot 是否放行
curl -A "GPTBot" -I https://你的網域/

# 看 robots.txt 對 PerplexityBot 回什麼
curl -A "PerplexityBot" https://你的網域/robots.txt

其他該一起看的地方：伺服器 access log 裡這些 user-agent 的狀態碼（200 是放行，403／503 或挑戰頁就是被擋）；Cloudflare 的 AI Crawl Control 與 Security Events；以及 Google Search Console 的 robots.txt 報告與網址檢查——後者確認 Googlebot 抓得到，等於確認你具備進 AI Overview 的資格。

六、豐遠資訊怎麼幫客戶檢查

我們把「AI 爬蟲可抓性」當成 SEO 健檢的固定項目，做的是三件可驗證的事：

• 實測而非猜測：用一份完整的 AI 爬蟲 user-agent 清單（GPTBot、ClaudeBot、PerplexityBot、CCBot 等）逐一打你的網站，記錄每支的回應碼，找出被擋的那些。
• 連邊緣一起查：不只看 robots.txt，還檢查主機／CDN 邊緣、Cloudflare AI Crawl Control／Bot Fight／WAF 規則，以及伺服器 log，把上一段那種「看不到的封鎖」揪出來。
• 依你的政策設定：先和你確認要不要被訓練、要不要被引用，再把 robots.txt 與邊緣規則設成你要的樣子，而不是一刀切。

作為對照，我們新站在上線前，對 GPTBot、ClaudeBot、PerplexityBot、CCBot 等五種主要 AI 爬蟲逐一實測，回應皆為 200——先確認內容抓得到，才有被引用的機會。我們無法、也不會保證你一定會被 AI 引用（沒有人能保證），但「先確保抓得到」是能做、也該先做到的一步。

常見問題

擋掉 GPTBot，會讓我從 Google AI Overview 消失嗎？

不會。AI Overview 用的是 Google 一般搜尋索引（Googlebot），GPTBot 是 OpenAI 的訓練用爬蟲，兩者無關。擋 GPTBot 只影響 OpenAI 是否拿你的內容訓練，不影響你在 Google AI Overview 的曝光。

到底該不該擋 AI 爬蟲？

看目的。想被 AI 答案引擎引用、爭取曝光，就放行檢索／引用型爬蟲；擔心內容被拿去訓練，或伺服器負擔太重，可以只擋訓練型爬蟲。這是商業選擇，建議逐支決定，不要一刀切。

robots.txt 真的擋得住 AI 爬蟲嗎？

對主流合規爬蟲（OpenAI、Anthropic、Perplexity、Google、Common Crawl）有效，它們會遵守。但 robots.txt 是自願性協定，惡意爬蟲不理會；若要強制阻擋，需搭配防火牆或 CDN 邊緣規則。

我明明沒設定，為什麼 AI 爬蟲還是抓不到？

多半是擋在網站程式碼之外——Cloudflare 的 AI 爬蟲封鎖或 Bot Fight Mode、WAF 依 user-agent 攔截，或主機邊緣層覆寫了 robots.txt。這些從 WordPress 後台看不到，要用帶 user-agent 的指令實測、並查伺服器 log 才會發現。

怎麼快速確認有沒有被擋？

用 curl -A "GPTBot" -I https://你的網域/ 看回應碼是不是 200，再用同樣方式測 robots.txt，並比對伺服器 log 裡各 AI 爬蟲的狀態碼。不確定的話，我們的免費 SEO 健檢會幫你把主要 AI 爬蟲都測一遍。

想知道你的網站，AI 爬蟲抓不抓得到？

內容能不能被 AI Overview、ChatGPT、Perplexity 引用，起點都是「抓得到」。我們的免費 SEO 健檢會實測主要 AI 爬蟲對你網站的回應，找出被 robots.txt、Cloudflare 或主機邊緣誤擋的地方，並附上該怎麼設定的建議。想進一步規劃內容在 AI 搜尋時代的佈局，可以了解我們的 SEO 成長服務；若問題出在主機或邊緣設定，網站維運服務能一起處理。

最後更新：2026-09-13

什麼是結構化資料？為什麼 AI 特別需要它

人看網頁靠版面理解意思，機器不會——搜尋引擎和生成式 AI 讀到的是一堆 HTML 標籤，需要一份標準化的「說明書」，才能確定這頁的公司、地址、服務、作者、問答分別是什麼。這份說明書就是結構化資料，通用詞彙表是 schema.org，最推薦的寫法是 JSON-LD。

在傳統 SEO 時代，結構化資料主要用來爭取「複合式搜尋結果」（rich results），例如星等、FAQ 展開、麵包屑。到了 AI 搜尋與 AI Overview 階段它更關鍵：當 AI 要判斷哪個網站是某問題的權威、要引用誰當來源時，機器可讀的實體資訊會大幅降低它猜錯的機率。把「我是台北的 SEO 代理商、提供這幾項服務」寫成機器讀得懂的格式，遠比讓 AI 從行銷文案自行推敲可靠。

要提醒的是：結構化資料能讓 AI 與 Google 更精準理解你的內容，但它不是排名保證，也無法讓空洞的內容變得有價值——它是把好內容翻譯給機器的橋樑，不是內容的替代品。

常見的結構化資料類型與各自用途

類型很多，但多數網站真正用得到的是以下這幾種。理解它們各自回答什麼問題，比背 schema.org 的完整清單更實用：

類型（@type）	回答的問題	誰該用
Organization	「這個網站背後是哪家公司？」名稱、logo、社群與各平台連結（sameAs）	所有品牌／公司網站
WebSite	「這是哪個網站？站內搜尋怎麼用？」有時帶站內搜尋框設定	所有網站
LocalBusiness	「你在哪、營業時間、服務範圍、評價幾分？」地址、地理座標、營業時段、評分	有實體或在地服務的店家、工程行、診所、事務所
Article／BlogPosting	「這篇文章在講什麼？誰寫的？何時更新？」標題、作者、發佈與更新日期	部落格、知識文、新聞頁
FAQPage	「這頁有哪些常見問答？」一問一答，容易被 AI Overview 與 PAA 摘錄	服務頁、長文、常見問題頁
BreadcrumbList	「這頁在網站架構的哪個位置？」麵包屑層級	所有有分層結構的網站
Service／OfferCatalog	「你提供哪些服務？」把服務清單結構化列出	服務型公司

實務上，在地服務型公司通常同時用 Organization、WebSite、LocalBusiness，服務頁加 FAQPage 與 BreadcrumbList，文章用 Article／BlogPosting 標明作者與更新日期——這正是我們協助客戶的預設起手式。

結構化資料怎麼做才正確：三個原則

一、全站集中成單一 @graph，而不是零散拼貼

很多網站的結構化資料東一塊、西一塊：首頁一段 Organization、外掛又吐一段 WebSite、文章頁再單獨掛 Article，這些片段彼此不認識，機器得自己拼湊關係。正確做法是把整頁實體收進單一 @graph，用 @id 讓節點互相參照——例如標明這個 Article 的發佈者是哪個 Organization。關係一旦明確，AI 就不必猜，也不會被兩段矛盾的標記混淆。

二、由網站統一輸出，不要每個外掛各自為政

結構化資料應該有「單一真相來源」。若 SEO 外掛、佈景主題、社群外掛各自注入 schema，很容易同一頁掛兩組 WebSite、兩組 FAQPage。重複標記通常不致命，卻是雜訊，會稀釋機器判讀的確定性。理想做法是由網站集中產生，其餘來源關掉，避免打架。

三、FAQ 等內容從「內文」解析，不要手打一份給機器看

這是最容易踩雷的一點。FAQPage 標記裡的問答，必須和頁面上看得到的內容一致。若標記裡塞了頁面根本沒有的問答，那叫 cloaking（對人和對機器顯示不同內容），是 Google 明文禁止的操作，抓到反受其害。正確做法是：先把 FAQ 寫進內文（每題答案放第一句，AI 最容易擷取），再由系統從內文自動解析成標記——內容改一次，兩邊同步，永不對不上。

常見錯誤：這些做法弊大於利

• 標記和內文不符（cloaking）：schema 裡的評價、問答、價格，頁面上卻找不到。這是最嚴重的一種，寧可不做也不要造假。
• 同頁重複掛同型標記：兩組 WebSite、兩組 FAQPage。我們檢視過一個業界案例，schema 地基很強，卻因不同外掛各自輸出而出現重複節點——正是「缺乏單一真相來源」的典型症狀。
• 為複合式結果亂加不相干標記：明明不是食譜、活動、產品，硬套 Recipe、Event、Product，機器讀到不相符的標記反而降低信任。
• 把標記當成寫內容者的負擔：手動硬塞 JSON-LD 到正文，日後改內文卻忘了改標記；或以為裝了 SEO 外掛就萬事俱備。外掛出基本標記是好起點，但標記應由系統統一產生，也不會替你設計實體關係。

豐遠（Richers）怎麼幫客戶做

我們把上面三個原則直接做進網站架構，而不是事後補外掛——這些都是我們自己跑過、驗證過的做法：

• 網站本身就是作品。我們重建的官方網站採用單一 @graph：Organization、WebSite、服務與文章實體全部收在同一節點裡互相參照，由網站統一輸出，避免重複衝突。FAQ 不手打給機器，而是從內文的 FAQ 區塊自動解析——編輯把問答寫進內文，標記就同步產生，杜絕 cloaking 風險。
• 在地服務站的實戰補強。協助一個在地服務型網站復原流量時，我們為它寫了一支輕量程式（mu-plugin），在首頁補上 Organization、WebSite、LocalBusiness／營建服務類標記，標明品牌、服務區域與聯絡方式，並避開與既有 SEO 外掛重疊（外掛只出 FAQ 與文章標記）。這就是「集中輸出、避免衝突」的落地。
• 我們不承諾排名。結構化資料能讓 Google 與 AI 更精準理解你的網站，但沒有人能保證被引用或排名。我們保證的是把可驗證的基礎工程做對——單一 @graph、乾淨不衝突的標記、內文與標記一致——這是內容有機會被看見的前提，不是結果的承諾。

結構化資料只是 AI 搜尋友善度的一環。想了解它在整體策略中的位置，可以延伸閱讀我們的 生成式引擎優化（GEO）完整指南；若你需要有人把這些工程一次做到位，這正是我們 SEO 服務與網站建置的一部分。

常見問題 FAQ

結構化資料一定要用 JSON-LD 嗎？

是。JSON-LD 是 Google 官方建議的格式，獨立於頁面內容之外，維護最單純。舊式的 Microdata、RDFa 雖仍可辨識，但新網站沒有理由不用 JSON-LD。

網站沒有結構化資料，Google 就找不到我嗎？

不會。沒有結構化資料，Google 一樣能索引你的網站。它的作用是讓機器更確定地理解內容、降低誤判，並爭取複合式結果與 AI 引用——是加分項，不是被收錄的門檻。

用 SEO 外掛（Yoast、RankMath、SureRank 等）出 schema 夠嗎？

作為起步足夠，能自動產生基本的 Article、FAQ 標記。但它不會替你設計實體之間的關係，也可能和其他外掛重複輸出。要做到單一 @graph、乾淨不衝突，通常需由網站層統一規劃。

FAQ 的結構化資料會不會被判定作弊？

只要標記裡的問答和頁面看得到的內容一致，就不會。會出問題的是「標記有、頁面沒有」的造假（cloaking）。最安全的做法是把 FAQ 寫進內文，再由系統解析成標記，兩邊永遠同步。

加了結構化資料，多久會被 AI 引用？

沒有人能給你保證的時間表，任何宣稱「保證被引用」的說法都不可信。結構化資料是提高被正確理解與引用「機率」的基礎工程；能不能被引用，仍取決於內容本身的品質、可信度與相關性。

想知道你的網站對 AI 是否可讀？

若你不確定網站有沒有結構化資料、有沒有重複衝突、標記與內文是否一致，我們可以幫你檢查。預約免費 SEO 健檢，我們會實際讀你網站的標記，告訴你 Google 與 AI 現在怎麼理解你——以及哪裡能做得更好。

我們是豐遠資訊（Richers），專做 WordPress 架站與 SEO 的顧問團隊。這篇不是理論，而是一份實戰復盤：2026 年 8 月 Google 垃圾更新（August 2026 spam update）過後，我們接手一個雙北在地水電服務網站的止血與重建。為保護客戶，站名不揭露，以下一律以「這個在地服務網站」稱呼；但每一個數字都是我們實際做過、可查證的。

作者：豐遠資訊 Richers 團隊　｜　最後更新：2026-09-13

先講結論：這是一次「重建品質訊號」，不是再灌一波內容

很多人流量一掉就急著多發文章補回來——這往往是把網站推下懸崖的那隻手。我們的方向相反：大幅減少機器批量產生的低品質頁面，把散落的薄內容收斂成少數扎實的主題專題，再用結構化資料與答案先行的寫法，讓 Google 與 AI 搜尋都清楚讀懂「這個網站是誰、擅長什麼」。這就是生成式引擎優化（GEO）在真實網站上的落地。

誠實地說：本文只呈現「我們做了什麼、為什麼這樣做」。流量是否回升仍在觀察期——Google 需要時間重新爬取與評估，我們不宣稱已回升多少百分比，也不對排名打包票。這是我們對每個客戶都堅持的立場。

背景與問題：8 月垃圾更新打的是什麼

這個網站在 2026 年 8 月中下旬遭遇斷崖式下滑。以 Google Search Console 的前後 28 天對照：

指標	下滑後 28 天	下滑前 28 天	變化
自然點擊	174	893	約 −80%
曝光	13,525	41,282	約 −67%

關鍵在於掉法：不是單一頁面出問題，而是幾乎每個主力頁都同時掉了 8~9 成，這是典型的整站型降權。伺服器回應正常（HTTP 200）、robots.txt 沒擋、沒有技術錯誤，時間點正好落在 August 2026 spam update 的推出區間。換句話說，Google 這次掃的不是某一頁的技術毛病，而是整個網站的內容品質輪廓（content profile）。

診斷：內容農場結構、索引膨脹、薄頁過多

我們盤點了整站 sitemap 與內容抽樣，問題很清楚——這是一個內容農場結構的網站，可索引網址接近 2.5 萬個，真正有商業價值、對得上服務的內容只佔一小部分。膨脹主要來自三塊：

• 自動生成的標籤彙整頁：約 1.6 萬頁，幾乎都是薄內容、彼此高度重複，帶不進自然流量，卻大幅拉低全站品質比。
• 薄／重複／離題文章：大量文章內容單薄或互相重複，甚至有拜拜、風水這類與水電無關的「流量誘餌」文，稀釋了主題一致性。
• 過多的分類彙整頁：分類頁數量遠超實際需要的核心服務類別。

這正是「大量產出、缺乏商業對映、沒有第一手素材」的失敗模式，也正是垃圾更新要打的輪廓。問題不在網站不夠大，而在於低品質頁面比例太高，把少數好內容的訊號給淹沒了。

我們的處置：五個動作，每一個都對得上真實數字

一、去膨脹：把低價值頁面移出索引

止血第一步，是讓 Google 只看到值得看的頁面。我們用 noindex（而非直接刪除，保留可回滾空間）把大量低價值頁面請出索引：

處置對象	數量	作法
標籤彙整頁	約 15,887 頁	整批設 noindex, follow
薄／重複／離題文章	189 篇	逐篇判定後 noindex
分類彙整頁	92 個	保留核心服務分類，其餘 noindex

原則是「有自然流量的頁面一律保留」——逐頁對照 GSC 點擊數據，只對真正沒流量、又稀釋主題的頁面下手，避免誤殺。單這一步，就大幅拉高了全站的品質比。

二、專題收斂：把數十篇薄文合併成主題專題（pillar-cluster）

散落各處、彼此競食（cannibalization）的薄文，我們收斂成少數幾個主題專題：一個扎實的核心頁，統整同一主題原本被拆散的內容。每篇留存內容都明確對映到一個服務頁，並用內鏈導向詢價／估價頁。這讓 Google 更容易判斷哪一頁是主題的權威頁，也讓讀者更快找到能成交的路徑。

三、補結構化資料（Schema）：讓機器讀懂「你是誰」

我們替網站補上 Organization 與 LocalBusiness 等結構化資料，用機器讀得懂的方式說明這個網站是誰、服務範圍在哪、提供哪些服務。這是 GEO 的地基：AI 搜尋與 AI Overview 在決定要不要引用一個來源時，第一件事就是要能清楚辨識這個實體。結構化資料統一交由站台機制產生，內容本身只輸出乾淨 HTML，不在內文硬塞 schema 標記——這也是避免內容與標記不一致（近似 cloaking）的正確做法。

四、答案先行的 FAQ 與 E-E-A-T：讓內容值得被引用

我們把 FAQ 全面改成「答案先行」——每個問題第一句就直接給答案，後面才補充細節；這種可摘錄格式，正是 AI Overview 與生成式引擎最容易擷取引用的形態。同時補上作者署名與內容更新日期，強化 E-E-A-T（經驗、專業、權威、可信）訊號。內容裡放的是這個團隊真實做過的案場、實際費用級距與處理經驗——有第一手素材才寫，沒有就不生成、不杜撰。

五、修好全站破圖：清掉拖累品質的技術債

盤點時我們發現全站有大量外部圖片破圖——原因是一個外掛把數千張外部特色圖導經第三方代理層，該層限流時就散出一堆破圖。破圖既傷使用者體驗，也是品質訊號的扣分項，我們用一個設定一次修好全站、讓圖片改為直連。

這套方法論，可以複製到哪些產業

這不是水電業專屬的解法。任何曾為了衝量而大量產出、導致索引膨脹與薄內容過多的網站，都適用同一套邏輯：

• 在地服務業（清潔、搬家、維修、裝修）：常用大量地區＋服務關鍵字批量生成頁面，最需要專題收斂與 LocalBusiness 結構化資料。
• 電商與商品目錄站：自動生成的標籤、篩選、分頁頁面最容易造成索引膨脹。
• 媒體／內容站：長年累積的舊文與標籤頁，稀釋了有價值內容的訊號。
• B2B 與專業服務：需靠結構化資料與答案先行，在 AI 搜尋時代被正確辨識與引用。

共通心法只有一句：SEO 與 GEO 的競爭力來自品質訊號的密度，不是頁面的數量。

觀察中的下一步

我們對成效的態度保守而誠實。上述處置都已上線，但Google 需要時間重新爬取整站、重新評估品質，成效目前仍在觀察期。接下來我們持續追蹤：

• 被 noindex 的頁面是否確實退出索引（依重爬進度）。
• 收斂後的專題頁，在核心商業關鍵字上的曝光與排名變化——看叢集的組合表現，不是全站總流量。
• 改寫前後的頁面，在重新被爬取後的點擊／曝光對照。
• 內容在 AI 搜尋與 AI Overview 的被引用情形。

我們不會、也不建議任何人在這個階段宣稱「已經回升幾成」或「保證回到第一頁」。負責任的說法是：我們已經把該重建的品質訊號重建好了，剩下的交給時間與數據驗證。

常見問題（FAQ）

網站被垃圾更新掃到，是不是多發文章就能救回來？

通常相反。如果下滑的原因是低品質頁面比例過高，再灌內容只會讓問題更嚴重。優先要做的是去膨脹、收斂與提升既有內容品質，而不是增加數量。

把上萬個頁面設 noindex，不會傷到流量嗎？

只要判定得當，不會，反而是止血關鍵。我們的原則是「有自然流量的頁面一律保留」，只對沒流量、又稀釋主題的頁面下手，並用 noindex 而非刪除，保留可回滾空間。

GEO（生成式引擎優化）和傳統 SEO 是兩件事嗎？

不是，GEO 是 SEO 的延伸。結構化資料、答案先行、乾淨可讀的內容，同時服務傳統排名與 AI 搜尋／AI Overview 的引用，地基是同一套品質工程。

想知道你的網站現在的體質如何？

如果你的網站也在近期演算法更新後掉了流量，或你懷疑自己累積了太多薄頁與索引膨脹，我們可以幫你做一次體檢，看看問題出在哪、有哪些可以先止血。

了解我們的做法，請看 豐遠資訊 SEO 服務；想直接知道你的網站現況，歡迎預約免費 SEO 健檢，我們用實際數據跟你說明可以怎麼做。

什麼是生成式引擎優化（GEO）？為什麼企業現在要關心

過去我們在 Google 打關鍵字，看到的是十條藍色連結；現在愈來愈多搜尋，最上方直接出現一段由 AI 生成的摘要（Google 稱為 AI Overview），或使用者根本改用 Perplexity、ChatGPT 這類工具直接問答案。生成式引擎優化（GEO），就是讓你的內容在這種「AI 先幫使用者讀完、再給一段答案」的環境裡，仍然能被讀懂、被信任、被引用的優化工作。

它有幾個常見的別名：AI 搜尋優化、答案引擎優化、AI Overview 優化，指的其實是同一件事。（提醒：台灣講的「AEO」通常是指海關的優質企業認證，和這裡的 AI 搜尋沒有關係，因此本文一律使用「GEO／生成式引擎優化／AI 搜尋優化」。）

為什麼「排第一」也可能流量下滑

對企業主最直接的衝擊是：排名和流量開始脫鉤。當 AI Overview 已經在搜尋結果最上方，用你的內容整理出一段答案，使用者看完就滿意了，不一定會再點進你的網站。也就是說，就算你辛苦排到第一，也可能拿不到過去該有的點擊。這不是排名掉了，而是「被看見的方式」變了——內容有沒有被 AI 選為引用來源，開始和排名一樣重要。

內容要被 AI 引用，要做對的關鍵要素

AI 引用內容時，偏好「機器容易讀懂、答案容易擷取、來源值得信任」的頁面。以下五個要素，是我們協助客戶做 GEO 時最優先處理的：

1. 結構化資料（Schema）：用機器讀得懂的格式，明確告訴搜尋引擎「你是哪一間公司、提供什麼服務、在哪個地區、聯絡方式是什麼」。這是實體化（Entity）的地基，讓 AI 有信心把你當成可引用的來源，而不是一堆猜測的文字。
2. 答案先行：每一個段落、每一個問題，第一句就把結論講完，細節與理由放在後面。AI 摘錄時是抓「最像答案的那一句」，鋪陳太久的內容很難被擷取。
3. 實體與 E-E-A-T：清楚呈現作者是誰、公司背景、真實案例與數據、更新日期。經驗（Experience）、專業（Expertise）、權威（Authoritativeness）、可信（Trust）這四項，是 AI 判斷「要不要相信並引用你」的依據。
4. FAQ 常見問題：把使用者真正會問的問題，用「一問一答、答案先行」的方式整理成 FAQ。這種格式最容易被 AI Overview 與「其他人也問」（People Also Ask）直接引用。
5. 內容深度與收斂：與其寫一百篇淺薄的短文，不如把同一主題收斂成一篇夠深、夠完整的主軸內容，再用內鏈串起相關文章。內容深度不夠，AI 沒有理由選你。

傳統 SEO 與 GEO 有什麼不同

GEO 不是把 SEO 打掉重練，而是在既有基礎上多做幾件事。兩者的差異可以這樣對照：

面向	傳統 SEO	生成式引擎優化（GEO）
成效衡量	關鍵字排名、點擊率	是否被 AI 摘要引用、AI 來源帶來的到站
內容寫法	圍繞關鍵字鋪陳	答案先行、可被機器擷取的段落與 FAQ
結構化資料	加分項	近乎必備的實體化地基
爬蟲對象	Googlebot 為主	再加上 GPTBot、ClaudeBot、PerplexityBot 等 AI 爬蟲
內容策略	單篇針對單一關鍵字	主軸文＋支援文收斂成主題叢集

結論很簡單：做好 SEO 的基本功仍然是前提，GEO 是在這之上，把內容整理成 AI 也讀得懂、願意引用的樣子。

豐遠怎麼幫客戶做 GEO：方法與立場

我們不保證排名，但這五件事一定做到

市場上有人敢「保證上首頁、保證被引用」。我們刻意不這麼說——搜尋結果與 AI 引用由 Google、各家 AI 模型決定，沒有人能保證。我們能承諾的，是這五件可被驗證、對 GEO 真正有幫助的工程一定做到：

1. 建立單一 @graph 結構化資料，把公司、網站、服務、地區等實體一次講清楚，節點彼此互相參照。
2. FAQ 直接從內文解析：畫面上看到的問答，就是餵給機器的內容，不做「給人看一套、給機器看另一套」的 cloaking。
3. 內容一律答案先行改寫，讓每段第一句就是可摘錄的答案。
4. 做好 AI 爬蟲可讀性：檢查 robots.txt、視情況提供 llms.txt，確認主流 AI 爬蟲讀得到內容。
5. 把薄內容收斂成主題叢集，並以內鏈導向對應的服務頁，讓權重集中、動線清楚。

新站本身就是作品

我們把上面這套方法先用在自己的新網站上：全站採單一 @graph 實體化、FAQ 從內文解析、附上 llms.txt，並實測 GPTBot、ClaudeBot、PerplexityBot 等五種 AI 爬蟲皆可正常讀取（回應 200）。我們也遇過真實踩坑——網域的 robots.txt 被主機邊緣強制擋成不給爬，於是我們用一層 Cloudflare Worker 代理，讓 Google 與 AI 爬蟲拿得到正確的 robots.txt。這些不是投影片上的名詞，是我們自己站上跑著的做法。

實例：把被垃圾更新掃到的在地服務網站救回來

我們協助過一個在地水電服務網站。問題：2026 年 8 月的一次 Google 垃圾內容更新（spam update）後，它的自然點擊掉了約八成、曝光掉約六成七。診斷後發現典型的內容農場結構——全站約兩萬五千個可索引網址，其中約六成是自動生成、沒有實質內容的標籤彙整頁，把整站的品質訊號往下拉。

我們做了什麼：

• 收斂薄頁：將約一萬六千個薄標籤頁與數十個非核心分類設為不索引（noindex），把少數離題誘餌文一併退出索引，讓「有實質內容的頁面」占比拉高。
• 強化商業核心：挑出幾個真正有商業意圖的主力頁，改寫成答案先行、含真實案場與報價級距（不列明細，避免被拿去現場比價）的內容，並以內鏈導向估價頁。
• 補結構化資料：以外掛注入單一來源的 LocalBusiness／Organization／WebSite 實體，讓機器讀得懂這是誰、服務哪個地區。

誠實說明：這個案子的復原成效目前仍在觀察中（Google 需要時間重新檢索被 noindex 的頁面），所以我們不會宣稱「已經回升多少百分比」。這裡分享的是我們判斷問題的邏輯與實際動的手，而這套「收斂薄內容、補實體、答案先行、內鏈導錢頁」的方法論，正是 GEO 時代該有的體質——它同樣適用於你的網站。

常見問題

GEO 和 SEO 是一樣的東西嗎？

不完全一樣，但高度重疊。SEO 是基本功，GEO 是在做好 SEO 的前提下，額外把內容整理成 AI 讀得懂、願意引用的樣子。做 GEO 不會浪費你原本的 SEO 投資，兩者相輔相成。

做 GEO 一定要重做網站嗎？

多數情況不用。大部分工作是在既有網站上補結構化資料、改寫內容成答案先行、整理內鏈與 FAQ。除非現有網站技術體質太差（例如爬蟲讀不到、大量薄頁），才會建議搭配改版一起處理。

小型企業網站也需要 llms.txt 嗎？

不是必需，但成本低、值得先做。llms.txt 是一份給 AI 模型參考的網站導覽，能幫助它更快理解你的重點內容。對頁數不多的網站，優先順序低於結構化資料與答案先行的內容，行有餘力再補即可。

怎麼知道我的內容有沒有被 AI 引用？

目前沒有像關鍵字排名那樣現成的工具，通常用兩種方式觀察：一是實際到 AI Overview、Perplexity 等平台搜尋相關問題，看是否引用到你的頁面；二是在 GA4 追蹤來自 AI 平台（如 perplexity.ai、chatgpt.com）的到站流量。這塊仍在早期，我們會協助你把量測先建好。

做 GEO 多久會看到成效？

沒有標準答案，取決於網站現況、內容品質與競爭程度。結構化資料與技術面的改善通常較快被檢索到；內容體質的調整則需要 Google 與 AI 模型逐步重新評估。我們不會給你一個保證的時間或名次，只會把該做的體質工程做到位。

想知道你的網站在 AI 搜尋時代的表現？

AI 搜尋改變的速度比多數人想像得快。如果你不確定自己的網站在結構化資料、內容體質、AI 爬蟲可讀性上做得如何，歡迎預約我們的免費 SEO 健檢，我們會實際檢視你的網站，指出最值得先處理的地方。想進一步了解我們如何協助企業做 SEO 與 GEO，可以參考SEO 服務。