WordPress SEO 遷移 301 重定向 -- Social Animal

我見過團隊為精美的新網站辛苦勞作，卻眼睜睜看著自然搜索流量因為有人遺漏關鍵的 URL 對應而直線下降 60%。這真是噩夢。老實說，大多數情況是可以避免的。

在過去幾年中，我為代理商、新創公司和中等規模公司進行過 WordPress 遷移—將它們遷移到 Next.js、Astro、無頭 CMS 設置，甚至翻新的 WordPress 安裝—我拼湊出了我戲稱為「301 重定向聖經」的東西。這是一份檢查清單，旨在在平台轉移期間保持你的排名穩定。

這不僅僅是理論。它基於許多個週一早上的實際經歷，我被困在 Google Search Console 圖表前，要麼在香檳慶祝，要麼在搶救災難現場。

WordPress 遷移為什麼會摧毀排名

說實話：Google 對 URL 進行排名，而不是對頁面。每個 URL 都有權威、反向連結、用戶參與度、內部連結和爬蟲資料的歷史。當這些 URL 在沒有指導的情況下改變時，你基本上是在按重置按鈕。

這是 WordPress 遷移期間的典型混亂：

URL 結構改變—WordPress 喜歡 /category/post-name/ 或 /yyyy/mm/post-name/，而其他平台往往會混淆。
嘟！頁面消失—分類存檔、標籤、作者頁面和附件曾經帶來流量，現在卻消失了。
重定向鏈—想象一個瘋狂的傳話遊戲，有 3-4 次跳躍；鏈接價值被稀釋。
協議和 www 轉移—從 www 轉移到非 www，或從 HTTP 轉移到 HTTPS 而沒有適當處理會讓機器人陷入混亂。
參數滿天飛—WordPress 功能如分頁 (/page/2/)、提要 URL 和你不知道已被索引的查詢字符串。

Ahrefs 在 2024 年的一項研究檢查了超過 200,000 次網站遷移。那些使用穩健的 301 重定向對應的網站在 2-4 週內恢復了 90-95% 的流量。忽視重定向？中位恢復率在 6 個月內只有可憐的 33%。有些永遠沒有反彈。

WordPress SEO 遷移：零流量損失的 301 重定向聖經

遷移前 SEO 審計：基礎

在你觸及那個閃亮新網站的第一行代碼之前，你必須知道你在處理什麼。相信我，這個審計階段將決定你的遷移成功與否。

爬取所有內容

Screaming Frog、Sitebulk 或 Ahrefs Site Audit 等工具是你的新好友。你需要：

每個返回 200 狀態碼的 URL。
每個已經重定向的 URL 及其目的地。
XML 網站地圖中的每個 URL。
至少有一個外部反向連結的每個 URL。

這是我慣用的 Screaming Frog 設置：

Configuration > Spider > Crawl:
- Check "Crawl All Subdomains"
- Check "Crawl Outside of Start Folder"
- Set crawl depth to at least 10
- Include pagination patterns

Configuration > Spider > Extraction:
- Enable all extraction options
- Custom extraction for any WordPress-specific elements

匯出你的排名資料

提前從 Google Search Console、Ahrefs、SEMrush—無論什麼適合你—獲取排名資料：

至少排名一個關鍵字的 URL。
每個 URL 排名的關鍵字。
當前位置。
月搜索量。
GSC 的點擊數據。

沒有穩健的遷移前快照，你將無法測量恢復。

識別你的高價值頁面

不是每個頁面都值得你全力關注。所以，把它們分類：

優先級層級	標準	行動
第 1 層 — 關鍵	按流量計的前 20 個頁面 + 10+ 個引用域	1:1 重定向 + 內容平價
第 2 層 — 重要	高容量關鍵字排名 1-20	需要 1:1 重定向
第 3 層 — 標準	所有其他索引流量頁面	重定向到最相關的新 URL
第 4 層 — 低價值	瘦弱、重複或非流量頁面	重定向到父類別/首頁
第 5 層 — 已棄用	你正在淘汰的頁面	410 已消失（不是 404）

