在協助企業對齊生成式搜尋的實務裡，最常見的誤區是：以為用 JSON-LD 並貼上 schema.org 規範，就確保 AI 引擎能讀到內容。但事實上，如果你的 JSON-LD 是透過 JavaScript 載入的，非 JS 爬蟲根本讀不到。這不是技術過時，而是信任基礎建設的起點：你的結構化資料必須在 raw HTML 階段就能被讀到，AI 引擎才會認你是一個可驗證的內容來源。
為什麼非 JS 爬蟲讀不到 JSON-LD？先搞懂「渲染時機」的差別
不是每隻爬蟲都會執行 JavaScript。這聽來像是老生常談，但在真實場景中，非 JS 爬蟲（特別是生成式引擎背後的引擎）的行為模式會直接影響你的內容是否被視為「可信來源」。
| 類型 | 是否執行 JS | 是否能讀取 JSON-LD | 常見引擎 / 爬蟲 | 爬蟲行為對應的真實場景 |
|---|---|---|---|---|
| 非 JS 爬蟲 | ❌ | ❌ | Google AI Overviews、部分垂直 AI 引擎 | 僅解析 raw HTML，無法讀取 JS 載入的資料 |
| JS 爬蟲 | ✅ | ✅ | Googlebot（部分情境） | 能載入 JS 腳本，完整解析頁面內容 |
核心問題不是 JSON-LD 有沒有寫對，而是它有沒有在 raw HTML 階段就存在。 這就像蓋房子時，地基是用水泥還是紙板——結構資料若要被 AI 引擎認可，必須在原始 HTML 中就可見，而不是靠 JS 在瀏覽器中「後來才出現」。
JSON-LD 的正確寫法：與 HTML 分離，確保在 SSR 階段就可讀
JSON-LD 是目前 Google 官方推薦的結構化資料格式，它讓搜尋引擎與 AI 引擎能機器可讀地理解你的頁面內容。但這一切的前提是——它必須在伺服器端渲染（SSR）階段就被嵌入 HTML 中，而不是靠客戶端 JS 在瀏覽器中動態載入。
為什麼 JSON-LD 要寫在 raw HTML？
1. 非 JS 爬蟲只讀 raw HTML：AI 引擎在解析內容時，可能只抓取 HTML 中的靜態結構，並不會執行動態腳本。如果你的 JSON-LD 是靠 JS 載入的，它就「不存在」於引擎眼中的可見內容中。 2. SEO 是基礎，GEO 才是目標：傳統 SEO 關注的是搜尋引擎機器人能不能讀到內容，而 GEO（生成式搜尋優化）更進一步關注的是：AI 引擎能不能在生成答案時引用你。 如果結構化資料是 JS 後載入的，AI 引擎就無法正確建立你的實體與內容之間的關聯。
TrueLink 的實作策略：JSON-LD 直接 SSR 進原始 HTML
TrueLink Blog 的實作方式是將 JSON-LD 以 SSR 的方式注入 HTML 中，確保無論是傳統 SEO 還是 GEO 的爬蟲，都能在抓取頁面時即時讀取結構化資料。這也與我們的技術實作 functions/routes/publicBlogPage.js 和測試 public-blog-section-visuals.test.js 中的驗證邏輯一致，確保可爬取性與結構化資料的可見性。
什麼樣的結構化資料值得被 AI 引擎引用？
讓 AI 引擎引用你的內容，並不是因為你用了 JSON-LD，而是因為你的內容本身具備「可驗證的獨特性」與「可溯源的結構」。這一點，與我們協助企業對齊 GEO 的實務觀察一致：AI 引擎更傾向引用那些結構完整、來源清晰、作者與組織有明確關聯的內容。
用 Article、Person 和 Organization 建立「可驗證的實體關聯」
schema.org/Article 是結構化資料中最重要的類型之一，但它並不是孤島。要讓 AI 引擎真正認你為一個「可信來源」，你必須把文章與作者、組織明確地連結。這意味著：
- 使用
author標記指向一個schema.org/Person； - 使用
publisher標記指向一個schema.org/Organization； - 用
sameAs把這些實體與你的真實網站或社交帳號連結。
這樣的結構，不僅讓引擎知道「這篇文章是誰寫的，出處在哪」，也讓引擎有能力去驗證你這個來源的可信度。這也正是 Google 在 E-E-A-T 中強調「可信度」與「真實性」的實務做法。
如何避免結構化資料被 JS 隔絕？實戰技巧與檢查清單
如果你的結構化資料是透過 JS 動態載入的，AI 引擎很可能會忽略它。這不是你的結構化資料寫錯了，而是你寫得不夠「可見」。以下是一些實戰技巧與檢查清單，幫你確保結構化資料在 raw HTML 階段就能被讀取：
✅ 檢查清單：結構化資料是否在 raw HTML 中可見？
1. JSON-LD 是否寫在 <script type="application/ld+json"> 區塊中？ 2. 這些 JSON-LD 是不是在 SSR 階段就寫入 HTML，而不是靠 JS 在瀏覽器中載入？ 3. JSON-LD 中是否正確標記 @type、@id、author 和 publisher？ 4. 是否有使用 sameAs 把組織或作者與真實網站連結？ 5. 是否避免過度依賴 JS 動態載入的內容？
建議的 JSON-LD 寫法範例：Article + Person + Organization
這是一個典型的結構化資料範例，結合 Article、Person 和 Organization，並使用 sameAs 來建立實體關聯：
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD 進 raw HTML vs JS 注入：為什麼非 JS 爬蟲看不到你的 schema",
"author": {
"@type": "Person",
"name": "林士華",
"sameAs": ["https://www.linkedin.com/in/shih-hua-lin"]
},
"publisher": {
"@type": "Organization",
"name": "TrueLink(誠通數位)",
"sameAs": ["https://truelink-group.com"]
},
"datePublished": "2026-04-05",
"description": "讓 AI 引擎認可你的內容，不是靠 JS 動態載入，而是把 JSON-LD 寫在 raw HTML 中。"
}為什麼這對 TrueLink 來說是核心？信任的基礎，不在 JS 裡
TrueLink 不是另一個 SEO 工具。我們的使命是建立「AI 信任時代的數位信任基礎建設」。我們的核心承諾是：讓 ChatGPT 引用你的品牌。要做到這一點，你必須確保你的結構化資料在 raw HTML 中就能被讀到，因為 AI 引擎不會執行動態 JS。
TrueLink Blog 的 JSON-LD 實作流程是在伺服器端渲染階段（SSR）就將資料注入 HTML，並透過 functions/routes/publicBlogPage.js 進行驗證。我們在實測中對 raw HTML 做比對，發現 JS 注入的 schema 經常會遺失，這進一步驗證了「可見性」的必要性。
這也與我們的實務經驗一致：在協助企業對齊 GEO 的過程中，結構化資料寫得再精美，只要它不是在 raw HTML 中就可見，AI 引擎就很可能忽略它。信任的基礎，不在 JS 裡，而在 HTML 裡。
