轉址是什麼？301 與 302 差別、設定與搬家不掉排名

轉址（Redirection）是將舊網址自動跳轉到新網址的技術，在網站搬家、網址變更、整併內容、修正 URL 結構時不可或缺。對 SEO 而言，轉址是否正確，直接決定舊網址累積多年的排名與連結權重能不能順利傳遞到新網址。目前主流的轉址方式有三種：301 永久轉址、302 臨時轉址，以及 Meta Refresh 跳轉。其中 301 是 SEO 最推薦的方法，因為 Google 表示 301 等永久轉址不會造成 PageRank 流失，並能讓搜尋引擎理解網頁已永久搬家。在 AI 搜尋時代，使用者透過 ChatGPT、Perplexity、Google AI Overviews 找到您的網站後，如果舊網址未正確轉址、出現 404 錯誤，不僅影響使用者體驗，也會讓 AI 引用您的資料時失準。這篇文章適合網站管理員、SEO 從業人員、工程師，以及準備改版或搬家的企業主閱讀。

什麼是轉址？為什麼 SEO 一定要懂

轉址（Redirection，又稱重定向）是當使用者或搜尋引擎請求某個 URL 時，伺服器自動將其導向另一個 URL 的機制。轉址在網際網路上幾乎隨處可見：當您鍵入 example.com，瀏覽器自動補成 https://www.example.com；當您點擊舊的活動連結，被導向最新的活動頁，這些都是轉址在背後運作。

轉址的核心目的

沒有正確轉址的代價

很多企業改版網站時忽略轉址規劃，導致排名一夕之間崩盤。實務上常見的後果包括：

• 舊網址全部變成 404，Google 開始大量取消舊頁面的索引
• 外部網站（媒體、合作夥伴、論壇）指向舊網址的反向連結全部失效，連結權重歸零
• 使用者書籤、社群媒體分享的連結通通打不開，直接流失既有流量
• Google Search Console 出現大量「找不到（404）」錯誤通知
• 網站整體排名與自然流量明顯下滑，需要很長一段時間才能恢復

轉址的四大種類比較

轉址在技術上可分為伺服器層轉址（由 HTTP 狀態碼回應）與網頁層轉址（由 HTML 或 JavaScript 執行）兩大類。下表整理四種主要轉址方式的差異：

301 永久轉址（Moved Permanently）

301 是永久性質的轉址，當搜尋引擎收到 301 回應時，會理解為「這個網頁已經永久搬家，以後請改用新網址」。Google 會在一段時間後將舊網址從索引中移除，並把原本舊網址的排名、外部反向連結權重、頁面權威度逐步轉移到新網址。

Google 在網站搬遷指南中明確表示，301 等永久轉址不會造成 PageRank 流失；過去流傳的「301 只能傳遞約 90% 至 99% 權重」已不適用。這也是為什麼 Google 官方建議：永久性的網址變更，一律使用 301。

302 Found 與 Moved Temporarily

302 是臨時性質的轉址。在 HTTP 1.0 規範中，302 的狀態描述為「Moved Temporarily（暫時移動）」，在 HTTP 1.1 中改為「Found（存在）」。雖然意義稍有不同，但對搜尋引擎來說，302 都代表「網頁只是暫時跳轉，原網址不應該被取消索引」。

Google 員工 John Mueller 曾多次在公開場合表示，如果長期使用 302，Google 最終可能會「猜測」這其實是 301，並把它當 301 處理。但「最終」要多久無從預估，期間 SEO 風險難以掌握，因此永久搬家絕對不應該用 302。

307 Moved Temporarily（僅 HTTP 1.1）

307 是 HTTP 1.1 規範中 302 的後續版本，主要差別在於嚴格保留原本的 HTTP 請求方法（例如 POST 維持 POST，不會被改成 GET）。在 SEO 上，主流搜尋爬蟲通常會把 307 視同 302 處理，所以實務上很少特別使用 307，除非是網站短期維護、A/B 測試等需要保留請求方法的情境。

Meta Refresh 網頁層跳轉

Meta Refresh 是寫在 HTML <head> 內的跳轉指令，典型寫法是：

<meta http-equiv="refresh" content="5;url=https://www.example.com/new-page">

這種方式通常搭配「如果您 5 秒內未自動跳轉，請點此」的文字一起出現。Meta Refresh 的問題在於：

• 跳轉發生在網頁層而非伺服器層，搜尋引擎處理較慢、不穩定
• 連結權重傳遞效果不如 301
• 使用者體驗較差（會看到中間的等待頁面）
• 容易被搜尋引擎判定為可疑行為（垃圾內容常用此技巧導流）

