AI 把首頁、聯絡表單和手機版一起生成出來，瀏覽器也能正常打開，是否就可以換上正式網域？先不要只看完成畫面。對一個要接收詢問的網站，最重要的是：客人送出的資料去了哪裡、失敗時會看到甚麼，以及手機上能否走完同一個流程。
下面以一個假想的服務介紹網站為例。它只有首頁和聯絡表單，沒有付款或會員功能。若你的網站有訂單、付費或私人資料，還要另驗權限與交易流程，不能用這份小站檢查代替。
先分清「畫面有反應」與「資料已收到」
點擊送出後跳出成功訊息，可能只是 JavaScript 改了幾個字。請開啟瀏覽器開發者工具的 Network，清空紀錄後送一筆明確標示為測試的資料，核對請求網址、方法、回應狀態與內容，再到自己管理的收件端找同一筆資料。不要把客戶真實姓名、電話或信件當作測試素材。
如果表單根本沒有送出請求，先問 AI：「這個按鈕只是展示，還是已接到真正的服務？請指出接收端與成功判斷。」若有請求但回應內容表示失敗，畫面不能仍然顯示成功。HTTP 200 也不一定代表收件完成，須依這個服務的回應格式及實際結果判斷。
拿四種輸入走一次表單
| 測試方式 | 應該核對的結果 |
|---|---|
| 必填欄位留空 | 指出需要填寫的欄位，不把空資料當成功 |
| 電子郵件填成明顯錯誤格式 | 提示格式問題；格式通過也不代表信箱存在 |
| 送出一筆合法測試資料 | 畫面結果與真正收件端一致，沒有重複建立 |
| 在隔離環境讓接收端失敗 | 顯示可理解的錯誤，保留可重試的輸入，不假報成功 |
HTML 的 required、type="email" 可以提供瀏覽器端檢查，但不是伺服器安全邊界。接收端仍須驗證輸入。測試錯誤情況時，使用自己的測試端點或模擬回應，不要故意令正式服務故障。
本文另用隔離的小表單實際跑過空值、錯誤格式、合法格式，以及模擬成功／失敗訊息。空值和錯誤格式未通過原生驗證；合法格式通過後，兩種模擬結果分別顯示。這個例子沒有寄信或寫入資料庫，正好說明：即使畫面測試全部通過，仍不能代替真正收件端的確認。
手機版要從開頁測到送出
不要只縮窄桌面視窗看第一屏。用手機模擬模式開啟頁面，確認 viewport、導覽、表單、錯誤訊息與頁尾都能讀取，並實際點擊欄位和按鈕。本文的隔離例子在 1280 與 390 像素視窗核對，沒有整頁橫向溢出；這不是所有手機都通過的證明。
常見問題是圖片或容器用了固定寬度，長網址和表格把頁面撐開，或者固定在底部的按鈕蓋住輸入欄。可以請 AI 針對出問題的元件修正，而不是直接把全站設成隱藏橫向捲動。後者可能只把看不到的內容藏起來。
若有實體手機，再檢查鍵盤彈出後是否擋住送出按鈕、選單是否容易關閉，以及直向與橫向切換。模擬器方便重現尺寸，不能完全替代真機操作。
SEO 先排除測試環境留下的設定
正式網域上線前，逐頁核對標題、主要標題、主要連結及實際顯示的內容。常見遺漏是仍保留測試站名稱、範例文字，或導覽連到 localhost、預覽網域和不存在的頁面。這些問題可以先在瀏覽器逐項確認，不必等搜尋結果反映。
希望被搜尋收錄的頁面，不應意外帶著測試用的 noindex。除了 HTML 的 robots meta，也要查回應標頭的 X-Robots-Tag。若原本就是私人或不希望收錄的頁面，應保留相應限制，不是全站一律移除。
robots.txt 的禁止抓取與 noindex 不是同一件事。Google 必須能抓到頁面，才看得到頁面上的 noindex 指示。也不要把 noindex 當作保護私人資料的方法，私人內容應靠登入與權限限制。
有設定 canonical 的頁面，確認它指向你選定的正式網址，而非測試站或無關首頁。Canonical 是協助搜尋引擎選擇代表網址的訊號，不能保證 Google 一定採用。上線後可再用 Search Console 檢查實際抓取與索引狀態，頁面打開並不代表已收錄或會獲得排名。
把問題交回 AI 時，附上可重現的步驟
例如：「在 390 像素手機模式，打開聯絡頁，填合法測試信箱後送出；測試接收端回傳失敗，但畫面顯示成功。請只修正成功判斷與錯誤提示，不改版型及接收端網址。修正後用相同輸入重新測成功和失敗兩種情況。」
每次修改後，都重新走過原本失敗的步驟，再檢查原本正常的流程。準備上線時保留上一版與回復方法，記錄這次改了哪些檔案。先讓少量實際使用者走完主要功能，比只看一張漂亮的完成截圖更能發現問題。
封面為 AI 生成的概念插圖。文中的表單為隔離示例，不代表任何正式網站或第三方服務已通過測試。
