快速答案：部落格要設定 Cloudflare，不是因為「免費 CDN 很香」，而是因為內容站最脆弱的幾件事都發生在主機前面：讀者等太久就離開、機器流量吃掉主機資源、Google 與 AdSense crawler 進不來、SSL 或快取設定一錯就讓網站掛掉。這篇的設定目標很清楚：讓文章頁更快、讓主機少扛一點、讓壞流量少一點，同時保留回退空間，不要為了跑分把 AdSense 和 SEO 穩定性賭掉。
如果你是因為「部落格變慢怎麼辦」、「網站流量異常怎麼辦」、「Cloudflare 擋機器人要怎麼設」才開始搜尋 Cloudflare 設定，這篇會比單純功能介紹更適合你。很多站長不是沒看過 Cloudflare 教學，而是心裡已經有壓力：網站想加速，但怕設定錯；想擋 bot，但怕擋到 Google；想保護 AdSense，但又不知道 Cloudflare 到底能幫多少。
我會寫這篇文章，是因為最近 Maplefeather 的網站流量變大，但流量型態看起來有點異常。我回到 Cloudflare 後台檢查，才發現有些機器人流量並沒有被好好擋下來；同時也注意到部分頁面的載入速度變慢，讀者進文章的等待時間變得不太漂亮。這不是那種「想優化就優化」的情境，而是網站真的開始長大之後，流量品質、速度和廣告穩定性會一起跑來敲門。
那天我沒有直接亂開開關，而是把問題拆開，一邊看 Cloudflare 後台，一邊問 AI：哪些設定可以提高速度、哪些設定能降低機器人流量、哪些功能對 AdSense 或內容站可能有風險。最後我花了兩個多小時，把 AI 給的建議逐項拿去對照 Cloudflare 和 Google AdSense 官方文件，再整理成這份保守版設定。這篇文章，就是想幫你省下那兩個多小時的查找、比對和踩雷時間。
我會建議先把 Cloudflare 想成「放在讀者和主機中間的守門員」，不是一個全能加速按鈕。它可以幫你快取靜態資源、降低原主機壓力、處理一部分惡意 bot、管理 HTTPS 與安全標頭；但它也可能因為設定太激進，讓新文章更新不出來、廣告腳本延遲、RSS 圖片破圖，甚至讓 HSTS 把網站鎖在錯誤憑證裡。
所以這篇不會叫你「能開的全部開」。我會用部落格與 AdSense 收益站的角度，先講清楚為什麼要設 Cloudflare、設了能得到什麼，再給一套保守但實用的第一版設定。你可以先照這套上線，觀察 72 小時，確認廣告、收錄、速度和主機都穩，再慢慢加碼。
為什麼部落格需要 Cloudflare：先解決變慢、流量異常與廣告風險
如果你的網站只是偶爾寫日記，Cloudflare 可能只是讓圖片讀快一點。但如果你靠 SEO、AdSense、聯盟行銷或內容產品變現，Cloudflare 的價值就不只是在速度，而是在降低幾種會直接傷害收入的風險。
站長痛點 | Cloudflare 可以幫什麼 | 不要誤會成什麼 |
|---|---|---|
讀者打開文章很慢 | 快取圖片、CSS、JS、字型等可快取資源，讓頁面骨架更快出來。 | 不是把所有 sharing 後台或其他內容管理系統的動態頁都自動變靜態站。 |
主機被爬蟲或暴衝流量拖慢 | 用快取、Tiered Cache、Bot Fight Mode 和安全事件觀察降低原主機壓力。 | 不是開了就永遠不會被攻擊，也不是取代主機監控。 |
怕 AdSense 無效流量或廣告空白 | 可以減少一部分自動化 bot，並透過觀察 Cloudflare Security Events 找異常來源。 | 不是 AdSense 帳號保證書；Google 仍會看整體流量品質。 |
SEO 收錄和 crawler 穩定性不安 | Crawler Hints 可協助支援的搜尋引擎更快知道內容變動，SSL 與快取穩定也能減少抓取障礙。 | 不是 Google 收錄保證，也不能掩蓋爛內容或錯誤 robots.txt。 |
怕設定錯後很難救 | 把高風險功能分階段開，保留回退路線，讓每次調整都能追蹤原因。 | 不是一份所有網站都能無腦照抄的萬用配置。 |
這也是我這篇最想先講的地方：Cloudflare 設定的目的不是把後台開關調到最滿，而是讓內容站在「讀者、搜尋引擎、廣告系統、主機」之間保持穩定。速度只是其中一塊，對 AdSense 站來說，能不能穩定顯示廣告、穩定被 crawler 存取、穩定更新文章，同樣重要。
部落格變慢、流量異常時，Cloudflare 要先保護四件事
真正有用的 Cloudflare 設定，應該從讀者和站長遇到的問題倒推，而不是從功能清單開始。當你看到頁面變慢、流量來源怪怪的、AdSense 廣告空白變多，第一步不是把開關全打開，而是先保護下面四件事。
- 保護讀者體驗：文章頁、圖片、字型和版面要盡快出來，尤其是手機流量和跨境讀者。
- 保護主機資源：讓可快取資源盡量不要每次都回源，避免主機因爬蟲、社群流量或爆文流量被拖垮。
- 保護 AdSense 與 SEO：擋掉可疑自動化流量，但不能誤傷 Google crawler、AdSense crawler、Search Console URL Inspection 或正常社群預覽。
- 保護回退能力：HSTS、Rocket Loader、Cache Everything、0-RTT 這類一旦出問題不好查的功能，先保守處理。
這四件事的順序很重要。新手最常犯的錯，是把「加速」放到「穩定」前面。跑分變漂亮很誘人，但如果代價是廣告空白、登入頁怪怪的、Crawler issues 變多，對內容站來說就是本末倒置。
Cloudflare 設定總圖：先照四區檢查，不要一次全開
你可以把上面這張圖放在旁邊當第一輪檢查表。我的做法會是先確認安全底線，再開低風險快取，接著處理 AdSense 防禦，最後把容易出事的功能先關掉。這樣做的好處是：如果網站出現廣告空白、抓取異常或版面錯亂，你比較容易知道是哪一組設定造成。
順序我會抓得很保守：先 SSL/TLS，再 Caching，再 Security / Bots，最後才碰 Speed 裡面會改變 JavaScript 行為的功能。這不是最刺激的設定法，但對靠流量變現的網站來說，穩定就是收入的一部分。
設定前先做三個檢查：不要把問題藏進 Cloudflare
在你開始按 Cloudflare 開關之前，先做三個檢查。這一步很無聊，但它會決定後面出了問題時你救不救得回來。
- 確認原主機 HTTPS 本來就是好的：Cloudflare 的 SSL/TLS 模式是管理「讀者到 Cloudflare」和「Cloudflare 到原主機」兩段連線。Cloudflare 官方也建議能用 Full 或 Full Strict 就用 Full / Full Strict。原站憑證若本來就壞，不要急著用 Cloudflare 遮起來。
- 先記錄現在的基準：至少記下主機 CPU、流量、TTFB、LCP、AdSense 廣告空白情況、Search Console 抓取狀態。沒有基準，後面你只會憑感覺猜。
- 每次只改一組設定：今天改 SSL，明天改快取，後天改 bot。不要同一天開 HSTS、Rocket Loader、Cache Everything 和 Bot Fight Mode，否則出事時很難定位。
Cloudflare 設定失控，通常不是因為單一功能很壞，而是太多功能同時改，最後你不知道是快取、JS、憑證、WAF 還是 crawler 被擋。
第一層：SSL/TLS 先穩，避免 Flexible 和 HSTS 鎖站
Cloudflare 的 SSL/TLS 是我會最先處理的地方。原因很簡單：速度問題可以慢慢調，SSL 設錯卻可能讓讀者、Googlebot 和你自己都進不了站。
設定 | 建議 | 目的 | 踩雷提醒 |
|---|---|---|---|
SSL/TLS encryption mode | Full 或 Full Strict | 讓讀者到 Cloudflare、Cloudflare 到原主機兩段連線都安全。 | 不要用 Flexible 當長期設定。原主機已強制 HTTPS 時，很容易遇到重新導向迴圈。 |
Minimum TLS Version | TLS 1.2 以上 | 淘汰太舊的協定，維持瀏覽器相容與安全底線。 | 除非你的讀者真的還有很舊裝置，否則不必為極少數舊環境犧牲安全性。 |
HSTS | 第一次先 1 個月 | 讓瀏覽器記住這個站應該走 HTTPS，降低降級攻擊風險。 | Cloudflare 文件提醒，移除 HTTPS 前未先停用 HSTS，網站可能在 max-age 期間無法被訪問。 |
HSTS includeSubDomains | 第一輪先關 | 避免子網域還沒整理好就一起被強制 HTTPS。 | 子網域如果沒有 HTTPS，開了 includeSubDomains 會直接出事。 |
HSTS preload | 第一輪先關 | 保留回退空間。 | preload 會把回退成本拉高，不適合剛搬站、剛換主機、剛整理子網域的新手站。 |
這裡可以參考 Cloudflare 的 SSL/TLS encryption modes 與 HSTS 文件。我的取捨很單純：HSTS 是好東西，但第一次不要把後悔藥丟掉。
第二層：部落格變慢時，快取要先降低主機壓力
很多人設定 Cloudflare 時會盯著 cache hit rate，看數字越高越安心。但對部落格來說，快取命中率不是唯一 KPI。真正要看的是：讀者打開文章是否變快、主機壓力是否下降、新文章是否正常更新、AdSense 與搜尋 crawler 是否照常運作。
Cloudflare 官方的預設快取行為會尊重許多 origin cache header，也會根據可快取條件處理資源；它不是自動把所有 HTML、登入頁、留言頁和個人化頁面都存起來。這也是為什麼我不建議新手一開始就全站 Cache Everything。
功能 | 第一版建議 | 好處 | 觀察方式 |
|---|---|---|---|
Browser Cache TTL | 先 8 小時，穩定後再拉到 1 天 | 讓回訪讀者的靜態資源更快載入。 | 改版後檢查手機、桌機、無痕視窗是否看到新版 CSS 與版面。 |
Crawler Hints | 開啟 | Cloudflare 會用快取訊號告訴搜尋引擎內容可能已變動，並支援 IndexNow。 | 觀察新文章被 Bing 等支援引擎抓取的速度；不要把它當 Google 收錄保證。 |
Always Online | 內容站可開 | 原主機短暫不可用時，有機會讓讀者看到可用的靜態內容。 | 知道它不能處理登入、表單、API 與所有動態內容，不要當成主機備援。 |
Smart Tiered Cache / Tiered Cache | 開啟 | 降低原主機被重複請求的機率，適合圖片與靜態資源多的內容站。 | 看 origin bandwidth、主機 CPU、Cloudflare Cache Analytics。 |
Cache Everything | 不要全站套用 | 只適合經過規則設計的匿名頁面或特定路徑。 | 如果新文章看不到、留言異常、登入狀態錯亂，先回退這組規則。 |
你可以把快取想成幫文章和廣告「鋪跑道」。Cloudflare 快取的是你網域上的資源，AdSense 廣告本身仍是讀者瀏覽器向 Google 廣告系統請求。頁面骨架越快、圖片和 CSS 越順，廣告比較不容易被整體載入拖累；但這不代表 Cloudflare 會把 Google 廣告快取成同一則給所有人看。
相關官方資料可看 Default cache behavior、Edge and Browser Cache TTL、Crawler Hints 與 Always Online。
第三層：網站流量異常時，先擋機器人但別擋到 AdSense crawler
AdSense 站長最容易焦慮的是無效流量。這個焦慮不是多餘的，因為 Google AdSense 說明裡明確把可能人為增加廣告主費用或發布商收益的點擊、曝光、自動工具、漫遊器和詐騙軟體列入無效流量範圍。問題是，Cloudflare 不能被當成「開了就不會有無效流量」的保險。
我會把 AdSense 防禦拆成兩條線：一條是擋掉可疑自動化流量，一條是確保 Google 與 AdSense 需要的 crawler 可以正常讀到內容。很多站長只做第一條，結果安全規則太硬，反而造成廣告檢索器問題。
設定或觀察 | 建議 | 為什麼 |
|---|---|---|
Bot Fight Mode | 可開，開後觀察 72 小時 | Cloudflare 說明它會偵測並緩解符合已知 bot 模式的流量，但也可能挑戰部分應用流量，所以要看 Security Events。 |
Block AI Bots | 有廣告的主機名稱可優先評估 | Cloudflare 提供「只在含廣告的 hostnames 封鎖」選項，適合想保護廣告頁又不想全站粗暴封鎖的內容站。 |
AdSense crawler issues | 每天看，尤其是改安全規則後 | Google 說明若廣告檢索器無法存取內容，會影響廣告投放；登入牆、robots.txt、地區或 IP 限制、重新導向都可能造成問題。 |
WAF 自訂規則 | 先從明顯異常路徑和來源下手 | 不要一開始就封太廣。內容站需要 crawler、社群預覽和工具存取，不是所有非真人請求都該被擋。 |
我的實務判斷是：只要你改了 bot、防火牆或 AI crawler 設定，就把 AdSense 政策中心、廣告檢索器問題、Cloudflare Security Events、Search Console 抓取狀態放在同一張觀察表。看到廣告空白變多或 crawler errors 增加，先回退最近那一項，不要硬撐。
可參考 Cloudflare 的 Bot Fight Mode、Block AI Bots，以及 Google AdSense 的 無效流量 與 AdSense 檢索器問題說明。
第四層：Rocket Loader 要開嗎？速度功能只開低風險
Cloudflare 的 Speed 頁面很容易讓人手癢，因為每個功能看起來都像會讓網站更快。但對 AdSense 部落格來說，速度功能要先問一件事：它會不會改變 JavaScript 載入順序？
Rocket Loader 的官方說明是延後載入 JavaScript，讓文字、圖片和字型等內容更早渲染。這個方向本身沒錯，但 AdSense、留言功能、目錄、追蹤碼、sharing 後台產生的版型互動，常常都依賴 JS 載入時機。官方也提醒，如果網站出現 JavaScript 或 jQuery 問題，可以停用 Rocket Loader 後重測。
Speed 功能 | 部落格第一版建議 | 理由 |
|---|---|---|
Cloudflare Fonts | 可開 | 風險相對低，主要改善字型載入路徑；開後檢查字型與版面即可。 |
0-RTT Connection Resumption | 純閱讀站可評估，有登入或交易先關 | Cloudflare 說明 0-RTT 對回訪讀者可降低延遲，且支援 GET、HEAD、OPTIONS；有狀態改變流程的網站要更謹慎。 |
Rocket Loader | 先關 | 它會改變 JS 載入時機。對 AdSense 與 sharing 這類內容站後台產生的頁面，穩定比單次跑分重要。 |
Auto Minify / 其他最佳化 | 一次只開一項測 | 若 CSS、JS 已由外掛或建置工具處理，不要重複壓縮到出問題。 |
這裡的取捨不是「不要追速度」，而是把速度放回正確位置。對內容站來說，速度要服務讀者停留、搜尋抓取和廣告穩定，不是讓測速頁面看起來比較漂亮而已。
Cloudflare 設定教學清單：部落格先穩，再快，再加碼
如果你現在只想要一份可以照著檢查的版本，我會從下面這張表開始。這份設定特別適合使用 sharing 或其他後台經營的部落格、自媒體內容站、AdSense 收益站、以 SEO 流量為主的文章站。
區域 | 設定 | 第一版建議 | 主要目的 |
|---|---|---|---|
SSL/TLS | Encryption mode | Full 或 Full Strict | 避免 Flexible SSL 造成 redirect loop。 |
SSL/TLS | Minimum TLS Version | TLS 1.2 以上 | 維持安全底線與主流瀏覽器相容。 |
SSL/TLS | HSTS | 先 1 個月、子網域 off、preload off | 保留憑證與搬站時的回退空間。 |
Caching | Crawler Hints | 開啟 | 協助支援搜尋引擎知道內容變動。 |
Caching | Browser Cache TTL | 先 8 小時，穩定後 1 天 | 加速回訪讀者，又不把改版風險拉太高。 |
Caching | Always Online | 可開 | 原主機短暫不可用時，提高靜態內容可讀機會。 |
Caching | Smart Tiered Cache / Tiered Cache | 開啟 | 降低 origin 重複請求與頻寬壓力。 |
Security / Bots | Bot Fight Mode | 可開，觀察 72 小時 | 降低一部分自動化 bot 流量。 |
Security / Bots | Block AI Bots | 依內容策略選擇 | 保護原創內容與廣告頁，但要考慮 AI 搜尋曝光取捨。 |
Speed | Cloudflare Fonts | 可開 | 改善字型載入。 |
Speed | Rocket Loader | 先關 | 避免 AdSense 與外掛 JavaScript 被改變載入時機。 |
Security | Hotlink Protection | 內容站通常先關 | 避免 RSS、論壇分享、社群預覽或合作同步破圖。 |
我會把這張表當成第一天版本，而不是終極版本。第一天先求穩，第二天看數據，第三天再決定要不要加強 WAF、調長 TTL、設更細的 Cache Rules。成熟的網站優化不是一次打滿，而是每一步都知道自己改了什麼。
調整後 72 小時觀察：看到這些狀況就先回退
Cloudflare 設定改完，真正的工作才開始。尤其是 AdSense 站，不要改完就關掉後台。至少觀察 72 小時，而且這段期間不要同時大改版型、換廣告位置、改快取外掛或搬主機，否則你會找不到原因。
觀察項目 | 去哪看 | 異常時先懷疑什麼 |
|---|---|---|
廣告是否空白變多 | 實際文章頁、AdSense 報表、政策中心 | Rocket Loader、Bot Fight Mode、WAF、AdSense crawler issues。 |
新文章是否正常顯示 | 手機、桌機、無痕視窗、Search Console URL Inspection | Browser Cache TTL 太長、Cache Everything 規則太粗。 |
Google / AdSense crawler 是否被擋 | Search Console、AdSense 檢索器問題、Cloudflare Security Events | WAF 規則、Bot Fight Mode、robots.txt、重新導向。 |
主機 5xx 是否下降 | 主機監控、Cloudflare Analytics、server log | 若沒有改善，問題可能在主機、資料庫、外掛或 PHP，不是 CDN 能單獨解決。 |
讀者速度是否真的變好 | PageSpeed Insights、CrUX、Cloudflare Web Analytics、實際手機測試 | 圖片太大、廣告腳本太多、外掛阻塞、主機 TTFB。 |
我自己的回退原則很簡單：看到異常，不要先改第二個功能來「補救」，先把最近改的那一項退回去。等問題消失，再用更小範圍測一次。這樣做比較慢，但你會真正知道網站的邊界在哪裡。
哪些網站不適合直接照抄這份設定？
這份設定是給內容站、部落格和 AdSense 收益站的保守起手式。如果你的網站有下面這些狀況，就要再把規則切細一點。
- 有會員登入：不要把登入後頁面、會員中心、個人化內容全站快取。
- 有購物車或付款：0-RTT、Cache Everything、過長 TTL 都要更小心，狀態改變型流程不能亂快取。
- 有 API 或表單：Always Online 和快取救不了 POST、API 狀態與動態資料，請用主機監控和備援處理。
- 有大量子網域：HSTS includeSubDomains 不要急著開，先確認每個子網域都有正確 HTTPS。
- 高度依賴 AI 搜尋曝光：Block AI Bots 不要全站無腦封鎖，要先想清楚你要保護內容，還是希望 AI 搜尋能引用。
也就是說，Cloudflare 的第一版設定可以保守共用，但進階規則一定要回到你的網站型態。內容站、會員站、電商站、工具站，本來就不該用同一份開關清單。
查證來源：我用官方文件確認哪些事
這篇的原則是「官方事實加站長取捨」。官方文件能告訴你功能怎麼運作，但不會替你的 AdSense、sharing 後台頁面、主機體質和 SEO 風險排序。我的建議主要是把這些功能放回內容站情境裡。
- Cloudflare：SSL/TLS encryption modes、HSTS、Default cache behavior、Browser Cache TTL、Crawler Hints。
- Cloudflare：Bot Fight Mode、Block AI Bots、Rocket Loader、0-RTT Connection Resumption。
- Google AdSense：無效流量、修正 AdSense 檢索器問題。
常見問題
部落格變慢時，Cloudflare 應該先開哪些設定？
先處理低風險、可回退的設定：Full 或 Full Strict、TLS 1.2 以上、Crawler Hints、Browser Cache TTL 先 8 小時、Always Online、Smart Tiered Cache / Tiered Cache。先不要急著全站 Cache Everything，因為內容站最怕文章更新、留言、登入或後台狀態被錯誤快取。
網站流量異常，可以用 Cloudflare 擋機器人嗎？
可以把 Cloudflare 當成第一層防線，但不要把它當成唯一解法。Bot Fight Mode、Security Events、WAF 規則可以幫你看出和處理一部分異常流量；但如果規則太硬，也可能影響 Google crawler、AdSense crawler 或社群預覽。我的做法是每次只改一組 bot / WAF 設定，觀察 72 小時再決定是否加碼。
Cloudflare 開啟 Bot Fight Mode 就能保證 AdSense 不會有無效流量嗎？
不能。Bot Fight Mode 可以協助處理一部分自動化 bot 流量，但 AdSense 的無效流量判斷仍看整體點擊、曝光、流量來源和行為品質。開啟後要同步觀察 AdSense 政策中心、廣告檢索器問題、Cloudflare Security Events 和流量來源，不要把它當成免死金牌。
sharing 後台的部落格可以開 Rocket Loader 嗎？
我的建議是第一版先關閉。Rocket Loader 會延後 JavaScript 載入，對廣告碼、留言功能、目錄、追蹤碼和 sharing 後台產生的版型互動都可能有影響。真的想測，請在低流量時段或測試站開，並確認 AdSense 空白率、互動功能和 Core Web Vitals 沒變差。
HSTS 要不要直接開一年並套用子網域？
第一次不建議。HSTS 會讓瀏覽器在 max-age 期間強制使用 HTTPS；如果憑證、主機或子網域還沒整理好，開太長會讓回退變困難。新手或剛搬站的部落格，先 1 個月、子網域關閉、preload 關閉，穩定後再逐步加長。
Cloudflare 快取命中率一定要追到 90% 以上嗎？
不一定。內容站真正要看的是讀者體感、TTFB、LCP、主機負載、廣告顯示和文章更新是否正常。為了追高命中率亂開全站 Cache Everything，反而可能讓新文章、留言、登入頁或會員狀態出問題。
最後建議：先保護收益，再追求更快
如果你經營的是靠內容、搜尋與 AdSense 累積收益的部落格，我會把 Cloudflare 的第一目標定成「讓網站穩定地變快」，不是「讓所有功能看起來都開滿」。先用 Full 或 Full Strict 把 SSL 打穩，Rocket Loader 先關，HSTS 先短，Cache Everything 不全站亂套，Bot 防禦開了要觀察，AdSense crawler 要能進來。
這套做法不花俏，但它比較像真正能長期經營網站的人會採用的節奏：先保護讀者體驗、搜尋收錄、廣告投放和主機穩定，再慢慢往更高階的快取規則與安全規則前進。
如果你想延伸看 AdSense 安全與網站收益風險，可以接著看我整理的 AdSense RPM 暴跌與無效流量踩坑。網站速度、安全和廣告收益，最後其實都回到同一件事：讓讀者進得來、看得順、廣告能正常投放，而你也能在出事時知道該從哪裡回頭。
