301 與 302 轉址教學：設定方法、SEO 影響與實作

網站改版、換網域或更換文章網址後，若舊網址沒有正確轉址，原本的入口可能回傳 404，使用者與搜尋引擎也找不到對應的新頁面。排名或流量下滑不一定只由轉址造成，但網址對應錯誤是改版後應優先排查的項目之一。

轉址是技術性 SEO 裡少數「做對了沒人感謝你、做錯了直接掉流量」的環節。它本身不會幫你排名往前，但它守護的是你已經累積下來的排名資產。一個設錯的 301，可能讓你好幾年才存下來的搜尋能見度在一夜之間蒸發；而一個該設卻沒設的轉址，則會讓舊網址的權重白白流失，無人承接。這篇會把 301 與 302 從協定層、Google 的實際處理邏輯、到 Apache、Nginx、WordPress 三種實作一次講清楚。

重點摘述

• 301 = 永久轉址，告訴搜尋引擎「這個網址已經永遠搬到新位置，請把權重轉過去」。
• 302 = 暫時轉址，告訴搜尋引擎「這個網址只是暫時不在，原網址才是正主」。
• 絕大多數 SEO 場景（換網域、改網址結構、HTTP 升級 HTTPS）都該用 301。
• 302 或 307 用於真的會還原的暫時情況；兩者對請求方法的處理不同，不能只從 SEO 角度互換。
• 設完要用狀態碼檢查工具驗證；網站搬家或大量改網址時，再搭配 Google Search Console 與 sitemap 觀測。單一網址轉址不必把 GSC 提交視為必要條件。

轉址到底是什麼：回到 HTTP 協定層看這件事

很多人學轉址，第一個念頭是「我要在哪個外掛按哪個按鈕」。這個順序其實反了。你得先理解轉址在底層是怎麼發生的，否則遇到沒有外掛能用的環境（例如純靜態站、或你自己架的伺服器），就會完全不知所措。

轉址的本質，是伺服器在回應一個請求時，回傳一個 3 開頭的 HTTP 狀態碼，外加一個 Location 標頭，告訴瀏覽器或爬蟲「你要的東西不在我這，請改去這個新網址」。瀏覽器收到這個回應後，會自動再發一個新的請求到 Location 指定的網址。對使用者來說，畫面「咻」一下就跳走了，感覺不到中間發生過兩次往返。

3xx 這個家族成員不少，但會在 SEO 實務上碰到、你需要分清楚的，主要有這幾個：

狀態碼	意義	SEO 實務上的角色
301	Moved Permanently（永久搬移）	絕大多數「永久改變」的場景都用它，權重會被轉移到新網址。
302	Found（原本的意涵是暫時搬移）	只用於暫時性的跳轉，原網址仍被視為內容的正式所在地。
307	Temporary Redirect（HTTP/1.1 的暫時轉址）	語意上等同 302，但嚴格要求保留原本的請求方法（POST 還是 POST）。SEO 上等同 302 看待。
308	Permanent Redirect（HTTP/1.1 的永久轉址）	語意上等同 301，同樣要求保留請求方法。Google 把它當 301 處理。

換句話說，301 與 302 的差別不在於「有沒有跳轉」，兩者都會跳轉。差別在於它們送給搜尋引擎的那個語意訊號不一樣：一個說「我永遠走了」，一個說「我只是暫時離開」。而這個訊號，會直接影響 Google 要把排名訊號累積在哪一個網址上。

用一個比喻把它變具體。想像你的網址是一間實體店面，301 像是你把店收了、在原址貼一張「永久搬到新地址」的告示，還把老顧客的會員資料一併轉到新店去。從此以後，所有人提到「原來那家店」，指的都是新店。302 則像你在店門口掛個「本店裝修中，暫時移到隔壁攤位營業」的牌子，老顧客知道你還會回來，會員資料繼續留在原店。這兩種告示傳達的訊息完全不同，顧客（與搜尋引擎）後續的行為也會跟著不同。

把這個比喻記住，後面所有的判斷都會變得直觀：凡是「不會再回來原址」的改變，就貼 301 那張永久告示；凡是「還會回來」的暫時狀態，就掛 302 那張裝修牌子。選錯告示，等於是給了搜尋引擎錯誤的承諾，而搜尋引擎會很認真地照著這個承諾去處理你的排名訊號。