301 與 302 的差別：選錯會掉排名

301 與 302 是最容易被混淆的兩種轉址，但選錯一個，排名可能在幾週內崩盤。它們的差別不只在「永久」與「暫時」這幾個字，而是搜尋引擎對網頁的處理邏輯完全不同。

301 與 302 的核心差異

選錯轉址會發生什麼事

• 永久搬家用了 302：新網址無法繼承排名 如果您把舊網址永久轉到新網址，卻誤用 302，Google 會繼續把排名留在舊網址。但使用者實際打開的是新網址，新網址因為沒有累積權重，排名遠不如預期。
  某電商把產品頁網址從 /p123 改為 /products/iphone，用 302 轉址。之後新網址遲遲排不上來，舊網址在搜尋結果還掛在那邊，但點進去就被跳轉，使用者一頭霧水。
• 臨時活動用了 301：活動結束後排名永久轉移 促銷活動頁通常只上架幾週，如果用 301 把日常頁面轉到活動頁，活動結束後原網址的排名就永久轉到了已下架的活動頁，難以還原。
  服飾品牌把熱門商品頁 301 轉到「黑色星期五專區」，活動結束後該專區下架，熱門商品頁原本的排名也大幅下滑。
• 混用 301 與 302：Google 收到混亂訊號 同一個網址在不同時間回應不同狀態碼，會讓 Google 不確定該如何處理。索引可能不穩定，排名也會跟著浮動。
  某網站的 CDN 設定錯誤，白天回 301、晚上回 302，索引狀態變得不穩定，自然流量也跟著明顯波動。

實務判斷準則

什麼情況下要做轉址？六大情境

實務上有六種最常見的情境需要做轉址規劃。理解這些情境，可以避免在改版或搬家時遺漏細節：

• 網站搬家或網域變更 從舊網域整體搬到新網域，所有舊網址都要 301 轉址到新網域對應的網址。這是最重要、也最常出錯的轉址情境。
  某公司從 oldcompany.com.tw 改為 newbrand.com.tw，必須把舊網域上的每一個 URL 都對應轉址到新網域的相對位置。
• HTTP 升級為 HTTPS 升級 SSL 憑證後，所有 http:// 的網址都應 301 轉到 https://。Google 的頁面體驗說明也把「是否以 HTTPS 安全提供網頁」列為檢查項目，且 Chrome 會對 HTTP 網站顯示「不安全」警示。
  舊網址 http://www.example.com/about 應 301 轉到 https://www.example.com/about。
• www 與非 www 規範化 www.example.com 與 example.com 在技術上是兩個不同的網址。如果兩者都能存取，Google 會視為重複內容。應選定其中一個作為標準版本，另一個 301 轉址過去。
  統一使用 https://www.newscan.com.tw，並將 https://newscan.com.tw 301 轉址到含 www 的版本。
• 網址結構改版 從動態網址（?id=123）改為靜態語意化網址（/products/iphone-15），或調整資料夾結構，都需要規劃完整的 301 對照表。
  舊網址 /product.php?id=123 改為 /products/iphone-15-pro，需要逐一建立對應規則。
• 內容整併或下架 兩篇主題相近的舊文章整併為一篇新文章時，兩個舊網址都應 301 轉到新網址。商品停售下架時，也應該 301 轉到分類頁或相關替代商品，而不是讓使用者看到 404。
  「SEO 入門教學」和「SEO 基礎指南」整併為新的「SEO 完整指南」，兩個舊網址都 301 過去。
• 結尾斜線（Trailing Slash）統一 /about/ 與 /about 對搜尋引擎是不同的網址。應該選定一種格式，另一種 301 轉址。常見做法是內容頁加結尾斜線，檔案類網址（如 .html）不加。
  統一使用 /about/，則 /about 應 301 轉到 /about/。

用 .htaccess 與 mod_rewrite 實作 301 轉址

在 Apache 伺服器上，實作 301 轉址最常見的方式是透過 .htaccess 檔案搭配 mod_rewrite 模組。這是最有彈性、最不需要動到主機核心設定的方法，適合大多數虛擬主機環境。如果您的網站使用其他主機形式，可以參考搜尋引擎優化完整指南了解更多細節。

啟用 mod_rewrite 模組

在 .htaccess 檔案最上方加入以下指令，啟用重寫引擎：

RewriteEngine On

單頁網址 301 轉址

最簡單的單頁轉址，只要一行指令就能完成：

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

