JSON-LD 結構化資料驗證工具
貼上HTML或原始JSON-LD即可驗證FAQPage、BreadcrumbList、Article等結構化資料，快速發現缺失的必需屬性以及Google富媒體搜尋結果中常見的錯誤。
JSON-LD 結構化資料驗證工具是什麼
JSON-LD是一種標記格式，用於以機器可讀的方式告訴Google頁面內容的實際型別——是FAQ、文章還是麵包屑導航等。只需將其以JSON形式寫入<script type="application/ld+json">標籤內，就能在完全不影響可見HTML的情況下新增結構化資料。如果實作正確，搜尋結果中可能會出現麵包屑導航等富媒體搜尋結果。另外，Google已於2026年5月7日起不再在搜尋結果中顯示FAQ富媒體搜尋結果（可展開的FAQ摘要）。
本工具會自動從貼上的HTML中提取<script>程式碼塊（也可直接輸入原始JSON-LD），並針對檢測到的FAQPage、BreadcrumbList以及Article型別（Article / NewsArticle / BlogPosting），依據Google結構化資料文件逐一核對必需屬性和推薦屬性是否齊全（Schema.org本身並未規定必需屬性）。同時還會標記出容易被忽視的典型錯誤，例如acceptedAnswer.text被誤寫成物件而非純字串、position編號不連續等。在發布前或修改後進行這樣的檢查，可以比事後在Search Console中才發現問題更早地捕捉到錯誤。
JSON-LD 結構化資料驗證工具的使用方法
- 準備頁面的HTML原始碼或JSON-LD 可以是透過「檢視網頁原始碼」取得的完整HTML，也可以只擷取<script>標籤中的內容。
- 貼上至輸入框，或透過URL獲取 既可以直接貼上文字，也可以針對已釋出的頁面輸入其URL來獲取內容。
- 檢視偵測到的實體及其驗證結果 如果輸入內容中包含多個<script>程式碼塊或多個@type實體，每一個都會單獨列出並驗證。
- 修正標記為「缺失」或「警告」的項目 每個屬性都會顯示正常、警告或缺失中的一種狀態，可據此直接定位到原始JSON-LD中的對應位置進行修正。
- 修正後重新驗證，再進行釋出 將修正後的JSON-LD重新貼上進行驗證，確認所有項目均顯示正常後，再將修改套用到實際頁面。
用好本工具的小技巧
- FAQPage的acceptedAnswer請將回答內容以字串形式直接放入text屬性中。如果填入物件或陣列，搜尋引擎將無法把它識別為回答內容。
- BreadcrumbList的position需要從1開始連續編號，如果存在缺號或重複，將無法被識別為正確的麵包屑導航。
- Google的文件沒有為Article規定必需屬性，也沒有規定headline的字數上限。不過，過長的標題在部分裝置上可能會被截斷，因此建議盡量簡潔。
- 即使貼上整個HTML頁面也沒問題，工具會自動提取 <script type="application/ld+json"> 程式碼塊中的內容進行驗證，只貼上JSON本身也同樣有效。
- 如果一個頁面中放置了多種結構化資料，建議分別寫在不同的 <script> 標籤中，這樣更便於維護和排查問題。
這些場景中可以派上用場
確認FAQPage標記的結構
可以發現acceptedAnswer.text格式錯誤等FAQPage中常見的結構問題。需要注意的是，Google自2026年5月7日起已不再顯示FAQ富媒體搜尋結果，因此該標記已無法改變頁面在Google搜尋中的顯示效果。
網站結構調整後檢查麵包屑導航
當分類或URL發生變化時，可以一次性確認BreadcrumbList的position編號是否仍然正確。
審查部落格文章的Article結構化資料
可以一次性檢查headline、author、datePublished、image等Google推薦的Article屬性是否缺漏。
排查富媒體搜尋結果測試工具報錯的原因
Google官方工具報錯時，可以先用本工具縮小範圍，明確具體是哪個屬性存在問題，再進行修正。
詞彙表
- JSON-LD
- 一種以JSON格式編寫結構化資料的規範。以獨立程式碼塊的形式嵌入<script type="application/ld+json">標籤內，可以在不改變現有HTML佈局的情況下新增面向搜尋引擎的資訊。
- Schema.org
- 由Google、微軟、雅虎等共同制定的結構化資料詞彙表，定義了FAQPage、Article等各類內容對應的型別（@type）及其屬性。
- FAQPage
- 表示常見問題及其回答的Schema.org型別。mainEntity中包含Question型別的陣列，每個Question填寫name（問題）和acceptedAnswer.text（回答）。Google已於2026年5月7日起不再在搜尋結果中顯示FAQ富媒體搜尋結果。
- BreadcrumbList
- 表示麵包屑導航（頁面在站內層級結構中的位置）的Schema.org型別。itemListElement中包含ListItem陣列，每個元素填寫position（順序）、name和item（URL）。根據Google的文件，最後一個元素的item可以省略，省略時將使用頁面自身的URL。
- 富媒體搜尋結果
- 在搜尋結果中顯示比一般標題和描述更多資訊（如麵包屑導航）的功能。正確實作結構化資料是前提條件，但即使實作了也不一定會顯示。
- 必需屬性
- Google要求某型別富媒體搜尋結果得以顯示所必須具備的屬性，缺失時該富媒體搜尋結果將完全無法顯示。相對而言，推薦屬性即使缺失也可能顯示，但具備時效果更佳。
- Google Search Console
- 用於檢視網站搜尋表現及索引狀態的Google官方工具，其「增強功能」報告可以顯示Google實際是如何解讀已釋出頁面中的結構化資料的。
常見問題
閒話 ― JSON-LD為何取代了Microdata與RDFa
JSON-LD（JSON for Linking Data）最初是W3C社群小組在2010年代初期制定的一種關聯資料格式。與Microdata、RDFa等傳統結構化資料寫法（直接將標記嵌入HTML元素的屬性中）不同，JSON-LD可以作為一段獨立的JSON，完整地寫在<script>標籤內，因此在新增或刪除結構化資料時完全不會破壞現有的HTML佈局。Google從2015年前後開始將JSON-LD定位為推薦格式，如今的富媒體搜尋結果文件也幾乎都以JSON-LD的寫法為前提進行說明。
本網站自身的FAQ區塊也是如此運作的：作者只需撰寫一次問答內容，系統便會在後臺自動生成對應的FAQPage格式JSON-LD。這樣一來，人類閱讀的視覺化手風琴列表與搜尋引擎讀取的結構化資料無需重複手動維護兩份，其中一處修改後另一處也會自動同步，從而避免了顯示內容與結構化資料不一致的問題。
即使JSON在語法上完全正確，如果缺少Google規定的必需屬性，或者缺少推薦屬性，富媒體搜尋結果（例如搜尋結果中的麵包屑導航顯示）也可能無法生效。acceptedAnswer.text這類巢狀層級較深的屬性，正是實作時容易出錯的典型案例。在發布前使用此類工具進行機械化檢查，可以比事後在Search Console的「強化功能」報告中才發現錯誤更早地發現問題。