透過連結實體、使用一致的識別碼以及保持模式與可見內容一致，避免結構化資料錯誤損害 AI 的可見性。
結構化資料長期以來被視為谷歌技術SEO的核心支柱。它能幫助搜尋引擎機器人更準確地理解頁面內容。許多SEO從業者花費大量時間更新和改進網站上的結構化數據，以反映其重要性。
在人工智慧搜尋的新時代，搜尋引擎優化人員認為他們已經掌握了結構化數據，這可以理解。然而，一些非常常見的錯誤會影響結構化資料在提升潛在客戶可見度方面的實際作用。
「Ask An SEO」欄位中最新提出的問題是：
“哪些最常見的結構化資料錯誤會損害人工智慧的可見性？”
在本文中，我們將探討一些最常見的誤解。
將結構化資料標記視為清單而非實體策略
最容易理解的錯誤之一是將結構化標記視為必須完成的事情，而沒有考慮更廣泛的「為什麼？」。
在為搜尋引擎優化 (SEO) 內容添加標記時，行銷人員通常會機械地覆蓋頁面上的主要結構化資料類型。畢竟，主要目的是幫助搜尋引擎清晰地理解內容。
然而，人工智慧搜尋的關鍵在於認識到語言學習者正在尋求對實體和關係的肯定。
這意味著，利用模式來提升AI搜尋可見性需要更深入的考慮和更具策略性的方法。企業不能僅僅因為頁面上存在結構化資料標記就認為資料已完整，而應該捫心自問：“我們的結構化資料是否能讓機器更容易理解頁面上資訊的上下文和關係？”
實際上，這表現為使用模式識別來強化品牌標識、內容作者身份、產品實體及其相互關係。其目標是為整個網站提供上下文關聯。例如，電商網站部落格上的文章就可以使用文章模式來識別。
從技術角度來說，這是正確的模式實現。該頁面的內容確實是一篇文章。這有助於搜尋引擎機器人理解這不是產品內容或商業內容，而是資訊類文章，一篇部落格文章。
然而，這種方法無法展現這篇文章與網站上其他實體之間的關聯。更好的實現方式是將此頁面的模式與整個網站關聯起來。例如，此頁面的模式應該連結到部落格的作者頁面。從策略角度思考如何利用結構化資料來提升人工智慧的可見性，更應該將文章與其作者以及作者所在的公司關聯起來。這意味著，除了使用文章模式標記內容之外，還需要包含作者和組織機構的模式。
僅依靠結構化資料來明確實體
從策略角度思考如何利用模式識別提升人工智慧的可見性，意味著要意識到僅僅明確頁面上的資訊類型是不夠的。被標記的資訊需要與學習管理系統（LLM）可能從其他管道取得的資訊保持一致。標記的內容不一定就是學習管理系統認為最權威的資訊。
這意味著結構化標記策略的一部分需要包括糾正網路上的錯誤訊息。
這可能很簡單，例如網站使用您以前的品牌名稱，或保留您產品的舊價格資訊。
僅僅在網站上標明正確的品牌名稱和產品價格可能不足以說服LLM（法學碩士）相信你的數據是值得信賴的。
未使用一致的實體標識符
實體識別碼是一種在整個網站中使用相同模式標記的方法，無需重複編寫程式碼。使用 @id 定義實體表示您可以重複引用該 @id，而無需為每個頁面的實體建立新的模式。例如，如果您想在多個頁面和範本中標記對組織的引用，只需定義一次組織實體，然後在後續頁面中引用它。
在下面的範例中，我正在標記一個虛構的網站 helensecommercestore.example 的組織實體。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.helensecommercestore.example/#organization",
"name": "Helen's Ecommerce Store",
"url": "https://www.helensecommercestore.example/",
"logo": {
"@type": "ImageObject",
"url": "https://www.helensecommercestore.example/images/logo.png"
}
}
</script>其中最重要的是「@id」：https://www.helensecommercestore.example/#organization
這並非真正的URL，但它用作唯一識別碼。它使用簡寫形式標記實體，這意味著後續使用此@id將傳遞與最初描述的實體相同的所有資訊。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Choose the Right Running Shoes",
"publisher": {
"@id": "https://www.helensecommercestore.example/#organization"
}
}
</script>在上面的例子中，無需重新定義實體。機器人會清楚知道，這個組織與最初引用的組織是同一個組織。
這樣做不僅可以簡化編碼流程，還能確保資訊一致性。這可以降低網站各處出現資訊衝突的風險。
在這個例子中，可能是2022年在Helen’s Ecommerce Store的產品頁面上添加了組織架構，當時組織名稱仍為舊的公司名稱「Helen’s Shop」。而首頁的架構在2026年進行了更新，組織名稱更正為「Helen’s Ecommerce Store」。這會為代理人帶來一些衝突：哪一個才是該組織的正確名稱？
透過在組織架構中使用 @id ，首頁的更新將被所有使用該 @id 的其他頁面繼承。這意味著不會發生衝突，也無需進行多次更新。