網站結構化資料怎麼驗？從頁面內容到測試結果逐項核對

沿著六個核對步驟檢查結構化資料：選對頁面類型、比對可見欄位、確認格式與真實性，保存錯誤證據並在修改後重測樣本。

結構化資料的檢查，不是看程式碼能否通過工具就結束；真正要確認的是標記描述的主體、欄位和值，是否和訪客看見的頁面一致。以下依序從頁面類型、可見內容、格式、誤標、錯誤紀錄與重測樣本，整理成可交接的核對流程。採用本文流程時，先留存樣本，再按差異分派，最後用相同網址和同模板頁面驗收。

選定適用頁面類型

先選定一個網址，記下它的主要用途、讀者能完成的任務，以及頁面目前呈現的主體。結構化資料是替頁面內容加上明確描述，類型要跟主體相符；不能因為某個標記能被測試工具辨識，就把它套在所有頁面。文章頁可以先比對文章主體與作者資訊，商品頁要看頁面是否真的在介紹可購買的商品，活動頁則要確認可見內容確實是在說明一場活動。

實作前先查看搜尋平台對該類型的文件，分清楚「Schema.org 有這個類型」、「Google 能解析」和「符合某種搜尋外觀資格」是不同層次。Google 的 Rich Results Test 檢查可產生哪些 Google 搜尋豐富結果；Schema Markup Validator 則檢查較廣泛的 Schema.org 標記，兩者回答的問題不同。Google 結構化資料測試工具說明有列出兩者用途。先定類型，再選工具，報告才不會把「未支援某種搜尋外觀」誤判成整段標記無效。

例如，一篇分享網站核對步驟的教學，主體是文章，就以文章頁作為判斷方向；若同一網址還有目錄、作者資訊或導覽路徑，先問這些內容是否真是頁面上獨立、可理解的項目，再決定是否補充描述。不要只因網站有商店，就將全站套上商品標記，也不要在純服務介紹頁塞入沒有展示的商品價格或評論。判斷準則是：讀者打開這個網址，最先能辨認的主要內容是什麼？標記是否只描述該內容及頁面實際提供的資訊？

可以先做一列清單：網址、頁面用途、主要主體、候選類型、採用依據、待確認問題。遇到多種內容混在同一網址，先拆分主體與附屬項目，必要時請網站負責人確認模板設計；不要由核驗人員憑搜尋詞或其他網站做法臆測類型。這份清單是後續比對欄位和指派修正責任的共同起點。

比對可見內容欄位

選定類型後，把瀏覽器實際顯示的頁面和讀取到的結構化資料並排核對。可見內容不只看首屏標題，也要看文章正文、作者署名、商品資訊、活動日期、圖片和頁面狀態等實際存在的資料。若標記由版型或 JavaScript 產生，要以使用者和搜尋工具最後取得的呈現結果核對，而不是只檢查編輯器裡的原始欄位。動態內容載入失敗、不同裝置顯示不同值，都可能讓程式碼和頁面脫節。

可用下表記下差異；以下是純假設的教學頁例子，名稱和內容不代表任何實際網站：

每列都問三件事：頁面看得到嗎、值是否一致、來源能否追到內容管理欄位或維護紀錄。若標記標題省略副標，只要核心意思和頁面主體仍一致，未必是錯誤；若將舊活動日期、已下架價格或另一篇文章的圖片帶進來，就應列為差異。對照時也要確認欄位指向的主體，例如作者不是網站客服、圖片不是裝飾性預設圖。

最後標註差異類型：頁面內容缺漏、標記映射錯誤、資料過期、模板沿用錯值，或需要內容負責人判斷。每一筆都附上實際網址和畫面位置，讓負責人知道改的是頁面、資料來源還是模板；無法判定時先保留問題，不要自行把標記改成另一個看似合理的值。

檢查必要值與格式

欄位核對通過後，再依選定類型的官方說明確認必填與建議欄位。先標出缺少後會造成錯誤或失去特定搜尋外觀資格的必要值，再整理可補充的建議值；兩者不可混為一談，也不要把別種頁面類型的欄位要求搬過來。官方規格會隨類型和功能不同而變動，應以該類型文件為判斷依據，保存文件連結或版本資訊，方便之後重新確認。

格式檢查可由外到內進行：標記是否在描述目前這個頁面、網址是否完整且指向正確版本、日期是否採標準格式、文字是否為預期型態、清單是否真的是清單、巢狀物件是否結構完整。JSON-LD 還要確認 JSON 語法能解析，例如引號成對、逗號位置正確、字串沒有未跳脫的換行。常見問題是把空字串當作有效作者、把日期寫成讀者看得懂但程式無法穩定解析的句子，或將單一網址錯放進陣列欄位。

建議逐欄記錄「規格要求、目前值、頁面依據、檢查結果」。例如頁面沒有公布活動結束時間，就不能為了填滿欄位而推估一個時間；若作者在版面上顯示為團隊名稱，便應核對標記是否也呈現同一個具體名稱，而不是從文章檔案名稱猜作者。可選值若沒有可靠來源就留白或移除，不要用「未知」、「待補」冒充真實資料。

工具回報有效，也只代表它在該工具與檢查範圍內通過解析或符合特定條件。它不能替你確認文字是否真實、頁面是否清楚展示，或某項搜尋呈現一定會出現。若測試有錯誤，先定位到欄位和來源，再判斷該修資料、語法或模板；若有警告，讀取相應類型的文件，確認它是必須處理、品質建議，還是與此頁無關。