跳過分層並平等對待每個頁面？新手錯誤。在第 1 層花更多愛。第 4 層可以處理基於模式的重定向。

反向連結審計

使用 Ahrefs 或 Majestic 等工具提取完整的反向連結資料。然後，與你的重定向對應進行交叉引用。有價值的反向連結的 URL？它們需要重定向，沒有例外。

# Quick way to extract unique URLs from an Ahrefs backlink export
cut -d',' -f7 ahrefs-backlinks-export.csv | sort -u > unique-backlink-targets.txt

構建你的完整 URL 對應

你的 URL 對應—這是任何遷移的福音。將每個舊 URL 與其新位置對齊的電子表格。這是我的結構：

Old URL | New URL | Redirect Type | Priority Tier | Notes
/blog/my-old-post/ | /articles/my-old-post | 301 | Tier 2 | Slug kept
/category/design/ | /topics/design | 301 | Tier 1 | Category renamed
/author/john/ | /team/john-doe | 301 | Tier 3 | Author page
/2023/05/post-name/ | /blog/post-name | 301 | Tier 2 | Removed date

自動化 URL 對應

對於大型網站（1,000+ 頁面），手動對應是不切實際的。這是我為 slug 匹配編寫的 Python 腳本：

import csv
from difflib import SequenceMatcher

def find_best_match(old_slug, new_urls):
    best_match = None
    best_ratio = 0
    for new_url in new_urls:
        new_slug = new_url.rstrip('/').split('/')[-1]
        ratio = SequenceMatcher(None, old_slug, new_slug).ratio()
        if ratio > best_ratio:
            best_ratio = ratio
            best_match = new_url
    return best_match, best_ratio

# Load old and new URLs
with open('old_urls.csv') as f:
    old_urls = [row[0] for row in csv.reader(f)]

with open('new_urls.csv') as f:
    new_urls = [row[0] for row in csv.reader(f)]

# Generate mapping
for old_url in old_urls:
    old_slug = old_url.rstrip('/').split('/')[-1]
    match, confidence = find_best_match(old_slug, new_urls)
    print(f"{old_url} -> {match} (confidence: {confidence:.2f})")

如果信心下降到 0.8 以下，就要卷起袖子進行手動審查。

別忘了這些 WordPress URL

一些 WordPress URL 會隱藏在雷達下：

/feed/ 和 /feed/atom/ — RSS 提要
/wp-content/uploads/yyyy/mm/image.jpg — 媒體檔案（特別是如果被熱連結）
/page/2/、/page/3/ — 分頁
/?p=123 — 預設永久連結格式（可能隱藏在舊連結中）
/wp-json/ — REST API 端點（如果有人使用它們）
/?s=keyword — 搜尋結果頁面（通常無需重定向）
/attachment/image-name/ — WordPress 附件頁面
/category/name/feed/ — 分類 RSS 提要

301 重定向策略和實施

瞭解重定向類型

讓我們澄清一下：

重定向類型	何時使用	SEO 影響
301（永久）	永久 URL 移動	傳輸 ~95-99% 頁面等級
302（臨時）	內容將返回	隨著時間推移傳遞鏈接權益
307（臨時）	與 302 相同，保留 HTTP 方法	與 302 相同的 SEO 影響
308（永久）	與 301 相同，保留 HTTP 方法	與 301 相同的 SEO 影響
Meta Refresh	就是別用	（用戶體驗和 SEO 噩夢）
JavaScript 重定向	避免遷移	與 Googlebot 的固有不一致

對於遷移？堅守 301 如膠似漆。我見過 302 被用作「臨時修復」，結果永遠沒有被修復。避免業餘時間。

重定向實施順序

優先級很重要：

精確匹配重定向。
正則表達式模式重定向。
全部捕捉首頁重定向—謹慎使用。

伺服器級別對比應用級別重定向

