結構化資料不是玄學，它就是一份給機器看的自我介紹。介紹寫得完整、和頁面可見內容一致，機器就敢引用你；欄位缺漏或彼此矛盾，機器就會保守處理。以下這份清單是我們實際用來檢查客戶網站的版本。
每一頁都應該有一份描述組織的結構化資料，欄位至少包含：
服務頁應該描述提供什麼、給誰、在哪些地區提供，以及交付形式。要避免的是把三條不同的產品線寫成一個籠統的服務，機器無法據此判斷你適合哪一類查詢。
我們自己的做法是三條產品線各自獨立成頁、各自描述：海外房地產企業顧問、逆向破解競業情報書、履歷重構暨面試技巧，定價、流程與交付都分開，不綁售。
不需要複雜工具。三個動作就能驗收：把結構化資料裡的每個欄位，逐一到頁面上找到對應的可見文字；把名稱、地址、成立年份拿到所有社群簡介核對一次；把 canonical 全站掃一次，確認都是 https 且指向自己。
這三件事我們在自己的網站上是每次改版都跑一次的例行檢查。全站一百多頁掃完不到十分鐘，但它擋掉的是最容易被忽略、也最傷的一類錯誤。
如果你希望由我們協助把整站的實體資訊盤點並對齊，可以從 聯絡窗口 說明現況，或直接填寫對應服務的需求問卷。
服務邊界是判讀實體的重要訊號。當你明確寫出不承接的範圍，機器在把你歸類時會更有把握，也比較不會把你放進不相關的候選名單。對使用者來說，這同時省下了雙方的時間。
實作上，邊界可以寫在服務頁的可見內容裡，並在結構化資料的服務描述中呼應。兩者用字不必相同，但事實必須一致。
第三項最常被忽略。如果主要內容必須靠腳本才會出現，機器讀到的可能是一個近乎空白的頁面，前面所有努力都會失效。
這個順序的重點是：先有事實、再有可見內容、最後才是機器版本。反過來做，結構化資料會變成一份和頁面對不上的宣稱，長期是扣分的。
第一項是語法驗證，用官方工具檢查必填欄位與格式。第二項是內容一致性驗證，逐一確認標記裡的每個值都能在頁面上找到對應的文字。第三項是渲染驗證，用瀏覽器的原始碼檢視確認標記確實輸出，而不是被前端框架吃掉。
第三項最常被忽略。有些網站的標記在編輯器裡存在，但因為模板處理的方式，最終輸出時被移除或轉義了。只做語法驗證不會發現這個問題。
第四項是最容易出事的時候。改版時模板被重寫，結構化資料經常在無人注意的情況下整組消失，而這件事在報表上不會有任何顯示。
結構化資料最大的維護風險是它與頁面內容脫節。預防的方式是讓兩者來自同一個資料來源，服務名稱、價格邏輯、聯絡方式都從同一份設定產生，而不是在標記與頁面上各寫一次。
如果技術上做不到單一來源，退而求其次的做法是建立一份對照清單，列出每一個標記欄位對應到頁面上的哪一段文字。內容修改時，照著清單同步更新。
這份清單同時也是驗證的工具。每季拿出來逐項核對一次，可以及早發現脫節。