排除不實或空白標記

核驗時要主動找出「程式上存在、頁面上卻沒有」的資訊。比對標題、正文、圖片、日期、價格、評分、作者和其他可見屬性；若標記描述隱藏內容、過期內容、虛構評論或與頁面主題無關的項目，即使語法正確，也不能視為完成。Google 的通用指南要求標記能代表讀者可見的頁面內容，且測試通過不保證搜尋結果一定採用該呈現方式。通用結構化資料指南可作為內容真實性檢查的依據。

空白和預設值特別容易由共用模板帶入。逐一搜尋空字串、只有空格的文字、佔位符、範例網址、預設圖片、零值，以及已停用或未確認的欄位。零值應回查來源，不可一概判錯。若欄位沒有內容且類型不要求，就移除該標記；若屬必要欄位，交給資料或內容負責人補上有根據的值，不能以空字串湊過測試。

也要檢查重複和互相衝突的描述：頁面上有兩段 JSON-LD 時，是否重複描述同一主體，或一段仍留著舊標題；外掛與自訂模板是否各自產生一組作者、麵包屑或組織資訊；手機與桌機、登入前後是否拿到不同內容。可用「標記欄位—可見證據—資料來源—處置」建立清單，每個疑點都要能指出是哪個來源提供錯值，而不是只在測試結果截圖上圈起來。

修正原則是刪除無根據的描述，或修正其實際資料來源；不要靠新增另一組標記覆蓋舊值，也不要把不可見的內容塞進頁面程式碼來迎合測試。若某項資訊因版面設計未顯示但業務端認為應提供，先由內容和網站負責人決定是否讓它成為使用者可見資訊，再同步更新頁面與標記。這樣才能避免核驗報告變成單純消錯，而實際誤導仍留在網站。

保存測試錯誤紀錄

測試紀錄要能讓另一位負責人重現問題。每筆至少保存受測網址、測試方式、所用工具、頁面類型、錯誤原文、受影響欄位、重現步驟與證據位置；需要比較修改前後時，再保存版本識別或程式碼變更連結。若以程式碼測試，記下輸入段落，避免誤當成網址測試。截圖外另抄錯誤文字與欄位。

將結果拆成三類會更容易分派：解析錯誤通常先交給模板或工程負責人；欄位缺漏或內容不一致要回到資料來源與內容負責人；警告則需要查閱該類型文件，確認是否影響資格、品質或與頁面無關。記錄中寫清楚優先級理由和預期驗收條件，例如「作者名稱須與頁面署名一致」，不要只留下「請修 schema」。若尚無法判斷，記為待確認並指定需要回答的人，而不是默認不必處理。

建議使用固定格式：問題編號、網址、頁面範本、測試工具、錯誤訊息、受影響欄位、畫面或原始輸出、推定來源、修正負責人、驗收條件、處理狀態。來源推定先標假設，查到模板或欄位映射後再確認。若一次測到多種標記，拆成多筆紀錄，方便不同負責人各自處理，也能看出同一問題是否反覆出現在多個網址。

交接前先檢查紀錄是否包含足以定位的資訊，同時避免把訪客個人資料、登入憑證或不必要的內部資訊放入截圖和工單。負責人完成修正後，更新狀態並附上重新測試結果；原始錯誤保留作為前後比較，另行註明已解決、仍需內容判定或被證實為非問題。這份紀錄的目的，是把「看到什麼、誰來確認、如何驗收」串起來，而不是累積一疊無法追蹤的報告。

改後重測頁面樣本

修正後不能只重跑貼入程式碼的片段，還要測實際網址，確認線上頁面載入後的標記與可見內容已同步。先用原本報錯的網址做回歸，再從同一模板挑一個不同內容的樣本；若修的是共用文章版型，就挑另一篇文章確認欄位沒有只對單篇生效。其他頁型另抽樣，不以一頁代表全站。

依問題選工具：要確認 Google 搜尋可辨識哪些豐富結果，使用 Rich Results Test；要檢查一般 Schema.org 語法和結構，可再用 Schema Markup Validator。工具測試完，回到頁面本身重看標題、主要內容和被修正欄位，必要時查看測試工具抓到的呈現結果。可記錄原錯誤是否消失、是否出現新的錯誤、原欄位是否正確、可見頁面是否相符、其他樣本是否受影響。不能只比較紅色錯誤數量，因為錯誤消失不代表值正確。

驗收條件要在修正前先寫好，避免看到「有效」就臨時降低標準。例子包括：指定欄位有真實來源、標記值與頁面相符、目標網址無解析錯誤、共用模板的第二個樣本沒有殘留舊值。若只有建議警告，記下文件依據與是否採納；若無法完成，就保留負責人和下一步，不把未測結果標成通過。結構化資料有效也不等於搜尋結果必然顯示相應外觀，這兩種結果應分開記錄。

最後建立簡短核驗摘要，附上樣本網址、修正版本、工具結果和未解項目，讓內容、工程與網站維護人員都能讀懂。若模板改版、欄位來源改變或內容管理系統升級，重新抽樣確認受影響頁型；日常新增內容則沿用相同核對表。下一步可以挑一篇最具代表性的頁面，照六項順序完成對照，再把需要釐清的網站流程、欄位來源與交接責任帶到 ZhenheAI 官網了解後續方向。