超越Webflow：擴展業務的下一步
超越 Webflow：快速發展業務的下一步
每個成長中的企業在使用 Webflow 時都會經歷一個時刻。通常始於一些小問題——也許你需要超過 10,000 個 CMS 項目，或者你的行銷團隊想要伺服器端個性化，或者你的開發人員第三次在本季度對抗 10,000 字元自訂程式碼限制。你用第三方工具修補它。然後是另一個。然後是另一個。某一天你看著你的堆棧，意識到你已經在一個根本不是為你要求它所做的事情而設計的網站構建器周圍建立了一個魯布·戈德堡機器。
我已幫助幾十個團隊度過這一確切的轉變。有些是客戶已經超越 Webflow 的代理機構。其他是在早期在 Webflow 上啟動的 B 輪創業公司的內部團隊，現在需要能夠真正擴展的東西。對話始終以相同的方式開始：「我們喜歡 Webflow 的外觀，但我們一直在碰壁。」
如果你現在處於這種情況，本文適合你。我們將具體說明 Webflow 在何處崩潰，2025 年現實的替代方案是什麼樣子，以及如何計畫一次不會破壞你的 SEO 或理智的遷移。
目錄
- 迫使遷移的真實 Webflow 限制
- 你的業務已經超越 Webflow 的跡象
- Webflow 之後是什麼：現實的選項
- 無頭 CMS + 現代框架：最常見的路徑
- 後 Webflow 團隊的框架比較
- 計畫遷移而不破壞你的 SEO
- 代理商視角：何時建議遠離 Webflow
- 真實成本分解：Webflow 對比自訂堆棧
- 常見問題
迫使遷移的真實 Webflow 限制
讓我們明確一點：Webflow 對於特定用例來說確實很棒。行銷網站、登陸頁面、投資組合網站、中小型內容網站——它可以漂亮地處理所有這些。視覺化構建器是同類最佳的。設計人員的學習曲線比任何基於代碼的替代方案都要低得多。我不是來貶低 Webflow。
但存在硬性限制，它們不是理論上的。它們是我一次次看到團隊碰到的。
CMS 項目限制
Webflow 的 Business 方案限制你最多 10,000 個 CMS 項目，可擴展到 20,000 個附加組件。Enterprise 計畫可以將其推送到 50,000–100,000+，但你需要根據協商從大約 $800–$1,000+/月開始的自訂 Enterprise 定價。
對於有 200 篇部落格文章和 50 個案例研究的 B2B SaaS 公司？沒有問題。對於有數千個 SKU 的目錄網站、市場、媒體出版物或電子商務目錄？你會很快碰到這堵牆。
沒有伺服器端邏輯
Webflow 為你處理託管——直到你需要在伺服器上做任何事情，這才很好。沒有超出基本 301 的自訂重定向（即使這些也有限制）。沒有中介軟體。沒有動態資料的伺服器端呈現。沒有邊界函數。沒有 API 路由。
想根據用戶的位置顯示不同的內容？想在用戶看到頁面之前驗證他們？想運行伺服器端 A/B 測試以便沒有佈局轉移？你要裝上外部服務或你被卡住。
自訂程式碼字元限制
Webflow 將自訂程式碼嵌入限制為每頁 10,000 個字元，網站範圍的標題/頁腳為 10,000 個字元。這聽起來很多，直到你在嵌入 Google Tag Manager、客戶支持小部件、分析腳本、個性化工具和行銷自動化像素。突然間，你在積極縮小所有內容，並就哪些工具可以在哪些頁面上存在做出權衡。
企業級但不夠高級的電子商務
Webflow 電子商務多年來有所改進，但截至 2025 年，它仍然缺少結帳時的多貨幣支持、訂閱計費、複雜的產品變體、多個倉庫的庫存管理，以及不斷增長的 DTC 品牌需要的大部分功能。缺乏主要的電子商務更新已促使許多代理機構查看無頭電子商務解決方案，例如 Shopify Hydrogen、Medusa 或 Saleor，與 Webflow 或自訂前端配對。
託管鎖定
你可以從 Webflow 匯出你的 HTML、CSS 和影像。你不能匯出的：CMS 內容以清晰對應到另一個系統的結構化格式、交互和動畫、表單提交、邏輯屬性，或與 Webflow 專有功能相關的任何內容。匯出為你提供靜態檔案——一個快照，而不是一個活的網站。這使遷移比應該的要困難。
大規模集成受限
Webflow 與一把握工具配合得很好：Google Analytics、Mailchimp、Zapier、基本 webhook。但沒有與 Salesforce、HubSpot 的完整套件、Segment、Braze 或大多數 CDP 和行銷自動化平台的原生集成。你最終通過 Zapier 或 Webflow 更新某些內容時會中斷的自訂腳本構建脆弱的連接。
你的業務已經超越 Webflow 的跡象
並非每一個挫折都意味著你應該遷移。有些問題最好通過停留在 Webflow 並添加有針對性的集成來解決。但有明確的跡象表明該平台本身已成為瓶頸：
- 你在解決方法上花費的時間比實際開發多。 如果你的開發人員花 40% 的時間與 Webflow 的限制搏鬥而不是構建功能，數學不再成立。
- 你的第三方工具成本超過你的 Webflow 訂閱。 當你為 Memberstack、Jetboost、Finsweet 屬性、Outseta 和三個 Zapier 連接支付費用只是為了獲得基本功能時，你為受限平台支付自訂開發價格。
- 你需要經過身份驗證的用戶體驗。 受保護的內容、用戶儀表板、個性化的視圖、基於角色的訪問——所有這些在 Webflow 中都需要裝上的解決方案，與專用實施相比感覺不靠譜。
- 你的內容團隊被 CMS 限制阻擋。 多參考欄位限制、每個集合 20 欄位的限制（增加但仍然限制複雜內容模型），以及 CMS 項目上限都為內容繁重的操作造成摩擦。
- 效能要求要求伺服器端控制。 如果你需要 ISR（增量靜態再生）、動態內容的伺服器端呈現、帶有自訂邏輯的邊界快取或任何形式的後端處理，Webflow 無法提供。
- 你因為技術限制而失去交易。 對於代理機構，這是最明確的信號。當潛在客戶詢問你無法在 Webflow 上提供的功能，並且你一次次轉介業務到其他地方時，是時候擴展你的堆棧了。
Webflow 之後是什麼：現實的選項
沒有單一的「後 Webflow」答案。正確的路徑取決於你的團隊的技術能力、你的內容工作流程、你的預算，以及具體什麼在破裂。
選項 1：在 Webflow 上保留行銷，分別構建應用程式
老實說？這對許多團隊是正確的答案。如果你的行銷網站在 Webflow 上運行得很好，但你需要應用程式功能，不要遷移行銷網站。在自訂堆棧上運行 app.yourdomain.com，並在 Webflow 上保留 www.yourdomain.com。你的行銷團隊保持不受阻礙，你的工程團隊獲得他們需要的工具。
選項 2：無頭 CMS + 現代框架
這是真正超越 Webflow 的團隊最常見的遷移路徑。你選擇一個無頭 CMS（Sanity、Contentful、Storyblok、Payload、Strapi）用於內容管理，並與現代框架（Next.js、Astro、Remix、Nuxt）配對以用於前端。我們在 Social Animal 進行了大量這類工作——你可以在我們的 headless CMS 開發 和 Next.js 開發 頁面上看到我們的方法。
選項 3：無頭電子商務堆棧
對於超越 Webflow 商店功能的電子商務業務，通常的做法是 Shopify 的 Storefront API（或 Medusa/Saleor 等替代方案）與自訂前端。你獲得 Shopify 的防彈結帳和庫存管理，具有前端的完整設計自由度。
選項 4：完整自訂應用程式
有時你不再構建「網站」——你在構建一個產品。一個 SaaS 儀表板、一個市場、一個平台。在這些情況下，你需要一個全棧框架、一個真實的後端、一個真實的資料庫和一個真實的部署管道。這不是網站遷移；這是產品構建。
無頭 CMS + 現代框架：最常見的路徑
由於這是大多數 Webflow 團隊最終採用的路線，讓我們深入挖掘這實際上是什麼樣子。
選擇無頭 CMS
CMS 決定比大多數團隊意識到的更重要，因為它決定了你的內容團隊的日常體驗。以下是我看到的有效方式：
| CMS | 最適用於 | 定價（2025） | CMS 項目 | 學習曲線 |
|---|---|---|---|---|
| Sanity | 複雜的內容模型、即時協作 | 免費層級，然後 $15/用戶/月（Growth） | 所有方案無限制 | 中等 |
| Contentful | 企業團隊、強大的 API 生態系統 | 免費層級，然後 $300/月（Team） | 因計畫而異（最多 1M+ 項目） | 低-中等 |
| Storyblok | 視覺編輯、基於組件的內容 | 免費層級，然後 €106/月（Business） | 付費方案無限制 | 低 |
| Payload | 自託管、完整控制、TypeScript 原生 | 免費（開源）、Cloud 從 $35/月 | 無限制（你的資料庫） | 中等-高 |
| Strapi | 自託管、靈活、大型社群 | 免費（開源）、Cloud 從 $29/月 | 無限制（你的資料庫） | 中等 |
對於來自 Webflow 的團隊，Storyblok 通常因其視覺化編輯器而感覺最熟悉。Sanity 對於複雜項目是我的個人最愛，因為其 GROQ 查詢語言和即時協作功能非常出色。Payload 在 2025 年為想要擁有其基礎結構的團隊獲得了真正的動力。
選擇前端框架
這是你開發人員的偏好重要的地方，但存在應該影響選擇的真實技術差異。
對於內容繁重的網站（部落格、文件、行銷網站），其中效能至關重要，Astro 很難被擊敗。它預設發送零 JavaScript，只水化互動組件——一個稱為「島嶼架構」的概念。我們看到 Lighthouse 分數從 Webflow 上的中等 70 年代跳到 Astro 構建上的一致 95+。
對於需要動態功能——用戶身份驗證、即時資料、複雜的交互——Next.js 仍然是最久經考驗的選項。App Router（自 Next.js 13 穩定，到 2025 年 Next.js 15 時成熟）為你提供伺服器組件、串流和處理 Webflow 無法觸及的確切用例的中介軟體。
對於想要比 Next.js 更簡單但比 Astro 更動態的東西的團隊，Remix 或 SvelteKit 值得評估。但在實踐中，大多數團隊著陸在 Next.js 或 Astro。
後 Webflow 團隊的框架比較
| 標準 | Next.js 15 | Astro 5 | Remix | Webflow（供參考） |
|---|---|---|---|---|
| 靜態網站生成 | ✅ 優秀 | ✅ 業界最佳 | ⚠️ 受限 | ✅ 內置 |
| 伺服器端呈現 | ✅ 完全支持 | ✅ 帶適配器 | ✅ 完全支持 | ❌ 無 |
| API 路由 | ✅ 內置 | ✅ 帶適配器 | ✅ 加載器/操作 | ❌ 無 |
| 視覺編輯 | ⚠️ 通過 CMS 外掛程式 | ⚠️ 通過 CMS 外掛程式 | ⚠️ 通過 CMS 外掛程式 | ✅ 原生 |
| 構建時間（1000 頁） | ~45 秒（ISR 可用） | ~30 秒 | N/A（隨需） | N/A（託管） |
| 託管成本（典型） | $20-100/月（Vercel） | $0-20/月（Netlify/Cloudflare） | $20-50/月 | $39-212/月 |
| 設計人員的學習曲線 | 高 | 中等 | 高 | 低 |
| CMS 項目限制 | 無 | 無 | 無 | 10,000-20,000 |
計畫遷移而不破壞你的 SEO
這是我看到團隊犯昂貴錯誤的地方。計畫不當的遷移會在幾個月內重創你的有機流量。以下是我們遵循的流程：
1. 在你動任何東西之前審計一切
使用 Screaming Frog 或 Sitebulb 爬取你現有的 Webflow 網站。記錄每個 URL、其狀態代碼、規範標籤、中繼資料和內部連結。通過 API（REST API，而不是視覺化匯出）匯出你的 Webflow CMS 內容。對應每個你在 Webflow 的儀表板中設定的 301 重定向。
2. 完全匹配 URL 結構
如果你的 Webflow 部落格位於 /blog/post-slug，你的新網站應該使用 /blog/post-slug。不是 /posts/post-slug。不是 /blog/post-slug/。每個更改的 URL 都需要 301 重定向，即使有重定向，你也會失去一些連結權益。你需要的重定向越少越好。
// next.config.js - URL 重定向對應範例
module.exports = {
async redirects() {
return [
// 僅用於必須更改的 URL
{
source: '/old-webflow-path/:slug',
destination: '/new-path/:slug',
permanent: true,
},
];
},
};
3. 以程式設計方式遷移內容
不要手動複製貼上內容。使用 Webflow 的 CMS API 匯出結構化資料，然後編寫遷移腳本以將其匯入新的 CMS。以下是粗略的模式：
// 範例：將 Webflow CMS 項目遷移到 Sanity
import { createClient } from '@sanity/client';
const sanity = createClient({
projectId: 'your-project',
dataset: 'production',
token: process.env.SANITY_TOKEN,
apiVersion: '2025-01-01',
useCdn: false,
});
async function migrateWebflowToSanity(webflowItems: WebflowItem[]) {
for (const item of webflowItems) {
await sanity.create({
_type: 'blogPost',
title: item.name,
slug: { current: item.slug },
body: convertRichTextToPortableText(item['post-body']),
publishedAt: item['published-on'],
excerpt: item['post-summary'],
});
}
}
4. 從一開始實施適當的技術 SEO
Webflow 自動處理的事項，你需要在自訂堆棧上手動實施：
- XML 網站地圖（對 Next.js 使用
next-sitemap或對 Astro 使用@astrojs/sitemap） - 規範標籤
- Open Graph 和 Twitter 卡中繼標籤
- 結構化資料（JSON-LD）
- Robots.txt
- 影像優化（Next.js Image 組件或 Astro 的內置影像優化）
5. 並行運行兩個網站
在中斷之前，將新網站部署到暫存 URL，然後運行比較爬取。檢查每個 URL 是否傳回正確的狀態代碼，中繼資料是否相符，以及效能指標至少與 Webflow 一樣好。使用 Google Search Console 的 URL 檢查工具驗證呈現。
代理商視角：何時建議遠離 Webflow
如果你是一個代理機構，決定將客戶遷移離開 Webflow 是有負擔的。Webflow 項目有可預測的時間表，設計人員可以獨立處理大量構建，維護很直接。遷移到自訂堆棧意味著更多的開發時間、更複雜的部署，以及一個長期需要更多的客戶。
最後一點實際上是上行的。當客戶超越 Webflow 時，能夠引導遷移的代理機構——而不是轉介他們到開發商店——深化關係，並通過持續開發、優化和支持開放經常性收益。
以下是我建議的框架：
如果以下情況，請停留在 Webflow 上：
- 客戶的挫折可以通過 1-2 個第三方工具解決
- 該網站的月訪問者不到 100,000
- 內容量在 5,000 項目以下且增長緩慢
- 不需要經過身份驗證的體驗或自訂後端邏輯
- 客戶沒有自訂開發預算（$30,000+ 以進行良好執行的遷移）
如果以下情況，請遷移：
- 第三方工具成本超過每月 $200，加上 Webflow
- 團隊在解決方法上花費大量時間
- 業務要求包括 Webflow 從根本上無法支持的功能
- 效能需求超過 Webflow 託管所能提供的
- 客戶有開發團隊（或預算）來維護自訂堆棧
如果你是一個代理機構，希望向客戶提供這條路徑，但沒有用於 Next.js 或 Astro 構建的內部開發團隊，那正是我們合作的工作類型。查看我們的 capabilities 或 聯繫我們——我們定期與代理機構作為開發合作夥伴合作。
真實成本分解：Webflow 對比自訂堆棧
讓我們談論真實的數字。這些是根據我們在 2024–2025 年交付的項目。
| 成本類別 | Webflow（Business 計畫） | 自訂堆棧（Next.js + Sanity） | 自訂堆棧（Astro + Payload） |
|---|---|---|---|
| 平台/CMS | $49/月（$588/年） | $15/用戶/月（Sanity Growth） | $0-35/月（Payload Cloud） |
| 託管 | 包含 | $20-100/月（Vercel） | $0-20/月（Cloudflare Pages） |
| 初始構建 | $5,000-15,000 | $25,000-60,000 | $20,000-50,000 |
| 第三方工具 | $100-400/月（典型） | 大多內置 | 大多內置 |
| 年度維護 | $2,000-5,000 | $6,000-15,000 | $5,000-12,000 |
| 第一年總計 | $9,000-22,000 | $33,000-77,000 | $26,000-63,000 |
| 第二年及以後總計 | $4,000-10,000/年 | $8,000-18,000/年 | $6,000-15,000/年 |
自訂堆棧在第一年的成本是 3-4 倍。不要糖衣。但到了第二年，差距顯著縮小，你獲得 Webflow 根本無法提供的功能。對於這些功能直接轉化為收益的企業——更好的轉換率、更快的頁面載入、個性化體驗、複雜的電子商務——投資回報率數學成立。
如需根據你的具體情況進行更詳細的分解，我們的 定價頁面 給你一個典型項目範圍的概念。
常見問題
對於不斷增長的企業，Webflow 的最大限制是什麼？ 最有影響力的限制是 CMS 項目上限（Business 計畫中的 10,000–20,000 項目）、沒有伺服器端邏輯或 API 路由、自訂程式碼字元限制（每個嵌入 10,000 個字元）、帶有有限匯出功能的託管鎖定，以及缺少多貨幣、訂閱和複雜庫存管理的電子商務功能。對於大多數行銷網站，這些不是問題，但當企業擴展時它們成為交易破壞者。
我可以匯出我的 Webflow 網站並在其他地方託管它嗎？ 你可以匯出靜態 HTML、CSS 和影像，但你失去了所有 CMS 內容結構、Webflow 交互、表單功能，以及與 Webflow 平台相關的任何邏輯。匯出本質上是你的網站在一個時間點的凍結快照。它不是正在進行開發的可行路徑——它更像是最後的手段備份。
對於內容繁重的網站，Webflow 的最佳替代方案是什麼？ 對於內容繁重的網站，Astro 或 Next.js 與 Sanity 或 Payload 等無頭 CMS 的組合為你提供無限內容項目、對內容模型的完整控制，以及顯著更好的效能。Astro 特別強大，因為它發送最少的 JavaScript，可以快速生成數千個靜態頁面。
Webflow 遷移到 Next.js 需要多長時間？ 一個有 50–100 個頁面和 CMS 內容的典型遷移需要 8–14 週。這包括新 CMS 中的內容建模、前端開發、內容遷移腳本編寫、SEO 審計和重定向對應、QA 和分階段推出。更大的網站或那些具有複雜自訂功能的可能需要 16–20+ 週。
從 Webflow 遷移會傷害我的 SEO 嗎？ 如果執行不當可能會。關鍵是維護 URL 結構（或設定全面的 301 重定向）、確保所有中繼資料正確轉移、維護內部連結結構，以及在遷移後立即提交更新的網站地圖。執行正確時，大多數網站會在 2–4 週內看到 10–15% 的有機流量臨時下降，隨後恢復，通常由於更好的 Core Web Vitals 分數而改善。
Webflow 對於電子商務是否足夠好？ 對於簡單產品的小型商店（500 個 SKU 以下、單一貨幣、無訂閱），Webflow 電子商務運行良好。超出這一點，你需要一個專用的電子商務後端。最常見的方法是將 Shopify 的 Storefront API 與使用 Next.js 構建的自訂前端配對——你獲得 Shopify 經過驗證的結帳和庫存系統，具有完整的前端設計控制。
Webflow 遷移需要花費多少？ 根據複雜性，初始構建預算 $20,000–$60,000，持續維護月 $500–$1,500。這比 Webflow 構建要高得多，但你獲得一個沒有功能上限的自訂平台。當 Webflow 的限制直接造成你的收益成本或當第三方解決方法增加 $200+/月的 SaaS 成本時，投資是有意義的。
代理機構應該學習 Next.js 還是與開發團隊合作？ 兩條路都行。如果你的代理機構想在內部處理所有事務，投資 Next.js 或 Astro 專業知識需要 6–12 個月才能建立真實的能力。如果你寧願保持專注於設計和策略，與 headless 開發代理機構 合作讓你在沒有構建開發團隊開銷的情況下向超越 Webflow 的客戶提供自訂解決方案。許多成功的代理機構使用混合方法——處理設計和內容策略，同時在技術實施上合作。