如果你想在更廣的技術 SEO 脈絡裡把這塊看清楚，可以回頭讀一下 技術性 SEO 完全指南，那篇講的是整體的網站架構與爬蟲溝通，這篇則是鑽進轉址這一個子題。

301 與 302 的本質差別，濃縮成四個字

如果你只能記住一個觀念，記住這四個字：永久、暫時。301 代表永久，302 代表暫時。後面所有的 SEO 影響、該不該用、設錯會怎樣，全部都是從這四個字推導出來的。

301 永久轉址：把過去累積的全部搬走

當你回傳 301，你等於是在跟 Google 發一個正式聲明：「這個網址的內容已經永遠搬到新位置了，以後請你把這個新網址當作正式版本，原本指向舊網址的反向連結、累積的排名訊號，請一併歸到新網址頭上。」

Google 大致上會照辦。它會在索引裡把新網址取代舊網址，舊網址累積下來的那些外部連結的價值，也會透過這個 301 被轉嫁到新網址。這就是為什麼換網域、改網址結構時，301 是標準答案。你想保護的是過去好幾年才存下來的搜尋資產。

302 暫時轉址：原網址才是正主

302 講的是另一個故事：「這個網址暫時把內容搬到別的地方，但我還會回來，原網址才是內容的正式家。」在這個語意下，Google 傾向把排名訊號繼續累積在原網址上，新網址暫時拿不到。

這聽起來好像 302 對 SEO 不利，但關鍵跟你直覺想的利不利無關，重點是「你到底是不是暫時」。如果你只是雙十一期間把首頁暫時導到活動頁，活動結束就會還原，那 302 才是誠實的選擇。硬要用 301 反而會讓 Google 以為首頁永遠變成活動頁，活動結束後你還得再轉一次回來，多此一舉。

這裡還有一個常被搞混的親戚：canonical。轉址是真的把使用者與爬蟲「整個人」搬走，canonical 則只是留一張紙條說「內容的標準版本在另一個網址，但你不用真的跳過去」。兩者處理的問題很像（重複內容、網址版本），但機制完全不同。把這層關係弄清楚，進一步可以參考 Canonical URL 完全指南。

Google 現在怎麼看待 301 與 302：拆解四個過時觀念

SEO 圈子裡關於轉址的說法，有不少是十年前留下來、早就過時的觀念。它們聽起來很合理，但會誤導你做錯決定。接下來把最常見的四個搬出來逐一拆解。

觀念一：「302 不會傳遞權重」

早期確實如此，但 Google 早就改變了做法。Google 的官方人員多次說明，現在的爬蟲會去觀察這個 302 到底是不是真的暫時。如果它判斷這個 302 其實擺了很久、內容看起來是永久性的，它有可能把它當 301 來處理，把權重轉過去。

但這裡藏著一個陷阱：你不能依賴這個自動判斷。Google 的判斷需要時間，過程中你的排名訊號可能還掛在原網址上，新網址拿不到。所以原則還是一樣：如果你心裡想的是永久，就老老實實用 301，不要賭 Google 會不會幫你把 302 當 301 看。

觀念二：「301 會損失一部分 PageRank」

這個觀念源自早年 Google 曾暗示內部連結的價值會在傳遞過程中衰減。於是有人推論：既然 301 是一種「把權重傳過去」的動作，那是不是也會打折？

Google 現行網站搬移文件說明，301 與其他永久轉址不會造成 PageRank 損失。因此，永久搬移時不必因早年的「轉址會打折」說法而避開 301。不過，排名仍可能因重新抓取、重新索引、內容或網站結構變動而暫時波動。

不過要注意一個分寸：這講的是單一層的 301。如果你弄成好幾層串在一起的轉址鏈（A 跳 B、B 跳 C、C 跳 D），每一跳都是一次額外的請求往返，雖然權重最終還是會傳到終點，但爬蟲的爬取預算會被消耗，使用者也要多等。這件事在〈爬取預算〉那篇有深入討論，大型網站特別要當心。

觀念三：「反正都會跳，用哪個都一樣」

這是最危險的一個。正因為 301 與 302 對使用者來說看起來完全相同（都會跳轉），很多人就隨手挑一個、或拿外掛的預設值就用。但對 Google 來說，兩者送出的語意訊號天差地別，後續處理也完全不同。

