如果你即將進行大型系統更新、伺服器搬遷，或主機 IP 即將異動，最常見的擔心是：「這會不會害我的 SEO 排名掉下來？」本文先用一張圖把結論講清楚，再附上可以直接逐項勾選的自我檢查清單。

先講結論

如果你即將進行大型系統更新、伺服器搬遷，或主機 IP 即將異動，最常見的擔心是：「這會不會害我的 SEO 排名掉下來？」

直接回答：

主機 IP 異動「本身」對 SEO 幾乎沒有直接影響；數小時的計畫性停機，只要處理方式正確，通常也不會造成排名損失。

真正的風險不在「IP 換了」或「停機了」，而在於「切換過程是否乾淨」以及「停機期間 Google 來爬網站時看到什麼」。

換句話說，這是一件「做對流程就安全、做錯流程才出事」的事，而不是一件本質上危險的事。下面說明原因，並附上一份可以直接拿來逐項勾選的檢查清單。

一、為什麼「IP 異動本身」通常不影響 SEO

Google 索引網站的單位是網域與網址（domain / URL），不是 IP 位址。只要：

  1. 你的網域（例如 yourbrand.com.tw）沒有改變，
  2. DNS 能正確把這個網域解析到新的 IP，

那麼對 Google 而言，它造訪的還是同一個網址、看到的還是同一批內容。IP 在背後換了一個數字，對排名的判斷基準（內容、連結、權重）並沒有改變。

圖解：Google 看的是「網域 / 網址」，不是 IP

網域
yourbrand.com.tw
不變 → DNS 解析 → 新 IP
換成新數字

網域沒變 → Google 造訪的還是同一個網址 → 排名判斷基準不變

少數需要留意的例外

雖然多數情況無礙，但有兩種例外值得確認：

共用主機的 IP 信譽問題（bad neighborhood）如果新主機是共用 IP，而同一個 IP 上有大量垃圾網站或曾被標記為惡意來源，理論上可能受到牽連。選用信譽乾淨的主機商通常就能避免，這在正規主機商身上很少發生。
伺服器地理位置早年伺服器所在國家曾是很微弱的地區性訊號，但現今 Google 主要依賴網域型態（ccTLD）、hreflang 與內容語言來判斷地區，伺服器實體位置幾乎已不構成排名因素。除非你的主機從本地搬到網路延遲極高的海外、導致網站變慢，否則不需要擔心。

二、真正要小心的，是這三件事

風險不在 IP，而在「換的過程」。以下三點才是會真正影響 SEO 的地方。

1
DNS 切換與 TTL 設定
2
停機期間回傳的 HTTP 狀態碼
（最關鍵、最常做錯）
3
新舊主機並行與資料一致性

1. DNS 切換與 TTL 設定

DNS 異動需要時間在全球生效（propagation）。如果沒先處理 TTL，可能出現「一部分使用者與爬蟲連到新主機、一部分還連到舊主機」的混亂期。

什麼是 TTL？

TTL 是「Time To Live」的縮寫，可以理解成 DNS 紀錄的「快取保存期限」。

當有人輸入你的網域時，他的電腦或網路服務商（ISP）會去查詢「這個網域對應到哪個 IP」，查到後會把答案暫時記住一段時間，不會每次都重新查。這個「記住多久」就是 TTL，單位是秒。

舉例：如果 TTL 設成 86400（＝ 24 小時），代表大家查過一次後，接下來 24 小時內都會用記住的舊答案。這時你即使換了 IP，部分使用者仍可能連到舊主機長達一天，直到他們的快取過期才會拿到新 IP。

TTL = 86400（24 小時）
快取很久才過期 → 換 IP 後，部分人最久拖一天才連到新主機。
TTL = 300（5 分鐘）
快取很快過期 → 換 IP 後幾分鐘內就普遍生效。

所以技巧是：換主機前先把 TTL 調短（例如 300 秒＝5 分鐘），讓大家的快取很快過期、很快拿到新 IP，切換就能在數分鐘內生效，而不是拖一兩天。

  • 異動前 24–48 小時，先把 DNS 記錄的 TTL 調低（例如降到 300 秒）。注意：因為原本的舊 TTL 還在生效中，所以要提前一個「舊 TTL 的時間長度」去調，新的低 TTL 才來得及在切換前普及。
  • 切換完成、確認新主機穩定後，再把 TTL 調回正常值（例如 3600 秒以上），減少 DNS 查詢負擔。
  • TTL 通常在你的網域註冊商或 DNS 代管後台（如 Cloudflare、GoDaddy、Gandi 等）的 DNS 記錄設定頁面調整，找到對應的 A 記錄即可修改。