整個資料夾 301 轉址

當整個資料夾下的所有網頁都要轉到新位置，使用 RedirectMatch 搭配正規表達式：

RedirectMatch 301 ^/old-folder/(.*)$ https://www.example.com/new-folder/$1

這條規則的意思是：把 /old-folder/ 下的所有檔案（包含子資料夾），全部轉到 /new-folder/ 對應的位置，保留檔名與路徑。

強制使用 www 子網域

將沒有 www 的請求 301 轉到有 www 的版本：

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

強制使用 HTTPS

將所有 HTTP 請求 301 轉到 HTTPS：

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

同時統一 www 與 HTTPS

實務上最完整的做法是同時統一 www 子網域與 HTTPS，避免發生兩次轉址（會浪費爬蟲資源，也拖慢使用者開啟頁面的速度）：

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\\\\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

Nginx 主機的等效寫法

如果您的網站使用 Nginx 而非 Apache，.htaccess 不適用，需要編輯 Nginx 設定檔。同等的 301 轉址寫法如下：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    return 301 https://www.example.com$request_uri;
}

正規表達式（Regex）在轉址中的應用

當網站有幾百個甚至幾千個網址要轉址時，逐條撰寫規則不切實際。這時就需要正規表達式（Regular Expression，簡稱 Regex）來建立通用規則，一條指令處理大量網址。

正規表達式常用語法

實務範例：變更副檔名

舊網站使用 PHP，新網站全部改為靜態 HTML。要把所有 .php 結尾的網址轉到 .html：

RedirectMatch 301 ^/(.*)\\\\.php$ https://www.example.com/$1.html

說明：^/(.*)\\\\.php$ 匹配開頭是斜線、中間任意字元、結尾是 .php 的網址，把中間任意字元捕獲為 $1，再貼到新網址的對應位置，加上 .html 結尾。

實務範例：保留 GET 查詢字串

如果舊網址 /product.php?id=123&color=red 要轉到 /products.php?id=123&color=red（保留所有查詢參數）：

RewriteEngine On
RewriteRule ^product\\\\.php$ /products.php [L,R=301,QSA]

其中 QSA（Query String Append）旗標會自動把原本的查詢字串附加到新網址。

實務範例：多副檔名一次處理

把所有 .htm、.html、.php 結尾的舊網址都轉到對應的新 PHP 網址：

RedirectMatch 301 ^/articles/(.*)\\\\.(htm|html|php)$ https://www.example.com/blog/$1.php

轉址常見錯誤與排除方法

即使懂得語法，實作時仍有許多細節容易出錯。以下是台灣中小企業在做網站改版時最常踩到的六個轉址陷阱：

• 把所有舊網址全部轉到首頁 這是最常見的錯誤。為了省事，工程師把所有舊網址一律 301 到首頁，結果 Google 可能把這些轉址視為「軟性 404」（soft 404），舊網址累積的價值等於白白浪費。Google 的網站搬遷指南就明確提醒，不要把大量舊網址轉到首頁這類不相關的單一網址。改善方式：每個舊網址都應該轉到內容主題最相近的新網址，真的找不到對應新頁面才轉到分類頁或首頁。
• 混用 301 與 302 臨時用 301、永久用 302，或同一網址不同時間回應不同狀態碼，讓 Google 收到混亂訊號。改善方式：建立明確的判斷準則，永久搬家用 301，真的會回來才用 302，並用工具（如 Screaming Frog、Redirect Checker）定期檢查全站狀態碼一致性。
• 轉址鏈太長（Redirect Chain） 一個網址轉到 B、B 再轉到 C、C 再轉到 D。每多一站就多一次請求與出錯機會，且 Google 的檢索器預設最多跟隨 10 次轉址，超過就不會繼續抓取（Google 官方說明）。改善方式：把所有舊網址直接轉到最終目標，不要經過中間站。網站搬家時應該重新檢查全站轉址，把所有鏈式轉址壓平。
• 忽略 HTTPS 與 www 的組合 只做了 HTTPS 強制轉址，但沒處理 www 統一，結果出現「http://example.com 轉到 https://example.com，再轉到 https://www.example.com」的雙重轉址。改善方式：用單一條規則同時處理 HTTPS 與 www，一次到位。
• 忘記更新內部連結 做完 301 轉址後，網站內部選單、麵包屑、文章連結仍指向舊網址，造成每次點擊都經過轉址。改善方式：網站改版後，應該全面更新內部連結直接指向新網址，把 301 轉址留給外部連結與舊書籤使用。
• 用 JavaScript 或 Meta Refresh 替代 301 為了方便，用前端 JavaScript 或 Meta Refresh 做跳轉，搜尋引擎無法正確識別為永久轉址，SEO 效果大打折扣。改善方式：所有 SEO 相關的轉址都應該在伺服器層執行，回應正確的 301 HTTP 狀態碼。

