知識庫

面對不講武德的 AI 爬蟲，網站主不能只靠單一方法防守。因為許多粗暴的爬蟲不只會大量抓取頁面，還可能偽裝成正常瀏覽器、無視 robots.txt，甚至使用無頭瀏覽器模擬真人行為。
如果只靠單一防線，例如只寫 robots.txt、只封鎖 User-Agent，或只安裝一個外掛，往往很快就會被繞過。真正有效的做法，是建立一套「多層次防禦機制」，從溫和的規則宣告，到伺服器層級限制，再到 CDN / WAF 防護與應用層陷阱，逐步提高防禦強度。

這篇文章將整理 4 個層級的 AI 爬蟲防護方式，幫助網站主在不影響正常訪客與搜尋引擎的前提下，降低惡意 AI 爬蟲對伺服器資源、頻寬與網站速度的影響。

為什麼 AI 爬蟲不能只靠單一方法阻擋？

AI 爬蟲的麻煩之處，在於它們的行為不完全相同。有些大型公司的官方爬蟲會遵守 robots.txt，有些資料抓取器會明確標示自己的 User-Agent，但也有不少爬蟲會偽裝成一般瀏覽器、使用資料中心 IP 大量請求，甚至透過無頭瀏覽器完整載入網頁。

因此，單一防護方式通常只能解決其中一部分問題：

• robots.txt： 可以告訴合規爬蟲不要抓取，但無法強制阻止惡意爬蟲。
• User-Agent 封鎖： 可以擋掉明顯機器人，但擋不住偽裝成 Chrome、Safari 的爬蟲。
• IP 封鎖： 可以阻擋特定來源，但爬蟲可能更換 IP 或使用代理。
• CAPTCHA： 可以攔截部分機器人，但若使用不當，可能影響真人使用體驗。

所以，正確的防護策略應該是分層處理：先用低成本方式宣告規則，再用伺服器限制高頻請求，接著透過 CDN / WAF 在源站前面過濾流量，最後才針對高風險行為設計應用層陷阱與驗證機制。

AI 爬蟲防護 4 層架構總覽

第一層：基礎宣告防護

第一層防護，是透過 robots.txt 向爬蟲宣告網站規則。這是最基本、成本最低，也最不影響正常訪客的方式。

robots.txt 位於網站根目錄，例如：

https://example.com/robots.txt

它的作用是告訴搜尋引擎、AI 爬蟲或其他自動化程式：「哪些路徑可以抓，哪些路徑不希望被抓」。

雖然惡意爬蟲不一定會看規則，但像部分大型公司的官方爬蟲，通常仍會參考 robots.txt。因此，第一步仍建議先建立清楚的宣告。

• 更新 robots.txt 檔案： 在網站根目錄的 robots.txt 中，明確拒絕已知 AI 爬蟲或資料抓取器。

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Anthropic-ai
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Bytespider
Disallow: /

註：CCBot 是 Common Crawl 的爬蟲，許多開源資料集或 AI 訓練資料都可能與其資料來源有關。不同 AI 爬蟲的名稱可能會隨時間變動，建議定期檢查與更新 robots.txt。

如果只想禁止 AI 爬蟲抓取特定區域，也可以針對路徑設定：

User-agent: GPTBot
Disallow: /knowledgebase/
Disallow: /blog/
Disallow: /downloads/

User-agent: CCBot
Disallow: /knowledgebase/
Disallow: /blog/
Disallow: /downloads/

需要注意的是，robots.txt 是一種「規則宣告」，不是防火牆。它不能真正阻止請求進入網站，也不能防止惡意爬蟲偽裝身份。

簡單來說，robots.txt 是告示牌，不是鐵門。它適合約束守規矩的爬蟲，但無法阻止不守規矩的爬蟲。

第二層：伺服器層級阻擋

如果爬蟲無視 robots.txt，下一步就要在伺服器層級直接處理。這一層的目標，是讓異常請求在進入網站程式之前就被拒絕，避免它們繼續消耗 PHP、MySQL、CPU 與記憶體資源。

伺服器層級阻擋通常會從兩個方向進行：

• User-Agent 黑名單： 阻擋明顯不是正常瀏覽器的請求。
• Rate Limiting： 限制短時間大量請求，避免伺服器被瞬間打滿。

1. User-Agent 黑名單

User-Agent 是瀏覽器或程式在請求網站時會帶上的身份資訊。正常瀏覽器通常會顯示 Chrome、Safari、Firefox、Edge 等資訊；但許多簡易爬蟲、掃描器或自動化工具，可能會直接顯示 python-requests、curl、wget、scrapy 等字眼。

這類請求通常不會像正常使用者一樣瀏覽網站，而是大量抓取頁面、測試路徑或掃描資料。因此，可以在伺服器層級直接拒絕。

Apache / .htaccess 範例：

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} (python-requests|curl|wget|scrapy|libwww-perl|httpclient|Go-http-client) [NC]
RewriteRule .* - [F,L]

Nginx 範例：

if ($http_user_agent ~* "(python-requests|curl|wget|scrapy|libwww-perl|httpclient|Go-http-client)") {
    return 403;
}

