301 是「永久」轉址，會把舊網址的排名權重與索引移交給新網址；302 是「暫時」轉址，權重原則上留在原網址。換網域、改版、HTTP 升 HTTPS 一律用 301；短期活動、A/B 測試、臨時維護才用 302。Google 在 2016 年由 Gary Illyes 公開確認 301 不再稀釋 PageRank，選錯狀態碼才是排名掉下去的真正元兇。
TL;DR：301 傳遞權重、新網址取代舊網址；302 不轉移權重、舊網址留在索引。Google 自 2016 年確認 301 不稀釋 PageRank，真正讓排名蒸發的不是 301 本身，而是把所有舊頁導向首頁。
文章目錄
301 與 302 Redirect 的核心差異：永久 vs 暫時，一句話講清楚
301 代表「永久重新導向」，舊網址的 PageRank 會移交給新網址，新網址會取代舊網址出現在搜尋結果。302 代表「暫時重新導向」，權重原則上留在原網址，舊網址繼續留在 Google 索引裡。一句話決策邏輯：問自己「這個轉址會不會永久存在」，會就用 301，不會就用 302。這個判斷跟你的網站類型、流量大小都無關，純粹看網址變動的本質。
很多人怕 301 會掉排名，於是改用 302 來做永久搬家。這個想法聽起來保守，結果卻最危險。權重一直卡在舊網址，新網址排不上來，等於搬家搬了一半。真正該擔心的不是 301，而是把永久當暫時來處理，這個誤判比你想像中常見。
HTTP 狀態碼的語意對 Google 來說是訊號，不是裝飾品。亂用會讓 Google 誤判整個網站結構，這在 技術 SEO 的健檢裡屬於高優先序的問題。Googlebot 讀到 3xx 會跟著走，但走完之後怎麼處理權重與索引，完全取決於你是給它 301 還是 302，這個判斷對 整體 SEO 策略的影響比多数人以为的更深。與其糾結哪個數字看起來比較新，不如先確認這次網址變動的本質。
一個常見的誤解是把 301 當成「危險動作」，於是能用 302 就用 302。實際上 301 才是 Google 最熟悉、處理最穩定的永久轉址方式。你怕的那個「掉權重」早已是過時資訊，反倒是不設轉址、或設成 canonical 處理不一致，才是真正的地雷。
選擇狀態碼的判斷流程
- 會永久存在（換網域、改版、HTTPS 升級）→ 301
- 只是暫時的（短期活動、A/B 測試、臨時維護）→ 302
- 拿不準，問自己一個月後這個轉址還會不會在 → 會就在 301，不會就在 302
Redirect 重定向到底是什麼？為什麼網站非做不可
Redirect（重定向，又稱轉址）是當使用者或 Google 爬蟲連到 A 網址時，伺服器自動把它導向 B 網址的技術，背後靠的是 HTTP 3xx 狀態碼。它的存在是為了在網址變動時不讓訪客撞上 404，同時讓搜尋引擎知道內容搬去了哪裡。
不做轉址的後果很直接。訪客看到 404 頁面就離開，外部連結的權重歸零，Google 把頁面從索引移除，排名跟著掉。這不是可選項，是網址異動時保護排名資產的必做動作，跟 內部連結最佳化一樣屬於地基工程。地基沒打好，上面蓋再多 站內 SEO 內容都會跟著晃。
會用到轉址的情境其實比想像中多。換網域、改版調整網址結構、刪除舊頁面、HTTP 升 HTTPS、合併重複內容、www 與非 www 統一、活動頁上下線，每一個都需要對應的轉址設定。把這些情境想清楚，才不會臨時找不到對的狀態碼。很多站長第一次碰到轉址，都是在網站最佳化流程或主機搬移的時候，平常根本不會主動想這件事。
3xx 系列家族成員
- 301：永久重新導向，權重轉移
- 302：暫時重新導向，權重原則上不轉移
- 307：302 的升級版，嚴格保留 request method
- 308：301 的升級版，永久且保留 method
這四個的差別只有兩個維度：永久還是暫時、要不要保留原始的 HTTP method。對多數內容網站來說，301 與 302 已經夠用，307 與 308 是給表單、API、付款流程用的進階選項。
301 重定向對 SEO 排名的真實影響：權重會不會掉
正確設定的 301 會把舊網址的權重幾乎完整傳遞給新網址，不會永久損失排名。短期內可能出現波動，這是 Google 重新檢索與重新評估新網址的正常過程，等重新索引穩定後會回來。早年一度傳聞 301 會損失 15% 權重，這個說法已經過時，卻還在不少論壇與教學文章裡流傳，把很多站長嚇得不敢用 301。
Google 在 2016 年由 Gary Illyes 公開確認 301 不再稀釋 連結權重。這代表你不需要為了「怕掉權重」而閃躲 301，反而要怕的是設錯方向。短期波動屬正常，小站通常數天到兩週內回穩，大型網站或大量同時轉址可能要數週到數個月。這段波動期間不要急著改設定，給 Google 搜尋足夠的時間重新檢索才是正解。
影響回穩速度的關鍵有三個：是否做到頁面對頁面的 1:1 對應、是否更新站內連結、是否提交新 sitemap。這三件事缺一不可，尤其是第一個。把所有舊頁全部 301 到首頁，會讓長尾排名大量流失，這是搬家翻車的第一名原因，比 核心演算法更新造成的波動更難救回來。
另一個容易被忽略的點：301 的回穩速度也跟你新頁面的內容品質有關。如果新頁面本身就符合 E-E-A-T 的信任與專業訊號，Google 重新評估時會更快給予肯定。反之，新頁面內容單薄，就算權重轉移成功，排名也可能在重新評估後往下修。
301 回穩期間會發生什麼事
- 第 1 到 7 天：舊網址排名可能暫時起伏，新網址尚未完全索引
- 第 1 到 4 週：Google 重新檢索舊網址與新網址，索引逐步轉換
- 第 4 到 8 週：新網址曝光與索引數逐步回升，排名趨於穩定
這段期間不要慌。很多人看到隔天排名掉了就以為設定失敗，其實是 Google 還在處理。你可以用 Google 搜尋的運作方式來理解這個時間差，給它 7 到 28 天的觀察期再做下一步判斷。
302 重定向什麼時候才該用：3 個合理場景與一個危險地帶
只有當轉址真的是「暫時的、之後會還原」時才用 302。合理場景有三個：短期活動頁、A/B 測試、網站臨時維護。千萬不要因為「怕 301 會掉排名」就拿 302 來做永久搬家，那反而會讓權重卡在舊網址、新網址排不上來。
第一個合理場景是短期活動。例如雙 11、聖誕節促銷，首頁暫時 302 到活動頁，活動結束拿掉轉址就回到原頁。第二個是 A/B 測試，把部分流量暫時導向測試版本頁面，這跟 轉換率最佳化的實驗流程直接相關。第三個是網站臨時維護或伺服器搬移，預期很快就會回來。這些情境的共同點是「之後會還原」。
危險地帶在這裡：把本來該用 301 的永久搬家誤用 302。權重一直留在舊網址，新網址永遠排不上去。或者反向把暫時的用成 301，活動結束後想還原才發現已經被當永久處理。Google 的灰色地帶是，302 放太久可能自動當成 301，但這個行為不可預期，不能當作依賴的理由。
活動頁下線的正確處理
活動結束後，網址不能留成 404。若活動期間用過 302，下線後應改 301 導到最相關的分類頁或常設活動頁。這個動作與 降低跳出率直接相關，留成 404 等於把好不容易累積的流量推開，也等於丟掉這段期間衝出來的 自然流量。
301 vs 302 完整比較表：從權重、索引到設定一次看懂
兩者在權重轉移、索引行為、回穩速度、適用情境上都不同。301 傳遞權重且新網址取代舊網址；302 原則不轉移權重、舊網址留在索引。這張比較表是你在選擇時最直接的判斷依據，看完就不用再糾結。把這張表存下來，下次遇到改版或活動頁下線時直接對照，能幫你省下反覆查資料的時間。
| 比較項目 | 301 永久轉址 | 302 暫時轉址 |
|---|---|---|
| 性質 | 永久重新導向 | 暫時重新導向 |
| PageRank 轉移 | 傳遞（完整） | 原則上不轉移（放太久行為會變） |
| 索引行為 | 新網址取代舊網址出現在搜尋結果 | 保留原網址在索引 |
| 回穩時間 | 需等 Google 重新檢索（數天到數週） | 權重未動，通常較無排名波動 |
| 適用場景 | 換網域、改版、HTTP 升 HTTPS、合併重複內容 | 短期活動、A/B 測試、臨時維護 |
| 設定差異 | 狀態碼寫 301 | 狀態碼改 302（其餘寫法相同） |
看清楚這張表你會發現，301 與 302 的寫法只差一個數字，但背後的 SEO 意義完全不同。設定前務必備份，設定後要用狀態碼檢查工具驗證真的回傳了對的 3xx，否則跟 常被忽略的技術 SEO 錯誤一樣，問題要到掉排名才被發現。這也是為什麼 網站架構最佳化的文件會把轉址驗證列為必跑流程。
如何設定 301 與 302 轉址：.htaccess、nginx、WordPress 三種實戰寫法
常見有三條路：Apache 伺服器寫 .htaccess、nginx 改設定檔、或 WordPress 站長直接裝 Redirection 外掛。三種方式的 301 與 302 寫法只差一個狀態碼數字，但設定前務必備份、設定後要用工具驗證實際回傳的 3xx。
Apache .htaccess 寫法
單頁 301 的寫法很簡單：Redirect 301 /old.php https://example.com/new.php。把 301 改成 302 就是暫時轉址。整網域搬家則要開啟 RewriteEngine，用 RewriteRule 把所有路徑導到新網域。這是最常見的HTTP 升 HTTPS轉址寫法，也是多數站長第一次接觸 .htaccess 的契機。
Apache 的 RewriteCond 還能做條件判斷，例如只在 HTTPS off 時才觸發轉址，避免已經是 HTTPS 的請求被重複轉一次。這類規則寫錯很容易產生迴圈，建議參考 網站程式碼最佳化的原則，改一段驗一段，不要整批上線。.htaccess 一旦寫錯，輕則 500 內部錯誤，重則整站打不開，這個風險值得你多花十分鐘分批驗證。
nginx 設定檔寫法
nginx 不認 .htaccess，要改設定檔。整網域搬家用 return 301 https://newdomain.com$request_uri;，單頁可用 rewrite 搭配 permanent 或 redirect 關鍵字。改完記得 reload 讓設定生效，這一步常被忘掉。nginx 的設定跟 HTTP/2、快取規則寫在同一個檔案，改的時候要小心不要動到其他區塊。
WordPress 外掛寫法
WordPress 站長不用碰程式碼。裝 Redirection 外掛就能在後台逐一設定 301 或 302，並記錄 404 錯誤。Rank Math 也內建轉址功能，與 WordPress SEO 最佳化整合得更緊。對不熟伺服器的人來說，外掛是最安全的入口，配合 Site Kit by Google 一起用，轉址設定與資料監控都能在同一個後台搞定。
驗證步驟不能省
設完不是結束。用 httpstatus.io 或 curl -I 檢查實際回傳的狀態碼，確認是 301 或 302 而不是 200，也不是錯誤的鏈狀轉址。很多人設完就放著，等掉排名才回頭查，這時候損失已經發生了。驗證的同時也可以順手用 Google WEB.DEV 或 PageSpeed Insights 確認轉址沒有拖慢頁面速度。
網域搬家完整 SOP：5 個步驟把 301 用對，不讓排名蒸發
換網域的核心是「舊網址 1:1 對應到新網址、設好 301、提交新 sitemap、保持舊網域轉址至少半年」。最忌諱把所有舊頁全部導向新網域首頁，那會讓長尾排名大量流失。下面這五個步驟照著做，能把風險壓到最低。
步驟一：新網域先建好站
新網域先建好站、確認每個頁面都能正常開啟，再開始動舊站。順序不能反，否則舊站的 301 指向一個還沒準備好的新站，等於把使用者帶到工地。這一步也包含確認 行動優先索引在新站正常運作，以及 Core Web Vitals分數沒有因為換主機而退化。
步驟二：建立 1:1 對應清單
建立舊網址到新網址的 1:1 對應清單，page-to-page，不要整批導首頁。這份清單是整個搬家工程的骨架，漏一頁就少一份權重。把清單建好之後，再對照 改善 SEO 的方法檢查新站的站內連結是否到位。
步驟三：舊站設定 301
在舊站設定 301，逐頁對應轉到新網域的對應頁面。設完立刻用 httpstatus.io 抽查幾個關鍵網址，確認回傳的是 301 而不是 200 或 404。這個動作要在流量離峰時段做，避免搬家期間影響正在下單的使用者。
步驟四：提交新 sitemap 到 Search Console
到 Google Search Console 使用「變更網址」工具，並提交新網域的 sitemap。這會加速 Google 發現新站並開始重新檢索，原理跟 加速索引是一致的。同步更新站內所有指向舊頁的連結與 Schema 中的 URL 欄位，避免訊號互相矛盾。
步驟五：舊網域 301 至少維持半年
舊網域的 301 至少維持六個月以上，同時更新外部連結（社群、合作媒體、名片）指向新網址。AI 爬蟲與既有外部連結會持續造訪舊網址一段時間，太早下線等於把這些訪客推開。用 Search Console 監看新網域的索引數與曝光是否逐步回升，通常 4 到 8 週能看到趨勢。
最常見的 5 個轉址錯誤：這些動作會直接傷害你的 SEO
最致命的五個錯誤是：把所有舊頁全導首頁、放任轉址鏈、該用 301 卻用 302、用 meta refresh 或 JS redirect 來做 SEO 轉址、設定完沒驗證狀態碼。任何一個都可能讓排名無聲地往下掉，等到發現時往往已經流失好幾週的流量。老實說，這些錯誤我都在實際專案裡看過，沒有一個是理論上的危險，它們每天都在不同的網站上發生。
- 錯誤一 page-to-home：所有舊頁 301 到新站首頁，長尾關鍵字權重全數流失，是搬家翻車第一名原因
- 錯誤二 redirect chain：A→B→C，應改成 A 直接指向 C，鏈太長 Google 可能放棄追蹤並丟失權重
- 錯誤三 永久誤用 302：權重卡在舊網址、新網址排不上去
- 錯誤四 用 meta refresh 或 JS：搜尋引擎處理較慢且訊號不明確，應改用標準 3xx
- 錯誤五 設完不驗證：以為設了 301 其實伺服器回傳 200 或迴圈
還有一個隱藏版殺手：轉址迴圈（redirect loop）A→B→A。這會讓瀏覽器與 Googlebot 都無法開啟頁面，等於直接把頁面下架。這類問題通常出現在 HTTPS、www、子網域與子目錄設定互相打架的時候，設完務必用工具跑一次全站。轉址鏈太長也會吃掉 網站速度，每多一跳就多一次往返，手機用戶感受尤其明顯。
307 與 308 是什麼？跟 301、302 的差別在哪
307 是 302 的升級版（暫時）、308 是 301 的升級版（永久），差別在於它們嚴格保留原始的 HTTP request method，POST 不會被偷偷改成 GET。對多數網站 SEO 而言 301 仍夠用，但如果是表單、API、登入流程涉及 POST 的轉址，307 與 308 更安全。簡單說，307 與 308 是給開發者用的防呆機制，對純內容站長來說，知道它們存在就夠了。
302 的歷史包袱在這裡：早期實作會把 POST 改成 GET，307 就是為了修正這個行為，明確保留 method。308 是 301 的對應版本，永久且保留 method。對一般靜態頁面與內容網站，301 與 308 的排名訊號效果相近，Google 都能正確處理。差別只在牽涉到表單與 結構化資料提交流程時，保留 method 才不會出問題。
實務建議很簡單。純內容網站用 301 與 302 即可，涉及表單提交、API、付款流程時改用 307 與 308 避免 method 被改。不要為了看起來新就硬改用 308，大多數主機與外掛對 308 支援不如 301 成熟，反而埋下日後除錯的麻煩。把這條記下來，能幫你省掉很多半夜被叫起來查問題的時間。
換個角度想，狀態碼的世界其實只有兩個問題要回答：這次轉址是永久的還是暫時的？要不要保留原始的 HTTP method？第一個問題決定你用 3xx 的哪一組，第二個問題決定你要不要升級到 307 或 308。兩個問題都回答完，狀態碼就選定了，剩下的只是寫法與驗證。
2026 年 AI 搜尋時代，轉址還要做哪些調整
2026 年除了傳統 SERP，Google AI Overviews 與各種 AI 答題引擎也會抓取並引用網頁內容。轉址時除了設好 301，還要確保新網址的 canonical、結構化資料、內部連結都指向新頁，並保持舊網址長期可達，否則 AI 引用舊連結會把使用者帶到錯的地方。這跟 AEO 答案引擎最佳化講的是同一件事：訊號必須一致，AI 才抄得對。
AI 也有獨立檢索層。根據 Ahrefs 2026 年資料，被 AI 引用的頁面中有相當比例在傳統 SERP 流量為零，代表 AI 有自己的發現與索引邏輯，轉址訊號必須清楚一致。只設 301 但 canonical 還指著舊網址，會讓 Google 與 AI 收到互相矛盾的訊號，這也是 GEO 生成式引擎最佳化會反覆強調的重點。
換網址後，站內所有指向舊頁的連結、Schema 中的 URL 欄位都要改成新網址。舊網址不要急著下線，AI 爬蟲與既有外部連結會持續造訪舊網址一段時間，301 要維持至少半年以上。若發現 AI 搜尋引用的是舊網址，代表轉址或 canonical 訊號還沒完全傳遞，需要再驗證。從 Google I/O 2026 的方向看，未來 AI Agent 抓取網頁的頻率只會更高，舊網址長期可達的重要性只增不減。
AI 時代的轉址檢查清單
- 301 設好之外，canonical 同步指向新網址
- 站內連結與 Schema 的 URL 欄位全部更新
- 舊網址長期可達，至少維持半年
- 監控 AI 引用來源，發現引用舊網址就回頭查訊號
退一步看，AI 搜尋帶來的新功課其實只有一個：訊號要一致。301、canonical、站內連結、Schema、外部連結，這五個地方只要有一個還指著舊網址，AI 與 Google 就會收到矛盾訊號。一致性比任何單一設定都重要，這是 2026 年做轉址時最值得記住的一句話。
轉址設定後的檢查與監控：用這幾個工具確認沒有漏網之魚
設完不是結束，要用 httpstatus.io 或 curl -I 驗證回傳的狀態碼、用 Screaming Frog 爬全站找出漏掉的 404 與轉址鏈、用 Google Search Console 監看索引與曝光變化。這三層檢查缺一不可，否則出問題往往要等掉排名才會發現。觀察週期建議設定後第一週、第一個月、第三個月各跑一次，特別是大規模搬家或改版。
第一層：單點抽查
用 httpstatus.io 或 curl -I 抽查幾個關鍵網址，確認回傳的是 301 或 302 而不是 200、404、或迴圈。這是最快的第一道防線，花不到五分鐘就能排除最常見的低級錯誤。
第二層：全站爬蟲
用 Screaming Frog SEO Spider 爬全站，找出還沒設轉址的 404、過長的轉址鏈、與 redirect loop。這一層能看到單點抽查看不到的全貌，跟 Google SEO 工具搭配 SERP 監控一起跑，屬於定期該做的例行工作。爬蟲報表也能順便檢查 錨文字是否還有指向舊網址的殘留，這類殘留一旦累積太多，會讓 Google 對你網站的內部連結結構產生誤判。
第三層：Search Console 監看
Google Search Console 的索引涵蓋範圍報表，觀察新網址是否逐步被索引、舊網址曝光是否正常移交。建議設定後第一週、第一個月、第三個月各檢查一次，特別是大規模搬家或改版。就算設定正確，Google 也需要時間重新檢索，不要因為隔天沒動就以為失敗。
301 與 302 常見疑問 FAQ：搬家、活動頁、HTTPS 一次回答
把站長最常遇到的情境整理成 FAQ：換網域要設多久、活動頁下線後怎麼處理、HTTP 升 HTTPS 用哪個、302 放太久會怎樣、轉址會不會影響已經排上的關鍵字、還有設完多久才會看到排名回穩。每題都給一個可以直接照做的答案。
Q1：換網域的 301 要保留多久？
至少半年以上，長一點更保險。外部連結與 AI 爬蟲會持續造訪舊網址，太早把舊網域下線等於把這些來源推開。與 網站改版一樣，舊的東西不要急著拆。這段期間也要持續經營新網域的權重，讓 網域權重穩定累積。
Q2：活動頁下線後網址怎麼辦？
若是短期活動用過 302，下線後改 301 導到最相關的分類頁或常設活動頁，不要留成 404。這個動作能保住活動期間累積的流量，也避免使用者與 Google 撞上死胡同，對 內部連結的權重傳遞也有幫助。
Q3：HTTP 升 HTTPS 要用哪個？
301。這是永久性的協定升級，整站都要設。升級完記得更新 llms.txt 與 sitemap 裡的網址，讓所有訊號一致指向 HTTPS 版本。升級的脈絡可以參考 Chrome 移除安全標籤的歷史，HTTPS 早已從加分項變成基本標準。
Q4：302 放太久會怎樣？
Google 可能自動當成 301 處理，但行為不可預期。若其實是暫時的，反而會被誤當永久，活動結束後想還原才發現回不去。正確做法是按實際需求選對狀態碼，不要依賴 Google 的自動判斷。把命運交給搜尋引擎的自動判斷，等於把網站排名押在一個你無法控制的機制上，這不是穩健的 SEO 做法。
Q5：轉址會影響已經排上去的關鍵字嗎？
301 正確對應的情況下權重會轉移、排名通常會回穩。亂導首頁或放任轉址鏈則會掉。這跟 演算法更新後的排名回復邏輯一致，訊號清楚才有機會回穩。回穩期間也可以參考 SEO 入門的基礎檢查，確認沒有其他技術問題同時發生。
Q6：設完多久才會看到排名回穩？
小站常見幾天到兩週，大站或大量轉址可能要數週到數個月。這段期間用 Search Console 監看新網址的索引與曝光變化，給它 4 到 8 週的觀察期再做下一步判斷。若超過兩個月仍沒有回升跡象，就要回頭檢查是不是有轉址鏈、canonical 不一致，或新頁面內容品質不足等問題。
回顧一下整篇文章的主軸：301 與 302 的選擇，不是看數字哪個看起來比較安全，而是看這次網址變動的本質。會永久存在就用 301，只是暫時就用 302，設完記得驗證狀態碼、更新站內連結與 canonical、保持舊網址長期可達。把這幾件事做對，你的排名資產就能跟著新網址一起搬過去，而不是無聲地蒸發在搬家過程裡。
直白地講，轉址這件事沒有什麼高深的學問，最常出事的永遠是那幾個老問題：整批導首頁、轉址鏈、設完不驗證、永久誤用 302。把這篇的網域搬家 SOP 走一遍，再動手設定，會比事後補救輕鬆很多。如果你正準備換網域或改版，建議先跟 SEO 公司或技術顧問確認過轉址清單，把 1:1 對應表建好再開工。真正難的不是寫那行 RewriteRule，而是在動手前把每一個舊網址都想清楚要去哪。
