前面幾天，我們把 AI 接進訊息平台、財務報表與社群雷達。這些自動化解決的是「每天要做什麼」；但如果自家網站本身沒有持續改善，流量、詢問與轉換仍然會停在原地。

今天談一個我在 ZoneTech 實作中的做法：把網站優化拆成兩層循環，讓 AI 不只產生一份 SEO 建議，而是持續追蹤、提出問題、執行修改、再用真實資料評分。

網站優化不是一次性的文章生成

最容易踩的坑，是把「找幾篇熱門文章、整理關鍵字、請模型寫一篇文章」誤認為 SEO 系統。這條流程可以產生內容，卻沒有回答三個工程問題：

1. 這個問題是否真的存在於我們的網站？
2. 修改後是否改善了搜尋與轉換結果？
3. 如果結果變差，誰負責發現並回滾？

所以我把流程分成兩個迴圈。

外層迴圈：策略與問題定義

外層先讀取 Google Search Console（GSC）與 Google Analytics 4（GA4）的實際數據，再對照 zonetech.tw 的頁面。它要找的不是抽象趨勢，而是網站目前的落差，例如：

外層的輸出不是「請寫一篇文章」，而是一個可驗證的 Issue：目標頁面、問題證據、預期指標、修改範圍、風險與驗收日期。

內層迴圈：執行與品質評分

內層由多個 Worker 分工。有人負責搜尋意圖，有人檢查內容結構，有人檢查 GEO/AEO 可讀性，也有人只負責挑錯。最後由 Picky 評分器統一檢查，避免產出者自己判定自己成功。

這裡的重點不是模型數量，而是角色邊界。每個 Worker 都應該收到明確輸入，產出固定格式，並且不能越權修改正式網站。修改先落在草稿或 Issue，通過人工或規則驗證後才發布。

一個 Issue 至少包含：

• 來源：GSC、GA4、網站頁面或客戶問題
• 假設：我們認為哪個因素造成落差
• 變更：要調整哪個頁面、段落、標題或連結
• 指標：曝光、點擊率、排名、轉換或詢問品質
• 時間窗：何時開始、何時重新評估
• 回滾：結果變差時如何恢復

為什麼一定要對照真實網站

我曾經遇過分析報告看起來很完整，列了大量熱門主題與建議標題，但真正打開 zonetech.tw 後，才發現報告假設的頁面不存在，或網站早已經有相近內容。這種報告文字正確，決策卻是錯的。

因此流程中把「讀取網站現況」放在研究之後、提案之前。每個建議都要標示：已確認的頁面、尚未找到的頁面、推測的搜尋意圖。讀不到正文時就標示缺口，不用模型補造。

GSC、GA4 與網站資料的角色也不同。GSC 告訴我們搜尋曝光與查詢；GA4 告訴我們使用者進站後的行為；網站檢查則確認實際內容、內部連結與可被讀取的頁面。三者不能互相替代。

把評估寫成工程驗收

AI 產出的建議不能用「看起來不錯」驗收。我的驗收分成三層：

第一層是內容品質：標題是否符合搜尋意圖、內容是否有實際答案、是否避免堆砌關鍵字。

第二層是網站一致性：服務名稱、案例、CTA、內部連結是否與網站現況一致，是否誤把草案或不存在的服務寫成事實。

第三層是真實結果：在合理的觀察期間重新讀取 GSC 與 GA4，與修改前的基準比較。短期沒有顯著改善不代表一定失敗，但沒有設定基準，就無法知道自己是否真的做了什麼。

這也是 Bilevel Loop 和單次 Agent 任務的差別。單次任務只需要完成輸出；雙層循環還要產生下一輪問題，讓系統根據結果修正策略。

我會保留哪些證據

每輪優化至少保留四份資料：原始數據快照、研究與網站對照結果、修改前後版本、評估報告。報告附上來源連結與資料日期，避免下週的模型把上週的推測當成新事實。

如果是正式網站，還要記錄發布者、發布時間與回滾方式。這些紀錄看似增加工作，實際上是在降低「不知道哪個修改造成結果」的維運成本。

今天的實際判斷

AI 很適合加速網站優化中的資料整理、差距比對、草稿產生與反向審查；它不適合在沒有證據時自行宣稱排名提升，也不應該直接把未驗證內容發布到正式網站。

ZoneTech 目前採用的方向是：GSC/GA4 追蹤 → 建立 Issue → 多 Worker 分析 → Picky 評分 → 產生草稿 → 驗證後發布 → 重新追蹤。這不是把一個更大的模型丟進 CMS，而是把網站當成一個需要觀測、變更與回饋的產品。

驗證清單

• 是否讀取了最新 GSC、GA4 與網站實際頁面？
• 每個建議是否都有來源與資料日期？
• 是否區分已確認證據、推論與待核准變更？
• 修改前是否留下基準與可回滾版本？
• 發布後是否安排下一次數據讀回，而不是以發布成功當成優化成功？

真正的網站優化，不是讓 AI 每天寫更多文章，而是讓每一輪修改都留下證據，並且讓下一輪比上一輪更接近客戶真正需要的答案。