檢查轉址是否正確的工具

實作完轉址規則後，建議用以下工具驗證是否運作正常：

• Redirect Path 或 Link Redirect Trace Chrome 擴充功能：即時查看當前頁面經過幾次轉址、每一站的狀態碼
• Screaming Frog SEO Spider：爬取全站，匯出所有轉址清單，找出鏈式轉址與循環轉址
• httpstatus.io：批次貼上多個 URL，一次檢查 HTTP 狀態碼
• Google Search Console 涵蓋範圍報告：檢查是否有「重新導向錯誤」「找不到（404）」等通知
• curl 指令：命令列輸入 curl -I https://example.com/page 直接查看 HTTP Header

AEO 時代：轉址對 AI 搜尋的影響

如今的搜尋環境，已經不只是 Google 一家獨大。ChatGPT Search、Perplexity、Claude、Google AI Overviews、Bing Copilot 等 AI 搜尋工具，正在改變使用者尋找資訊的方式。在這個 AEO（Answer Engine Optimization）時代，轉址的重要性比 SEO 時代更高。

AI 搜尋如何處理轉址

• AI 爬蟲的轉址上限沒有公開 ChatGPT 的 GPTBot、Anthropic 的 ClaudeBot、Perplexity 的 PerplexityBot 都沒有公開說明會跟隨幾次轉址。Google 的檢索器預設最多跟隨 10 次，官方也提醒個別產品的檢索器上限可能不同；面對規則不明的 AI 爬蟲，讓每個舊網址一次就轉到最終目標最保險。
  例如官網的轉址鏈長達好幾站，Googlebot 仍能抓到最終頁面，但無法確定每一種 AI 爬蟲都會跟到底，把轉址壓平成一站才不必冒這個險。
• 引用連結直接影響可信度 AI 搜尋會把引用來源的網址直接給使用者點擊。如果使用者點進去看到 404 或不相關的頁面，對這個來源的信任會打折，這次引用原本能帶來的流量也跟著流失。
  使用者問 ChatGPT「如何做 SEO 轉址」，ChatGPT 引用了某網站的舊文章連結，但該網址已下架且未做 301，使用者點進去只看到 404 頁面，這次被引用的機會等於白費。
• 舊內容仍可能被 AI 工具快取 ChatGPT、Claude 等大型語言模型的訓練資料有時間落差，可能仍記得您舊網址的內容。如果舊網址沒做 301，使用者透過 AI 找到的舊連結就會打不開，影響使用者體驗。
  例如改版時把熱門文章從 /article/seo-tips 改為 /blog/seo-tips-guide，若沒做 301，AI 工具仍可能引用舊網址，使用者點進去就會撞 404。

AEO 時代的轉址檢查清單

• 所有 HTTP 網址都已 301 轉到 HTTPS
• 所有非 www 網址都已 301 統一到 www（或反向）
• 沒有任何鏈式轉址（用 Screaming Frog 確認）
• 舊內容下架時都有 301 對應到主題相近的新內容
• 網站搬家時建立完整的舊網址與新網址對照表
• Google Search Console 沒有「重新導向錯誤」通知
• 主要 AI 爬蟲（GPTBot、ClaudeBot、PerplexityBot）未被 robots.txt 封鎖
• 網站與轉址的回應速度足夠快，避免爬蟲抓取逾時

結論：轉址做對，SEO 與 AEO 一起受益

轉址不是技術細節，而是網站長期 SEO 健康度的基礎建設。一個從未做好轉址規劃的網站，即使內容再好，也會在每次改版時流失流量；反之，一個轉址規則完善的網站，即使搬家、改版、升級，排名與權重都能順利傳承。

規劃轉址前，可以先用以下五個問題自我檢查：

• 網站是否已強制使用 HTTPS，並 301 轉址所有 HTTP 請求？
• www 與非 www 是否已選定其一作為標準，另一個 301 轉址過去？
• 過去改版或搬家時，是否有保留完整的舊網址與新網址對照表？
• 網站內是否存在鏈式轉址（A 轉 B 轉 C），需要壓平為直接轉址（A 轉 C）？
• 主要 AI 爬蟲是否能正常抓取您的內容，沒有被失效連結阻擋？

常見問答 FAQ