始終，始終，始終執行伺服器或邊緣級別的重定向。它節省資源並保持速度。

對於 Nginx：

server {
    location = /old-blog-post/ {
        return 301 /new-blog-post/;
    }
    
    location ~ ^/\d{4}/\d{2}/(.+)$ {
        return 301 /blog/$1;
    }
    
    location ~ ^/category/(.+)$ {
        return 301 /topics/$1;
    }
    
    location ~ ^/author/(.+)$ {
        return 301 /team/$1;
    }
    
    location = /feed/ {
        return 301 /rss.xml;
    }
}

對於 Apache (.htaccess)：

RewriteEngine On

RewriteRule ^old-blog-post/?$ /new-blog-post/ [R=301,L]

RewriteRule ^(\d{4})/(\d{2})/(.+)$ /blog/$3 [R=301,L]

RewriteRule ^category/(.+)$ /topics/$1 [R=301,L]

RewriteRule ^author/(.+)$ /team/$1 [R=301,L]

WordPress SEO 遷移：零流量損失的 301 重定向聖經 - 架構

平台特定的重定向方法

目標平台決定了你如何處理重定向。

遷移到 Next.js

當遷移到 Next.js（就像我們許多客戶在 Next.js 開發）時，將你的重定向放在 next.config.js 中：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-wordpress-post/',
        destination: '/blog/old-wordpress-post',
        permanent: true,
      },
      {
        source: '/:year(\\d{4})/:month(\\d{2})/:slug*',
        destination: '/blog/:slug*',
        permanent: true,
      },
      {
        source: '/category/:path*',
        destination: '/topics/:path*',
        permanent: true,
      },
      {
        source: '/blog/page/:num',
        destination: '/blog?page=:num',
        permanent: true,
      },
    ];
  },
};

對於更大的設置，從 JSON 檔案載入可以節省大量工作：

const redirects = require('./redirects.json');

module.exports = {
  async redirects() {
    return redirects.map(({ source, destination }) => ({
      source,
      destination,
      permanent: true,
    }));
  },
};

注意：在 Vercel 上，next.config.js 最多只能處理 1,024 個重定向。對於更大的列表，請考慮邊緣中間件。

遷移到 Astro

對於基於 Astro 的網站，一切都取決於你的託管設置：

// astro.config.mjs
export default defineConfig({
  redirects: {
    '/old-post/': '/blog/old-post/',
    '/category/[...slug]': '/topics/[...slug]',
  },
});

Astro 在 v2.6 中對重定向支持取得了巨大進步。但對於大型列表，嘗試在託管/CDN 級別進行。

遷移到無頭 CMS 設置

在我們使用無頭 CMS 架構的經驗中，靈活性是王道。CMS 儲存內容；你的前端框架管理路由。在有意義的任何地方設置重定向—通常在邊緣。

對於 Cloudflare Workers：

const REDIRECTS = new Map([
  ['/old-wordpress-post/', '/blog/new-post/'],
  ['/category/design/', '/topics/design/'],
]);

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const redirect = REDIRECTS.get(url.pathname);
    
    if (redirect) {
      return Response.redirect(`${url.origin}${redirect}`, 301);
    }
    
    return fetch(request);
  },
};

處理 WordPress 特定的 URL 模式

WordPress 的怪癖會破壞最好的計畫。

尾部斜杠

WordPress 喜歡它的尾部斜杠。如果你的新設置沒有，處理 /my-post/ 和 /my-post。別讓這麼小的事情解開你的重定向鏈。

混合永久連結結構

WordPress 網站以發展 URL 結構而聞名：

/?p=123（預設）
/2020/05/my-post/（基於日期）
/my-post/（文章名稱）
/blog/my-post/（自訂結構）

所有這些都需要引導用戶到正確的地方。在分層新的之前檢查舊的重定向跡象。

WordPress 多網站注意事項

遷移多網站？離散地處理每個子網站，考慮到它們的不同模式（/site1/post-name/ 或 site1.domain.com/post-name/）。

