轉址(Redirection)是將舊網址自動跳轉到新網址的技術,在網站搬家、網址變更、整併內容、修正 URL 結構時不可或缺。對 SEO 而言,轉址是否正確,直接決定舊網址累積多年的排名與連結權重能不能順利傳遞到新網址。目前主流的轉址方式有三種:301 永久轉址、302 臨時轉址,以及 Meta Refresh 跳轉。其中 301 是 SEO 最推薦的方法,因為它能傳遞 90% 以上的連結權重,並讓搜尋引擎理解網頁已永久搬家。在 2026 年的 AI 搜尋時代,使用者透過 ChatGPT、Perplexity、Google AI Overviews 找到您的網站後,如果舊網址未正確轉址、出現 404 錯誤,不僅影響使用者體驗,也會讓 AI 引用您的資料時失準。這篇文章適合網站管理員、SEO 從業人員、工程師,以及準備改版或搬家的企業主閱讀。
什麼是轉址?為什麼 SEO 一定要懂
轉址(Redirection,又稱重定向)是當使用者或搜尋引擎請求某個 URL 時,伺服器自動將其導向另一個 URL 的機制。轉址在網際網路上幾乎隨處可見——當您鍵入 example.com,瀏覽器自動補成 https://www.example.com;當您點擊舊的活動連結,被導向最新的活動頁,這些都是轉址在背後運作。
轉址不只是一個「網址跳轉」的技術動作,而是網站結構變動時,保護 SEO 資產與使用者體驗的安全網。
轉址的兩個核心目的
www vs 非 www、http vs https、結尾斜線等規範化問題,避免搜尋引擎判定為重複內容。沒有正確轉址的代價
很多企業改版網站時忽略轉址規劃,導致排名一夕之間崩盤。實務上常見的後果包括:
- 舊網址全部變成 404,Google 開始大量取消舊頁面的索引
- 外部網站(媒體、合作夥伴、論壇)指向舊網址的反向連結全部失效,連結權重歸零
- 使用者書籤、社群媒體分享的連結通通打不開,直接流失既有流量
- Google Search Console 出現大量「找不到 (404)」錯誤通知
- 網站整體排名與自然流量在 2-4 週內明顯下滑,需要 3-6 個月才能恢復
轉址的四大種類比較
轉址在技術上可分為伺服器層轉址(由 HTTP 狀態碼回應)與網頁層轉址(由 HTML 或 JavaScript 執行)兩大類。下表整理四種主要轉址方式的差異:
| 轉址類型 | HTTP 狀態 | 連結權重傳遞 | 適用情境 | SEO 建議 |
|---|---|---|---|---|
| 301 永久轉址 | 301 Moved Permanently | 90%–99% | 網頁永久搬家、網域變更、HTTPS 升級 | 強烈推薦 |
| 302 臨時轉址 | 302 Found | 不穩定,通常較少 | 促銷活動、A/B 測試、地區語系切換 | 謹慎使用 |
| 307 臨時轉址 | 307 Temporary Redirect | 類似 302 | 網站維護期間、保留請求方法 | 特殊情境 |
| Meta Refresh | 200(網頁層執行) | 部分傳遞 | 不建議用於 SEO | 避免使用 |
301 永久轉址(Moved Permanently)
301 是永久性質的轉址,當搜尋引擎收到 301 回應時,會理解為「這個網頁已經永久搬家,以後請改用新網址」。Google 會在一段時間後將舊網址從索引中移除,並把原本舊網址的排名、外部反向連結權重、頁面權威度逐步轉移到新網址。
根據 Google 官方文件與多年來業界實測,301 轉址可傳遞約 90% 至 99% 的連結權重。這也是為什麼所有 SEO 專家、Google 官方都建議:永久性的網址變更,一律使用 301。
302 Found 與 Moved Temporarily
302 是臨時性質的轉址。在 HTTP 1.0 規範中,302 的狀態描述為「Moved Temporarily(暫時移動)」,在 HTTP 1.1 中改為「Found(存在)」。雖然意義稍有不同,但對搜尋引擎來說,302 都代表「網頁只是暫時跳轉,原網址不應該被取消索引」。
Google 員工 John Mueller 曾多次在 Twitter 與 Search Central 影片中表示,如果長期使用 302,Google 最終可能會「猜測」這其實是 301,並把它當 301 處理。但「最終」可能要 3 至 6 個月,期間 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;不會 → 用 301。
301 與 302 的核心差異
| 比較項目 | 301 永久轉址 | 302 臨時轉址 |
|---|---|---|
| 意義 | 網頁永久搬家 | 網頁暫時搬家,未來會回來 |
| 連結權重 | 傳遞 90%–99% 到新網址 | 權重保留在舊網址 |
| 索引處理 | 逐步用新網址取代舊網址 | 持續索引舊網址 |
| 瀏覽器快取 | 會記住轉址,直接跳轉 | 每次都重新確認 |
| 適用情境 | 網域變更、HTTPS、永久整併 | 促銷活動、A/B 測試、維護 |
選錯轉址會發生什麼事
-
永久搬家用了 302:新網址無法繼承排名
如果您把舊網址永久轉到新網址,卻誤用 302,Google 會繼續把排名留在舊網址。但使用者實際打開的是新網址,新網址因為沒有累積權重,排名遠不如預期。
某電商把產品頁網址從
/p123改為/products/iphone,用 302 轉址。三個月後新網址完全沒進前 10 名,舊網址在搜尋結果還掛在那邊,但點進去就被跳轉,使用者一頭霧水。 -
臨時活動用了 301:活動結束後排名永久轉移
促銷活動頁通常只上架幾週,如果用 301 把日常頁面轉到活動頁,活動結束後原網址的排名就永久轉到了已下架的活動頁,難以還原。
服飾品牌把熱門商品頁 301 轉到「黑色星期五專區」,活動結束後該專區下架,熱門商品頁排名直接從第 3 名掉到第 30 名外。
-
混用 301 與 302:Google 收到混亂訊號
同一個網址在不同時間回應不同狀態碼,會讓 Google 不確定該如何處理。索引可能不穩定,排名也會跟著浮動。
某網站的 CDN 設定錯誤,白天回 301、晚上回 302,Google Search Console 出現「索引狀態異常」通知,自然流量在兩週內波動達 40%。
實務判斷準則
會回來 → 用 302 臨時轉址。
不會回來 → 用 301 永久轉址。
.com.tw 換成 .tw → 301。某商品停售並下架 → 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.tw301 轉址到含 www 的版本。 -
網址結構改版
從動態網址(
?id=123)改為靜態語意化網址(/products/iphone-15),或調整資料夾結構,都需要規劃完整的 301 對照表。舊網址/product.php?id=123改為/products/iphone-15-pro,需要逐一建立對應規則。 -
內容整併或下架
兩篇主題相近的舊文章整併為一篇新文章時,兩個舊網址都應 301 轉到新網址。商品停售下架時,也應該 301 轉到分類頁或相關替代商品,而不是讓使用者看到 404。
「SEO 入門教學」和「SEO 基礎指南」整併為新的「2026 年 SEO 完整指南」,兩個舊網址都 301 過去。
-
結尾斜線(Trailing Slash)統一
/about/與/about對搜尋引擎是不同的網址。應該選定一種格式,另一種 301 轉址。常見做法是內容頁加結尾斜線,檔案類網址(如.html)不加。統一使用/about/,則/about應 301 轉到/about/。
用 .htaccess 與 mod_rewrite 實作 301 轉址
在 Apache 伺服器上,實作 301 轉址最常見的方式是透過 .htaccess 檔案搭配 mod_rewrite 模組。這是最有彈性、最不需要動到主機核心設定的方法,適合大多數虛擬主機環境。如果您的網站使用其他主機形式,可以參考新視野 SEO 教學指南了解更多細節。
啟用 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]
.htaccess 之前,務必先備份原檔。語法錯誤會讓整個網站出現 500 Internal Server Error,造成全站無法瀏覽。如果不熟悉 Apache 設定,建議在測試環境先驗證再上線。詳細的 .htaccess 操作可參考新視野 SEO 教學指南。
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)來建立通用規則,一條指令處理大量網址。
正規表達式常用語法
| 符號 | 意義 | 範例 |
|---|---|---|
. |
匹配任何單一字元 | a.c 可匹配 abc、a1c、a@c |
* |
匹配前面字元零個或多個 | ab* 可匹配 a、ab、abb、abbb |
+ |
匹配前面字元一個或多個 | ab+ 可匹配 ab、abb,但不匹配 a |
() |
圓括號捕獲群組,用於反向引用 | (.*) 捕獲任意字串為 $1 |
| |
「或」運算 | (php|html) 匹配 php 或 html |
^ |
字串開頭 | ^/blog/ 匹配以 /blog/ 開頭 |
$ |
字串結尾 | \\\\\\\\\\\\\\\\.html$ 匹配以 .html 結尾 |
\\\\\\\\\\\\\\\\ |
跳脫字元 | \\\\\\\\\\\\\\\\. 代表真的點號,不是任意字元 |
實務範例:變更副檔名
舊網站使用 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),不傳遞權重,反而傷害 SEO。改善方式:每個舊網址都應該轉到內容主題最相近的新網址,真的找不到對應新頁面才轉到分類頁或首頁。
- 混用 301 與 302 臨時用 301、永久用 302,或同一網址不同時間回應不同狀態碼,讓 Google 收到混亂訊號。改善方式:建立明確的判斷準則——永久搬家用 301,真的會回來才用 302,並用工具(如 Screaming Frog、Redirect Checker)定期檢查全站狀態碼一致性。
- 轉址鏈太長(Redirect Chain) 一個網址轉到 B、B 再轉到 C、C 再轉到 D。每經過一次轉址,權重就流失一些,且 Google 爬蟲最多只跟隨 5 次轉址,超過會直接放棄。改善方式:把所有舊網址直接轉到最終目標,不要經過中間站。網站搬家時應該重新檢查全站轉址,把所有鏈式轉址壓平。
-
忽略 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 搜尋的影響
2026 年的搜尋環境,已經不只是 Google 一家獨大。ChatGPT Search、Perplexity、Claude、Google AI Overviews、Bing Copilot 等 AI 搜尋工具,正在改變使用者尋找資訊的方式。在這個 AEO(Answer Engine Optimization)時代,轉址的重要性比 SEO 時代更高。
AI 搜尋工具引用網頁時,如果遇到失效連結或錯誤轉址,會直接跳過您的網站,改引用競爭對手。轉址不只是 SEO 議題,更是 AEO 的基礎建設。
AI 搜尋如何處理轉址
-
AI 爬蟲遵循 301 但更敏感
ChatGPT 的 GPTBot、Anthropic 的 ClaudeBot、Perplexity 的 PerplexityBot 都會跟隨 301 轉址。但 AI 爬蟲的容忍度比 Googlebot 更低,只要遇到鏈式轉址或回應緩慢,可能直接放棄該頁面。
某品牌官網的轉址鏈長達 4 站,Googlebot 仍會抓取,但 PerplexityBot 在第 2 次轉址就放棄,結果該品牌資料完全不出現在 Perplexity 的引用中。
-
引用連結直接影響可信度
AI 搜尋會把引用來源的網址直接給使用者點擊。如果使用者點進去看到 404 或不相關的頁面,會降低對 AI 工具的信任,AI 工具也會調降對該網站的引用權重。
使用者問 ChatGPT「如何做 SEO 轉址」,ChatGPT 引用了某網站的舊文章連結,但該網址已下架且未做 301,使用者看到 404 頁面,下次 ChatGPT 就會避免引用該網站。
-
舊內容仍可能被 AI 工具快取
ChatGPT、Claude 等大型語言模型的訓練資料有時間落差,可能仍記得您舊網址的內容。如果舊網址沒做 301,使用者透過 AI 找到的舊連結就會打不開,影響使用者體驗。
某顧問公司改版網站,熱門文章從
/article/seo-tips改為/blog/seo-tips-2026。沒做 301 的結果是 ChatGPT 仍引用舊網址,使用者全部撞 404。
AEO 時代的轉址檢查清單
- 所有 HTTP 網址都已 301 轉到 HTTPS
- 所有非 www 網址都已 301 統一到 www(或反向)
- 沒有任何鏈式轉址(用 Screaming Frog 確認)
- 舊內容下架時都有 301 對應到主題相近的新內容
- 網站搬家時建立完整的舊網址—新網址對照表
- Google Search Console 沒有「重新導向錯誤」通知
- 主要 AI 爬蟲(GPTBot、ClaudeBot、PerplexityBot)未被 robots.txt 封鎖
- 網站速度足夠快(轉址回應應 < 200ms),避免 AI 爬蟲放棄抓取
結論:轉址做對,SEO 與 AEO 一起受益
轉址不是技術細節,而是網站長期 SEO 健康度的基礎建設。一個從未做好轉址規劃的網站,即使內容再好,也會在每次改版時流失流量;反之,一個轉址規則完善的網站,即使搬家、改版、升級,排名與權重都能順利傳承。
規劃轉址前,可以先用以下五個問題自我檢查:
- 網站是否已強制使用 HTTPS,並 301 轉址所有 HTTP 請求?
- www 與非 www 是否已選定其一作為標準,另一個 301 轉址過去?
- 過去改版或搬家時,是否有保留完整的舊網址—新網址對照表?
- 網站內是否存在鏈式轉址(A→B→C),需要壓平為直接轉址(A→C)?
- 主要 AI 爬蟲是否能正常抓取您的內容,沒有被失效連結阻擋?
常見問答 FAQ
301 轉址和 302 轉址哪一個對 SEO 比較好?
網站改版需要做轉址規劃嗎?有什麼風險?
什麼是轉址鏈(Redirect Chain)?為什麼要避免?
301 轉址後,舊網址的排名多久會轉移到新網址?
使用 WordPress 該如何設定 301 轉址?
.htaccess,加入 Redirect 301 或 RewriteRule 規則。優點是效能最好(伺服器層級執行),缺點是語法錯誤會讓整站掛掉,務必先備份。3. 使用 Yoast SEO Premium 或 Rank Math 等 SEO 外掛——這類 SEO 外掛通常內建轉址功能,且會在您變更網址時自動建立 301 規則,減少人為遺漏。實務建議:中小型網站用 Redirection 外掛即可;規則超過 500 筆的網站,建議改用 .htaccess 直接設定,效能會明顯更好,因為外掛規則需要載入 WordPress 才能執行,速度較慢。
網站從 HTTP 升級到 HTTPS,轉址要怎麼做?
RewriteEngine On / RewriteCond %{HTTPS} off / RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]。3. 同時處理 www 統一——建議用單一規則同時處理 HTTPS 與 www,避免雙重轉址。4. 修正內部連結——資料庫中所有 http://... 開頭的內部連結應全部改為 https://...,可用 Better Search Replace 外掛批次處理。5. 更新 Google Search Console——HTTPS 版本被 Google 視為不同網站,需重新驗證並提交 sitemap。6. 處理 Mixed Content——HTTPS 頁面中若仍載入 HTTP 的圖片、JS、CSS,瀏覽器會出現安全警告,需逐一修正。整體升級過程通常 2 至 4 週內可完成,排名短期可能輕微波動,但長期一定會比 HTTP 版本好,因為 HTTPS 已是 Google 確認的排名因素之一,且 Chrome 對 HTTP 網站會顯示「不安全」警示,影響使用者信任。
