您啟動了新網站。一切看起來都很棒。設計現代化，性能指標出色，團隊在慶祝。然後週一早上到了。Google Search Console 顯示流量下降了 40%。您的電話開始響起。

我經歷過這種情況的次數比我想承認的要多。我們已將網站從 WordPress 遷移到 Next.js、從單體平台遷移到無頭架構、從舊版 CMS 遷移到 Astro —— 而遷移後的流量下降是 Web 開發中最可預測（也最可防止）的問題之一。好消息是什麼？在大多數情況下，您可以完全恢復。有時您甚至會獲得更好的結果。但您需要快速而有系統地採取行動。

本文是我們在 Social Animal 實際使用的恢復方案，用於處理遷移未按計劃進行的情況。沒有理論 —— 只是有效的步驟。

目錄

網站遷移後流量下降？恢復排名的完整指南

為什麼遷移後流量會下降

在我們修復任何東西之前，讓我們先了解為什麼會發生這種情況。Google 不會立即「看到」您的新網站並立即信任它。遷移時，會同時發生多項變化，其中任何一項都可能引發排名下降。

最常見的原因

原因 頻率 嚴重性 恢復時間
缺少或損壞的重定向 非常常見 高 2-6 週
沒有正確對應的 URL 結構變更 非常常見 高 4-12 週
內容變更或移除 常見 中-高 4-8 週
內部連結結構變更 常見 中等 2-4 週
Robots.txt 阻止爬蟲 偶發 嚴重 數天（修復後）
暫存環境中留下的 Noindex 標籤 偶發 嚴重 數天（修復後）
網域或協議變更 偶發 中等 6-12 週
結構化數據丟失 常見 中等 2-6 週
頁面速度變慢 常見 低-中等 2-4 週
JavaScript 渲染問題 SPA 常見 高 2-8 週

以下是大多數文章不會告訴您的內容：即使您完全按照規劃進行，遷移期間流量暫時下降 10-20% 實際上是 正常的。Google 需要重新爬取並重新處理您的網站。這需要時間。問題是當下降幅度更大或在幾週內沒有恢復時。

Google 的重新爬取和重新評估期

當 Google 遇到您的新 URL（即使有適當的重定向）時，它需要：

  1. 發現重定向
  2. 爬取新的目標 URL
  3. 索引新頁面
  4. 重新評估內容品質和相關性
  5. 更新其排名信號

此過程並不是即時的。對於大型網站（10,000+ 頁面），Google 完全處理所有內容可能需要數週。在此期間，您會看到波動。這是預期的。在 4-6 週後不期望出現持續下降是 不 預期的。

前48小時：分類檢查清單

當您注意到流量下降時，不要驚慌 —— 但要快速採取行動。以下是我在前 48 小時內運行的分類檢查清單：

步驟 1：驗證爬取未被阻止

這是我見過最常見的「哦不」時刻。有人忘記更新 robots.txt 文件，或者暫存環境的 noindex 元標籤被發送到生產環境。

# 檢查 robots.txt
curl -s https://yoursite.com/robots.txt

# 尋找這些危險信號：
# User-agent: *
# Disallow: /

同時檢查您的頁面源以查找 noindex 標籤：

<!-- 這會KILL您的排名 -->
<meta name="robots" content="noindex, nofollow">

在 Next.js 中，當基於環境的元標籤配置不當時，這經常會發生：

// 檢查您的 layout.js 或 _app.js
// 確保這不是在生產環境中有條件地呈現 noindex
export const metadata = {
  robots: {
    index: process.env.NODE_ENV === 'production',
    follow: process.env.NODE_ENV === 'production',
  },
};

如果您正在與我們的 Next.js 開發團隊 合作，我們有 CI/CD 檢查在部署前捕獲這個問題。但如果您自己處理，請添加部署後驗證步驟。

步驟 2：立即檢查 Google Search Console

轉到 Search Console 並查看：

  • 涵蓋範圍/頁面報告：頁面是否被索引？是否有新的錯誤？
  • 爬取統計：Googlebot 的爬取率是否下降？
  • 手動操作：遷移是否觸發了手動處罰？（罕見，但請檢查。）
  • 核心網絡生命力：性能是否崩潰？

步驟 3：驗證您的網站地圖

確保您的新網站地圖已提交並包含正確的 URL：

curl -s https://yoursite.com/sitemap.xml | head -50

我見過網站地圖仍然指向舊 URL 的遷移，更糟的是，指向暫存網域。這向 Google 發送了關於哪些 URL 是規範的相互矛盾的信號。

步驟 4：抽查關鍵頁面

