AI 文章量產翻車：文章很多，不代表網站有 SEO 價值

AI 很會寫文章。

只要給它一個主題，它很快就能產出一篇看起來完整的內容。

標題有了。
摘要有了。
段落有了。
結論也有了。

如果再加上 GitHub 後台貼文流程，文章甚至可以很快上線。

但這次實際操作後，我們踩到一個很重要的坑：

文章很多，不代表網站有 SEO 價值。

如果一篇文章沒有搜尋意圖、沒有標題鉤子、沒有清楚 H2 架構、沒有技術支撐、沒有實例場景，那它就算字數很多，也可能只是「內容初稿」。

不是不能用。

但不能把它當成正式 SEO 文章完成品。

---

這次怎麼翻車？

我們當時的目標很明確：

先把 printapp.uk 的文章規模撐起來。

SEO 文章不只是字數，要有可搜尋的問題

AI 很容易把文章寫長。

但 SEO 不是只有字數。

一篇文章要先對應一個可搜尋問題。

例如：

AI 文章量產有用嗎？ AI 寫文章為什麼沒有 SEO 效果？ 小企業怎麼用 AI 做內容網站？ AI 文章要怎麼做 SEO 架構？ Cloudflare Pages 網站沒更新怎麼辦？ GitHub Pages 發文流程怎麼做？

這些都是讀者可能搜尋的問題。

文章應該圍繞這些問題展開。

如果文章只是內部紀錄，搜尋價值就會弱。

所以每篇文章要先有搜尋意圖。

例如這篇的搜尋意圖是：

想用 AI 快速產文章的人，想知道為什麼文章很多卻沒有 SEO 效果，以及要怎麼修正。

這樣內容才會收斂。

以後新文章的標準流程

後續新文章不再直接寫正文。

先做 SEO 架構。

固定格式如下：

分類： 檔名： 主關鍵字： 延伸關鍵字： 搜尋意圖： 標題鉤子： 讀者痛點： 真實場景： 技術支撐： H2 架構： 內鏈方向： CTA：

例如：

分類：內容自動化踩坑 主關鍵字：AI 文章量產 搜尋意圖：想用 AI 快速寫文章，但發現流量和品質不如預期 真實場景：Boss 指出量產文章標題沒有鉤子、內文沒有 SEO 架構 技術支撐：frontmatter、category、GitHub、Cloudflare Pages、curl 檢查 CTA：找小陳整理 AI 內容網站發文流程

架構通過後，才寫正文。

這樣比較不會跑偏。

已發文章怎麼辦？

已經發出去的文章不用刪。

它們可以先當作內容初稿庫。

後續要做的是 SEO retrofit，也就是第二階段優化。

優化項目包括：

重寫標題 改 summary 調整 H2/H3 架構 補搜尋意圖 補技術支撐 補實例場景 補內鏈 補 CTA 必要時補圖片

例如：

shared-accounts-create-ai-risk.md

可以補：

共用帳號清點表 AI 專用帳號權限範例 不該貼進聊天的憑證類型 GitHub / WordPress / Cloudflare 權限分層 發布權限與刪除權限的差異

這樣文章會從觀念文變成實用文章。

SEO 架構和技術支撐要一起存在

只有 SEO 架構，容易變成模板文。

只有技術細節，容易變成工程筆記。

這個網站需要的是兩者結合。

讀者是小企業主，不一定想看太深的程式碼。

但他也不想看空泛說法。

所以文章要做到：

小企業主看得懂 有現場問題 有操作線索 有真實案例 有技術支撐 不誇大 AI 不假裝全自動很簡單

這樣才符合網站定位。

這次踩坑留下的規則

這次 AI 文章量產踩坑後，留下幾條規則：

先有 SEO 架構，再寫正文。 標題要對應搜尋意圖，不只是內部筆記。 每篇文章要有主關鍵字與延伸關鍵字。 H2 要有清楚層次，不要只是一路講觀念。 每篇至少放一個真實場景。 每篇至少放一個技術支撐。 已發文章先當初稿庫，後續做 SEO retrofit。 不要只追求文章數量。 GitHub 貼文完成後，要提供公開網址人工確認。 文章要讓小企業主看懂，也要讓懂技術的人看得出是真的做過。