給你一個很實際的後果：如果你把一個頁面用 301 轉走，事後反悔想把排名訊號要回舊網址，會非常麻煩。Google 一旦認定「舊網址永遠搬到新位置」，要它改變心意、重新把訊號放回舊網址，需要的時間遠比你想像的長。所以選錯狀態碼，代價其實存在，只是延遲發生、且難以逆轉。

說到底，轉址是整併網址訊號的工具，不是製造排名的工具。永久搬移時，應讓舊網址一對一指向最相關的新網址，並同步更新內部連結與 sitemap；內容品質、網站整體訊號與新頁面是否可索引，仍需另外處理。第三方排名相關性研究（如 Backlinko 的搜尋結果分析，2025 年 4 月版）可作為觀察資料，但不能當成 Google 公開的權重或因果證明。

觀念四：「頁面下架就一律轉到首頁」

這是內容站常見的壞習慣。一篇文章下架了，怕 404 傷害體驗，就把舊網址 301 到首頁。若目的頁與原內容明顯無關，Google 可能把這類網址判為 soft 404，而不是照站方期待把它視為有效替代頁。

正確做法分兩種情況。如果舊頁面有主題相近的替代頁，就把舊網址 301 到那個替代頁。如果真的沒有對應內容、頁面永久消失，就讓它回 404 或 410 Gone。Google 目前對 404 與 410 的處理方式相同，不能假設 410 一定移除得更快。404 不是 SEO 處罰；真正要避免的是把大量無關舊網址都轉到首頁。

哪種情況用 301、哪種情況用 302：一張決策表幫你定下來

理論講完了，落地才是重點。這張表是實務上常用的判斷依據，把常見場景一次列清楚。你以後遇到任何轉址需求，先對照這張表再下手。

場景	該用	為什麼
整個網站換新網域	301	永久搬家，要把所有權重導到新網域。
從 HTTP 升級到 HTTPS	301	這是永久性的協定升級，不會再退回 HTTP。
統一 www 與非 www 版本	301	選一個當標準版本，另一個永久指過去。細節可參考 www 與非 www。
修改某篇文章的網址結構	301	舊網址不會再用，要把累積的排名訊號搬到新網址。
頁面永久下架、沒有替代頁	不要轉址	直接回 404 或 410，讓 Google 知道這頁真的沒了。硬轉到首頁是壞習慣。
頁面下架但有替代內容	301	轉到主題最接近的替代頁，比丟 404 好。
季節性活動頁（活動結束會還原）	302	暫時把流量導到活動頁，結束後原網址恢復原狀。
A/B 測試或短期實驗	302	實驗有期限，原網址才是正式版本。
伺服器維護、短期維修	302、307 或 503	若只是暫時導向另一頁可用暫時轉址；服務確實不可用時回 503，並可搭配 Retry-After，讓爬蟲知道稍後再試。

判斷的核心永遠是同一個問題：這個改變會不會還原？會還原就用 302，不會還原就用 301。回答不出這個問題，就把整件事想清楚再動手，不要急著設。

轉址的實作手法：為什麼優先使用伺服器端 3xx

這裡要拆解一個很多人搞混的觀念：能讓頁面「跳走」的機制有好幾種，但它們在 SEO 上的分量完全不同。把這層差異弄清楚，你才會知道為什麼實務上一直強調要在伺服器端設 3xx，避開其他取巧的方法。

機制	在哪一層發生	SEO 評價
伺服器端 3xx（Apache / Nginx / PHP header）	伺服器回應時就直接回傳狀態碼	黃金標準。Googlebot 收到的第一個回應就是 301 或 302，處理最快、最可靠。
PHP header()	伺服器端（程式碼層）	等同伺服器端 3xx，因為它送出的就是真正的 HTTP 狀態碼。
meta refresh（HTML <meta http-equiv="refresh">）	瀏覽器端，要先取得 HTML	Google 能辨識；即時 refresh 可作為永久轉址訊號，延遲 refresh 則較弱，但通常只建議在無法設定伺服器端轉址時使用。
JavaScript 跳轉（window.location）	瀏覽器端，需要轉譯 JavaScript	Google 能處理，但必須先轉譯，發現與處理通常不如伺服器端 3xx 直接，適合作為受限環境的備案。

關鍵差別在於Googlebot 何時發現目的網址。伺服器端 3xx 在第一個回應就提供狀態碼與 Location，不必先處理頁面內容。meta refresh 要先取得 HTML，JavaScript 跳轉還可能需要轉譯，因此發現與處理通常較慢，也更容易受實作錯誤影響。

