surfup

保險公司

網站與線上銷售遷離舊技術架構,流量未流失

保險 · 遷移 · 開發 · SEO · YMYL
專案背景

客戶是一家保險公司,線上銷售汽車強制責任險、車體險和旅遊保險。平台多年來逐步建置:自製 PHP、文件遺失、每次修改都要等上幾週,外部稽核還發現 11 個重大漏洞。儘管如此,網站仍是主要銷售管道,有數萬個頁面已被索引,內容屬於對品質要求嚴格的 YMYL 領域;遷移中的任何錯誤都可能造成排名流失,而保險業要把排名追回來非常昂貴。

01 · 挑戰

將網站和保單線上投保遷移至現代技術架構,同時確保銷售一天也不中斷:

保住搜尋流量、修補漏洞、加快平台速度,並讓團隊放心開發產品。董事會還提出額外要求:專案必須透過提升轉換率回本,而不能只做到「技術整理」。

02 · 已完成工作

我們把遷移拆成可獨立切換的階段:先遷移內容頁,再遷移計算器和投保流程,最後才處理個人帳戶。每個階段都能單獨回復,讓風險分批承受,而不是一次全部累積。

  • 完成系統盤點:全面爬取 URL、繪製功能地圖、整理與支付及會計系統的整合清單,並依流量和營收排定頁面優先順序。
  • 設計目標架構:搜尋頁面採用 Next.js 伺服器端渲染前端,在現有服務上增加 API 層,並分階段淘汰舊程式碼。
  • 遷移內容頁:為 8 萬個 URL 建立重新導向對照表,移轉中繼資料與標記,並逐頁對照原版確認內容和結構。
  • 重寫保單線上投保流程:包含計算器、投保步驟和付款,並讓新舊版本在部分流量上平行運作。
  • 依金絲雀方案切換流量:5% → 25% → 100%,每一步都監控錯誤、轉換率和搜尋排名。
  • 為每一階段準備回復方案:指標若惡化,可在幾分鐘內將流量切回舊平台,而非耗上幾小時。

我們另外設置遷移 SEO 安全流程:每日檢查索引狀況、優先群組排名和爬取錯誤,並將流量與去年同期比較。正是這套紀律讓自然流量在兩週內平穩恢復,而不是像這類專案常見的那樣下滑數月。董事會要求的成果也都達成:在同一個專案中提升速度並保護銷售管道。

03 · 成果

轉換率提升 34% 是速度增加與投保流程簡化的直接成果。在行動流量上的提升最大,因為過去七秒的載入時間會讓交易直接流失。對業務而言,這代表每天多出數十份保單,卻不必增加廣告預算;依客戶估算,遷移在一季內回本。開發速度也提升了:以前需要幾週的功能,現在幾天即可推出。

04 · 主要成果
指標成果
頁面載入速度(LCP)6,8 秒 → 1,4 秒
保單投保轉換率+34%
重大漏洞11 → 0
自然流量兩週內恢復,之後持續成長

指標取自案例原始資料。僅在來源有記錄時註明統計期間。

遷移一季後
LCP 載入時間(原為 6.8 秒)
1.4秒
保單投保轉換率
+34%
重大漏洞(原為 11 個)
0
自然流量恢復所需時間
2 週
速度與安全
載入時間(LCP),秒
之前6.8秒
之後1.4秒
數值越低越好
重大漏洞
之前11
之後0
數值越低越好
金絲雀式流量切換
5%
1
25%
2
100%
3

每一步都監控錯誤、轉換率和排名,並準備回復方案。

遷移階段
  1. 01內容頁8 萬個 URL 的重新導向對照表
  2. 02計算器與投保流程新舊版本平行運作
  3. 03個人帳戶區最後
後續步驟

新技術架構帶來的發展機會:

  • Headless CMS:行銷團隊不必找開發人員就能自行發布保險產品登陸頁。
  • A/B 測試平台:將保單投保流程實驗變成持續作業,而非一次性專案。
  • 個人化推薦:依車輛類型、地區和客戶歷史提供不同方案。
客戶評語
三年來我們一直不敢遷移,擔心流量和銷售會流失。最後沒有一天停止營運,轉換率還提高了三分之一。

— 保險公司數位通路總監

最新資源

所有資源

SurfUp 的實用文章與指南。

指南 · 10 分鐘閱讀

「什麼是…」頁面與 AI 答案:點擊流失還是需求下降

某銀行的參考區塊造訪減少 24%,需求下降 13%。如何區分被 AI 區塊搶走的點擊與需求下滑,以及如何量測。

閱讀
指南 · 8 分鐘閱讀

Google 更新後流量下滑

如何判斷流量下滑是 Google 更新、季節性還是網站故障造成:2026 年更新時程、六題檢查,以及前 14 天的行動計畫。

閱讀
指南 · 9 分鐘閱讀

是需求下降還是網站流失:用 Wordstat 對照流量

定存需求下降 75%、流量下降 37%;金融卡需求 −35%、流量 −63%。如何對照流量與需求,避免把市場的問題算到網站頭上。

閱讀