301重新導向設定指南：舊網址轉新網址的SEO流程與排查清單

301 重新導向是什麼？它在 SEO 裡扮演什麼角色？

301 重新導向是把舊網址永久導到新網址的 HTTP 狀態，適合網站改版、搬站、URL 結構調整或內容合併。正確設定可協助搜尋引擎理解頁面已永久搬家，並把舊網址累積的部分 SEO 訊號轉到新網址。

301 代表「永久搬家」，不是暫時跳頁

當使用者或搜尋引擎進入舊網址時，伺服器回傳 HTTP 301 或 301 Moved Permanently，表示這個資源的正式位置已經改到新網址。實務上，台灣 SEO 常把它稱為 301 轉址或永久轉址。

例如舊文章從 /old-seo-guide 改成 /articles/seo-guide，只要舊網址未來不再使用，就應設定 301 重新導向到新網址，而不是讓舊網址變成 404。

Google 看到 301 後會如何處理舊網址與新網址

Googlebot 重新抓取舊網址時，會看到它已永久導向新網址，接著重新理解索引中的代表網址。若新舊頁主題一致、內容對應清楚，搜尋引擎較容易把舊頁的排名訊號、反向連結訊號與索引關係轉移到新頁。

我的判斷是，301 最怕的不是設定本身，而是對應關係粗糙。把「台北 SEO 顧問服務」導到首頁，和導到新的「台北 SEO 顧問」頁，對搜尋引擎來說是完全不同的訊號品質。

301 不等於立刻恢復排名，搜尋引擎需要重新處理訊號

301 設定後，使用者通常會立刻被導向新網址，但排名、索引與流量不一定同步穩定。搜尋引擎需要重新抓取舊網址、新網址、內部連結、canonical、sitemap 與外部連結訊號。

所以 301 不是保證排名不動的按鈕。它是讓搜尋引擎用較合理的方式理解網址永久變更，降低改版或搬站造成的 SEO 損失。

301、302、canonical、404、410 該怎麼選？

永久換網址用 301，短期變更用 302，重複內容通常優先判斷 canonical，沒有替代頁才考慮 404 或 410。選錯類型會讓搜尋引擎誤判頁面生命週期，造成索引混亂或訊號浪費。

用下面這張表先判斷處理方式，再決定要不要做 301 轉址設定。

永久替換用 301

只要舊網址未來不再作為正式頁面，且有明確的新網址承接，就應使用 301。常見情境包括文章 slug 修改、分類路徑調整、產品頁合併、網域更換與 HTTP 改 HTTPS。

短期活動、測試、維護用 302

302 適合暫時轉址，例如短期活動頁導向促銷頁、系統維護時暫時導向通知頁，或 A/B 測試中短期改變使用者路徑。若你已確定舊網址不會回來，就不要長期使用 302。

重複內容不一定用 301，可能用 canonical

canonical 適合處理重複或近似內容，例如排序參數頁、列印版頁面、商品多規格網址。canonical 不會讓使用者離開原網址，只是告訴搜尋引擎哪個版本應作為標準頁。

如果舊網址已不該被使用者看到，才是 301 的場景；如果舊網址仍需要存在，只是不要分散索引訊號，canonical 通常更合理。

永久移除且沒有替代頁時，可考慮 404 或 410

當頁面已永久刪除，而且沒有相近的新內容可以承接搜尋意圖，404 或 410 比硬做 301 更乾淨。410 更明確表示資源已永久移除，404 則表示目前找不到頁面。

低價值舊頁不一定值得轉址

沒有自然流量、沒有反向連結、沒有排名、沒有內部連結價值，也沒有相近替代頁的低品質舊頁，不一定要做 301。我的經驗是，為了讓報表看起來零 404 而亂轉址，常比保留合理 404 更傷判斷。

什麼情況一定需要設定 301 重新導向？

只要舊網址的內容、權重或使用者入口需要永久搬到新網址，就應設定 301 重新導向。網站改版、搬站、HTTPS 轉換、內容合併與商品下架，都是最常見的 301 使用情境。

網站改版或 URL 結構調整

改版時若 URL 從 /blog/post-name 改為 /articles/post-name，舊網址就必須導向新網址。這類變更看似只是路徑調整，但對搜尋引擎來說是不同 URL。

正確做法是先整理所有舊網址，再逐一對應到新網址。不要等上線後才從 GSC 的 404 報表回頭補救，因為那時流量與抓取訊號已經開始流失。

更換網域或 HTTP 改 HTTPS

更換網域時，例如從舊品牌網域搬到新品牌網域，必須把每個舊頁導到新網域上的對應頁。HTTP 改 HTTPS 也應使用 301，並搭配更新內部連結、canonical、sitemap 與 GSC 設定。