wp-content 和媒體檔案

這個有點棘手但至關重要。如果像 /wp-content/uploads/2023/05/hero-image.jpg 這樣的 URL 被熱連結，它們要麼需要留在原位，要麼適當重定向。選擇很多：

在你的新網站上保留媒體 URL 結構。
從 /wp-content/uploads/ 重定向到你的新媒體路徑。
部署一個精明的 CDN，掌握 URL 重寫。

遷移後監控和恢復

你的工作不會在點擊「啟動」時停止。它才剛剛開始。

立即檢查（第 1 天）

測試每個第 1 層重定向；手動確保它們正確著陸。
針對舊列表運行 Screaming Frog 以驗證 301。
識別重定向鏈（A → B → C）並將它們展平為 A → C。
在 Google Search Console 中提交新的 XML 網站地圖。
檢查 GSC 的 URL 檢查工具中的熱門頁面。
通過伺服器日誌跟踪實時 404。

第 1 週監控

每天檢查 GSC 的覆蓋率報告以尋找爬蟲錯誤。
在 5-7 天內追蹤索引頁面穩定。
搜尋軟 404（Google 將 200 頁標記為 404）。
密切關注第 1 層關鍵字的排名。

第 2-4 週恢復

度過那些波浪。即使你的重定向完美，排名也會下跌。Google 需要時間：

找到重定向。
爬取你的新 URL。
重新評估新連結處的內容。
相應地更新索引。

Google 的 2025 部落格告訴我們這個「結算期」是典型的，可以跨越 2-6 週，受網站大小影響。

長期監控（第 1-3 個月）

保持重定向至少一年（更好的是，永遠）。
監控反向連結—聯繫高價值的連結網站以更新 URL。
觀察 GSC 中的爬蟲預算分配。
注意舊快取頁面和新頁面之間的內容同類相食。

摧毀排名的常見遷移錯誤

這是基於非常常見的失誤的速成課程：

過早移除重定向—有人手癢，砰！流量直線下降 40%。永遠保持它們。
所有重定向都以首頁結尾—對 Google 看起來很懶，他們將其視為軟 404。
在沒有思考的情況下改變 slug—如果你的 URL 是 /best-crm-tools/，將其改為 /top-crm-software-2025/ 會改變 URL 和內容訊息。堅持 slug。
忘記內部連結—你的新內部連結必須反映新的 URL 以避免不必要的重定向迴路。
忽視 HTTPS/www 變體—涵蓋所有協議/子域變體。
週五發佈—在週中上線。當有商務日支持時，你會為自己高興。
在實時網站上留下「noindex」—容易完成，災難性地被忽視。始終仔細檢查。
忽視行動—Google 全力投入行動優先索引。在手機上徹底測試，而不僅僅是模擬器。

時間表和恢復預期

這是你成功的倒計時：

階段	持續時間	活動
遷移前審計	2-4 週	爬取、反向連結審計、對應 URL、基線
重定向構建	1-2 週	設置和測試所有重定向規則
暫存準備	1 週	驗證重定向、渲染、資料
啟動	1 天	部署、提交網站地圖、密切監控
早期監控	2-4 週	檢查 GSC、排名追蹤、處理 404
確認恢復	4-8 週	目標讓你的流量返回基線
持續中	始終	保持重定向、季度檢查

對於典型的 500 頁網站轉換，你正在看從審計到恢復確認的 6-10 週工作量。

如果你有複雜的情況或需要額外的幫手，我們已經多次走過這條路—如果你想聊天，請隨時檢查我們的定價頁面或直接聯繫我們。

常見問題

WordPress 遷移後 301 重定向應該保留多長時間？ 永遠。真的。當反向連結仍然針對那些舊 URL 時移除它們會使你付出該連結權益的代價。相比風險，開銷微乎其微。

移出 WordPress 時會看到排名損失嗎？ 在頭幾週可能會短暫下降 10-20%。即使進行了完美的重定向設置，Google 的過程也不是即時的。但是，301 和內容一致性意味著在 4-8 週內恢復。搞砸了，你可能會與 50-70% 的流量揮手告別。