如果是一般 WordPress 網址搬移，應優先使用伺服器端 3xx；meta refresh 與 JavaScript 跳轉較適合無法控制伺服器回應時的備案。登入後導向等功能性需求則另當別論，不要與公開網址搬移混在一起。對 JavaScript 與 SEO 之間更廣泛的互動關係有興趣，可以再看一下 JavaScript SEO 介紹。

順帶一提，PHP 的 header('Location: ...', true, 301) 這種寫法，本質跟在 .htaccess 設規則是同一件事，它送出的就是真實的 301 狀態碼。有些老一輩的開發者習慣在 PHP 程式裡用 header() 做轉址，這完全沒問題，只要記得在呼叫 header() 之前不能有任何輸出（連一個空白或 BOM 都不行），否則會噴「headers already sent」錯誤，轉址就失效了。

五個會讓流量不見的轉址地雷

知道了該用哪個狀態碼，不代表就不會出事。最常見的災難，很少出在選錯 301 或 302，多半出在接下來這些細節。每一個都是實務上反覆出現的狀況。

地雷一：轉址鏈太長，爬蟲爬到放棄

網站改版過幾次之後，很容易出現 A 跳 B、B 跳 C、C 跳 D 的狀況。每一跳都會增加請求往返，也提高爬蟲未能到達最終網址的風險；鏈條過長時，後面的網址可能無法被正常處理。

正確做法是把轉址鏈拍平：讓仍有人造訪或仍被引用的舊網址直接指向最終新網址。改版、搬家或調整網址規則後就應檢查，不必死守固定週期。

地雷二：轉址迴圈，自己跳到自己

A 跳 B、B 又跳回 A，瀏覽器會直接顯示「這個網頁重新導向次數過多」，網站等於掛了。這種事常發生在設規則的時候條件寫錯，或兩條規則互相覆蓋。設完任何一條轉址，第一步一定是打開瀏覽器實際跑一次，別只看後台顯示「已新增」就放心。

地雷三：把暫時的事用 301 設了，事後收不回來

前面提過，301 一旦被 Google 認定，要逆轉很慢。常見的狀況是：為了活動把首頁 301 到活動頁，活動結束想轉回來，結果花了好幾週排名才穩定下來。記住：只要你的心底還有一絲「以後會改回來」的念頭，就用 302。

地雷四：轉址與 noindex 互相打架

有人會在舊網址上同時設 301 又想加 noindex，覺得這樣是「雙保險」。實際上，伺服器回 3xx 時，搜尋引擎主要處理狀態碼與 Location；舊網址回應本文裡的 HTML meta noindex 通常沒有作用。要檢查舊網址是否正確轉址，也要另外確認目的網址是否可索引，不要把兩者混成一個設定。對 noindex 沒把握時，可以先讀 noindex 介紹。

地雷五：設了轉址，卻忘了更新內部連結與 sitemap

很多人以為「反正舊網址會 301 到新網址，選單裡連舊網址沒關係」。技術上沒錯，但這等於讓使用者和爬蟲每一次點擊都多走一跳。正確做法是：設完 301 之後，回頭把站內所有指向舊網址的連結、以及 sitemap 裡的網址，全部改成新的。轉址是保險，不是日常通行路線。

在 Apache 用 .htaccess 設定 301 與 302

如果你的網站跑在 Apache 伺服器上（多數共享主機、cPanel 環境都是），最直接的設定方式就是編輯網站根目錄的 .htaccess 檔。這個檔案的語法不複雜，但寫錯一個字可能整站 500，所以改之前一定要先備份。如果你對檔案操作不熟，先看一下 FTP 教學 搞懂怎麼抓到這個檔案。

最簡單的單頁轉址

把一個舊網址轉到一個新網址：

# 301 永久轉址，單一頁面
Redirect 301 /old-page https://example.com/new-page

# 302 暫時轉址，單一頁面
Redirect 302 /old-page https://example.com/temp-page

Redirect 301 也可以寫成 Redirect permanent，兩者完全等價。同理，Redirect 302 等於 Redirect temp。

用 mod_rewrite 處理較複雜的規則

當你需要條件判斷（例如「只有 HTTP 的請求才轉到 HTTPS」），就要動用 mod_rewrite。這段是強制全站 HTTPS 的經典寫法：

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

