將Webflow遷移至Next.js不損失SEO

我在過去三年中將大約十五個網站從 Webflow 遷移到 Next.js。有些遷移進行得非常順利。有幾個過程很痛苦。其中一個是真正的災難，當時一個客戶在六週內失去了 40% 的自然流量，因為我們遺漏了一批埋藏在 Webflow CMS 集合頁面中的重定向規則。那次經歷讓我對遷移期間的 SEO 保護的了解遠超任何文檔。

以下是我對如何正確執行此操作的全部了解——技術步驟、沒有人會警告你的陷阱，以及我們在 Social Animal 使用的確切流程，以確保搜索排名在轉換期間保持穩定。

為什麼從 Webflow 遷移到 Next.js

讓我說清楚：Webflow 在其擅長的領域中確實很優秀。它生成乾淨的語義 HTML，本機處理元標籤，自動生成 XML 站點地圖，並管理 robots.txt 而無需接觸配置文件。對於不需要太多自訂邏輯的行銷網站，它很出色。

但你正在閱讀這篇文章，這意味著你可能已經碰到了瓶頸。以下是通常促使團隊轉向 Next.js 的原因：

性能瓶頸。 具有大量互動、許多 CMS 項目或複雜動畫的 Webflow 網站開始在 Core Web Vitals 中出現裂縫。我們見過 Webflow 網站在移動設備上的最大內容繪製 (LCP) 時間超過 4 秒——遠超 Google 的 2.5 秒閾值。構建得當的 Next.js 網站具有伺服器端渲染和 next/image 優化，通常會將其減少一半。

定製限制。 需要集成無頭 CMS（例如 Sanity 或 Contentful）？想要構建自訂結帳流程？需要用於邊緣 A/B 測試的中間件？Webflow 的圍牆花園開始感覺非常小。

規模化成本。 Webflow 的 CMS 計畫為每個網站每月 $29，但企業功能會推高到 $49+/月。當你計算多個網站或本地化需求時，在 Vercel 的 Pro 計畫上託管 Next.js 應用程序（每月 $20）開始看起來很聰明——特別是因為你獲得了邊緣函數、分析和預覽部署。

性能數據支持這一點。 Webflow 自己的工程團隊記錄了當他們使用 SSR 將其儀表板遷移到 Next.js 時的 20% 負載時間改進。在 2025 年基準測試中，使用 App Router 的 Next.js 15 網站在 Lighthouse 上的得分一致比具有複雜互動的等效 Webflow 構建高 15-25%。

如果你對現代 Next.js 棧的可能性感興趣，我們在 Next.js 開發功能頁面上詳細介紹了我們的方法。

遷移的真實成本

在我們談論代碼之前，讓我們先談談錢。我見過太多團隊在沒有理解完整投資的情況下開始遷移。

組件	估計成本	備註
Webflow 匯出和內容審核	$1,000 – $3,000	手動工作；Webflow 匯出遺漏 CMS 數據
Next.js 開發（10-20 頁）	$8,000 – $25,000	取決於複雜性、互動和集成
Next.js 開發（20-50 頁）	$20,000 – $60,000	具有 CMS、身份驗證和自訂邏輯的企業網站
無頭 CMS 設置	$2,000 – $8,000	Sanity、Contentful 或 Payload CMS 配置
SEO 重定向對應和 QA	$1,500 – $4,000	此列表中最重要的項目
Vercel/Netlify 託管（每月）	$20 – $150/月	取代 Webflow 的 $29-$49/月託管
遷移後監控	$500 – $2,000	4-8 週的 Search Console 監控

對於具有 30 頁和博客的典型中型行銷網站，你正在尋找 $15,000–$40,000 的總投資。這不便宜。但如果你的 Webflow 網站正在產生有意義的自然流量，那麼遷移失敗的成本要高得多。

我們在 /pricing 上為此類項目發布透明的定價——如果你想要適合你特定情況的現實範圍，值得查看。

遷移前 SEO 審核

這是大多數人跳過步驟的地方，也是大多數遷移失敗的地方。在你寫一行 Next.js 代碼之前，你需要完整了解當前的 SEO 足跡。

爬取所有內容

針對你的實時 Webflow 網站運行 Screaming Frog（或 Sitebulb 或 Ahrefs Site Audit）。匯出每個 URL。我的意思是每個 URL——頁面、CMS 集合項目、分頁存檔頁面、實用程序頁面，所有內容。

