重設前，先在一個重要頁面完成這 10 項檢查
先選一個服務或產品落地頁，按下表走完整個買家任務。網站速度、內容存取、操作和實際收件各有不同證據，應分項記錄。表格是建議驗收流程，並非對某個網站已完成的審核結果。
例如買家需要查看型號、閱讀規格，再提出報價查詢。即使頁面載入很快，繁體版本缺少規格或結果把未傳送草稿寫成成功，這條路徑仍未完成。
| 檢查項目 | 可重做的方法 | 驗收證據 |
|---|---|---|
| 1. 主要內容 | 比較同一服務或產品的電腦與手機版。 | 服務範圍、限制、規格及重要連結仍可找到。 |
| 2. 頁面主題 | 閱讀標題、主要標題及開首答案。 | 三者清楚說明目前語言的同一服務或產品。 |
| 3. 搜尋存取 | 在 Search Console 查看即時網址及呈現內容。 | 分開記錄存取、索引及 canonical 狀態，與版面檢查區分。 |
| 4. 雙語路徑 | 在落地頁切換英文與繁體中文。 | 進入相同主題，事實一致，並能返回原有路徑。 |
| 5. 導覽 | 開啟及關閉選單，再到下一個相關頁面。 | 連結正常、焦點可見，固定控制項沒有遮住任務。 |
| 6. 閱讀與控制項 | 用長標籤及放大文字測試窄手機畫面。 | 文字可讀，按鈕可操作，標籤不互相遮擋。 |
| 7. 圖片與穩定性 | 觀察首屏、圖片及通知的載入過程。 | 記錄可見位移，預留空間，相關圖片正常載入。 |
| 8. 產品證據 | 查看完整規格表並開啟產品文件。 | 數值對應欄目，文件型號正確，返回路徑正常。 |
| 9. 查詢狀態 | 測試未填資料、修正及實際接收或草稿流程。 | 錯誤後保留輸入，結果準確標示草稿、失敗或接收。 |
| 10. 效能 | 記錄手機實際使用者資料及可重做的實驗室測試。 | 列明來源與限制，修正後重測觀察到的原因。 |
縮小版面時保留必要內容
Google 以手機版本的內容作索引及排名依據，因此桌面與手機應保留相應的主要資訊。手機版可以重新安排閱讀次序，但不宜只為縮短畫面便刪掉服務限制、規格或重要連結。
建立桌面與手機的對照清單，逐項查看交付地區、產品資料、資歷說明、下載文件和查詢提示。長內容可用合適的摺疊區整理，但要測試內容及控制項是否正常。尤其是獨立製作的手機模板，更新後容易與桌面版本出現差異。
要分清「收起內容」與「按下後才載入內容」。摺疊區可以已在呈現的頁面中包含完整答案；首次按下才取回主要答案，是另一種實作。Google 指出主要內容不應依賴使用者操作才載入，應請開發人員示範訪客按下前已有哪些內容。
Google：手機版優先索引（英文） 官方技術參考；本文的裝置對照與驗收任務是編輯建議。
分開檢查繁體中文與英文路徑
英文導覽名稱與繁體中文所需空間不同。不要只用幾個短字測試選單；應放入實際的產品分類、長服務名稱和語言切換項目，確認文字換行合理、選單可關閉，切換語言後仍能找到相應內容。
產品規格表要保留數值與欄目之間的關係。清楚提示可橫向捲動的表格，有時比把文字縮得極細更實用。用資料最完整的產品作測試，並檢查固定 WhatsApp 按鈕會否遮住最後一行或表格錯誤訊息。
語言及下一步連結除了外觀，也要檢查實作。Google 建議使用帶有 href 目的地的連結元素（a），只有程式點擊事件的控制項未必能可靠讀取。標籤應具體說明將開啟的主題或文件，方便買家判斷。
把查詢測試做到收件人一端
按鈕能打開表格，不代表查詢流程已通過。先輸入測試資料、觸發錯誤並修正。W3C 建議使用清楚的錯誤與完成訊息；手機鍵盤彈出時，要確認提示及操作仍可見，並保留已輸入資料。
按網站實際提供的模式驗收。有接收端時，使用已約定及標記的測試資料提交，核對接收系統和收件匣；只準備電郵草稿時，則核對產品資料及在電郵程式自行傳送的提示。準備草稿不能證明已送達，未核對收件的一項應記為尚未驗證。
若主要聯絡方法依賴另一個應用程式，宜考慮實際受眾需要的替代途徑。海外買家未必使用 WhatsApp，電郵可能更適合傳送規格。分析時亦要分清「按下聯絡按鈕」與「收到有效查詢」，兩者不能當成同一項成果。
W3C WAI：表格錯誤與完成通知（英文） 錯誤與完成回饋的技術參考；提示文字本身不能驗證送達。
本工作室的實際檢查
手機詢盤流程，逐步檢查
從產品規格、資料連結到詢盤草稿，查看香港繁體貿易頁本地預覽的實際畫面。
- 單欄佈局390 px 視口下，沒有整頁橫向溢出。
- 至少 46 px所檢查的欄位及操作按鈕均達到這個高度。
- 型號一致ZQ-DEMO-02 保留在資料連結及 RFQ 草稿中。
- 僅準備草稿數量 500、目的地香港；沒有傳送查詢。
這次檢查的範圍
畫面、表單及草稿均使用繁體中文，擷取時的瀏覽器視口為 390 × 844 px。這是瀏覽器響應式檢查，並非實體手機或 Core Web Vitals 評分；此次沒有驗證收件服務、實體手機鍵盤或其他視口。
原先的文章只有建議檢查表。本次加入可操作示例、單欄佈局與以上觀察，讓讀者可以重現檢查；沒有可比較的改版前手機量測，因此不宣稱速度、CLS 或轉化率提升。
在有搜尋曝光的頁面量測 Core Web Vitals
先用 Search Console 找需要調查的 Core Web Vitals 群組，再以 PageSpeed Insights 查看落地頁。良好門檻為 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，按手機與電腦分開評估第 75 百分位。缺少實際使用者評估，是證據不足，不能記為通過或不合格。
把實際使用者資料與實驗室測試分成兩行，記錄前者屬於此網址還是整個來源網站、資料期間及是否有足夠樣本。實驗室則記錄網址、日期、工具、模擬裝置與網絡設定。本地預覽或一次電腦版 Lighthouse，不能證明線上手機使用者的體驗。
根據診斷調查主圖、互動延遲或載入通知等實際原因。修正後用相同設定重測，說明改動；待實際使用者資料涵蓋新版本後再核對。Lighthouse 效能分數不能當成 INP 量測或搜尋排名結果。
web.dev：Core Web Vitals 指標與門檻（英文） 官方門檻參考；本地和實驗室觀察應與實際使用者資料分開標示。
手機 SEO 對 AI 搜尋答案有甚麼幫助？
Google AI Overviews 與 AI Mode 的支援連結，須來自已建立索引並可顯示搜尋摘要的頁面。Google 說明無需特殊 AI 檔案或結構化資料標記。這是 Google 的條件，不能代表每個答案引擎，也不保證獲選。
實際做法是在手機頁面以文字清楚列出服務、限制、產品事實和可核對來源。在問題旁先寫簡短答案，再提供驗證答案所需的細節。這是方便讀者理解的編輯改善，不應當成保證取得 AI 引用的公式。
本檢查表以 GEO 指生成式答案的可見度，AEO 指對客戶問題提供有用答案。可重現的引用、搜尋訪問及已接收查詢，應分開量度。觀察引用時記錄引擎、問題、語言及日期；一次回答是觀察結果，不是穩定排名。
Google：AI 搜尋功能與網站（英文） Google 搜尋 AI 功能的官方資格與技術說明；其他引擎有各自政策。
將問題寫成可驗收的修改單
把一個問題寫成一行：網址、語言、裝置或視口、買家任務、目前結果、預期結果、負責人。例如「390 px 英文 RFQ 的錯誤訊息被固定按鈕遮住」，比「手機版不好用」更容易驗收。
修正後重做同一任務，保留截圖或錄影。將內容與操作修正、效能量測及實際收件分開記錄。先用上面的十項表決定需要哪些證據，再把未完成項目放進修改簡介。
資料來源與適用範圍
- Google：手機版優先索引（英文）developers.google.com
支持手機內容及依賴操作才載入的技術說明；十項任務驗收屬編輯建議。
- Google：Core Web Vitals 與搜尋結果（英文）developers.google.com
說明與搜尋的關係；良好指標不能保證前列排名。
- web.dev：Core Web Vitals 指標與門檻（英文）web.dev
現行良好門檻，以及手機與電腦第 75 百分位評估的依據。
- Google：AI 搜尋功能與網站（英文）developers.google.com
支持 Google AI Overviews 及 AI Mode 資格說明；不承諾引用或流量結果。
- Google：可擷取連結與連結文字（英文）developers.google.com
可讀取 href 連結的參考；語言及下一步連結應通往預期主題。
- W3C WAI：表格錯誤與完成通知（英文）w3.org
支持清楚的表格錯誤與完成回饋；送達須另行核對。