這些規則比繼續硬產文更重要。

結語：AI 可以量產，但不能跳過架構

AI 文章量產很快。

但快不是唯一目標。

如果沒有 SEO 架構，文章越多，只是初稿越多。

如果沒有技術支撐，文章越長，只是觀念越長。

如果沒有真實場景，文章越完整，也越像空泛顧問文。

所以 AI 內容網站真正要做的，不是讓 AI 一直寫。

而是先設計好：

搜尋意圖 標題鉤子 分類 技術支撐 實例場景 檢查流程 內鏈方向 後續優化節奏

這樣 AI 才是在幫網站建立內容資產。

不是只是在幫網站堆文字。

這次量產翻車很有價值。

因為它提醒我們：

文章很多，不代表 SEO 有價值。

真正有價值的文章，是能回答讀者正在搜尋的問題，也能看出背後真的有做過。

Commit 訊息：

blog: add AI content scale SEO structure article

網址：

https://printapp.uk/blog/ai-content-scale-without-seo-structure/
OK

第 22 篇，分類：內容自動化踩坑
這篇補「已發初稿怎麼做 SEO retrofit」，有實例、有技術路徑、有檢查方式。

檔名：

seo-retrofit-for-ai-draft-articles.md

網址：

https://printapp.uk/blog/seo-retrofit-for-ai-draft-articles/

貼這篇：

---
title: "AI 寫好的文章不一定能直接用：小企業內容網站如何做 SEO Retrofit？"
date: "2026-05-20"
summary: "AI 可以快速產出文章初稿，但初稿不等於 SEO 完成品。這篇用 printapp.uk 的真實量產經驗，整理如何把已發文章重新補上搜尋意圖、標題鉤子、H2 架構、技術支撐、實例場景、內鏈與 CTA。"
code: "AUTO-003"
category: "content-automation"
---

AI 寫文章很快。

幾分鐘內，它可以產出一篇完整文章。  
有標題。  
有摘要。  
有段落。  
有結論。  
甚至可以直接貼進 GitHub 後台，讓 Cloudflare Pages 自動部署上線。  

但這次實際量產後，我們踩到一個很重要的問題：

**AI 寫好的文章，不一定能直接當 SEO 完成品。**

它可能只是初稿。

文章有字數，不代表有搜尋意圖。  
文章有標題，不代表有點擊鉤子。  
文章有段落，不代表有 SEO 架構。  
文章有觀念，不代表有技術支撐。  
文章有結論，不代表能引導讀者下一步。  

所以當 AI 已經寫出一批文章後，下一步不是刪掉重寫。

而是做：

**SEO Retrofit。**

也就是把已經存在的文章，重新補上 SEO 結構、實例場景、技術細節與內鏈方向。

---

## 什麼是 SEO Retrofit？

SEO Retrofit 可以理解成：

**對已經存在的文章做搜尋結構補強。**

它不是整篇重寫。

而是針對文章缺少的部分補強。

例如：

- 標題不夠像搜尋結果，就改標題
- 摘要太像內部說明，就改 summary
- H2 結構太散，就重排段落
- 只有觀念，缺技術支撐，就補實際路徑與檢查方式
- 沒有案例，就加入真實翻車場景
- 沒有內鏈，就補相關文章方向
- 沒有 CTA，就補下一步行動

這很適合 AI 文章量產後的第二階段。

因為第一階段先建立內容規模。  
第二階段再把內容變成真正有搜尋價值的文章。

---

## 為什麼不直接重寫？

很多人看到 AI 文章不夠好，第一反應是：

「那就重寫。」

但這不一定划算。

因為已經寫好的文章裡，通常還是有可用內容。

可能只是：

- 標題不夠好
- 架構不夠 SEO
- 技術細節不夠
- 例子不夠真實
- 分類和內鏈還沒補
- 底部沒有引導

如果整篇重寫，就會浪費已經可用的內容。

比較好的做法是：