你需要：

**完整的 URL 清單——**返回 200 狀態的每個頁面
每個頁面的標題標籤和元描述
標準 URL—— Webflow 有時在集合頁面上以奇怪的方式設置這些
**內部連結結構——**哪些頁面連結到哪些
結構化數據—— Webflow 生成的任何架構標記
**Core Web Vitals 基線——**在前 20 個頁面上運行 PageSpeed Insights

記錄你的頂級表現者

打開 Google Search Console。轉到效能。按過去 12 個月的點擊次數排序。匯出此數據。這些是你絕對不能承受破裂的頁面。

我通常會建立一個包含以下列的電子表格：

URL | 月點擊數 | 熱門查詢 | 平均排名 | 優先級
/blog/seo-guide | 2,400 | "seo guide 2025" | 3.2 | CRITICAL
/pricing | 890 | "agency pricing" | 5.1 | HIGH
/about | 340 | "social animal dev" | 1.0 | MEDIUM

CRITICAL 和 HIGH 類別中的每個頁面在遷移期間都會收到手動關注。沒有自動批量重定向。沒有假設。

保存你的反向連結配置文件

運行 Ahrefs 或 SEMrush 反向連結報告。如果外部網站連結到特定 Webflow URL（特別是部落格文章或資源頁面），這些 URL 在遷移後必須正確解析——要麼在同一路徑，要麼透過 301 重定向。

匯出您的 Webflow 網站

Webflow 的匯出功能是...有限的。以下是你實際獲得的內容以及你沒有獲得的內容。

匯出包含的內容

在 CMS 或 Business 計畫上，點擊項目設置中的匯出代碼會獲得一個包含以下內容的 ZIP：

每個頁面的靜態 HTML 文件
CSS（包括 Webflow 的實用程序類）
JavaScript（Webflow 的運行時 + 你的自訂代碼）
圖像和其他上傳的資產

匯出不包含的內容

這是關鍵部分：Webflow 的 CMS 數據不隨匯出提供。 你的部落格文章、團隊成員、案例研究——存儲在 CMS 集合中的任何內容——不會以有用的方式顯示為單個 HTML 文件。它們將作為靜態內容烘焙到匯出的 HTML 中，但你會失去結構化數據。

要正確取出 CMS 內容：

使用 Webflow 的 CMS API 將集合項目拉出為 JSON
從 Webflow Designer 匯出集合為 CSV（集合設置 → 匯出）
使用 Whalesync 或 Make.com 之類的工具 將 CMS 數據導入到新的無頭 CMS

以下是透過其 API 拉取 Webflow CMS 項目的快速腳本：

// fetch-webflow-cms.js
const WEBFLOW_API_TOKEN = process.env.WEBFLOW_TOKEN;
const COLLECTION_ID = 'your-collection-id';

async function fetchCollectionItems() {
  const response = await fetch(
    `https://api.webflow.com/v2/collections/${COLLECTION_ID}/items`,
    {
      headers: {
        'Authorization': `Bearer ${WEBFLOW_API_TOKEN}`,
        'accept': 'application/json'
      }
    }
  );
  const data = await response.json();
  
  // Write to JSON file for import into your headless CMS
  const fs = require('fs');
  fs.writeFileSync(
    'cms-export.json',
    JSON.stringify(data.items, null, 2)
  );
  console.log(`Exported ${data.items.length} items`);
}

fetchCollectionItems();

不要僅依賴 HTML 匯出。如果需要從靜態 HTML 提取內容，請使用 Cheerio 之類的工具解析匯出的文件，但 API 路由更乾淨。

構建 Next.js 替代方案

現在進行實際構建。我假設你使用 Next.js 14 或 15 搭配 App Router——如果你在 2025 年重新開始，沒有理由使用 Pages Router。

URL 結構對應

這是不可協商的：你的新 URL 結構應盡可能與舊結構相符。 每個 URL 更改都是風險。如果你的 Webflow 博客位於 /blog/post-slug，你的 Next.js 博客應位於 /blog/post-slug。

app/
├── page.tsx                    # 首頁
├── about/
│   └── page.tsx               # /about
├── blog/
│   ├── page.tsx               # /blog（列表）
│   └── [slug]/
│       └── page.tsx           # /blog/post-slug
├── services/
│   └── [slug]/
│       └── page.tsx           # /services/web-development
└── contact/
    └── page.tsx               # /contact

