AO2 GUIDE 11 · 搜尋與量測
結構化資料實作先整理一致的名稱、規格與服務範圍，再用 Schema 描述頁面。從真實內容選類型、核對欄位、驗證輸出並安排維護。
這份指南分清楚企業資料結構與網頁標記的關係，並用品牌商的情境說明如何選類型、整理來源、安排測試與持續更新。它是一套工作方法，實際支援的搜尋功能與欄位要求，仍應以各平台當時的官方文件為準。
結構化資料實作：先分清楚：資料結構與網站標記
企業內部的結構化資料，可以理解為有明確欄位與定義的資訊。例如產品編號、名稱、尺寸、適用環境、版本、核准人與更新日期。這些欄位讓不同部門知道同一份資料代表什麼，也讓後續網站、文件與系統更容易共用。
網站上的結構化資料標記，則是依約定的詞彙與格式，描述頁面中的實體與內容關係。Schema.org 提供常用詞彙；Google 文件說明其搜尋功能支援的類型與要求。兩者相關，但不能把「有 Schema 類型」直接當成「Google 一定會提供對應展示」。
企業知識庫與公開網站也不是同一個範圍。內部資料可能含有測試中數字、專案條件或機密資訊，不能因為已整理成欄位，就自動公開。先訂可公開範圍與核准流程，可參考 企業知識庫整理服務 的資料整理方向。
從一個真實頁面開始，決定要描述什麼
不要一開始就問網站能加幾種 Schema。先挑一個重要頁面，確認它主要是在介紹公司、提供文章、展示產品，還是說明服務。頁面任務清楚，才有辦法選擇合適的類型，並檢查標記是否反映讀者真正看得到的內容。
例如一篇技術文章，可以描述文章名稱、作者或發布資訊；產品頁則可能需要描述產品本身及相關公開資訊。不要把文章硬標成商品，也不要因為頁面出現數個問題，就假設一定會得到搜尋問答展示。結構化資料的用途，應建立在內容的實際性質上。
若產品頁本身還缺用途、規格或限制，可以先閱讀 產品頁內容規劃指南。標記無法替可見內容補上選型依據，完整的頁面才是後續資料描述的基礎。
建立欄位對照表，讓每個值都有來源
選定頁面後，建立一張簡單對照表：要公開什麼、資料從哪裡來、頁面顯示在哪裡、誰負責核准、何時需要更新。這一步能讓行銷、PM 與網站人員針對同一份事實討論，而不是各自猜測欄位的意思。
| 欄位 | 應確認的內容 | 常見問題 |
|---|---|---|
| 名稱與識別 | 正式名稱、型號及穩定編號 | 網頁與型錄使用不同名稱 |
| 規格與範圍 | 單位、條件與適用版本 | 只留下數值，缺少前提 |
| 文件與來源 | 核准文件、版本及負責人 | 無法確認哪份資料最新 |
| 公開狀態 | 可公開、待核准或僅限內部 | 測試資料被當成正式承諾 |
遇到缺少資料時，請明確標記待補，不要用看似合理的預設值填滿欄位。尤其價格、供應狀態與評分，會直接影響讀者理解。需要個案詢價的產品，也不能用零元代替未知價格；零元會表達另一種不同的商業事實。
JSON-LD 是格式，不是自動正確的保證
Google 支援多種標記格式，並通常建議在適合的網站環境使用 JSON-LD，因為較容易維護。對內容團隊而言，不必每個人都會手寫程式碼，但需要知道標記由哪個系統產生、使用哪份資料，以及改動內容後是否會同步更新。
使用外掛、主題或客製程式時，先確認各自負責的範圍。若兩個工具同時輸出產品資料，可能出現不同名稱、網址或價格。重點不是看到多段程式碼就全部刪除，而是確認它們是否在描述同一實體、是否互相衝突，以及哪個來源應該被保留。
網站人員可以留下一份設定紀錄，寫明模板、資料欄位、輸出位置與測試頁面。這份紀錄也應包含回復方式，讓外掛或版型更新之後，團隊知道要檢查什麼。需要處理模板與資料來源時，可將 WordPress 網站整合 與內容整理一起安排。
可見內容、標記內容與搜尋資格要分開驗收
第一層是事實：名稱、規格與條件是否正確。第二層是呈現：使用者能否在頁面讀到相關內容。第三層是語法與功能要求：標記是否能被解析，是否符合所選搜尋功能的規範。這三層都需要檢查，不能只看測試工具顯示綠燈。
Google 的一般規範要求標記符合頁面內容，也明確說明正確標記不保證複合式搜尋結果。像 Product 功能有自己的條件，不是每一個企業產品頁都具備相同資格。缺少真實資料時，應調整預期與實作範圍，而不是捏造評分、評論或交易資訊。
可以用兩個問題協助判斷：若客戶只看頁面，是否會得到與標記相同的理解？若 PM 看到輸出的值，是否願意確認它代表目前產品？只要有一題答不出來，就回到來源與公開內容修正。漂亮的搜尋預覽，不能取代內容核准。
用小範圍上線，避免整站一起放大錯誤
先挑少數代表頁面測試，包括一般文章、核心產品與有特殊條件的頁面。使用 Schema 驗證工具檢查基本結構，再依需要的 Google 搜尋功能使用 Rich Results Test。測試工具回答的問題不同，沒有某一種搜尋展示資格，不代表企業資料整理完全沒有用途。
接著檢查實際公開網址，而不只測貼上的程式碼。快取、外掛或模板差異，都可能讓線上輸出與本機測試不同。網站若正在施工並保留 noindex，測試與上線搜尋的預期也應分開處理；未正式開放之前，不應把未出現在搜尋結果視為內容失敗。
正式開放後，再依可取得的搜尋報表檢查錯誤與展示情況。修正時記錄影響範圍、原因與回查日期。完整網站檢查可以接著參考 SEO 健檢與改善順序，把資料問題放回整體網站優先順序判斷。
產品一更新，相關資料就應一起回查
結構化資料不是一次安裝後就完成。產品改版、名稱變更、文件更新、價格調整或頁面合併，都可能影響標記。建議把網站內容、標記與內部主資料列入同一張更新清單，指定負責人，避免只改可見文字卻留下舊資料。
例如某型號新增了可選配件，團隊應確認哪些資訊是標配、哪些是選配，以及哪些舊內容容易誤解。更新時，先核准主資料，再調整網站與文件，最後檢查線上呈現。這樣的流程也能支持後續多語內容與問答系統，減少不同管道各說各話。
對 AO2 而言，企業大腦的基礎就是這些可以追溯、能更新的資料關係。Schema 是對外描述的一個環節，不能取代內部知識整理。若要串接內容產生與系統同步，可以在流程穩定後，再評估 自動化流程整合，並保留必要的核准節點。
用一次版本變更，測試這套資料流程是否真的成立
可以挑一個常見的變動情境做演練：某項產品更新了適用範圍，原本網站、型錄與問答都需要調整。先由產品負責人指出核准來源，再確認哪些欄位受影響、哪些頁面引用了它，以及誰負責更新。若團隊找不到引用位置，就代表資料仍需要更清楚的對照關係。
更新後，請分別檢查使用者看到的文字、下載文件與網站標記。若其中一處仍使用舊版本，不要只修正眼前畫面，應追查它的資料來源。可能是手動輸入、快取未更新，也可能是另一個工具仍在輸出舊值。原因不同，處理方式也不同。
這次演練還應確認回復方式。若新的來源被發現有誤，團隊是否知道先前版本在哪裡、哪些內容需要暫停使用，以及如何重新核准。保留歷史紀錄的用途，是讓資料異動可以追溯，不是讓所有舊版本同時對外流通。
當一個產品的更新可以被完整追蹤，再擴展到更多產品與市場。這樣建立的資料結構，才有機會支撐長期內容與系統整合；只把欄位填滿，卻不知道變更後誰來維護，仍然容易回到各部門各自保存答案的狀態。
常見問題
加上 Schema，就能保證被 AI 搜尋引用嗎？
不能。Google 的 AI 搜尋說明沒有要求特殊 Schema 才能參與；先確保頁面符合適用的檢索、索引與摘要資格，內容有可靠來源且可閱讀。Schema 用來準確描述可見資訊，驗收時核對名稱、網址、類型與問答一致，不加入隱藏主張。外部 AI 是否引用需另保存實際提問與來源紀錄。標記解析成功與外掛分數都不能作為被引用的證明。 延伸閱讀：GEO、AEO 與 SEO 指南。
已經有 SEO 外掛，還需要人工檢查嗎？
需要。外掛能產生格式，不能確認產品事實或來源有效性。先抽查核心產品、不同模板與更新頁，對照可見標題、Meta、canonical、robots、圖片 ALT 及 JSON-LD；再核對主張、版本和公開範圍。若有多個外掛或自訂碼，檢查是否重複輸出 FAQPage 或互相矛盾。每次內容變更後重驗受影響範圍，不必為了綠燈反覆修改無關欄位。
小公司應該先從哪裡開始？
先選一個核心產品或服務，建立名稱、用途、條件、來源、版本與負責人清單，再讓頁面回答一組真實問題。確認內容可閱讀、內部入口清楚，才加入適合的 Schema 並驗證輸出。用一次規格修改測試主檔、正文和標記能否同步，再擴大。測試站維持既定索引政策，不因標記完成就自行公開；先完成可維護的循環，比一次套滿全站更容易驗收。
參考資料
本文由 AO2 獨立編寫，參考相關主題與官方文件；文中的工作情境、清單及試行安排為方法示例。平台功能與規範請以官方最新文件為準。