如果只把首頁轉過去，內頁卻沒有一對一對應，搜尋引擎很難判斷整站內容已完整搬移。

兩篇內容合併成一篇時，用 301 集中訊號

當兩篇文章搜尋意圖重疊、關鍵字互相競爭，且你決定保留其中一篇作為主頁，另一篇應 301 到合併後的新頁。這可以降低內容內耗，也能把舊頁累積的部分訊號集中到更完整的頁面。

舊商品、舊文章下架後，導向相似頁或上層分類頁

商品下架後，第一優先是導到最相似的新商品；若沒有相似商品，才導到最相關分類頁。舊文章下架也一樣，先找能滿足同一搜尋意圖的文章，再考慮上層主題頁。

把所有下架商品導到首頁通常不是好選擇。使用者原本想看某項商品，突然被丟到首頁，既不符合需求，也不利搜尋引擎判斷新舊頁關係。

哪些舊網址值得做 301？哪些可以不用？

有自然流量、排名、反向連結、營收或重要內鏈的舊網址，應優先做 301。無價值、無替代頁、主題過期或品質很差的舊頁，可以保留 404 或 410，不必硬轉。

用這張表快速評估舊網址是否值得投入轉址規劃。

必轉：有自然流量、排名、外部連結、營收或重要內鏈的 URL

這類 URL 是改版時最不能漏掉的資產。即使頁面內容看起來舊，只要它仍有曝光、點擊、外部連結或商業價值，就應該被納入 URL 對照表。

可合併：主題接近、內容重複或搜尋意圖相同的頁面

如果兩個舊頁都在回答同一件事，與其讓它們分散排名訊號，不如合併成一篇更完整的新頁，再把被淘汰的舊網址 301 到主頁。這類轉址最重視新舊內容的語意一致性。

可不轉：無流量、無連結、無替代頁、低品質或已過期頁面

舊頁沒有搜尋價值，也沒有相近內容可承接時，不轉址反而比較清楚。這些頁面可以回傳 404 或 410，讓搜尋引擎逐步從索引中移除。

不要為了「看起來完整」把所有舊頁硬轉到首頁

全站導首頁常被誤以為可以保護 SEO，其實只是把不同搜尋意圖混在一起。我的判斷是，首頁只適合承接品牌型、公司型或無法更細分但仍有品牌意圖的舊頁，不適合承接所有文章、商品與分類。

301 重新導向設定方法：平台、伺服器與 CDN 怎麼做？

301 重新導向可在 CMS、伺服器、CDN 或電商平台後台設定。選擇位置時，優先考慮維護權限、規則數量、上線風險與是否能批量管理，不要同時在多層重複設定相同規則。

用下面這張表決定要在哪一層做 301 轉址設定。

WordPress：外掛或伺服器規則

WordPress 適合少量到中量的文章、分類、固定頁面轉址。常見做法是使用轉址外掛管理舊網址與新網址，也可以由伺服器規則統一處理。

適合情境：編輯團隊常調整文章 slug，或 SEO 人員需要自行管理轉址。檢查方式：設定後用舊網址開啟頁面，確認最終 URL 正確，再用狀態碼工具確認回傳 301。

Apache .htaccess 範例

Apache 主機可在 .htaccess 設定單頁 301，適合舊路徑與新路徑明確對應的情境。

Redirect 301 /old-page https://www.example.com/articles/new-page

若要處理整個資料夾的路徑變更，可以用 rewrite 規則，但要先在測試環境確認不會誤傷其他 URL。檢查方式是用 curl -I 看舊網址是否回傳 301，且 Location 是否為目標新網址。

Nginx rewrite / return 301 範例

Nginx 建議優先使用 return 301 處理清楚的永久轉址，適合自管主機、流量較大或需要工程部署控管的網站。

location = /old-page {
  return 301 https://www.example.com/articles/new-page;
}

適合情境：固定舊網址導向固定新網址，或網域、協定、www 規則統一。檢查方式是重載 Nginx 後抽測多組舊網址，避免某些規則造成轉址鏈。

Cloudflare Redirect Rules / Page Rules

Cloudflare 適合在 CDN 層處理網域、路徑或批量規則，尤其是源站不方便調整時。可使用 Redirect Rules 或舊版 Page Rules，把舊路徑永久導向新路徑。

適合情境：網站已接 Cloudflare、需要快速套用 HTTP 到 HTTPS、舊網域到新網域，或部分路徑規則。檢查方式是確認 Cloudflare 規則與主機規則不重複，避免 HTTP 到 HTTPS 再到 www 再到 non-www 的多段跳轉。

Wix、SHOPLINE、CYBERBIZ 等平台後台的限制與注意事項

