Cloudflare DNS 配置如何影響 SEO 排名？CDN 與解析速度的關鍵設定

先說結論... 設定比你想的更重要

嗯... 今天想聊聊 Cloudflare 跟 SEO。很多人都說，用了 Cloudflare 網站就會變快，排名就會變好。這個... 說對也對，但... 不完全是這樣。

我自己是覺得，它比較像一把雙面刃。設定對了，是真的能幫你，但如果... 你只是點一點，全部用預設值，有時候，甚至可能會有反效果。說真的，魔鬼都藏在細節裡。

為什麼大家說的「開了就好」是錯的？

我看了很多教學，大部分都在講怎麼註冊、怎麼把 DNS 換過去。像是 LOYSEO 或 Wumetax 的文章，都寫得很詳細，步驟很清楚。但很少有人提到... 為什麼有些設定要那樣選，或是... 選錯了會怎樣。

有一個比較少人提的點，是「共享 IP」的問題。在一些比較舊的討論裡，像是 Reddit 上就有人說，因為 Cloudflare 的免費版會讓你的網站跟很多... 嗯，各式各樣的網站，放在同一個 IP 位址下。如果你的鄰居是... 比較不好的網站，Google 可能會對這個 IP 有點... 戒心。雖然現在這個影響應該很小了，但這件事告訴我們，它不是一個完美的解決方案。

還有一個更大的問題，是設定錯誤。你開了快取，結果把不該快取的東西也存起來了... 像是購物車。那使用者看到的永遠是舊的，這體驗就很差，SEO 自然也不會好。

所以，到底要怎麼設定？

我覺得不用去記每一個按鈕。你只要理解幾個... 核心觀念就好。

第一步：DNS，一切的起點

當你把網域的 Name Server 指向 Cloudflare 之後，所有的「問路」請求都會先到它那裡。這一步... 影響的就是 TTFB (Time to First Byte)，就是... 伺服器回應第一個位元組的時間。DNS 解析越快，TTFB 的基底就越好。Kinsta 有篇文章也提過 DNS 對 TTFB 的影響。

在 Cloudflare 的 DNS 設定頁面，最重要的就是 A 紀錄跟 CNAME。A 紀錄就是... 把你的網域名稱（www.example.com）指向你主機的 IP 位址。這裡的重點是... 那個橘色雲朵的圖示，一定要亮起來。亮著橘雲，代表流量有經過 Cloudflare 的 CDN 和防火牆。如果是灰雲，那就只是單純的 DNS 解析，流量是直接回到你的主機。

我自己的習慣是，主網域（A 紀錄）跟郵件相關的（MX 紀錄）一定會再三確認。之前就有客戶自己亂改，結果信箱就收不到信了... 這真的很麻煩。

第二步：CDN 快取，這最容易出錯

CDN 的原理，就是把你的網站內容... 像是圖片、CSS、JS 這些不太會變動的檔案，複製一份到全世界各地的節點。這樣，不管使用者在哪，都可以從最近的地方抓資料，速度當然快。這對 Core Web Vitals 裡面的 LCP (最大內容繪製) 很有幫助。

但問題來了... Cloudflare 預設只會快取這些靜態檔案。你的 HTML 頁面本身，預設是不會快取的。如果你想讓 TTFB 變得更極致，你可以用 Page Rule 設定「Cache Everything」。

可是！... 這就是我說的陷阱。一旦你設定了 Cache Everything，它會把整個頁面都存成一份靜態檔。如果你的網站是部落格，那沒問題。但如果是電商網站，或是任何需要會員登入的地方... 那就完蛋了。每個使用者都會看到同一份被快取的頁面，那登入狀態、購物車內容全都會亂掉。

所以，比較好的做法是... 你要用 Page Rule 加上一個條件，例如網址包含 `/wp-admin/` 或是有特定 cookie 的時候，就「Bypass」快取。這樣才能兼顧速度跟功能正常。

第三步：SSL/TLS 加密模式，安全也是排名因素

