把「應該可以」變成
「我驗證過」

一、校網遷移不是「換個網址」

一所學校要從自建舊站搬到共構平台，同時準備無障礙 AA，表面上像是把文章、照片與附件搬過去； 實際上還牽涉內容盤點、網站結構、外部連結、處室資料、圖片替代文字、FreeGo、人工審查、 正式網址切換，以及舊站 HTTPS 的維持。

當專案主要由一位資訊組長維護時，最重要的設計原則不是把頁面做得多華麗， 而是每一步都能被下一個人重做、查證與交接，不依賴某個人的記憶。

二、接手後的第一課：文件先於直覺

交接文件裡最吸引人的通常是「全站通過」或「全部完成」這類結論； 但如果沒有同時寫出掃描網址、日期、範圍與原始報告，就不能判斷那是不是正式站的結果。

準備站和正式站外觀看起來一樣，並不代表即時同步；舊站能開啟，也不代表 HTTPS 憑證、轉址與內容網址都正確。 因此接手時要重新跑關鍵檢查、查 Git 紀錄，再把每一個結論分成可驗證的證據。

三、三個網址，三種身分

四、FreeGo 的轉折：檢測 → 找問題 → 修正 → 重測

本機對比度工具或瀏覽器檢查很適合找線索，但不是官方判定本身。 看到一個色彩數字就全站換色，可能破壞共用主題並製造新的問題；正確做法是先確認實際渲染結果與影響範圍。

正式 FreeGo 檢測時，先輸入正式新站網址，選全網站與 AA，並保存掃描日期、頁數、逾時頁面、 違規代碼與排除條件。修正後要用同一個正式網址重新測，才能比較前後結果。

五、從自動檢測走到正式送審

自我評量不要照抄別校答案。應依正式新站的實際頁面，逐項確認 PDF 是否能選取文字、鍵盤操作、 跳至主內容、圖片／輪播、表單標籤、驗證與響應式呈現，再填入審查員能重現的位置。

送出後看到「待指派」時，代表案件進入等待官方分案或審查的階段； 它不是「送出失敗」，也不是「標章已核發」。案件畫面、送出日期與官方通知都應保存為證據。

五之一、收到結果後：限期改善、符合與標章揭示

官方審查不是只有「送出」與「通過」兩種畫面。若收到限期改善，應以通知列出的網址與問題為準， 先修正同類型的全站共用問題，再在期限內回覆修正情形；不要只改被抽到的那一頁。

收到「符合」通知後，才是正式核發標章的時間。此時請分清兩個官方連結： Detail 是公開標章應連往的專屬標章頁；DetectLog 是檢測歷程與校內維護證據， 適合留在交接文件、修正紀錄與日後重測對照表。

1. 將官方標章圖檔放到你校可維護的位置。
2. 在正式網站的穩定位置（通常是頁尾）加入標章、替代文字與專屬 Detail 連結。
3. 以一般訪客身分確認圖片、連結、鍵盤焦點與替代文字都能正常使用。
4. 保存核發通知、Detail、DetectLog、修正內容與驗證日期；公開教材只放流程，不放案件編號。

有些共構平台會在申請統計頁直接顯示 AA。那是平台的狀態紀錄，不等於它已替你把標章嵌入校網； 真正公開頁尾仍須由你校依核發通知完成揭示並驗證。

六、舊站 HTTPS 是獨立工作線

如果舊站要保留，HTTPS 應拆成另一張工作清單：先確認 DNS 解析，再查 CAA／DNSSEC、 ACME 驗證、網頁伺服器的主機名設定、現有憑證與公開 TLS 回應。

遇到 DNS SERVFAIL 時，不要只是不斷重試憑證申請；先用多個公開 DNS 查詢確認權威解析， 再依序排除 DNS、CAA、伺服器設定與憑證部署問題。最後要用公開請求驗證 HTTP 轉址、HTTPS 狀態、 subject、issuer、SAN 與有效期限。

七、給其他學校的十個可複製原則

1. 先讀規範再碰網站。先找出不可自行決定的事項。
2. 正式站、準備站、舊站分開命名。外觀相同不代表同步。
3. 每個數字附來源、網址與日期。沒有證據的「全過」不能放進交接。
4. FreeGo 不等於標章。自動檢測、人工審查、核發是三階段。
5. 色彩警示先分類。先看實際畫面，再決定是否改。
6. 先修共用問題。一個共用元件可能影響大量頁面。
7. AA 與 HTTPS 分線。新站無障礙和舊站安全性各自驗證。
8. DNS 問題先查權威解析。不要盲目重試 ACME。
9. 每次修改留下回復方式。報告、指令、commit 與實測回應都要可追溯。
10. 公開分享前做去識別化掃描。不要發布校名、網域、個資、帳密或案件編號。

八、如何把這份教材套到你的學校

先複製線上操作台的 12 步驟，建立校內版證據表；再把三個網址、FreeGo 報告、 自我評量畫面、修正 commit 與官方通知填進去。公開版只保留流程與格式，校內版才保存真實資料。

遇到問題時，不要只寫「失敗」：請記下網址、時間、瀏覽器／工具版本、輸入條件、 實際錯誤文字、已嘗試的修正與下一步。下一位資訊組長才能從同一個現象繼續，而不是重新猜一次。