平台型網站通常提供後台轉址功能，但規則能力、批量匯入、參數處理與觸發條件會受限制。設定前要先確認是否支援一對一轉址、是否支援路徑規則、是否能匯入大量 URL。

部分平台可能只有舊網址成為 404 時才觸發轉址

有些平台的轉址邏輯只在舊網址不存在時生效。如果舊頁仍存在，轉址可能不會觸發。這種情況要先確認舊頁是否已下架，並用實際舊網址測試，而不是只看後台顯示已建立規則。

大量 URL 變更時，如何規劃批量 301？

大量 URL 變更時，先做 URL 對照表，再依頁面類型、路徑規則與商業價值規劃批量 301。不要等上線後用 404 報表補洞，因為那會讓搜尋引擎先看到一批失效網址。

這張流程表適合改版、搬站、電商分類重整前使用。

先做 URL 對照表，不要直接上線後補救

URL 對照表至少要包含舊網址、新網址、頁面類型、流量、排名、外部連結、處理方式與備註。這份表不是行政文件，而是改版 SEO 的控制台。

商品頁、分類頁、文章頁要分開規劃

商品頁重視替代商品與營收意圖，分類頁重視分類架構與篩選頁，文章頁重視搜尋意圖與主題一致性。把不同頁型混在同一條規則中，很容易把高價值商品頁導到不相關分類。

相同路徑規則可用群組重新導向

如果只是路徑前綴改變，例如 /blog/ 全部改成 /articles/，可用群組規則處理。但如果 slug、分類或語言結構同時改變，就要小心不要過度依賴單一規則。

中文網址、參數網址、UTM 與篩選頁要先標準化

台灣網站常見中文網址，設定 301 時要確認後台顯示、瀏覽器網址、伺服器記錄中的編碼是否一致。參數網址如 UTM、排序、篩選條件，則要先判斷是否有索引與流量價值，不要每一個參數版本都手動轉址。

301 對 SEO 有什麼影響？會不會掉排名？

301 通常能協助搜尋引擎把舊網址訊號轉到新網址，但仍可能出現短期排名與自然流量波動。結果取決於新舊頁相關性、抓取頻率、內鏈更新、canonical、sitemap 與網站整體品質。

301 通常能協助搜尋引擎把舊頁訊號轉到新頁

當舊頁與新頁主題一致，且新頁能滿足相同或更完整的搜尋意圖，301 有助於搜尋引擎理解這是同一資源的永久位置變更。反向連結、內部連結與歷史訊號也較有機會被重新歸到新 URL。

不要承諾「完整保留權重」

301 不是 100% 保留 SEO 權重的保證。若新頁內容薄弱、主題不相關、內鏈仍指向舊網址，或網站同時發生大量結構變更，排名波動會更明顯。

我會把 301 視為降低損失的正確工程，而不是排名保險。真正影響結果的，是新頁是否值得承接舊頁的搜尋意圖。

設定後恢復時間取決於網站規模、抓取頻率與對應品質

小型網站少量 URL 變更，搜尋引擎可能較快重新處理；大型電商或大量文章改版，更新索引與穩定排名通常需要更長時間。不要只看上線後一天的排名判斷成敗，至少要搭配多週趨勢觀察。

用 GSC、排名、流量、404、伺服器 log 監控

設定後要看 Google Search Console 的索引狀態、找不到網頁、轉址頁面、自然搜尋點擊與曝光。若有伺服器 log，也可確認 Googlebot 是否持續抓取舊網址，以及是否順利抵達新網址。

301 設定前、中、後的 SEO 檢查清單

301 設定要分成上線前、上線時與上線後檢查。上線前盤點舊 URL，上線時確認狀態碼與內鏈，上線後追蹤 GSC、404、排名、自然流量、轉址鏈與轉址迴圈。

上線前：盤點舊 URL、流量頁、外鏈頁、排名頁

• 從 sitemap、GSC、Analytics、後台與爬蟲工具匯出舊 URL。
• 標記有自然流量、排名、反向連結、營收與重要內鏈的頁面。
• 建立 URL 對照表，確認每個高價值舊網址都有最相關新網址。
• 分開處理商品頁、分類頁、文章頁、活動頁與系統頁。
• 確認 canonical 規劃，新頁不應指回舊網址。

上線時：檢查狀態碼、canonical、sitemap、內鏈

• 抽測重要舊網址是否回傳 301，而不是 302、404 或 200。
• 確認最終目標頁是正確新網址，不經過多段轉址鏈。
• 更新 sitemap，只保留應被索引的新網址。
• 更新內部連結，避免站內仍連到舊網址再依賴 301 跳轉。
• 確認新頁 canonical 指向自己或正確標準頁。

上線後：追蹤 GSC、404、排名、自然流量、轉址鏈