不過，User-Agent 黑名單只能阻擋「誠實表明身份」或寫得較粗糙的爬蟲。如果對方偽裝成正常 Chrome 或 Safari，單靠這一招就不夠。

2. IP 頻率限制 Rate Limiting

Rate Limiting 是對付高併發爬蟲最有效的基礎手段之一。它的概念很簡單：同一個 IP 或同一類請求，在一定時間內只能存取一定次數；一旦超過限制，就回傳 429 Too Many Requests，或暫時封鎖該來源。

這可以有效緩解以下情況：

• 同一 IP 在幾秒內請求數十到數百個頁面。
• 大量請求搜尋頁、分類頁、標籤頁。
• 重複打登入頁、API 或表單頁。
• 爬蟲快速掃描文章列表與分頁。

Nginx Rate Limit 範例：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;

    server {
        location / {
            limit_req zone=one burst=20 nodelay;
        }
    }
}

上述範例代表每個 IP 平均每秒允許 5 個請求，並允許短暫 burst。實際設定需依網站流量、架構與訪客行為調整，不建議直接套用到所有網站。

對於 WordPress、WHMCS、購物網站或會員系統，建議特別針對以下路徑做限制：

• /wp-login.php、/wp-admin
• /xmlrpc.php
• /wp-json
• 搜尋頁，例如 /?s=、/search
• API、登入頁、註冊頁、表單送出頁

注意： Rate Limit 設太鬆沒有作用，設太嚴則可能誤傷正常訪客、搜尋引擎、付款回調或 API 串接。建議先觀察 Log，再依照實際情況逐步調整。

第三層：導入 CDN 與 WAF 服務

如果不想把所有防護壓力都放在源站主機上，導入 CDN 與 WAF 是非常重要的一層。

CDN 的價值不只是加速網站，而是讓訪客與爬蟲先經過 CDN 節點，再決定是否放行到源站。這樣可以在流量進入主機前，就先完成快取、過濾、挑戰與封鎖。

常見做法包含：

• 快取靜態資源： 讓圖片、CSS、JS、字型由 CDN 回應，降低源站壓力。
• WAF 規則： 針對 User-Agent、IP、國家、ASN、路徑進行過濾。
• Bot 防護： 辨識自動化流量，對可疑來源進行挑戰或封鎖。
• Rate Limit： 在 CDN 層限制高頻請求，避免請求打回源站。

1. 使用 Cloudflare 等 CDN 服務

對多數中小企業網站來說，Cloudflare 是最常見的入門選擇。只要 DNS 正確代理，網站流量就會先進入 Cloudflare，再由 Cloudflare 決定是否回源。

可以考慮的設定方向包含：

• 開啟 CDN Proxy，讓網站流量經過 Cloudflare。
• 針對圖片、CSS、JS 設定快取。
• 對搜尋頁、API、登入頁設定 Rate Limit。
• 對可疑 User-Agent 設定 Managed Challenge 或 Block。
• 對高風險國家、資料中心 ASN 或異常 IP 進行限制。

2. WAF 規則範例方向

WAF 可以針對特定條件建立規則，例如：

• User-Agent 包含明顯 AI Bot 名稱時，要求驗證或封鎖。
• 非正常瀏覽器大量打搜尋頁時，限制存取。
• 某些 IP 短時間請求大量文章頁時，觸發挑戰。
• 針對 /wp-login.php、/xmlrpc.php、/admin 等高風險路徑提高安全等級。

WAF 的優點是可以比單純伺服器規則更彈性，也能在請求進入源站前先處理掉。這對於主機資源有限的網站特別重要。

3. 瀏覽器指紋與無頭瀏覽器辨識

有些高階爬蟲會偽裝成一般瀏覽器，甚至使用 Headless Chrome 來完整載入頁面。它們看起來像正常使用者，但行為模式仍可能和真人不同。

高階 WAF 或 Bot 防護服務可以透過瀏覽器特徵、JavaScript 行為、Cookie、TLS 指紋、滑鼠行為與請求模式，判斷對方是真人瀏覽器，還是自動化工具。

如果網站經常受到高階爬蟲影響，單純封鎖 User-Agent 可能不夠，這時就需要透過 CDN / WAF 進行更細緻的判斷。

第四層：網站架構與應用層陷阱

當爬蟲偽裝得越來越像真人，伺服器規則與 WAF 有時也需要搭配應用層設計，才能更準確地辨識異常行為。這一層的重點不是只靠封鎖，而是讓機器人自己暴露行為。

1. 無感驗證碼 CAPTCHA

傳統驗證碼需要使用者點圖片、找紅綠燈、輸入文字，容易影響使用體驗。現在比較常見的方式，是使用 Cloudflare Turnstile、Google reCAPTCHA v3 等無感或低干擾驗證方式。

這類工具會在背景判斷使用者行為、瀏覽器環境與風險分數，若判斷為正常人類，通常不會出現額外操作；若判斷為機器人或可疑請求，才會要求驗證或阻擋。

適合加上 CAPTCHA 的位置包含：

• 登入頁
• 註冊頁
• 聯絡表單
• 詢價表單
• 留言區
• API 高風險操作入口