**保留可用內容，補強缺口。**

這也是內容自動化很重要的觀念：

AI 產出的第一版，不一定要一次到位。

但後續要有修正流程。

---

## 真實場景：我們量產後被 Boss 打槍

這次 printapp.uk 量產文章時，前面幾篇發得很快。

文章放在：

```text
src/content/blog/

每篇都是 Markdown 檔案。

例如：

ai-content-scale-without-seo-structure.md
small-business-ai-adoption-precheck.md
shared-accounts-create-ai-risk.md

文章 frontmatter 格式像這樣：

---
title: "文章標題"
date: "2026-05-20"
summary: "文章摘要"
code: "AUTO-003"
category: "content-automation"
---

GitHub 後台貼文後，commit 到 main，Cloudflare Pages 自動部署。

流程很快。

但 Boss 很快指出兩個問題：

標題不符合鉤子，內文沒有 SEO 架構。

接著又補一句：

太偏理論，缺技術支撐。

這兩句就是 SEO Retrofit 的起點。

因為問題不是文章不能看，而是文章還沒變成真正能打搜尋的內容。

第一步：先補搜尋意圖

每篇文章都要先問：

讀者為什麼會搜尋這篇？

如果回答不出來，文章就容易變成內部筆記。

例如一篇文章叫：

小企業工具越用越多，問題不是工具不夠，而是沒有人整理

這個標題有觀點，但搜尋意圖不夠明確。

讀者可能真正搜尋的是：

小企業工具太多怎麼整理
公司帳號太多怎麼管理
AI 導入前要整理哪些工具
小企業資料分散怎麼辦
共用帳號有什麼風險

所以 Retrofit 時，要先補：

搜尋意圖：
小企業主發現公司工具、帳號、資料、AI 工具越來越多，想知道怎麼整理，避免導入 AI 後更混亂。

有了搜尋意圖，文章才知道要回答誰的問題。

第二步：重寫標題鉤子

SEO 標題不只是好看。

它要同時做到三件事：

對應主關鍵字
點出痛點
讓讀者知道看完會得到什麼

例如原本標題：

共用帳號不是省事：小企業導入 AI 前，先整理誰能登入、誰能發布、誰能刪除

可以改成：

小企業導入 AI 前，為什麼要先整理共用帳號與後台權限？

更有鉤子的版本：

小企業 AI 導入最容易忽略的風險：共用帳號、後台權限與誰能發布

這樣讀者比較容易判斷：

這篇是在講 AI 導入前的帳號權限風險。

而不是一般管理觀念。

第三步：重排 H2 架構

AI 初稿常常段落很多，但 H2 不一定有策略。

SEO Retrofit 時，要把 H2 改成能帶讀者一路走下去。

例如「共用帳號風險」這篇，可以重排成：

## 為什麼共用帳號會變成 AI 導入風險？
## 小企業常見的 5 種共用帳號場景
## AI agent 拿到共用帳號後，可能造成哪些問題？
## 導入 AI 前要先整理哪些權限？
## 共用帳號整理檢查表
## 實際技術檢查：GitHub、Cloudflare、WordPress 權限要怎麼分？
## 結語：AI 導入前，先把權限邊界整理清楚

這樣 H2 就不是隨機段落。

而是一條搜尋回答路徑。

讀者從問題、場景、風險、檢查、實作一路讀到結論。

第四步：補技術支撐

這次最重要的修正是：

不能只寫觀念。

例如寫「要整理權限」不夠。

要補：

哪些系統有權限
哪些欄位要檢查
哪些操作會觸發部署
哪些檔案會影響文章
哪些指令可以驗證
出錯怎麼回滾

以 printapp.uk 為例，文章不是放在 WordPress。

文章放在 GitHub repo：

src/content/blog/

每篇文章用 frontmatter 管理：

title: "文章標題"
date: "2026-05-20"
summary: "文章摘要"
code: "AUTO-003"
category: "content-automation"

如果 category 缺少或錯誤，文章分類 badge 可能顯示不對。

如果 commit 到 main，Cloudflare Pages 會自動部署。

如果要驗證，可以檢查公開網址：

https://printapp.uk/blog/seo-retrofit
https://printapp.uk/blog/ai-content-scale-without-seo-structure/
這篇文章截斷

[CHATGPT GOVERNANCE]

確認，這篇真的截斷了。
公開頁面只顯示到：

網站是 Astro 靜態網站，文章放在：src/content/blog/

後面就直接進頁尾，代表文章 Markdown 檔案本身在那裡中斷，不是快取問題。

先不要繼續發新文，先修這篇。

修法

到 GitHub：

src/content/blog/ai-content-scale-without-seo-structure.md

點右上角鉛筆 Edit this file。

找到最後一行附近：

src/content/blog/

在它下面補上這段：

每篇文章用 frontmatter 管理：

```yaml
---
title: "文章標題"
date: "2026-05-20"
summary: "文章摘要"
code: "AUTO-002"
category: "content-automation"
---