根據遷移前的自然流量，選取排名前 20 的頁面並手動驗證：

  • 舊 URL 是否正確重定向到新 URL？
  • 新頁面上的內容是否相同（或更好）？
  • 標題標籤和元描述是否完整？
  • 結構化數據是否仍然存在？

診斷根本原因

完成分類後，您需要確切地找出導致下降的原因。這是偵探工作，它需要來自多個來源的數據。

使用 Google Search Console 的性能報告

比較遷移前的 28 天期間與遷移後的 28 天期間。查看：

  • 哪些查詢失去了展示？ 如果特定查詢集群下降，可能是內容或 URL 問題。
  • 哪些頁面失去了點擊？ 這告訴您受影響的具體頁面。
  • 整個網站下降，還是只有某些部分？ 網站範圍的下降表明技術問題（robots.txt、noindex）。特定部分的下降表明重定向或內容問題。

像 Google 一樣爬取網站

使用 Screaming Frog、Sitebulb 或 Ahrefs 的網站審計來爬取您的新網站：

# 使用 screaming-frog CLI（如果可用）
screamingfrog --crawl https://yoursite.com --output-folder ./audit

# 或使用基於 Node 的爬蟲進行快速檢查
npx broken-link-checker https://yoursite.com --recursive

查找：

  • 應該存在的頁面上的 404 錯誤
  • 重定向鏈（超過 2 跳）
  • 返回軟 404 的頁面（200 狀態但帶有錯誤內容）
  • 沒有內部連結指向的孤立頁面

檢查重定向對應表與現實

您的遷移前重定向對應表只有在實際正確實施時才有用。我無法告訴您有多少次我見過完美計劃的重定向對應表因打字錯誤、錯誤的狀態碼或完全缺失的條目而被實施。

// 快速 Node.js 腳本以驗證重定向
const https = require('https');
const oldUrls = [
  '/old-blog/my-post',
  '/products/widget-a',
  '/about-us',
  // ... 您的完整列表
];

oldUrls.forEach(url => {
  https.get(`https://yoursite.com${url}`, { method: 'HEAD' }, (res) => {
    if (res.statusCode === 301 || res.statusCode === 302) {
      console.log(`✅ ${url} → ${res.headers.location} (${res.statusCode})`);
    } else if (res.statusCode === 404) {
      console.log(`❌ ${url} → 404 NOT FOUND`);
    } else {
      console.log(`⚠️  ${url} → ${res.statusCode}`);
    }
  });
});

網站遷移後流量下降？恢復排名的完整指南 - 架構

修復重定向問題

重定向是遷移後流量損失的第一大原因。讓我們把它們做好。

301 vs 302：這仍然重要

在遷移時使用 301（永久）重定向。句號。302（暫時）重定向告訴 Google 將舊 URL 保留在其索引中。這不是您想要的。

在 Next.js 中，您的重定向位於 next.config.js：

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true, // 這使其成為 301
      },
      {
        source: '/products/:category/:product',
        destination: '/shop/:product',
        permanent: true,
      },
    ];
  },
};

在 Astro（我們在許多 Astro 開發項目 中使用）中，重定向可以在 astro.config.mjs 或通過您的託管平台進行配置。

處理重定向鏈

重定向鏈看起來像這樣：A → B → C → D。每次跳躍都會失去少量的連結權益，在 3-4 次跳躍後，Googlebot 可能會簡單地停止跟隨。通過將所有內容直接指向最終目標來修復鏈。

批量重定向實施

對於大型網站，您可能需要平台級別的重定向。以下是使用 Vercel（Next.js 部署的常見選擇）大規模處理它們的方法：

// vercel.json
{
  "redirects": [
    { "source": "/old-path", "destination": "/new-path", "permanent": true },
    { "source": "/blog/2024/:slug", "destination": "/blog/:slug", "permanent": true }
  ]
}

對於 Netlify：