這部分是為了 HTTPS。Google 早就說過 HTTPS 是排名因素之一。在 Cloudflare 的 SSL/TLS 設定裡，至少要選「Full」。

我解釋一下這幾個模式的差別：

Flexible：使用者到 Cloudflare 是加密的，但 Cloudflare 到你主機是沒加密的。這最不安全，只是讓瀏覽器顯示那個鎖頭圖示而已，有點... 自欺欺人。
Full：使用者到 Cloudflare、Cloudflare 到你主機，全程都是加密的。但它不會驗證你主機上的 SSL 憑證是不是有效。
Full (Strict)：這是最推薦的模式。全程加密，而且 Cloudflare 還會驗證你主機上的憑證必須是有效、而且受信任的。這才算是完整的安全設定。

選錯模式，可能會導致所謂的「混合內容（Mixed Content）」錯誤，或是網站出現重新導向迴圈，直接打不開。這對 SEO 來說是... 災難。

一些有用的加速小設定

在「Speed」>「Optimization」裡面，還有幾個可以順手打開的。

Brotli：這是一種比 Gzip 更強的壓縮演算法，可以讓檔案變得更小。打開它，沒壞處。
Auto Minify：自動幫你壓縮 HTML, CSS, JS 程式碼，拿掉多餘的空白和註解。大部分情況下是安全的，但如果你的網站 JS 寫得比較... 特別，有可能會出錯。

Rocket Loader™

實戰經驗：台灣網站到底有沒有用？

嗯... 這就要講到在地化的問題了。如果你的訪客全部都在台灣，那用 Cloudflare 的 CDN，效果還明顯嗎？畢竟台灣就這麼大。

我的經驗是，還是有差，但差異不像跨國網站那麼巨大。主要好處來自於 DNS 解析速度和... 網路的穩定性。Cloudflare 在台灣有節點，而且跟中華電信這種主要 ISP 的線路品質通常不錯。以前有些國外主機，在晚上尖峰時段，從台灣連過去就會變得很慢。用了 Cloudflare 之後，它會幫你走一條比較穩定的路徑回源，這個「穩定性」對使用者體驗和 Google 爬蟲來說，其實比極限速度更重要。

之前有個客戶的網站，主機在美國，TTFB 在台灣測都超過 800ms。我們沒有換主機，只是套上 Cloudflare，然後用 Page Rule 把首頁跟文章頁設定 HTML 快取，TTFB 就降到 200ms 以下了。這對 SEO 的改善就很直接。

總結一下... 風險與限制

所以，Cloudflare 不是萬靈丹。它最大的風險就是「設定錯誤」。

我整理一下最常看到的幾個問題：

快取了不該快取的內容：這是第一名。造成會員資料錯亂、購物車失效。
SSL 模式選錯：選 Flexible 或 Full，結果網站出現混合內容警告，或是因為主機沒裝憑證，導致一直重新導向，網站掛掉。
防火牆規則太嚴格：WAF（Web Application Firewall）是付費功能，但免費版也有一些基本防護。有時候規則太嚴格，會擋掉正常的 API 請求，或是把 Google 爬蟲擋在門外。這就要去檢查 Log 了。
以為它能解決所有速度問題：Cloudflare 主要是優化「網路傳輸」這一段。如果你的主機本身就很慢、資料庫查詢效率很差，那... 幫助還是有限。它能治標，但不能完全治本。就像 Kinsta 的文章說的，TTFB 受很多因素影響，DNS 只是其中一環。

所以，我的建議是... 抱著一個「優化工具」而不是「解決方案」的心態去用它。慢慢來，一次改一個設定，然後用 PageSpeed Insights 或其他工具去測試。看看改動帶來的是好處還是壞處。這樣... 才能真的發揮它的價值。

你呢？你在用 Cloudflare 的時候，有沒有踩過什麼坑？或是有哪個設定你一直不太確定要怎麼選？可以在下面留言聊聊。