AI 生成程式碼本身不是排名問題；未審查的路由、語意標記、canonical、狀態碼、渲染與效能錯誤才是風險。把 AI 產出當成需要 code review 的草稿，而不是可直接上線的成品。
最常見的問題不是某個模型寫了程式，而是一次生成大量相似頁、把按鈕當連結、讓正文只存在瀏覽器狀態，或在模板裡錯放 noindex。
先看哪些訊號，再決定怎麼處理
| 檢查訊號 | 代表什麼 | 下一步 |
|---|---|---|
| H1、正文只在 hydration 後出現 | 初始 HTML 不完整 | 改成 SSR 或預先渲染 |
| 每個篩選組合都有 URL | 可能製造大量近似頁 | 限制路由並統一 canonical |
| 導覽使用 onclick，沒有 href | 搜尋系統難以發現下層頁 | 改成可抓取連結 |
操作示例
操作示例：在 AI 產生頁面後，固定跑四項檢查：curl 原始 HTML、關閉 JavaScript、抓 canonical／robots、掃描站內 URL 數量。任何一項異常都不進 production。
最容易誤判的地方
- 認為只要 Lighthouse 分數高就沒有 SEO 問題
- 用生成速度當成頁面品質與索引價值
適用與不適用情境
適合用在
適合使用 AI 建站工具、程式助理或大量產頁管線的團隊。
不適合直接套用
如果網站內容本身沒有明確需求，程式碼再乾淨也不會自動變成有價值的頁面。
接下來怎麼做
- 把 SEO invariant 寫進 code review 清單
- 針對模板抽樣檢查原始 HTML 與 URL
- 限制自動產頁並保留人工發布 gate
先照這個順序拆
- 先問這題對應的是需求、結構、技術還是信任。
- 再問它該落在母頁、問題頁還是辭典頁。
- 先補訊號一致性，再考慮放大規模。
- 最後才追求工具或戰術層面的優化。
這題通常不是表面看到的那一種問題
- 很多 SEO 問題沒有單一標準答案，先拆上下文才有判斷空間。
- 技巧本身不是重點，重點是它解的是哪一層問題。
先判斷這是需求判讀、頁面結構還是權威信任問題，再決定對應的處理層級。多數方向錯誤源於還沒釐清問題層次就急著套用技巧。
表面問的是單一技巧怎麼做，實際要解的是：在有限資源下，我該優先處理哪一層問題才不會白做工。關鍵在於先定位問題類型，再選對應的頁面角色與解法。
怎麼做比較穩
- 先把問題定位到正確層次。
- 回到既有母頁與辭典結構確認落點。
- 用小範圍頁面改動先驗證。
要避開的做法
- 不要只抄別人的技巧而不看自己的頁面條件。
- 不要把不同層次問題混成一個待辦。
- 不要一開始就用規模化方法解還沒定義清楚的問題。
社群裡常見的問題點
- 社群常直接給技巧，卻沒先確認問題層次
- 不同網站答案差異大，關鍵在成熟度與資源不同
- 有價值的回覆會先把問題拆回更底層判斷