# _redirects 文件
/old-path    /new-path    301
/blog/2024/* /blog/:splat 301

從內容和 URL 變更中恢復

如果您在遷移期間更改了內容 —— 即使是「改進」了它 —— Google 可能需要重新評估頁面對其目標查詢的相關性。

不要一次改變所有內容

這是多年前我希望有人給我的建議：遷移應該是一個 橫向移動。改變技術棧，改變設計，但試著初始時保持內容、URL、標題標籤和元描述相同。您可以在遷移穩定後優化內容。

如果您已經更改了內容並失去了排名：

  1. 比較舊內容（來自 archive.org 或您的備份）與新內容
  2. 確定哪些頁面失去了最多的流量
  3. 檢查這些頁面是否仍然針對相同的關鍵詞
  4. 考慮恢復最受影響頁面上的內容

URL 結構變更

如果您更改了 URL 結構（例如，從 /blog/2024/01/my-post 到 /blog/my-post），請確保每個舊 URL 都有相應的重定向。使用您的遷移前爬取數據來構建完整列表。

無頭 CMS 遷移 的常見誤區是更改 slug 格式。如果您的舊 CMS 生成帶有日期的 slug，而您的新 CMS 沒有，您需要為每篇文章進行重定向。

技術 SEO 恢復步驟

以下是我遵循的系統恢復流程：

1. 修復所有爬取錯誤

在 Google Search Console 中，轉到頁面 > 未索引，並修復每個「未找到 (404)」和「軟 404」錯誤。優先處理在遷移前有流量的頁面。

2. 重新提交您的網站地圖

從 Search Console 中移除舊網站地圖並提交新網站地圖。然後使用 URL 檢查工具為您最重要的頁面申請索引編制。

3. 重建內部連結

遷移中最容易被忽視的問題之一是破損的內部連結。您的舊網站可能有數百個內部連結指向舊 URL。如果這些 URL 現在重定向，您通過重定向不必要地傳遞連結權益。

更新所有內部連結以直接指向新 URL：

// 在內容中查找舊 URL 的腳本
const glob = require('glob');
const fs = require('fs');

const oldDomain = 'old-site.com';
const files = glob.sync('src/**/*.{md,mdx,jsx,tsx}');

files.forEach(file => {
  const content = fs.readFileSync(file, 'utf8');
  if (content.includes(oldDomain)) {
    console.log(`發現舊網域引用在：${file}`);
  }
});

4. 恢復結構化數據

如果您的舊網站有架構標記（Product、Article、FAQ、BreadcrumbList），請確保在新網站上複製它。丟失的結構化數據意味著丟失豐富的摘要，這意味著較低的點擊率，這意味著較少的流量。

5. 驗證規範標籤

每個頁面都應該有一個自引用的規範標籤指向其自己的 URL。檢查規範標籤是否指向舊 URL 或暫存網域。

<!-- 這應該指向當前頁面的 URL -->
<link rel="canonical" href="https://yoursite.com/current-page" />

6. 檢查 Hreflang 標籤（如果多語言）

如果您的網站服務多種語言或地區，遷移後損壞的 hreflang 標籤可能會在國際市場中造成重大流量損失。

性能和核心網絡生命力

團隊遷移到現代框架的主要原因之一是性能更好。但有時相反的情況會發生。

客戶端渲染陷阱

如果您遷移到 React SPA 而沒有服務器端渲染，Googlebot 可能會難以看到您的內容。Google 在渲染 JavaScript 方面變得更好，但仍然不完美。渲染在第二波索引編制中進行，這意味著您的內容需要更長時間才能出現在搜索結果中。

這就是為什麼我們強烈建議針對內容豐富的網站使用 SSR 或 SSG。使用 App Router 的 Next.js 默認情況下提供服務器組件。Astro 將所有內容渲染為靜態 HTML，除非您選擇進行客戶端交互。

核心網絡生命力對比

使用 CrUX 數據或 PageSpeed Insights 運行遷移前後對比：

指標 遷移前 遷移後 目標
LCP 2.1s ? < 2.5s
INP 180ms ? < 200ms
CLS 0.05 ? < 0.1
TTFB 800ms ? < 800ms

如果您的遷移後指標更差，那可能會對排名下降有所貢獻。首先修復性能問題 —— 它們會加劇所有其他問題。

時間表：恢復的實際樣子

讓我設定現實的期望。根據我們處理的遷移：

場景 預期恢復時間
僅技術問題（robots.txt、noindex） 修復後 1-2 週
小型網站上的重定向問題（<500 頁） 2-4 週
大型網站上的重定向問題（5000+ 頁） 4-8 週
內容變更 + URL 變更 6-12 週
網域變更 8-16 週
多個複合問題 3-6 個月

恢復曲線不是線性的。您經常會看到急劇下降，然後是平台期，然後是逐步上升。某些頁面的恢復速度比其他頁面更快。具有強大反向連結資料的高權限頁面傾向於首先反彈。

何時應擔心

如果在 8 週後，在所有修復到位的情況下，您沒有看到 任何 改進，那麼可能出現了更深層次的問題。此時，考慮：

  • 專業 SEO 審計
  • Google 是否將遷移視為網站品質變更
  • 在遷移期間是否失去了重要的反向連結
  • 聯繫我們團隊進行 遷移恢復評估

防止未來遷移中的流量損失

預防總是好於恢復。以下是我們的遷移前 SEO 檢查清單：

