嗨，我是 Eric，浪花科技的資深工程師。如果你正在看這篇文章，八成是你（或是你的客戶）準備幫網站進行大改版，或者更慘——剛改完版發現 Google Analytics 的流量曲線像大怒神一樣垂直下降，老闆正站在你身後，火氣很大。

在 2026 年的今天，網站改版已經不只是換換佈景主題那麼簡單。隨著 Headless WordPress 架構、前後端分離技術的普及，URL 結構的變動往往是傷筋動骨。這時候，301 轉址（301 Redirect）就不只是一個技術設定，它是你網站 SEO 權重的「呼吸器」。

今天這篇文章不講廢話，我們要直接進入工程師的實戰視角，教你如何規劃、執行並驗證 301 轉址策略，確保舊網站累積多年的 SEO 功力，能一滴不漏地灌注到新網站上。

為什麼 301 轉址是網站改版的「保命符」？

簡單來說，當你把網站從 old-domain.com/blog/post-1 搬到 new-domain.com/articles/post-1 時，Google 的爬蟲（Crawler）並不知道這兩頁是同一個東西。如果沒有設定轉址，Google 會看到舊連結變成 404 Not Found，然後認為這個頁面「死掉了」。

結果就是：

• 關鍵字排名消失：Google 會把搜不到的頁面從索引中移除。
• 反向連結（Backlinks）失效：別的網站連給你的權重（Link Juice）全部流進水溝。
• 使用者體驗崩盤：老客戶點擊書籤或舊連結，只看到錯誤頁面。

在工程師眼裡，301 Moved Permanently 是一個 HTTP 狀態碼，它在告訴 Google：「嘿，這個人搬家了，請把他的信件（權重）轉寄到新地址，以後也都寄到那邊去。」

2026 改版災難預防：工程師的「轉址對照表」SOP

很多行銷人會說「我有裝 Redirection 外掛啊！」，但這遠遠不夠。身為工程師，我們追求的是精確與效能。以下是浪花科技內部的標準作業流程：

步驟一：扒光舊網站的所有 URL

不要只看 Sitemap。Sitemap 只有「你希望 Google 看到的頁面」，但我們要找的是「Google 實際上索引的頁面」以及「外部連結連到的頁面」。

請務必匯總以下來源：

• Sitemap.xml：基礎清單。
• Google Search Console (GSC)：匯出「成效」報表中的所有頁面。
• Google Analytics (GA4)：過去一年有流量的所有 Landing Pages。
• Ahrefs / Moz：匯出有外部連結（Backlinks）的頁面。

把這些資料丟進 Excel 或 Google Sheets，去重（Remove Duplicates），這就是你的「舊網址清單」。

步驟二：建立 1-to-1 的對應邏輯（嚴禁偷懶！）

這是最痛苦但也最重要的一步。很多開發者為了省事，把舊網站所有 404 頁面全部 301 轉去「新網站首頁」。

千萬不要這樣做！

Google 官方已經多次表示，將所有頁面轉向首頁會被視為「軟性 404」（Soft 404），權重依然不會傳遞。你必須做到：

• 舊產品頁 A → 新產品頁 A (或最相關的替代品)
• 舊分類頁 B → 新分類頁 B
• 舊文章 C → 新文章 C
• 真的找不到對應頁面 → 轉到最相關的上層分類，最後才是首頁。

實戰程式碼：Apache vs Nginx 轉址寫法

身為工程師，我建議盡量在伺服器層級（Server Level）處理轉址，而不是用 WordPress 外掛（Application Level）。因為伺服器層級的執行速度快得多，不會消耗 PHP 資源。

場景一：Apache / LiteSpeed (使用 .htaccess)

如果你使用一般的虛擬主機，通常是修改 .htaccess 檔案。以下是 2026 年常見的正規表示法（Regex）範例：

# 1. 強制重定向到 HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# 2. 整個目錄結構改變 (例如 /blog/ 變成了 /news/)
# 這種寫法可以保留後面的 slug，例如 /blog/abc 變成 /news/abc
RewriteRule ^blog/(.*)$ /news/$1 [L,R=301]

# 3. 單一頁面轉址 (針對高流量頁面)
Redirect 301 /old-page-name https://yoursite.com/new-page-name

場景二：Nginx (高流量網站首選)

如果你的 WordPress 跑在 VPS 或 Cloudways 上，Nginx 設定檔是效能最好的選擇。這通常在 nginx.conf 或網站特定的 config 區塊中設定：

# 1. 簡單的目錄重寫
location ~ ^/blog/(.*)$ {
    return 301 /news/$1;
}

# 2. 精確匹配並保留 Query String (例如 UTM 參數)
# Nginx 預設會保留參數，除非你明確丟棄它
location = /old-product {
    return 301 /new-product;
}

# 3. 複雜的規則 (需要小心使用)
# 這裡將所有 .html 結尾的網址轉為無副檔名
location ~ ^/(.*)\.html$ {
    return 301 /$1/;
}

進階防雷：保留 UTM 參數與動態 Query String

這是 2026 年很多開發者容易忽略的雷點。我們花了大錢投廣告，網址帶有 ?utm_source=facebook&utm_medium=cpc，如果你的 301 設定錯誤，導致這些參數在轉址過程中「被吃掉」，你的 GA4 報表就會顯示一堆「Direct / None」的流量，行銷部門絕對會拿刀追殺你。

Nginx 小撇步：
通常 Nginx 的 return 301 會自動帶上參數。但如果你用了 rewrite 指令且結尾沒有加 ?，參數也會保留；若加了 ? 則會清除參數。務必在 Staging 環境先測試！

上線後的黃金 48 小時：監控與補救

轉址設定上去，網站上線後，工程師的工作才真正開始。我們需要進行「驗屍級」的檢查：

1. 檢查伺服器 Log：直接看 Access Log，過濾出狀態碼 404 的請求。找出那些你漏掉的舊連結，立刻補上 301。
2. Google Search Console「網址變更工具」：如果是更換網域，一定要去 GSC 提交「網址變更通知」。
3. 再次爬蟲測試：用 Screaming Frog 再爬一次新網站，檢查是否有「轉址鍊」（Redirect Chains，即 A → B → C）。轉址鍊會稀釋權重並拖慢速度，請修正為 A → C。

工程師的碎碎念

網站改版是為了更好的未來，不要讓 SEO 死在黎明前。301 轉址雖然繁瑣，甚至有點枯燥，但它是保護數位資產最重要的防火牆。多花一天整理 Excel 對照表，可以省下未來半年救流量的痛苦時間。

如果你的網站結構極其複雜，或者涉及數萬頁的資料庫遷移，不確定 Regex 該怎麼寫才不會炸掉伺服器，歡迎來找我們聊聊。

---

延伸閱讀

• 321. 你的 Nginx 還在用預設值？資深工程師的 WordPress 效能調校聖經，榨乾伺服器最後一滴效能！
• 176. Google 演算法下的隱形冠軍：WordPress 技術 SEO 終極實戰，從速度、結構到程式碼一次搞定！
• 127. 網站跑分一片紅？工程師教你暴力破解 Core Web Vitals：LCP 與 CLS 終極優化指南