文章目錄
可以上線，前提是驗收結果符合網站的用途。 AI 參與開發並不自動降低品質，也不免除安全、功能、搜尋和交接的工作。你需要知道誰負責確認，以及怎麼證明重要流程正常。
以下三個問題適用於自己做的原型，也適用於委託廠商開發的網站。
問題一：安全與資料處理怎麼驗證？
先列出網站有哪些入口。單純展示內容的頁面、會收個資的表單、會員後台和付款流程，需要的測試不一樣。
| 功能 | 至少要驗證的情境 | 可留下的證據 |
|---|---|---|
| 聯絡表單 | 無效輸入、重複送出、通知失敗與濫用 | 測試結果、收件與錯誤紀錄 |
| 會員與後台 | 未登入、不同角色、越權存取 | 權限表與失敗測試 |
| 檔案上傳 | 格式、大小、讀取權限與儲存方式 | 限制規格與測試紀錄 |
| 金流與訂單 | 回呼重送、付款失敗、退款與對帳 | 測試訂單及狀態變更紀錄 |
| 第三方 API | 金鑰不在前端、服務逾時與額度耗盡 | 設定說明與例外處理測試 |
可以用 OWASP ASVS協助選定驗證項目。應依風險訂定範圍，而不是把 CAPTCHA、某個 HTTP header 或一次掃描視為完整安全保證。
若蒐集可識別個人的資料，需要核對適用的蒐集、利用與告知規定。本文不以固定罰款數字判斷風險；實際法規與生效狀態應查閱全國法規資料庫，並依業務確認。
問題二：搜尋引擎讀到的是什麼？
不要只看開發環境有沒有設定。請檢查部署後的重要頁面：
- 回傳正確的狀態碼，沒有誤設登入限制或 noindex。
- 標題、主要內容與重要連結可被讀取，canonical 指向正確網址。
- sitemap 包含應公開的頁面，robots 沒有擋到需要的資源。
- 結構化資料與頁面可見內容一致，圖片網址可讀取。
- 多語版本有正確對應；改版時，舊網址有適當的轉址或處理方式。
Google 可以處理 JavaScript，但仍要確認渲染結果與資源可用性。SSR 或 SSG 有助於直接提供內容，卻不是搜尋排名保證。官方 JavaScript SEO 說明解釋了爬取、渲染與索引的關係。
Lighthouse 是自動檢查工具。SEO 100 分不代表排名第一，效能實驗室分數也不等於所有使用者的體驗。上線後要持續查看 Search Console 的索引、查詢與 Core Web Vitals 資料。
Google 的 AI 搜尋指南同樣以可索引性、可靠內容與一般 SEO 基礎為核心，沒有能保證 AI 引用的特殊 schema。
問題三：交接後能不能繼續改？
拿一個實際需求做交接演練，例如新增聯絡表單欄位。請接手者依文件完成啟動、修改、測試與部署，確認通知和後台也同步更新。
需要一起交付的資訊包括：
- 程式與版本紀錄、使用到的授權與依賴套件。
- 開發、測試與正式環境的啟動方式。
- 網域、主機、資料庫及第三方服務的帳號權限。
- 環境變數名稱與安全交付方式，不把秘密寫在公開文件。
- 備份、還原、監控、回復版本與後續維護窗口。
文件是否好用，要由另一個人操作來驗證。不能只靠程式行數、commit 數量或半小時的印象，就決定網站一定得重做。
上線驗收要看結果，不只數勾選格
建議把每個項目記成「情境、預期結果、實際結果、負責人與處理期限」。依影響程度決定哪些必須在上線前處理，哪些可以排進後續改善。
例如表單成功送出但沒有人收到通知，即使其他項目全過，仍會直接影響接案。反過來，沒有會員功能的展示頁，也不需要為不存在的登入流程填滿檢查表。
完整的操作情境可參考〈網站驗收怎麼做〉；維護責任見〈網站上線後真正會出事的地方〉。
常見問題
AI 寫的網站安全嗎？
不能只看程式來源判斷。應依網站的登入、表單、檔案、交易與資料使用情境，驗證權限、輸入處理、金鑰保管及錯誤流程；程式審查和自動掃描都只是驗證的一部分。
AI 寫的網站 SEO 效果如何？
取決於內容品質、可讀取與索引狀態、內部連結及實際頁面體驗。Lighthouse 與結構化資料檢查能找出部分技術問題，但不能保證收錄或排名，也不能代替 Search Console 的觀察。
怎麼確認其他工程師接得手？
請接手者依文件啟動測試環境、完成一個小修改並部署，再演練回復與資料還原。原始碼、服務帳號、必要設定、授權範圍和維護責任都應一起交接。
想確認網站目前還缺哪一段，可以帶著網址和預期用途來討論。