如果 category 缺少或錯誤，文章分類 badge 可能顯示不對。

如果 commit 到 main，Cloudflare Pages 會自動部署。

如果要驗證，可以檢查公開網址：

https://printapp.uk/blog/ai-content-scale-without-seo-structure/

也可以用本機檢查：

npm run build
git status --short
curl -I https://printapp.uk/blog/ai-content-scale-without-seo-structure/

這些技術細節放進文章，讀者才會知道這不是空泛的 AI 內容建議，而是真的從網站實作流程中整理出來的經驗。

真實場景：content badge 顯示錯誤

這次還有一個很好的實例。

文章上線後，頁面上方一開始顯示英文：

content

看起來只是小問題，但追下去才發現是資料結構問題。

原本網站用 code 去推分類。

例如：

code: "AI-SEC-001"

但 code 應該是文章編號，不應該拿來當分類。

後來修正成：

code: "AI-SEC-001"
category: "ai-safety"

模板也改成讀 category，再對照中文顯示：

ai-safety → AI 安全治理
ai-governance → AI 協作治理與風險控管
content-automation → 內容自動化踩坑

這就是技術支撐。

不是只說「分類要整理」，而是說清楚：

哪個欄位用錯
哪個模板讀錯
怎麼修
修完怎麼驗證
為什麼以後不會再顯示 content

這種實例比空泛講分類重要很多。

真實場景：GitHub 後台貼文很快，但仍要人工確認網址

另一個實例是 GitHub 後台貼文。

流程本身很快：

到 src/content/blog/
新增 .md 檔案
貼上文章
Commit directly to main
等 Cloudflare Pages 自動部署
打開公開網址確認

但這裡也有坑。

Commit 成功，不等於網站已更新。

HTTP 200，也不等於內容正確。

例如文章上線後，仍然要人工確認：

標題是否正常
分類 badge 是否中文
文章內容是否完整
黑底 code block 是否合理
網址是否能開
是否不是快取舊版

所以後來流程固定成：

貼文 → Commit changes → 提供公開網址 → Boss 人工確認 → 再繼續下一篇。

這比只說「發文完成」可靠很多。

真實場景：AI 寫太快，反而忘了 SEO

這次量產翻車的本質，是 AI 寫太快。

文章連續產出時，很容易只注意：

有沒有 frontmatter
有沒有分類
有沒有 commit
有沒有網址
有沒有上線

但忘了文章本身要服務搜尋意圖。

例如一篇「AI 導入前檢查」文章，如果只寫：

要整理資料
要整理流程
要整理權限

這樣太理論。

更好的寫法應該加入場景：

小企業想把 AI 放進文章發文流程。
文章檔案放在 src/content/blog/。
每篇要有 title、summary、code、category。
Boss 用 GitHub 後台 commit 到 main。
Cloudflare Pages 自動部署。
如果 category 缺失，badge 可能顯示錯。
如果 commit 後沒等部署，可能誤判成網站壞了。

這樣文章就有現場感，也有技術支撐。

SEO 文章不只是字數，要有可搜尋的問題

AI 很容易把文章寫長。

但 SEO 不是只有字數。

一篇文章要先對應一個可搜尋問題。

例如：

