在生成式搜尋時代，結構化資料（structured data）的部署已不是技術選項，而是信任資產。JSON-LD 作為 Schema.org 的推薦格式，常見的疑問之一是：「它該放在 HTML 的 <head> 還是 <body> 裡？」

答案是：解析上無差異，但渲染時機會影響 AI 引擎能否完整讀取並建立引用機會。這不是一個「最佳做法」的問題，而是與網站行為、資料完整性、以及 AI 引擎抓取行為的細微互動。

為什麼 JSON-LD 放 head 或 body，解析上無差異？

結構化資料的機器可讀設計，使其在 HTML 中的位置本質上對「解析」無影響。Google Search Central 明確指出，結構化資料的有效性取決於語法與語義，而非載入順序或頁面位置（來源：Google 結構化資料文件）。

這代表只要 JSON-LD 的語法正確，且資料語義符合 Schema.org 定義（例如 Article、FAQPage、Organization），搜尋引擎與 AI 引擎就能解析其內容，並用它來理解頁面類型與實體關係。

為什麼渲染時機會影響 AI 引用的機會？

真正關鍵的是結構化資料是否在 AI 引擎抓取時「已經完成渲染」。這涉及到幾個技術實務問題：

1. 動態注入 vs. 靜態嵌入

  • 動態注入（例如透過 JavaScript 注入 JSON-LD）會有風險：若 AI 引擎抓取時腳本尚未執行，結構化資料就無法被讀取，導致引擎將這份內容忽略。
  • 靜態嵌入（直接寫在 <head> 或 <body>）則穩定得多，因其資料在 HTML 載入時就存在，無需依賴客戶端執行腳本。

2. 網站行為與載入順序

在 SSR（伺服端渲染）網站中，JSON-LD 往往是與首屏內容同步渲染的，因此無論放在 <head> 或 <body>，引擎都會在載入首屏時就讀到它。但在 CSR（客戶端渲染）網站中，結構化資料可能在頁面載入後才動態產生，這就可能導致 AI 引擎抓不到。

真實情境：結構化資料「被錯過」的三個常見場景

場景發生機率(風險等級)背後機制解決方式
JavaScript 動態注入結構化資料中引擎抓取時腳本尚未執行將 JSON-LD 靜態嵌入 HTML，或透過 SSR 優化載入順序
結構化資料位於分頁內容中高多數 AI 抓取器以初始 HTML/首屏為主，延遲渲染內容有被略過風險將核心結構化資料放在第一屏內容，並在分頁內容中補充
結構化資料依賴 Cookie 呼叫中引擎無法模擬 cookie 狀態獨立結構化資料，使其不依賴動態條件

實務建議：該放在 `<head>` 還是 `<body>`？

這不是一個非此即彼的問題，而是根據你的網站行為與內容特性來調整。TrueLink 的建議如下：

✅ **首選做法：靜態嵌入 HTML，優先放在 `<head>`**

  • 優點：結構化資料在 HTML 載入即完成，確保 AI 引擎與搜尋引擎能穩定讀取。
  • 原理：<head> 是傳統 SEO 設計中結構化資料的常見位置，引擎對此行為已習慣，解析更順利。

✅ **次選做法：靜態嵌入 `<body>`，但確保不依賴動態載入**

  • 優點：結構仍穩定存在，但更易與首屏內容結合。
  • 限制：需確保結構化資料在 <body> 中的位置不會被分頁或無限捲動隱藏。

❌ **避免動態 JavaScript 注入結構化資料**

  • 風險：AI 引擎可能無法等到腳本執行完成就離開，導致資料被忽略。
  • 替代方案：將結構化資料寫為靜態 JSON-LD，或透過 SSR 優化動態載入順序。

結構化資料部署的「信任工程」視角

結構化資料不是 SEO 適配，而是建立內容可信度的基礎建設。Google 的 E-E-A-T 指南強調「真實性」與「可驗證性」（來源：Google E-E-A-T 公開文件），而結構化資料正是這過程中的關鍵環節。

透過正確的 JSON-LD 部署，你不僅是在「優化搜尋結果」，更是在讓 AI 引擎能理解你內容的實體關係、作者背景與內容類型。這正是 TrueLink 所說的「讓 ChatGPT 引用你的品牌」的機械基礎。

在 TrueLink 的實務中，我們觀察到：結構化資料的「完整性」遠比「位置」重要。例如：

  • 使用 Organization schema 並正確標註 sameAs，讓品牌與官方社群連結。
  • 使用 Person schema 並連結作者身分，強化 E-E-A-T 中的 Trust 要素。
  • 使用 FAQPage 來結構化問答，讓 AI 引擎更容易切片引用。

這些細節，才是 AI 引擎會「認得出你」的關鍵。我們把內容產線搬進自家 DGX 機房後的實作分工經驗（本地起草／雲端校正）也顯示：一篇能被 AI 引擎引用的文章，關鍵不在關鍵字密度，而在是否有『抽掉品牌名後就無法原樣掛在任一競品上』的第一手觀點。

真實的結構化資料，從細節做起

我們經營自動化內容產線、反覆審核大量 AI 草稿後的實務判斷是：AI 量產內容最大的風險不是產不出來，是產出『結構完整但通用空泛』的 slop；在發布前設一道機器評分閘＋一道人工放行閘，比事後補救有效得多。

生成式搜尋會切片引用，所以每段都要寫成『不靠上下文也能被獨立引述』的自足段落——破題句先給結論，再展開為什麼。這也是我們為 GEO 重寫文章結構時反覆驗證的寫法。

Q: AI 引擎會執行 JavaScript 嗎？

A: 多數 AI 抓取器以初始 HTML/首屏為主，JavaScript 動態注入的內容有被略過風險。

Q: 為什麼渲染時機影響引用機會？

A: 若結構化資料尚未完成渲染，AI 引擎可能就離開，導致資料未被讀取。

Q: JSON-LD 放在 head 還是 body 比較好？

A: 優先放在 <head>，確保資料在 HTML 載入時即存在。

Q: 結構化資料的「完整性」指什麼？

A: 包含正確語法、語義與實體關係，而非僅位置安排。

結論：JSON-LD 的位置不影響解析，但影響 AI 引用的機會

AI 引擎關注的不是你把結構化資料放在 HTML 的哪個標籤裡，而是你是否在它抓取的時機點上，讓資料完整存在。這是一個關於「渲染時機」與「資料可見性」的問題，而不是「位置」的問題。

因此，結構化資料的部署不該只是 SEO 的例行公事，而應視為一種「信任資產」的長期投資。