元數據實現

Next.js 15 的元數據 API 確實比 Webflow 提供的更好。你獲得完整的程序控制，一切都在伺服器端呈現——這意味著 Googlebot 在第一次繪製時看到它。

// app/blog/[slug]/page.tsx
import { Metadata } from 'next';
import { getPostBySlug } from '@/lib/cms';
import { notFound } from 'next/navigation';

type Props = {
  params: Promise<{ slug: string }>;
};

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = await getPostBySlug(slug);
  
  if (!post) return {};
  
  return {
    title: post.seoTitle || post.title,
    description: post.seoDescription || post.excerpt,
    openGraph: {
      title: post.title,
      description: post.excerpt,
      images: [{ url: post.featuredImage, width: 1200, height: 630 }],
      type: 'article',
      publishedTime: post.publishedAt,
    },
    alternates: {
      canonical: `https://yoursite.com/blog/${slug}`,
    },
  };
}

export default async function BlogPost({ params }: Props) {
  const { slug } = await params;
  const post = await getPostBySlug(slug);
  
  if (!post) notFound();

  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'BlogPosting',
    headline: post.title,
    datePublished: post.publishedAt,
    dateModified: post.updatedAt,
    author: {
      '@type': 'Person',
      name: post.author.name,
    },
    image: post.featuredImage,
    description: post.excerpt,
  };

  return (
    <article>
      <script
        type="application/ld+json"
        dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
      />
      <h1>{post.title}</h1>
      {/* Render post content */}
    </article>
  );
}

請注意標準 URL 明確設置。不要將此留給機會。Webflow 自動處理規範；在 Next.js 中，你需要有意為之。

性能優化

相對於 Webflow，最大差異是兩件事：

使用 next/image 進行圖像優化：

import Image from 'next/image';

<Image
  src={post.featuredImage}
  alt={post.imageAlt}
  width={1200}
  height={630}
  priority={true} // 對於首屏圖像
  sizes="(max-width: 768px) 100vw, 800px"
/>

使用 next/font 進行字體優化：

import { Inter } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
});

僅這兩個優化通常就可以使 LCP 從 Webflow 的預設字體和圖像處理中減少 1-2 秒。

對於正在考慮無頭 CMS 方面的團隊，我們在無頭 CMS 開發頁面上涵蓋該集成工作。

真正有效的 301 重定向策略

這是保存排名的部分。我將在此部分中盡量詳細，因為我見過太多遷移在重定向實現上失敗。

構建完整的重定向映射

取你審核階段的 Screaming Frog 爬取。對於 Webflow 網站上存在的每個 URL，你需要以下結果中的一個：

**Next.js 上的相同 URL——**不需要重定向，但驗證其有效
**Next.js 上的不同 URL——**從舊 URL 到新 URL 的 301 重定向
**頁面被移除——**301 重定向到最相關的現有頁面

永遠不要為之前有流量或反向連結的頁面返回 404。永遠不要。

在 next.config.js 中實現

// next.config.js
const redirects = require('./redirects.json');

/** @type {import('next').NextConfig} */
const nextConfig = {
  async redirects() {
    return redirects.map(({ source, destination }) => ({
      source,
      destination,
      permanent: true, // 301 狀態碼
    }));
  },
};

module.exports = nextConfig;

而你的 redirects.json：

[
  { "source": "/old-blog-post", "destination": "/blog/old-blog-post" },
  { "source": "/services/old-service", "destination": "/services/new-service" },
  { "source": "/team/:member", "destination": "/about" }
]

在 URL 結構系統性更改的地方使用路徑匹配模式進行批量重定向。但始終單獨測試這些——如果你不小心，模式匹配可能會導致重定向循環。

Webflow 特定的陷阱

Webflow 將尾部斜線附加到 URL。Next.js 預設不這樣做。這意味著 yoursite.com/about/（Webflow）和 yoursite.com/about（Next.js）在技術上是不同的 URL。

在你的 next.config.js 中，添加：

const nextConfig = {
  trailingSlash: false, // 或 true——只要保持一致
  // ...
};

然後為你的最高流量頁面的尾部斜線變體添加明確的重定向。Google 最終會透過規範自己計算出來，但明確的 301 加快了該過程。

處理 Webflow CMS 內容

如果你有一個 Webflow CMS 博客，有 200 篇文章，你需要一個地方放置該內容。你在 2025 年有幾個不錯的選項：