不建議將 CAPTCHA 無差別套用到所有頁面，否則可能影響正常訪客體驗，甚至降低轉換率。

2. 佈署蜜罐陷阱 Honeypot

Honeypot 的概念，是在網頁中放入真人看不到、但爬蟲可能會抓到的假連結、假欄位或假路徑。正常使用者不會點擊或填寫這些內容，但自動化爬蟲可能會無差別存取。

例如在 HTML 中放入一個隱藏連結：

<a href="/crawler-trap" style="display:none;" aria-hidden="true">hidden link</a>

正常人類不會看到，也不會點擊這個連結。但如果某個 IP 存取了 /crawler-trap，就代表它很可能是自動化爬蟲。這時可以將該 IP 加入觀察名單、提高挑戰等級，或直接封鎖。

Honeypot 也可以用在表單中，例如加入一個隱藏欄位：

<input type="text" name="website_url" style="display:none;" tabindex="-1" autocomplete="off">

正常使用者不會填寫這個欄位，但機器人可能會自動填入。若表單送出時該欄位有值，就可以判斷為可疑請求。

3. 保護高成本頁面與敏感路徑

有些頁面特別容易被爬蟲濫用，例如搜尋頁、分類頁、標籤頁、登入頁、會員中心、API、後台入口。這些頁面每次請求都可能觸發資料庫查詢、身份驗證或後端運算，因此應該優先保護。

可以採取的措施包含：

• 對搜尋頁加入請求頻率限制。
• 對登入頁加入 CAPTCHA 或雙因素驗證。
• 對 API 加入 Token 驗證與速率限制。
• 對後台入口限制 IP 或改用額外保護路徑。
• 對高成本查詢加上快取或限制條件。

這一層的重點是：不要讓爬蟲可以無限制呼叫最耗資源的功能。

實務建議：防護不應該一開始就全部封死

很多網站主在遇到 AI 爬蟲流量時，會想直接全部封鎖。但實務上，不建議一開始就採取過度激烈的封鎖策略，因為可能誤傷正常搜尋引擎、合作平台、付款回調、API 串接或真實使用者。

比較穩定的做法，是依照以下流程處理：

1. 先觀察網站 Log 與流量來源。
2. 找出高請求 IP、User-Agent 與高成本路徑。
3. 先使用 robots.txt 宣告規則。
4. 對明顯異常的 User-Agent 與路徑做限制。
5. 對高頻請求導入 Rate Limit。
6. 導入 CDN / WAF，將流量擋在源站前。
7. 對高風險表單、登入與 API 加上驗證與 Honeypot。
8. 持續觀察是否誤傷正常訪客，再逐步調整規則。

防護不是封越多越好，而是要讓真人順利進來，讓無效流量被擋在外面。

常見錯誤：這些做法可能讓防護效果打折

• 只寫 robots.txt： robots.txt 只能約束守規矩的爬蟲，無法阻止惡意流量。
• 只封 User-Agent： 爬蟲可以偽裝成正常瀏覽器，因此需要搭配行為判斷。
• Rate Limit 設太嚴： 可能誤傷正常訪客、搜尋引擎或 API 串接。
• CDN 沒有正確代理： 若 DNS 沒有走 Proxy，流量仍然會直接打到源站。
• 源站 IP 外洩： 即使使用 Cloudflare，攻擊者仍可能繞過 CDN 直接打主機 IP。
• CAPTCHA 到處亂加： 可能降低正常訪客體驗與表單轉換率。
• 沒有持續觀察： AI 爬蟲與 Bot 行為會變動，防護規則也需要定期調整。

總結：建立立體防護網，才能真正降低 AI 爬蟲影響

AI 爬蟲帶來的問題，不只是流量變多，而是大量無效請求會消耗網站的 CPU、RAM、資料庫、頻寬與連線數。若沒有妥善防護，正常訪客可能會被拖慢，網站也可能出現 502、503、504 等錯誤。

要有效阻擋 AI 爬蟲，不能只依賴單一方法，而是需要建立多層次防線：

• 第一層： 使用 robots.txt 宣告規則，約束合規爬蟲。
• 第二層： 在伺服器層級阻擋可疑 User-Agent 與高頻請求。
• 第三層： 導入 CDN / WAF，把異常流量擋在源站外。
• 第四層： 透過 CAPTCHA、Honeypot 與應用層規則辨識偽裝爬蟲。

真正好的防禦，不是把所有流量都拒絕，而是在不影響真人讀者、搜尋引擎與正常業務的前提下，把無效消耗資源的爬蟲流量降到最低。

從基礎宣告到強制封鎖，從源站保護到應用層陷阱，只有建立完整的立體防護網，網站才能在 AI 流量爆炸的時代，守住自己的速度、穩定性與伺服器資源。

延伸閱讀

• AI 爬蟲卡頓與中小企業風險： 網站流量暴增卻沒有訂單？小心是 AI 爬蟲正在吃掉你的主機資源
• Cloudflare 防護實戰： Cloudflare 能擋 AI 爬蟲嗎？用 CDN、WAF 與 Rate Limit 降低網站卡頓與流量爆炸