這裡的 [R=301,L] 是關鍵旗標：R=301 指定回傳 301 狀態碼，L 表示這是最後一條規則，不要再往下比對。如果要做 302，把 R=301 改成 R=302 即可。

整站換網域

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

這會把舊網域的每一個路徑，原封不動搬到新網域。$1 捕獲的是原本路徑，確保 /old-domain.com/article-a 會精準對應到 /new-domain.com/article-a。換網域是 SEO 的大事，完整的搬家流程不只是設轉址而已，整件事的來龍去脈寫在〈WordPress 搬家到新網域〉那篇，搬之前務必讀過。

在 Nginx 設定 301 與 302

Nginx 的設定邏輯跟 Apache 完全不同，它不用 .htaccess，而是把規則寫在伺服器設定檔（通常在 /etc/nginx/ 下）的 server 區塊裡。語法更簡潔，但改完要 nginx -t 測試、再 reload 才會生效。

單頁轉址

# 301 永久
location = /old-page {
    return 301 https://example.com/new-page;
}

# 302 暫時
location = /old-page {
    return 302 https://example.com/temp-page;
}

return 後面直接接狀態碼與目標網址，非常直白。

整站換網域

server {
    listen 80;
    server_name old-domain.com www.old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

$request_uri 會帶上原始路徑與查詢字串，效果等同 Apache 裡的 $1。

如果你是用虛擬主機、不知道自己是 Apache 還是 Nginx，通常主機商的文件會寫清楚。不確定的話，先確認主機環境再動手，這部分可以對照 虛擬主機指南。

兩種伺服器都有一個共同的紀律：改完設定，先測試再上線。Apache 改完 .htaccess 不需要重啟，但一個語法錯誤會立刻讓對應目錄回 500；Nginx 改完設定檔，務必先跑 sudo nginx -t 做語法檢查，通過了再 sudo systemctl reload nginx 讓它生效。這個「測試、再重載」的動作只要花十秒鐘，卻能幫你避開把整站弄掛的尷尬。這件事被燙過幾次就會學乖：不管改多小的規則，都建議養成先測試的習慣。

WordPress 用 Redirection 外掛設轉址，為什麼比改 .htaccess 安全

多數 whoops 讀者用的是 WordPress。對 WordPress 站長，強烈建議是：不要自己改 .htaccess，用外掛來設轉址。理由很實際：

• 改 .htaccess 一個錯字就讓整站掛掉，外掛通常有語法檢查，出錯頂多那一條規則無效，不會波及全站。
• 外掛會記錄每一次轉址，你隨時能在後台看到「總共設了哪些、最近觸發了哪些」。
• 好的轉址外掛還會自動捕捉 404，告訴你哪些網址有人連、卻沒有對應頁面，讓你順手補上轉址。
• 搬家或換主機時，外掛的規則跟著資料庫走，.htaccess 卻是主機上的檔案，容易在轉移過程中遺失。

實務上長期推薦的選擇是 Redirection 這個外掛。它免費、維護穩定、功能涵蓋絕大多數需求：手動新增 301 / 302、批次匯入、404 監控、連結失效檢查一次到位，詳情可查 WordPress 官方外掛庫的 Redirection 頁面（2026 年）。如果你還沒裝過任何 SEO 相關外掛，可以先讀一下 外掛安裝教學。

用 Redirection 設一條 301 的步驟

1. 在 WordPress 後台「外掛 > 安裝外掛」搜尋 Redirection，安裝並啟用。
2. 進入「工具 > Redirection」。
3. 在「來源網址（Source URL）」填入舊路徑，例如 /old-page（不用填網域）。
4. 在「目標網址（Target URL）」填入完整新網址。
5. 在「HTTP 狀態碼」下拉選 301 - moved permanently。
6. 按「新增轉址（Add Redirect）」。

設完之後，Redirection 貼心到會讓你按一個按鈕直接測試這條規則。請真的按下去，看它回傳的狀態碼是不是 301，不要只用肉眼檢查。

別忽略 Redirection 的 404 報表，那是站長的金礦

很多人裝了 Redirection，只用它設幾條轉址就擱著了。它的404 監控才是實務上最有價值的功能。這份報表記錄了所有訪客與爬蟲曾經請求、卻找不到的網址。你會在裡面看到三類資訊：

• 別人連到你的舊網址：可能是別的網站放了指向你某個已改版的頁面的連結，或 Google 還在爬你一年前就換掉的網址。這些就是你該補上 301 的地方。
• 打錯字的外部連結：有人把網址拼錯，連到例如把 /article 打成 /articel 這種漏一個字母的版本，這種錯字連結長期累積下來也會浪費流量，補一條轉址就能把人救回來。
• 爬蟲在試探的路徑：有些 404 是爬蟲在掃常見的漏洞路徑（例如 /wp-admin 變體、/xmlrpc.php），這些不用理會，但看一眼能讓你對站上被掃描的狀況心裡有底。

實務上建議每個月掃一次這份 404 報表，把前幾名被請求最多次的網址補上對應的轉址。這件事花不了十分鐘，卻能持續把「漏接的流量」一點一點救回來。長期下來，這比任何花俏的 SEO 操作都實在。

與其他 SEO 外掛的分工

Redirection 專注在轉址，不做其他 SEO 工作。你的網站通常還會裝一個綜合型的 SEO 外掛來處理 meta、sitemap、結構化資料。如果你用的是 Rank Math，它本身也內建轉址功能（Pro 版更完整），可以考慮直接用它、省得多裝一個。該怎麼選，可以參考〈Rank Math 教學〉，也有一份 WordPress SEO 外掛評測 可以交叉比對。站外 SEO 與連結經營那一塊，則可以回頭看 站外 SEO 指南，把整體的 SEO 藍圖拼起來。

轉址設完不算數：用 httpstatus.io 與 GSC 驗證真的生效

設完轉址最致命的錯誤，就是「設了就不管了」。你以為設好了，但可能規則沒生效、狀態碼回傳錯誤、或被上層的快取蓋掉。驗證是不能省的一步。

第一步：用 httpstatus.io 確認狀態碼

這是每天都會用到的工具。你只要貼上一個網址，它就會告訴你這個網址實際回傳的狀態碼是什麼、中間經過了幾跳、每一跳的狀態碼分別是多少。如果你的舊網址應該要 301 到新網址，httpstatus.io（2026 年資訊）卻顯示它回傳 200、或回傳 302、或跳了好幾跳才到終點，那就是設定有問題，得回去查。

特別注意它顯示的最終狀態碼。正確的結果應該是：舊網址回傳 301、然後新網址回傳 200。如果你看到舊網址回傳 200，代表轉址根本沒生效；如果看到一長串 301 串 301，代表有轉址鏈要清。

第二步：用 Google Search Console 觀測 Google 看到的狀態

驗證完畢後，可在 Google Search Console（簡稱 GSC） 觀測 Google 看到的狀態。單一網址轉址不需要額外「通知」才能生效；若是大量改網址或網站搬家，可以做兩件事：

1. 用網址檢查工具抽查舊網址與新網址，確認 Google 看到的狀態與你預期的一致。
2. 更新並提交只包含新網址的 sitemap，協助 Google 發現新的網址結構。

整個 GSC 的操作如果對你還很陌生，建議從 GSC 完整教學 開始打底。搬家期間難免會遇到收錄卡住或排名波動，那時候 GSC 就是你最重要的觀測站。

常見的驗證異常與背後原因

驗證過程裡，你大概率會碰到接下來這幾種「跟預期不一樣」的結果。知道它們各代表什麼，才不會在原地打轉：

• 舊網址回傳 200 而不是 301：代表轉址規則根本沒生效。可能是 .htaccess 的規則被上面的條件擋掉、或外掛設定沒存到。回去檢查規則順序與伺服器是否真的讀到那個檔案。
• 狀態碼對，但新網址回傳 404：轉址設對了，但你指向的新網址其實不存在。這是最尷尬的一種，等於把人從一個死胡同搬到另一個死胡同。確認新網址真的打得開再說。
• 舊網址回傳 302 而不是 301：你以為設的是 301，實際回 302。通常是外掛下拉選錯、或 .htaccess 語法用了 Redirect temp。這種錯誤最容易被忽略，因為使用者感受不出差別。
• httpstatus.io 顯示一長串跳轉：典型的轉址鏈。把每一跳記下來，找出可以直接合併的環節，拍平成單一跳轉。

有一個小技巧能幫你省下大量時間：在 httpstatus.io 一次貼上多個網址（它支援批次檢查），一次看完幾十個關鍵頁面的轉址健康狀況。比起一個一個測，效率差很多。搬家或大改版後，建議跑一次這種批次檢查，把整站的轉址地圖看清楚再交件。

搬家專案帶來的四個教訓

以一個戶外露營電商的搬家為例：從舊網域切到新網域，光是把上百個商品頁一條條對應到新網址、設好 301，就往往要花團隊將近一週。這種規模的搬家會帶來幾件課本上學不到的功課。

第一，對照表是命根子。搬家之前一定要先產出一份「舊網址 → 新網址」的完整對照表，每一列都核對過。沒有這份表，等到流量掉了你根本不知道是哪一條沒設好、或設錯了。上百個頁面靠記憶是靠不住的。

第二，先在測試環境驗證完整對照表與轉址規則。Google 對網站搬移的建議是完成網址對應與永久轉址，再讓新舊狀態保持一致；把同一批相依網址拆成長期分段搬移，反而可能增加重複與漏接。若網站規模很大，可以依彼此獨立的區段規劃，但每個區段仍要一次完成並監控。同樣道理，完整的備份與還原方案是搬家前提。

第三，排名回穩需要時間，不要每天盯著數字焦慮。即使 301 設得完美無缺，Google 重新處理索引、把排名訊號搬過去，也需要時間。大型搬家通常以「週」為單位在跑，期間排名會有一些波動屬正常。真正要擔心的是那些不回來的波動，那通常代表某條規則有問題，跟 Google「還在處理中」無關。如果你已經掉了一段時間沒起色，可以參考 網站流量下滑怎麼辦 的排查流程。

第四，外部反向連結是搬家期間最容易被放過的一環。301 能把舊網址的權重搬到新網址沒錯，但如果別人網站上指過來的連結還是指向你的舊網址，那等於讓每一個反向連結都多走一跳。實務上，你不可能要求所有外部站長更新連結，但幾個高權重的來源值得手動聯繫。搬家前建議先用工具把指向舊網址的主要反向連結列出來，挑出權重最高的十幾個，請對方更新成新網址。這一步的投資報酬率遠高於去修幾百個小連結。

正因如此，值得再次強調，搬家遠遠超過一個「技術操作」，它需要動到 SEO 的全維度：網址對應、伺服器規則、站內連結、sitemap、外部連結、收錄驗證，少照顧到一塊，那一塊就會在事後用流量下滑的方式提醒你。如果你正在評估要不要搬，排名掉了怎麼辦 那篇也可以先放進書單，搬家前後用得上。

現在就能動手的五步檢查清單

讀到這裡，別只是繼續吸收知識，立刻回頭對自己的網站做一遍。接下來這五步，是你今天就能執行的轉址健康檢查：

1. 盤點現有轉址：打開你的 Redirection 外掛（或 .htaccess），把所有規則匯出成一份清單，看看總共有幾條、哪些是多年前設的、哪些可能已經不需要。
2. 抓出轉址鏈：挑 10 個流量最高的舊網址，丟進 httpstatus.io，看它們各自經過幾跳。只要超過一跳，就記下來準備拍平。
3. 確認狀態碼正確：每一條 301 與 302 都對照「會不會還原」這個原則重新檢視。該是 302 的別用 301，該是 301 的別用 302。
4. 清掉無意義的轉址：那些指向已下架頁面、或硬轉到首頁的規則，該改成 404 就改成 404。把轉址當萬靈丹，只會讓站愈來愈亂。
5. 更新內部連結與 sitemap：站內任何還指向舊網址的連結、選單、sitemap，全部改成新網址。讓轉址只當後備，不當日常路線。

轉址這件事，做對了沒有人會誇你，因為它本來就該如此；做錯了，代價是實打實的流量與排名。把它當成網站的基礎工程來對待，定期保養、不心存僥倖，你的搜尋資產才守得住。

如果你正在規劃一次比較大的搬家或改版，心裡沒有把握，先避開常見的 SEO 地雷 是最划算的第一步。把這篇從頭到尾走一遍，你會發現轉址其實沒有那麼神秘：它就是一套用狀態碼跟搜尋引擎溝通的語言，只要你講的話跟你的真實意圖一致，Google 就聽得懂。多數災難，都是出在「嘴上說永久、心裡想暫時」這種前後不一的情況。

我們 Whoops SEO 也協助過不少網站走過搬家這一關，需要的時候，隨時可以把現況丟過來一起討論。把地基打穩，後面的內容與連結經營，才會真的滾得起來。SEO 從來沒有靠某一個神操作一夕翻盤這回事，靠的是這些不起眼的基礎工程，一塊一塊把護城河疊起來。