CMS	2025 年定價	最適合	遷移工作量
Sanity	免費層 → $99/月（成長）	複雜內容模型、實時協作	中等
Contentful	免費層 → $300/月（團隊）	企業團隊、多語言	中等到高
Payload CMS	自託管（免費）或雲端 $30/月+	完全控制、TypeScript 原生	初始較高，持續較低
MDX 文件在存儲庫中	免費	小博客（<100 篇文章）	低

對於大多數 Webflow 到 Next.js 的遷移，我推薦 Sanity。其架構靈活性與 Webflow 的集合結構映射良好，有導入 Webflow 數據的社區工具。Payload CMS 對於想要 TypeScript 中所有內容的團隊越來越受歡迎——如果你在構建自訂棧，值得評估。

關鍵事項：無論你選擇哪個 CMS，確保你的部落格文章 slug 完全相符。Webflow 上的 /blog/my-great-post 在 Next.js 上需要是 /blog/my-great-post，從新 CMS 拉取。

遷移後 SEO 監控

啟動日不是結束。這是 4-8 週監控期的開始。

第 1 週：立即行動

將新站點地圖提交 到 Google Search Console（https://yoursite.com/sitemap.xml）
使用 URL 檢查要求索引 前 20 個頁面
**監控報導報告——**查看 404 錯誤的尖峰
**檢查重定向鏈——**使用 Screaming Frog 爬取實時網站，並驗證每個重定向在一個躍點內解析

第 2-4 週：排名恢復

預期會臨時下降。即使使用完美的重定向，我也見過排名在前兩週下降 5-15 位。別驚慌。Google 需要重新爬取、重新處理和重新分配排名信號。

要監控的內容：

**Search Console 中的索引頁面計數——**應在 2 週內穩定
**點擊率——**如果 CTR 顯著下降，你的元描述可能需要調整
**Core Web Vitals——**你的 Next.js 網站應該得分更高；驗證 Search Console 的 CWV 報告

第 4-8 週：確認

到第 4 週，你的排名應該在恢復。到第 8 週，它們應該與或超過遷移前的基線。如果它們到第 6 週還沒有恢復，那就有問題了——檢查遺漏的重定向、標準問題或渲染問題。

導致排名下降的常見錯誤

忘記 Webflow 的自動生成頁面。 Webflow 創建你可能想不到的頁面——/blog（集合列表）、分頁頁面如 /blog?page=2、標籤/類別篩選頁面。對應所有這些。

不匹配標題層次結構。 如果你的 Webflow 網站在部落格文章上有 <h1> 標籤，Google 使用它來進行精選片段，你的 Next.js 網站需要相同的層次結構。別意外地將標題包裝在 <h2> 中，因為你的佈局組件已經在某處有 <h1>。

關鍵內容的客戶端渲染。 這是大問題。如果你的 Next.js 頁面加載空殼，然後在客戶端獲取內容，Googlebot 可能無法可靠地看到你的內容。使用伺服器組件（App Router 中的預設）或 generateStaticParams 進行靜態生成。SSR 是你轉向 Next.js 的原因——使用它。

忽略 Open Graph 和社交預覽。 Webflow 自動生成 OG 標籤。如果你的共享部落格文章突然在 LinkedIn 和 Twitter 上顯示損壞的預覽，你會失去間接影響 SEO 的社交流量。

在遷移期間更改域。 如果可以避免，不要同時更改域和平台。每個更改都是獨立的風險因素。先遷移平台，穩定排名，然後考慮域更改作為單獨的項目。

如果這感覺令人應接不暇，那是正常的。遷移項目是經驗最重要的地方。我們做過足夠多的項目來擁有可靠的流程——如果你想討論你的具體情況，請透過我們的聯繫頁面聯繫。

常見問題

Webflow 到 Next.js 遷移需要多長時間？ 對於具有 20-40 頁和博客的典型行銷網站，預期從審核到啟動需要 6-12 週。開發工作本身可能需要 4-8 週，但你需要時間進行前期的 SEO 審核和之後的監控。倉促遷移會導致你失去排名。

遷移 Webflow 時會丟失 SEO 排名嗎？ 如果你正確執行則不會。透過適當的 301 重定向、相符的 URL 結構和等效的頁面 SEO 元素，你應該在 4-8 週內看到排名恢復。有些網站實際上看到改進，因為 Next.js 提供更好的 Core Web Vitals 分數。關鍵是永遠不要讓之前索引的 URL 返回 404。

