網址規則先統一，再談索引
問題：舊內容與新頁面共站時，網址尾斜線、canonical 與重新導向若不一致，容易讓搜尋訊號分散，也讓內部連結驗收失真。
決策：全站採同一套 trailing slash 規則，由共用 URL helper 產生 canonical，build 後再檢查所有站內連結。
驗收：2026-08-31 驗收快照：完整 build 的站內連結檢查為 0 個斷裂連結。
先公開內部驗收快照
以下四個數字來自 2026-08-31 的完整 release 驗收，不是持續更新的商業績效；未來新增或移除頁面時，數字也會跟著改變。
- 完整產出的可瀏覽頁面
- 819
- 可在站內搜尋找到的文章
- 748
- 找不到目的地的站內連結
- 0
- 結構化資料語法通過頁面
- 819
判讀方式：頁面必須能被完整產出；站內搜尋必須實際收錄文章；每條站內連結的目的地必須存在；結構化資料必須能被解析。同日較早的 live audit 另涵蓋 500 個 URL 抽樣與 8 條代表性 browser route。這只能證明抽樣當下的回應與頁面行為，不能外推成所有裝置、所有網路或真實訪客的體驗保證。
每個修正都要回答三件事
不只列出做了什麼，也交代為什麼做，以及用什麼方式驗收。
748 篇內容不能只靠站內搜尋被找到
問題：大型內容庫若只提供 JavaScript 篩選，爬蟲與第一次造訪的人都很難理解分類、分頁與內容關係。
決策：保留主題中樞與分類入口，文章目錄改成可爬取分頁，Pagefind 作為搜尋補充，不取代資訊架構。
驗收：2026-08-31 驗收快照：Pagefind 索引 748 篇文章；文章目錄與分類入口可由一般連結抵達。
可用性要進入工程契約
問題：工具有結果不代表結果能被理解；表單藏在折疊區時，原生驗證也可能把使用者留在看不到錯誤的位置。
決策：工具結果使用語意標題與狀態區；表單驗證會先展開所屬步驟，再把焦點移到第一個無效欄位。
驗收：代表性 browser walkthrough 已驗證首頁帶值到免費診斷，且必填錯誤會展開聯絡步驟並聚焦姓名欄位。
量測轉換，但不傳送訪客輸入
問題：只看 pageview 無法知道工具與診斷流程在哪裡流失；直接把網址、姓名或 Email 當事件屬性，又會製造不必要的個資風險。
決策：事件只記錄受控的頁面類型、入口位置與目的地群組，使用者填寫內容不送進分析事件。
驗收：契約測試會拒絕把表單值或工具輸入送入 Plausible，並檢查來源群組在診斷流程中正確承接。
從內容風險到可持續驗收
這不是一次換皮，而是先把可見度風險、資訊架構、使用流程與驗收方式接成同一條工程鏈。
內容與風險盤點
把 748 篇文章、商業頁、工具與表單納入同一份可 build 的站點清單，先處理內容外洩與網址風險。
設計系統重建
以暖紙、墨色與品牌珊瑚建立 editorial 系統，讓長文、服務頁、目錄與工具共享同一組 tokens。
使用流程補齊
重做文章探索、免費工具結果、診斷表單與匿名漏斗量測，讓入口、回饋與下一步能被測試。
獨立驗收與加固
以完整 build、crawl、結構化資料、代表性瀏覽器操作與契約測試找出回歸，再逐項修正。
這個案例還不能證明什麼
透明不只是在有數字時附來源，也是在沒有資料時明確停下來。
目前未知
- Google 實際索引覆蓋、排名與自然搜尋流量變化
- 真實使用者 Core Web Vitals 與跨裝置長期表現
- 免費診斷完成率、有效詢問率與後續營收
需要外部資料才能回答
- Google Search Console、CrUX 與 Analytics 的長期趨勢
- 真實 AI crawler 與 WAF log 的存取狀況
- 客戶成效必須由客戶資料、授權與歸因條件另外驗證
輸入你的網站網址，取得免費 Search & AI Visibility 診斷
3 個工作天內寄出具體問題清單與優先順序，不會推銷、不會有業務打擾。
以可驗證資料為依據 · 不使用黑帽 SEO · 不承諾無法控制的排名或 AI 引用