2. 停機期間回傳的 HTTP 狀態碼（這是最關鍵、也最常做錯的一項）

停機本身不可怕，可怕的是「Google 在停機那一刻來爬，看到了什麼訊號」。

停機期間網站回傳 Google 的解讀 後果
503 Service Unavailable + Retry-After ✅ 「網站暫時維護中，稍後再來」 正確、安全，不會掉索引
200 OK（但畫面是錯誤或維護頁） 「這個網址的正式內容就是這頁空白/維護字樣」 可能用維護頁取代原本內容，傷排名
404 Not Found 「這些頁面不存在了」 可能被移出索引
500 Internal Server Error 「網站壞了」 短期無礙，長期累積會掉索引

503
正確做法

200
取代正式內容

404
移出索引

500
久了會掉索引

正確做法：計畫性維護期間，整站（含首頁與各頁）應回傳 503，並附上 Retry-After 標頭，告訴 Google「我只是暫時維護，預計多久回來」。這是 Google 官方建議的標準處理方式，數小時的維護幾乎不會有任何負面影響。

技術備註：請一併確認 robots.txt 在維護期間也是回傳 503，而不是回傳 200 的空白頁或錯誤頁，避免爬蟲對整站抓取行為產生誤判。

如果你從沒設定過 503，該怎麼做？

很多人看到「回傳 503」會卡住，因為平常根本不會碰到狀態碼。其實你不一定要自己寫程式，依照你的情況選一種：

做法 A（最推薦，給非技術人員）：直接交代給工程師或主機商

你不需要自己動手，只要把需求講清楚即可。可以直接複製這句話給對方：

「維護期間請讓全站回傳 HTTP 503（Service Unavailable）狀態碼，並加上 Retry-After 標頭（例如 3600 秒），維護結束後再恢復正常。robots.txt 也請一併回 503。」

對工程師而言這是標準需求，通常幾分鐘就能完成，重點是「明確要求 503」，而不是只說「掛個維護頁」——後者很容易做成錯誤的 200。

做法 B（WordPress / CMS 使用者）：用維護模式外掛，但務必驗證

WordPress 有不少「維護模式（Maintenance Mode）」外掛。但要特別注意：很多免費外掛只是顯示維護畫面，回傳的卻是 200，不是 503，這反而是錯的。挑選時要確認該外掛說明中明確寫到「回傳 503 status code」，啟用後再用下方的驗證方式檢查一次。

做法 C（給工程師：Apache 主機的設定範例）

在網站根目錄的 .htaccess 加入以下設定，把流量導向維護頁並回傳 503：

RewriteEngine On
# （可選）放行你自己的 IP，方便你預覽真實網站
RewriteCond %{REMOTE_ADDR} !=123.123.123.123
# 避免維護頁本身被無限導向
RewriteCond %{REQUEST_URI} !/maintenance.html$
# 其餘所有請求都導到維護頁，並標記為 503
RewriteRule .* /maintenance.html [R=503,L]
# 503 時實際顯示的內容
ErrorDocument 503 /maintenance.html
# 告訴爬蟲多久後再回來（單位：秒，3600＝1 小時）
Header always set Retry-After "3600"

（Nginx 環境則是在 server 設定中以 return 503; 搭配自訂錯誤頁與 add_header Retry-After 3600; 達成，可交由維運人員處理。）

最後一步：一定要「驗證」它真的是 503

設定完不要憑感覺，務必實測確認狀態碼正確：

  • 最簡單：用線上工具（搜尋「HTTP status checker / HTTP header checker」），貼上你的網址，看回傳是不是 503。
  • 瀏覽器：開啟網站 → 按 F12 開啟開發者工具 → 切到「Network（網路）」分頁 → 重新整理頁面 → 點第一筆請求，看 Status 是否為 503。
  • 指令列（給技術人員）：執行 curl -I https://你的網域，確認回應第一行是 HTTP/1.1 503 Service Unavailable，且含 Retry-After 標頭。

重點提醒：「有顯示維護畫面」不等於「回傳 503」。畫面是給人看的，狀態碼是給 Google 看的——這兩件事要分開驗證。

3. 新舊主機並行與資料一致性

  • 切換期間舊主機先不要立刻關閉，保留到 DNS 完全生效、確認新主機穩定為止。
  • 確認搬遷後內容、網址結構、內部連結、圖片路徑完全一致——如果搬主機的同時也動到網址或目錄結構，那才是真正需要做 301 轉址規劃的「網站搬遷」，風險等級完全不同（這種情況請務必事前告知我們）。