遷移前

  1. 現有網站的完整爬取 —— 保存每個 URL、其標題、元描述、規範標籤、結構化數據和內部連結
  2. 重定向對應表 —— 每個舊 URL 對應到其新目標
  3. 內容凍結 —— 不要在遷移期間更改內容
  4. 基準當前性能 —— 保存 Search Console 數據、排名和核心網絡生命力
  5. 在暫存環境中測試重定向 —— 在上線前驗證每個重定向
  6. 檢查 robots.txt 和元 robots —— 確保生產配置允許爬取

遷移期間

  1. 在低流量時段部署
  2. 上線後立即驗證重定向
  3. 在數小時內將新網站地圖提交至 Search Console
  4. 實時監控爬取統計

遷移後

  1. 前兩週每天監控 Search Console
  2. 上線後 48 小時運行完整網站審計
  3. 每天檢查排名前 50 個關鍵詞的排名位置
  4. 在發現問題後 24 小時內修復任何問題

如果您計劃遷移到無頭架構，我們的 定價頁面 概述了我們的遷移套件包含的內容 —— 包括大多數代理商跳過的 SEO 保護工作。

常見問題

網站遷移後需要多長時間才能恢復流量？ 如果問題被快速識別和修復，大多數網站在 4-8 週內恢復。簡單的技術問題，如阻止 robots.txt 或 noindex 標籤，可以在數天內解決，流量在 1-2 週內回升。涉及 URL 結構變更、內容修改或網域變更的更複雜問題可能需要 3-6 個月才能完全恢復。關鍵因素是您識別和修復根本原因的速度。

網站遷移後損失流量是正常的嗎？ 是的，即使執行良好的遷移，臨時下降 10-20% 是完全正常的。Google 需要時間重新爬取、重新索引和重新評估您的網站。此處理期間通常持續 2-4 週。下降超過 30% 或在 6 週後沒有顯示任何恢復跡象 不是 正常的。如果您看到這些模式，可能存在需要修復的技術問題。

我應該為網站遷移使用 301 還是 302 重定向？ 始終為網站遷移使用 301（永久）重定向。301 告訴 Google 移動是永久的，並將排名信號轉移到新 URL。302（暫時）重定向告訴 Google 將舊 URL 保留在其索引中，這違反了遷移的目的。唯一的例外是如果您真的打算將內容移回原始 URL —— 這在遷移期間幾乎不會發生。

更改我的 CMS 會導致排名下降嗎？ 更改您的 CMS 本身不會導致排名下降 —— 但 CMS 變更的副作用經常會。不同的 CMS 會生成不同的 URL 結構、HTML 標記、內部連結模式和頁面加載特性。如果您的新 CMS 在沒有適當重定向的情況下生成不同的 URL、刪除結構化數據、更改內容結構或客戶端呈現內容而不是服務器端，您可能會看到流量影響。

我如何知道 Googlebot 是否可以正確看到我的新網站？ 使用 Google Search Console 的 URL 檢查工具。輸入任何頁面 URL 並點擊「測試實時 URL」。Google 將向您展示 Googlebot 看到的內容，包括呈現的 HTML。如果重要內容在呈現的輸出中丟失，您有 JavaScript 渲染問題。您也可以查看 Search Console 中的「爬取統計」報告，以查看 Googlebot 的爬取率自遷移以來是否發生了變化。

遷移到新網站後我會失去我的反向連結嗎？ 如果您從舊 URL 實施適當的 301 重定向到新 URL，您不會失去反向連結。反向連結仍將指向舊 URL，但重定向將把連結權益傳遞給新頁面。但是，值得聯繫擁有最有價值反向連結的網站，並要求他們直接更新 URL —— 這樣做會消除重定向跳躍並確保最大的連結權益轉移。

我應該在遷移期間更改我的 URL 結構嗎？ 理想情況下，不應該。保持相同的 URL 結構完全消除了對重定向的需要，這是 SEO 最安全的方法。如果您必須更改 URL（例如，移除基於日期的路徑或重組類別），請確保您有一個完整的重定向對應表涵蓋每個舊 URL。不要在沒有相應 301 重定向的情況下更改 URL。

遷移後監控流量恢復應使用哪些工具？ Google Search Console 是您的主要工具 —— 它向您展示 Google 看到您網站的方式。將其與 Google Analytics 4 配對以監控流量、Screaming Frog 或 Sitebulb 進行技術爬取、Ahrefs 或 Semrush 進行排名跟蹤，以及 PageSpeed Insights 進行性能監控。在遷移後的前兩週每天檢查這些工具，然後每週檢查一次，直到流量穩定。