A COMEBACK STORY
🫖

SEO 分解茶
復活記

網站被停權、整站從網路上消失。
這是從 Wayback 重建、保住舊 URL 與索引,
並把它修得比停權前更健康的完整過程。

事情是這樣開始的

「分解茶」是一個寫了好幾年的 SEO 知識部落格,長篇教學為主,有幾篇單篇四十幾張圖、閱讀時間三十五分鐘那種。對台灣做 SEO 的人來說,是入門會讀到的網站。

某天原主機商寄來續約帳單,金額高得不合理。談不攏,網站直接被停權。不是暫停,是整站拔掉:頁面全掛、圖片全沒,連要把資料庫或檔案匯出來都做不到。

多年的內容資產與索引,一夜歸零。

救援的八個步驟

每一步都有「為什麼要這樣做」

🔎
STEP 01

先盤點還剩下什麼

原主機完全拿不回東西,所以第一件事是確認外部有沒有可用的內容來源。Wayback Machine 有分解茶的歷史快照,多數文章都被存到了。有快照就有救。

同時盤點的還有:GSC 裡的索引狀態、還活著的外部連結、以及網域本身(DNS 在 Cloudflare,網域本體沒事)。

🕰️
STEP 02

從快照把內容一篇篇還原

從 Wayback 的快照裡,把 19 篇文章的內文、標題、分類、發布日期逐篇比對還原。日期要對,因為它會影響 sitemap 的 lastmod 與內容的時序判斷。

🔗
STEP 03

重建站台,而且 URL 一比一復刻

在新主機重架 WordPress,把內容灌回去。這一步最講究的是 URL:完全復刻舊站結構,包含分類網址不帶 /category/ 前綴的舊格式(例如 /technical-seo//blog/最新資訊/)。

  • 舊的 /category/xxx/ 網址一律 301 導到新結構
  • 子分類的導向要帶父層路徑,否則會 301 到一個 404(這個 bug 我們真的踩到,後來用 slug 反查真實分類的永久連結才修好)
為什麼講究:Google 記得的是舊 URL,外部連結指向的也是舊 URL。URL 對得上、轉址不斷鏈,過去累積的排名與外部連結權重才接得回來。重建網站最貴的成本不是內容,是索引。
🎨
STEP 04

既然重做,順便換上新設計

本來可以只求恢復原狀,但既然整站重來,就換上雜誌編輯風的版面:全寬導覽列、首篇大卡橫幅、單篇有漸層底色、麵包屑、閱讀時間、文末同主題推薦,以及桌機側邊的浮動目錄。

🖌️
STEP 05

19 張封面用 AI 重繪

舊封面不是遺失就是比例跑掉、風格不一。改用統一的手繪粉彩風,替 19 篇各生一張全新封面,另外做了一隻噴射茶壺當站方吉祥物。封面同時是 og:image,分享到社群的預覽也一併統一了。

🗂️
STEP 06

圖片治理(工程量最大的一關)

  • 就地壓縮:全站 uploads 從 91 MB 降到 44 MB,同 URL、零轉檔搬移,畫質肉眼無損
  • WebP:產同名 .webp 兄弟檔,前端自動改吃 webp、原檔留作後備。單張封面 233 KB 降到 42 KB
  • 拆掉外部圖依賴:內文有大量圖片其實是 googleusercontent 的臨時網址(Google 文件匯入留下的),那種連結會過期。把 77 張全數下載進自站媒體庫、內文網址一併改寫
  • 自動裁白邊:偵測並裁掉圖片四周均勻留白,版面收斂、體積再降
為什麼要拆外部圖:那批連結不是「現在壞掉」,是「未來一定會壞」。等它失效時,會一次產生大量破圖,影響的是使用者體驗訊號與內容完整度,而且沒有預警。趁重建一次拆乾淨。
🧰
STEP 07

SEO 基礎建設與可用性修復

逐頁體檢後,把技術面的坑一個個補起來:

  • 全站沒有 meta description、og、canonical。根因是 Rank Math 裝了但從沒跑過設定精靈,設定值是空的,前台等於完全不輸出 SEO meta。補完設定後由它接管 title 模板、description、robots、Article 結構化資料與 og / twitter
  • robots 分層:文章、頁面、分類 index;tag、站內搜尋、作者與日期彙整頁 noindex
  • 分類頁重複 H1:佈景主題的預設彙整標題與自訂標題同時輸出,移除其一
  • sitemap:切到 Rank Math 的 /sitemap_index.xmlrobots.txt 同步指向,並重送 GSC
  • 破圖與空影片自動收合:Wayback 救不回的舊圖與失效的影片來源,前端偵測後隱藏,不留破格、不製造無效請求
  • 行動可用性:手機選單修復、表格加上橫向捲動不再撐破版面、圖片可點擊放大看細節
  • 圖片比例矯正:舊文有不少圖被前人在編輯器手動拖拉過尺寸,寬高各自被改導致比例失真,一次矯正回自然比例
STEP 08

效能:把兩根最大的槓桿拉下來

前面七步做完網站已經完整,但還不夠快。實測後發現瓶頸不在圖片,在另外兩處:

  • 中文網頁字型 1.4 MB:Google Fonts 載入的 Noto Sans TC 三個字重被切成 26 個 subset 檔。改成系統字型堆疊(蘋方 / 微軟正黑),只保留拉丁字的 Space Grotesk 22 KB,直接省掉 1.4 MB 的阻塞
  • HTML 完全沒進 CDN 快取:原本 cf-cache-status 一直是 DYNAMIC,代表每個訪客都回源。加一條 Cache Rule 讓文章頁進邊緣快取,並排除後台、登入 cookie 與 REST API
結果:TTFB 從 799 ms 降到 210 ms,而且剩下的 210 ms 幾乎全是到邊緣節點的網路往返,伺服器端已經沒有等待。

SEO 面特別顧到的事

重建網站,最貴的從來不是內容

URL 一比一復刻,不製造新的 404

分類、文章的網址格式完全比照舊站,讓既有索引與外部連結能直接對上。

舊網址 301 導向,含子分類父層路徑

轉址不能導到 404。子分類要帶完整父層路徑,這點一開始做錯,後來以 slug 反查真實永久連結修正。

canonical、meta description、og / twitter 補齊

原本全站空白,補完後社群分享與搜尋結果摘要才有正確資訊。

robots 分層,控制可索引範圍

內容頁開放索引;tag、搜尋結果、作者與日期彙整頁 noindex,避免低品質頁面稀釋。

Article 結構化資料與 sitemap 重送

結構化資料由 SEO 外掛接管,sitemap 切換後同步更新 robots.txt 並在 GSC 重新提交。

移除外部圖片依賴

77 張借放在 Google 臨時網址的圖片全數搬回自站,拆掉未來大規模破圖的未爆彈。

Core Web Vitals 導向的效能處理

字型阻塞、HTML 邊緣快取、圖片格式與體積,三面一起壓,頁面總重砍半。

數字說話

同一篇長文(40 張圖)優化前後實測

TTFB(首位元組時間)799 ms210 ms
DOM 可互動時間1,912 ms769 ms
頁面總下載量2.9 MB1.4 MB
資源請求數73 個48 個
網頁字型26 檔 1.4 MB1 檔 22 KB
全站 uploads 容量91 MB44 MB
單張封面圖233 KB42 KB
HTML 邊緣快取DYNAMICHIT
文章救回19 篇(全數)
外部圖搬回自站77 張

過程中的幾個插曲

不是每一步都順利

插曲 01

🤖 一顆佔滿畫面的 Android 機器人

某篇文章目錄底下冒出一個佔滿整個內容寬度的黑色機器人。查了半天,發現是多年前作者貼進內文的一個 Font Awesome 圖示,inline SVG 沒有尺寸限制,被撐成整頁寬。清掉後掃全站,同類的隱形地雷還有 13 個,分散在三篇文章裡。

插曲 02

💥 容器被操到 OOM 重啟

處理一篇有 45 張圖的長文時,每張圖匯入都同步觸發縮圖生成加 WebP 轉檔,記憶體直接爆掉、容器自動重啟。資料庫與已上傳的檔案都在持久卷上安然無恙,但放在容器層的 wp-cli 被清掉,重新下載就恢復了。教訓:這種批次影像處理要先關掉同步轉檔的 hook,事後再分批補。

插曲 03

💣 就地覆蓋的快取陷阱

裁完 77 張圖片的白邊後,前端看起來完全沒變。原因是檔案是就地覆蓋、URL 沒變,Cloudflare 邊緣還服務著舊版本。改內容(HTML)會立刻生效,改檔案(同 URL)則必須 purge。這個差異很容易讓人誤判「我的修改沒生效」。

從一個打不開的網址開始

到現在,它比停權之前更快、更完整,技術債也清掉一輪。這一整趟從搶救、重建、SEO 修復到效能優化,是魁哥和 AI 助手 Claude 一起,一步一步做完的。

去看看復活後的分解茶