三、停機對 SEO 的影響到底有多大？

把握一個原則：短時間（數小時內）的計畫性停機，影響極小甚至沒有影響；問題出在停機時間過長、或回應方式錯誤。

✓幾小時的維護 → 只要回 503，幾乎零影響。
!連續多日的不可用 → 才可能開始影響索引與排名。
×回應方式錯誤（回 200/404/500）→ 即使只停一小時，也可能比正確處理下停一整天更傷。

所以重點再強調一次：不是「停多久」決定風險，而是「停的時候回什麼狀態碼」決定風險。

四、自我檢查清單（可直接逐項勾選）

✅ 異動前（規劃階段）

  • ☐ 確認本次只是「換主機 / 換 IP」，網域與網址結構都不變（若會變動網址，屬於網站搬遷，需另行規劃 301 轉址）
  • ☐ 選用信譽良好的主機商，避免共用到被標記的 IP
  • ☐ 預先把 DNS 的 TTL 調低（建議 300 秒），並安排在低流量時段執行
  • ☐ 準備好維護頁機制，並確認它會回傳 503 + Retry-After，而非 200
  • ☐ 在 Google Search Console 確認目前索引與流量基準，作為事後比對依據
  • ☐ 通知合作的行銷／SEO 團隊預定時段，以便同步監控

✅ 異動中（執行階段）

  • ☐ 維護期間整站（含 robots.txt）回傳 503，而非錯誤頁或 200
  • ☐ 舊主機暫不關閉，待 DNS 生效後再退場
  • ☐ 以工具確認 DNS 已正確解析到新 IP（可用 DNS 查詢工具或 nslookup / dig）
  • ☐ 抽查數個重要頁面，確認新主機上內容與舊主機一致

✅ 異動後（驗收階段）

  • ☐ 全站頁面恢復正常 200 OK，維護頁已關閉
  • ☐ 重要頁面實際開啟測試（首頁、產品/服務頁、聯絡表單）
  • ☐ 表單、金流、追蹤碼（GA4、轉換追蹤等）功能正常
  • ☐ 網站速度未明顯變慢
  • ☐ Search Console 觀察「檢索統計」與「索引涵蓋範圍」是否異常
  • ☐ 後續 1–2 週留意自然流量與排名，與異動前基準比對
  • ☐ 切換穩定後，把 DNS 的 TTL 調回正常值

五、什麼情況建議直接找專業協助？

下列情況風險較高，建議在動工前先諮詢，而非事後補救：

  • 主機搬遷的同時，網址結構、目錄、網域也要變動（屬於真正的網站搬遷）
  • 預期會有長時間（超過一整天）的不可用
  • 網站系統較複雜（會員、金流、多語系、大量動態頁）
  • 不確定自家系統能否正確回傳 503 狀態碼

六、常見迷思澄清

✗ 迷思一：「換 IP 排名一定會掉。」→ 不會。Google 看的是網域與內容，不是 IP 數字。流程做對就沒事。
✗ 迷思二：「停機幾小時很危險。」→ 危險的是「停機時回錯狀態碼」。正確回 503，短時間維護幾乎零影響。
✗ 迷思三：「維護時掛一個漂亮的維護頁就好。」→ 維護頁若回傳 200，反而可能讓 Google 以為這就是正式內容。維護頁必須回 503。
✗ 迷思四：「搬完就沒事了。」→ 還要驗收與觀察。追蹤碼、表單、速度、索引狀態都確認無誤，才算真正完成。

一句話總結

換 IP 與計畫性維護，本質上是安全的；讓它變得危險的，從來不是「換」這個動作，而是「沒回對狀態碼、沒留緩衝、沒做驗收」。 照著上面的清單走，這件事就只是一次例行維運，而不是一場 SEO 風險。

如對特定情境（網址變動、長時間停機、複雜系統）有疑慮，建議於異動前先諮詢，事前規劃永遠比事後補救成本更低。

KPN 編輯部
AUTHOR

KPN 編輯部

奇寶網路自 2006 年成立，深耕搜尋行銷產業 — 服務超過 600 家企業客戶，自主研發站內廣告系統「客樂寶」，是 Google Partners 官方認證機構。

關於奇寶 → 聯絡顧問 →
SHARE Facebook LINE
STAY CONNECTED · 訂閱與社群

還想了解更多各類數位行銷資訊的話，歡迎訂閱電子報、加入奇寶 Line 好友，第一時間接收最新資訊！

Facebook 粉絲專頁：
奇寶網路 台北移動學苑

歡迎轉載 KPN 奇寶部落格相關文章，在轉載前請先詳閱著作權聲明及轉載原則。