AI 文章量產有用嗎？
AI 寫文章為什麼沒有 SEO 效果？
小企業怎麼用 AI 做內容網站？
AI 文章要怎麼做 SEO 架構？
Cloudflare Pages 網站沒更新怎麼辦？
GitHub Pages 發文流程怎麼做？

這些都是讀者可能搜尋的問題。

文章應該圍繞這些問題展開。

如果文章只是內部紀錄，搜尋價值就會弱。

所以每篇文章要先有搜尋意圖。

例如這篇的搜尋意圖是：

想用 AI 快速產文章的人，想知道為什麼文章很多卻沒有 SEO 效果，以及要怎麼修正。

這樣內容才會收斂。

以後新文章的標準流程

後續新文章不再直接寫正文。

先做 SEO 架構。

固定格式如下：

分類：
檔名：
主關鍵字：
延伸關鍵字：
搜尋意圖：
標題鉤子：
讀者痛點：
真實場景：
技術支撐：
H2 架構：
內鏈方向：
CTA：

例如：

分類：內容自動化踩坑
主關鍵字：AI 文章量產
搜尋意圖：想用 AI 快速寫文章，但發現流量和品質不如預期
真實場景：Boss 指出量產文章標題沒有鉤子、內文沒有 SEO 架構
技術支撐：frontmatter、category、GitHub、Cloudflare Pages、curl 檢查
CTA：找小陳整理 AI 內容網站發文流程

架構通過後，才寫正文。

這樣比較不會跑偏。

已發文章怎麼辦？

已經發出去的文章不用刪。

它們可以先當作內容初稿庫。

後續要做的是 SEO retrofit，也就是第二階段優化。

優化項目包括：

重寫標題
改 summary
調整 H2/H3 架構
補搜尋意圖
補技術支撐
補實例場景
補內鏈
補 CTA
必要時補圖片

例如：

shared-accounts-create-ai-risk.md

可以補：

共用帳號清點表
AI 專用帳號權限範例
不該貼進聊天的憑證類型
GitHub / WordPress / Cloudflare 權限分層
發布權限與刪除權限的差異

這樣文章會從觀念文變成實用文章。

SEO 架構和技術支撐要一起存在

只有 SEO 架構，容易變成模板文。

只有技術細節，容易變成工程筆記。

這個網站需要的是兩者結合。

讀者是小企業主，不一定想看太深的程式碼。

但他也不想看空泛說法。

所以文章要做到：

小企業主看得懂
有現場問題
有操作線索
有真實案例
有技術支撐
不誇大 AI
不假裝全自動很簡單

這樣才符合網站定位。

這次踩坑留下的規則

這次 AI 文章量產踩坑後，留下幾條規則：

先有 SEO 架構，再寫正文。
標題要對應搜尋意圖，不只是內部筆記。
每篇文章要有主關鍵字與延伸關鍵字。
H2 要有清楚層次，不要只是一路講觀念。
每篇至少放一個真實場景。
每篇至少放一個技術支撐。
已發文章先當初稿庫，後續做 SEO retrofit。
不要只追求文章數量。
GitHub 貼文完成後，要提供公開網址人工確認。
文章要讓小企業主看懂，也要讓懂技術的人看得出是真的做過。

這些規則比繼續硬產文更重要。

結語：AI 可以量產，但不能跳過架構

AI 文章量產很快。

但快不是唯一目標。

如果沒有 SEO 架構，文章越多，只是初稿越多。

如果沒有技術支撐，文章越長，只是觀念越長。

如果沒有真實場景，文章越完整，也越像空泛顧問文。

所以 AI 內容網站真正要做的，不是讓 AI 一直寫。

而是先設計好：

搜尋意圖
標題鉤子
分類
技術支撐
實例場景
檢查流程
內鏈方向
後續優化節奏

這樣 AI 才是在幫網站建立內容資產。

不是只是在幫網站堆文字。

這次量產翻車很有價值。

因為它提醒我們：

文章很多，不代表 SEO 有價值。

真正有價值的文章，是能回答讀者正在搜尋的問題，也能看出背後真的有做過。