為什麼 HTTP 轉址對 SEO 跟使用者體驗這麼重要
在網站經營過程中，轉址是不可避免的操作。無論是網站搬家、URL 結構調整、強制 HTTPS，還是刪除或合併頁面，都需要正確的轉址策略。選錯轉址類型，不僅會影響使用者的瀏覽體驗，還會對 SEO 產生負面影響。
轉址鏈的效能問題
轉址鏈是指多個轉址連續發生，例如 A → B → C → D。每一跳都會帶來效能損耗，鏈條過長會導致以下問題：
- 使用者體驗下降：每次轉址都會增加頁面載入時間，影響使用者體驗。
- SEO 權重流失：Google 會對過長的轉址鏈產生負面評價，甚至放棄爬取，導致 SEO 權重流失。
- 效能問題：每個轉址都會消耗伺服器資源，過多的轉址會增加伺服器負載。
建議轉址鏈最多控制在 3-5 跳以內，以確保效能和 SEO 效果。
HTTP 301 vs 302：永久 vs 臨時轉址的 SEO 影響
301 永久轉址
定義：表示頁面已永久移動到新位置。
SEO 影響：
- 權重傳遞：原始頁面的 SEO 權重（PageRank、Link Equity）會大部分傳遞到新頁面。
- 索引更新：Google 會更新索引，將新頁面納入搜尋結果。
- 瀏覽器快取：瀏覽器會快取這個轉址，下次直接訪問新位置。
使用時機：
- 網站搬家（舊網域 → 新網域）
- URL 結構調整（/product?id=123 → /product/widget）
- 合併兩個頁面
實務設定：
- Apache：
Redirect 301 /old-page.html https://fordige.com/new-page.html - Nginx：
return 301 https://fordige.com/new-page.html;
302 臨時轉址
定義：表示頁面暫時移動到新位置，未來可能會恢復。
SEO 影響：
- 權重傳遞：原則上不會傳遞 SEO 權重，但 Google 可能會傳遞少部分。
- 索引維持：Google 會繼續索引原始頁面，不會更新資料。
- 瀏覽器不快取：瀏覽器不會快取這個轉址。
使用時機：
- A/B 測試頁面
- 促銷活動的臨時到達頁
- 網站改版期間的過渡頁
注意事項：工程師常見錯誤是將網站改版後的轉址設為 302，導致 Google 持續索引舊頁面，新頁面無法獲得排名。應使用 301 來確保 SEO 權重傳遞。
HTTP 307 vs 308：保留 HTTP 方法的新時代轉址
307 Temporary Redirect
定義：臨時轉址，嚴格保留原始請求方法（GET/POST）。
使用場景：
- 網站維護中，暫時導向新的 API endpoint
- 行動版網頁暫時轉到回應式網址
- 負載平衡時，導向備援伺服器
特點：
- 請求方法不改變，例如 POST 請求會繼續使用 POST。
- 不會被降級成 GET。
308 Permanent Redirect
定義：永久轉址，嚴格保留原始請求方法。
使用場景：
- 網站永久更換網址，且有 REST API 使用 POST/PUT/DELETE
- 需要保留 SEO 權重，同時避免瀏覽器將 POST 意外改成 GET
- 嚴格遵循 HTTP 規範的應用場景
與 301 的區別：
- 308 保留了請求方法，而 301 可能會將 POST 改為 GET。
307 與 308 的核心差異
| 特性 | 307 Temporary Redirect | 308 Permanent Redirect |
|---|---|---|
| 轉址類型 | 臨時 | 永久 |
| HTTP 方法 | 嚴格保留 | 嚴格保留 |
| SEO 權重 | 不傳遞 | 傳遞 |
| 瀏覽器快取 | 不快取 | 快取 |
POST 請求的轉址陷阱：為什麼 308 是必要設計
在傳統的 HTTP 轉址中，301 和 302 都不保證保留請求方法，這會導致以下問題：
- 請求體丟失：例如，POST 請求的表單數據可能會丟失。
- 支付流程漏洞：在支付網關回調時，如果轉址方式錯誤，訂單狀態可能無法更新。
- SEO 問題：Googlebot 會將 POST 請求降級為 GET，導致 SEO 權重無法正確傳遞。
HTTP 308 的出現解決了這些問題，它明確規定請求方法必須與原始請求一致，確保了以下優勢：
- 保留請求方法：無論是 POST、PUT 還是 DELETE，都會被保留。
- 保留請求體：POST 請求的數據不會丟失。
- SEO 權重傳遞：確保 SEO 權重正確傳遞。
轉址鏈（A→B→C）的效能災難與 Google 爬蟲行為
轉址鏈過長會帶來以下問題：
- 效能問題：每個轉址都會增加頁面載入時間，影響使用者體驗。
- SEO 權重流失：Google 會對過長的轉址鏈產生負面評價，甚至放棄爬取。
- 資源消耗：每個轉址都會消耗伺服器資源，過多的轉址會增加伺服器負載。
如何偵測轉址鏈問題
- Chrome 開發者工具：在 Network 分頁中查看轉址鏈。
- 線上工具：使用線上轉址鏈檢測工具。
解決方案
- 減少轉址跳數：盡量控制在 3-5 跳以內。
- 合併轉址規則：避免多層轉址設定衝突，例如 Cloudflare、Nginx、Apache 之間的設定衝突。
- 優化轉址邏輯：確保轉址規則的準確性和簡潔性。
實戰設定：Nginx / Apache / Next.js redirect() 怎麼寫
Nginx
- 301 永久轉址：
return 301 https://fordige.com/new-page.html; - 302 臨時轉址：
return 302 https://fordige.com/new-page.html; - 307 臨時轉址：
return 307 https://fordige.com/new-page.html; - 308 永久轉址：
return 308 https://fordige.com/new-page.html;
Apache
- 301 永久轉址：
Redirect 301 /old-page.html https://fordige.com/new-page.html - 302 臨時轉址：
Redirect 302 /old-page.html https://fordige.com/new-page.html - 307 臨時轉址：
Redirect 307 /old-page.html https://fordige.com/new-page.html - 308 永久轉址：
Redirect 308 /old-page.html https://fordige.com/new-page.html
Next.js
在 Next.js 中，可以使用 next/redirect 進行轉址：
// pages/index.js
import { useEffect } from 'react';
import { useRouter } from 'next/router';
const HomePage = () => {
const router = useRouter();
useEffect(() => {
router.push('/new-page', undefined, { permanent: true }); // 301
// router.push('/new-page', undefined, { permanent: false }); // 302
}, []);
return <div>Redirecting...</div>;
};
export default HomePage;
常見踩雷 FAQ
1. 什麼情況下應該使用 301 轉址？
當頁面永久移動到新位置時，例如網站搬家、網域更換、URL 結構重構等。
2. 什麼情況下應該使用 302 轉址？
當頁面暫時移動到新位置時，例如促銷活動頁面的臨時導流、A/B 測試的流量分配等。
3. 什麼情況下應該使用 307 轉址？
當需要臨時轉址並且必須保留 HTTP 方法時，例如 API 端點的臨時導向。
4. 什麼情況下應該使用 308 轉址？
當需要永久轉址並且必須保留 HTTP 方法時，例如 REST API 的永久遷移。
5. 轉址鏈過長會有什麼影響？
轉址鏈過長會導致效能問題、SEO 權重流失以及伺服器資源消耗增加。
6. 如何避免轉址鏈過長？
盡量減少轉址跳數，合併轉址規則，並優化轉址邏輯。
關於本文
本文由 fordige.com 整合 4 篇同主題文章的獨特內容，提供 HTTP 轉址完整指南。
轉址迴圈：最容易被忽略的問題
轉址迴圈（A → B → C → A）會讓瀏覽器最終顯示「Too many redirects」錯誤。
常見原因：
- 轉址鏈太長（超過 5 次）
- 同一頁面同時設定 HTTP 和 HTTPS 轉址
- 錯誤的 .htaccess / Nginx 規則
- Cloudflare / Nginx / Apache 多層轉址設定衝突
如何偵測：Chrome 開發者工具 → Network 分頁，查看轉址鏈；或用線上工具 redirect-checker.org。
如何解決：
- 確認每個 URL 只設定一次轉址
- 檢查各層（CDN → Nginx → Apache）的轉址設定
- 確認沒有同時設定 HTTP → HTTPS 和 HTTPS → HTTP
Node.js Express 設定方式
如果你的網站是用 Node.js + Express 架設，有兩種常見寫法：
使用 Express 內建的 res.redirect()：
// 301 永久轉址
app.get('/old-page', (req, res) => {
res.redirect(301, '/new-page');
});
// 302 臨時轉址（預設值）
app.get('/temp-page', (req, res) => {
res.redirect('/temp-page'); // 預設是 302
});
使用 res.status() + res.setHeader()：
app.get('/old-page', (req, res) => {
res.status(301);
res.setHeader('Location', 'https://new-domain.com/new-page');
res.end();
});
實務上，Express 的 res.redirect() 預設就是 302。如果你確定要傳 301，務必明確寫出 301 參數。
如何驗證轉址是否正確
設定完轉址後，千萬別只是「打開瀏覽器測試」。瀏覽器會幫你跟著轉址走，你看不到原始的狀態碼。以下是推薦的驗證方式：
- curl 指令：
curl -I https://your-domain.com/old-page，檢查第一行的 HTTP 狀態碼 - HTTP Status 工具：輸入 URL，直接看到狀態碼與轉址鏈
- Google Search Console：「索引」→「網址檢查」中測試舊 URL，看 Google 怎麼處理
- SEO Spider（Screaming Frog）：大範圍網站審計必備，可一次檢查所有 URL 的轉址狀態
延伸閱讀
- 如何利用 WebMCP 重新定義網站設計以適應 AI 搜尋時代:同樣談「SEO」主題,延伸閱讀。
- 為什麼網站流量下滑？GA4 數據幫你找出原因:同樣談「SEO」主題,延伸閱讀。
- 如何正確解讀 SEO 報價，避免被誤導？:同樣談「SEO」主題,延伸閱讀。
- 結構化數據 (Schema Markup) 全攻略：讓您的網站在二零二六年 AI:同樣談「SEO」主題,延伸閱讀。
- SEO 排名優化服務:
