基礎標註為什麼不夠？
多數網站的結構化資料停在「每頁各貼一段」：首頁一個 Organization，文章頁一個 Article，各自獨立、互不引用。引擎解析後得到的是一堆碎片——這篇文章屬於哪個組織？這個組織和首頁那個是同一個嗎？基礎寫法見 技術實現；進階要解決的正是「把碎片拼成圖」。
巢狀 JSON-LD 怎麼寫？
核心手法是 @id 錨定：給 Organization 一個固定 @id（如官網網址加 #organization），之後全站所有標註用這個 @id 引用它——Article 的 author 與 publisher 指向它，WebPage 的 about 指向它，Product 的 brand 指向它。這樣無論引擎讀到哪一頁，都能把資訊歸屬到同一個實體節點。巢狀寫法（把 author 物件直接嵌進 Article）與 @id 引用寫法可混用，但同一實體的屬性口徑必須全站一致。
實體錨定的完整操作是什麼？
- 定主節點：Organization 標註寫全 name、alternateName（多語名稱）、foundingDate、address、contactPoint，設固定 @id。
- sameAs 指出去：列出所有官方帳號與權威檔案頁——社群、目錄、Wikidata 條目，形成跨站身份錨。
- 全站引用同一 @id：文章、商品、FAQ、本地據點頁（LocalBusiness 用 branchOf 或 parentOrganization 掛回主節點）。
- 標註與正文一致：價格、日期、評分必須和頁面展示逐字相同——不一致會在落地驗證關被扣分。
- 逐類型驗證：用結構化資料測試工具逐頁型檢查，錯誤與警告清零後再上線。
常見坑
坑一：每頁重複定義完整 Organization——產生多個互相矛盾的分身，正確做法是定義一次、到處 @id 引用。坑二：sameAs 亂指——只放官方控制的檔案頁，粉絲頁、仿冒頁指進去等於幫別人錨定。坑三：標了不管——改版後標註與新正文脫節，定期隨 月度監測複查。
常見問題
JSON-LD、Microdata、RDFa 選哪種？
JSON-LD。它是 Google 建議格式，與 HTML 解耦好維護，也是巢狀與 @id 引用寫法最成熟的載體。全站統一一種格式即可。
進階標註對 AI 引用有直接效果嗎？
間接但關鍵：結構化資料本身不是排名槓桿，它決定引擎能否正確拼出你的實體——實體清晰是落地驗證與知識圖譜收錄的前提，進而影響答案中的描述準確度。