• 在 GSC 觀察索引狀態、找不到網頁、已重新導向頁面與自然搜尋趨勢。
• 用爬蟲工具批量檢查 404、302、轉址鏈與轉址迴圈。
• 追蹤核心關鍵字排名與重點頁自然流量，不只看全站總流量。
• 修正仍留在 sitemap、內鏈或 canonical 裡的舊網址。
• 檢查重要外部入口頁是否已正確導到最相關新頁。

最常見的 301 錯誤：全站導首頁、轉址鏈與轉址迴圈

最常見的 301 錯誤包括把所有舊網址導到首頁、導到不相關頁、產生轉址鏈、形成轉址迴圈，以及 sitemap 或 canonical 仍指向舊網址。這些錯誤會讓搜尋引擎難以理解新舊頁關係。

用這張錯誤案例表檢查改版後是否踩到高風險問題。

不要把所有舊網址都導到首頁

首頁不能承接所有搜尋意圖。文章頁、商品頁、分類頁各有不同需求，把它們全導首頁，只是把明確的搜尋入口變成模糊入口。比較好的做法是逐頁找相近新頁，真的沒有替代內容時才考慮 404 或 410。

A → B → C 的轉址鏈會增加抓取與速度成本

轉址鏈常發生在多次改版後，例如舊文章先導到新版文章，後來新版文章又改 slug。應定期把規則整理成舊網址直接導到最終新網址，減少多段跳轉。

A → B → A 的轉址迴圈會讓使用者與爬蟲卡住

轉址迴圈通常來自重複設定，例如 Cloudflare、主機與 CMS 同時處理 HTTPS 或 www 規則。當瀏覽器顯示重新導向次數過多，或工具檢查不到最終頁，就要回頭檢查每一層規則。

舊網址仍在 sitemap、canonical 指回舊頁，會造成混亂

301 上線後，sitemap 應改列新網址，內鏈也應直接指向新網址。若新頁 canonical 仍指回舊頁，搜尋引擎會同時收到「舊頁已轉址」與「舊頁是標準頁」兩種矛盾訊號。

如何檢查 301 是否設定成功？

檢查 301 是否成功，要確認舊網址回傳 HTTP 301、Location 指向正確新網址、最終頁可正常開啟，且沒有 302、404、轉址鏈或轉址迴圈。單看瀏覽器跳頁成功不夠。

用瀏覽器確認舊網址是否導到正確新網址

先用無痕視窗打開舊網址，確認頁面是否自動導到預期的新網址。這一步能快速檢查使用者體驗，但瀏覽器不會明確告訴你中間是否經過 301、302 或多段跳轉。

用 curl -I 檢查狀態碼

技術檢查可以用 curl -I 看 HTTP 狀態碼與 Location。適合工程師、SEO 顧問與需要抽測重要 URL 的改版專案。

curl -I https://www.example.com/old-page

理想結果應看到 HTTP/2 301 或 HTTP/1.1 301，並且 Location 是正確的新網址。如果看到 302，代表不是永久轉址；如果看到 404，代表規則沒有命中；如果 Location 又指回原網址，就可能是轉址迴圈。

批量檢查時用爬蟲工具找 404、302、轉址鏈

大量 URL 不適合手動一筆一筆看。可用 Screaming Frog 類爬蟲工具、HTTP status checker 或自建腳本匯入舊網址清單，批量檢查狀態碼、最終 URL、轉址鏈與錯誤頁。

用 GSC 觀察索引與錯誤變化

Google Search Console 可觀察索引狀態、找不到網頁、已重新導向頁面、自然搜尋點擊與曝光變化。GSC 不是即時監控工具，但很適合判斷搜尋引擎是否逐步接受新的 URL 結構。

本文不處理的範圍

301 重新導向的重點是正確處理舊網址與新網址的永久變更，避免 SEO 訊號與索引混亂。與轉址決策無直接關係的圖片、DNS 全教程與 HTTP 狀態碼大全，不應混進同一篇操作指南。

不做圖片規劃

圖片命名、壓縮、alt、圖片 sitemap 與 CDN 圖片處理，不是這篇的核心範圍。除非圖片 URL 本身也發生永久變更，否則不需要放進 301 決策。

不展開 DNS、主機、CDN 完整課程

301 可能發生在主機或 CDN 層，但設定轉址不等於學完整 DNS、伺服器維運或 Cloudflare 全功能。這裡只保留與轉址是否生效、是否產生多段跳轉有關的判斷。

不把本文變成所有轉址類型百科

307、308 等狀態碼在技術上有其用途，但台灣 SEO 實務最常見的決策仍集中在 301、302、canonical、404、410。過度展開狀態碼規格，只會稀釋「如何正確設定 301 而不影響 SEO」這個核心問題。