總是使用 301 還是可以嘗試使用 302 重定向進行網站遷移？ 301 一直都是。它們讓 Google 知道你的行動是永久的，並將排名訊號轉移過去。即使 302 最終會傳遞頁面等級，301 也確保更快的轉換。

將 WordPress 分類/標籤頁面定向的最佳選擇是什麼？ 嘗試基於正則表達式的重定向模式。將 /category/name/ 重定向以與你的新網站的分類法對齊（例如 /topics/name/）。決定標籤頁面—新網站可能沒有相應的頁面。將它們指向最相關的分類或部分頁面，而不是首頁。

在 WordPress 轉移期間更改 URL 結構—是或否？ 當然可以，只要謹慎。從 /yyyy/mm/post-name/ 這樣的模式轉移到 /blog/post-name/ 只要有銳利的重定向就可以。但避免修改文章 slug。更改整個 URL 會讓 Google 對頁面的理解變得混亂。

遷移後我的 GSC 資料的命運如何？ 如果域/協議改變，你將需要驗證新屬性。舊歷史保留但缺少新更新。在轉換期間會有報告間隙。立即提交你的新網站地圖。對於域名轉移，使用 GSC 的「地址變更」工具。

重定向計數影響網站效能—事實還是虛構？ 伺服器級重定向（Nginx、Apache）可以處理大量—想象成數萬個而不會皺眉。但當你在應用級別（Next.js 等）達到 5,000-10,000 時，預期較長的構建時間。對於巨大的列表，讓邊緣級系統如 Cloudflare Workers 或類似解決方案承擔該負載。

你應該在 WordPress 遷移後更新反向連結嗎？ 絕對應該，對你的高價值連結。雖然 301 會轉移大多數連結權益，但直接連結到新 URL 稍微更好。遷移後，識別前 50-100 個引用你的域。聯繫他們以更新他們的連結—優先考慮有影響力的網站而不是低價值目錄，因為重定向將對那些網站起作用。

WordPress SEO 遷移：301 重定向聖經零流量損失

WordPress 遷移為什麼會摧毀排名

遷移前 SEO 審計：基礎

爬取所有內容

匯出你的排名資料

識別你的高價值頁面

反向連結審計

構建你的完整 URL 對應

自動化 URL 對應

別忘了這些 WordPress URL

301 重定向策略和實施

瞭解重定向類型

重定向實施順序

伺服器級別對比應用級別重定向

平台特定的重定向方法

遷移到 Next.js

遷移到 Astro

遷移到無頭 CMS 設置

處理 WordPress 特定的 URL 模式

尾部斜杠

混合永久連結結構

WordPress 多網站注意事項

wp-content 和媒體檔案

遷移後監控和恢復

立即檢查（第 1 天）

第 1 週監控

第 2-4 週恢復

長期監控（第 1-3 個月）

摧毀排名的常見遷移錯誤

時間表和恢復預期

常見問題

Let's build
something together.

WordPress 遷移為什麼會摧毀排名

遷移前 SEO 審計：基礎

爬取所有內容

匯出你的排名資料

識別你的高價值頁面

反向連結審計

構建你的完整 URL 對應

自動化 URL 對應

別忘了這些 WordPress URL

301 重定向策略和實施

瞭解重定向類型

重定向實施順序

伺服器級別對比應用級別重定向

平台特定的重定向方法

遷移到 Next.js

遷移到 Astro

遷移到無頭 CMS 設置

處理 WordPress 特定的 URL 模式

尾部斜杠

混合永久連結結構

WordPress 多網站注意事項

wp-content 和媒體檔案

遷移後監控和恢復

立即檢查（第 1 天）

第 1 週監控

第 2-4 週恢復

長期監控（第 1-3 個月）

摧毀排名的常見遷移錯誤

時間表和恢復預期

常見問題

Let's build something together.

Let's build
something together.