我能匯出我的 Webflow 網站代碼並在 Next.js 中使用它嗎？ 在技術上是的——Webflow 匯出乾淨的 HTML、CSS 和 JavaScript。但實際上，你不會想要。Webflow 的匯出代碼使用自己的類命名約定和運行時腳本，這些不能乾淨地對應 React 元件。最好使用 Webflow 匯出作為視覺參考在 React/Next.js 中重建你的 UI，然後單獨遷移內容。

我應該使用什麼無頭 CMS 來替換 Webflow 的 CMS？ Sanity 和 Payload CMS 是 2025 年 Next.js 項目中最受歡迎的選擇。Sanity 提供慷慨的免費層和出色的實時編輯。Payload CMS 是 TypeScript 原生的，可以自託管。對於更簡單的博客，甚至存儲在 Git 存儲庫中的 MDX 文件都有效。正確的選擇取決於你的團隊規模和內容複雜性。

遷移後如何處理 Webflow 表單？ Webflow 的表單處理不會轉移。在 Next.js 中，你可以使用 Server Actions（內置於 Next.js 14+）來處理表單提交，或集成 Formspree、Resend 或你自己的 API 路由之類的服務。對於聯繫表單，使用 Resend 進行電郵遞送的 Server Actions 是我的首選——它很簡單，並將所有內容保持在你的程式碼庫中。

Next.js 對於 SEO 真的比 Webflow 更好嗎？ 這取決於網站。對於一個沒有自訂邏輯的 10 頁行銷網站，Webflow 的內置 SEO 工具誠實地是充分的。但對於內容豐富的網站、需要基於用戶上下文的動態元標籤的網站，或者 Core Web Vitals 性能重要的網站（提示：它總是重要的），Next.js 給你更多控制。伺服器端渲染確保 Googlebot 總是看到完全呈現的 HTML，你對每個 SEO 元素都有程序控制。

從 Webflow 遷移到 Next.js 要花多少錢？ 中等網站的專業遷移的現實範圍包括 SEO 保護在內為 $15,000-$40,000。自由職業者的費率可能較低（$5,000-$15,000），但如果他們缺乏遷移經驗，風險會更高。最大的成本變數是是否需要無頭 CMS 集成以及需要重建多少自訂互動。

我應該對遷移的 Next.js 網站使用 SSR 或 SSG？ 對於大多數從 Webflow 遷移的行銷網站，靜態站點生成 (SSG) 是正確的預設。它更快、更便宜地提供。對於需要實時數據的頁面（例如從 API 拉取實時數據的定價頁面）選擇性地使用 SSR。Next.js 15 的 App Router 使在同一項目中使用伺服器元件和 generateStaticParams 混合這兩種方法變得容易。

如何將Webflow遷移至Next.js而不損失SEO排名

目錄

為什麼從 Webflow 遷移到 Next.js

遷移的真實成本

遷移前 SEO 審核

爬取所有內容

記錄你的頂級表現者

保存你的反向連結配置文件

匯出您的 Webflow 網站

匯出包含的內容

匯出不包含的內容

構建 Next.js 替代方案

URL 結構對應

元數據實現

性能優化

真正有效的 301 重定向策略

構建完整的重定向映射

在 next.config.js 中實現

Webflow 特定的陷阱

處理 Webflow CMS 內容

遷移後 SEO 監控

第 1 週：立即行動

第 2-4 週：排名恢復

第 4-8 週：確認

導致排名下降的常見錯誤

常見問題

Let's build
something together.

目錄

為什麼從 Webflow 遷移到 Next.js

遷移的真實成本

遷移前 SEO 審核

爬取所有內容

記錄你的頂級表現者

保存你的反向連結配置文件

匯出您的 Webflow 網站

匯出包含的內容

匯出不包含的內容

構建 Next.js 替代方案

URL 結構對應

元數據實現

性能優化

真正有效的 301 重定向策略

構建完整的重定向映射

在 next.config.js 中實現

Webflow 特定的陷阱

處理 Webflow CMS 內容

遷移後 SEO 監控

第 1 週：立即行動

第 2-4 週：排名恢復

第 4-8 週：確認

導致排名下降的常見錯誤

常見問題

Let's build something together.

Let's build
something together.