Blog

JSON-LD, sitemaps, and AI citation visibility for articles

Naly 工程筆記：JSON-LD、網站地圖與預測文章的 AI 引用準備

Naly 的編輯資產可透過將 metadata、來源 URL、schema 標記與 lead 摘要視為一等公民的發佈時產物，在搜尋與生成式發現中建立持久性。此筆記定義一個低摩擦、可衡量的 Next.js + drizzle-orm + PostgreSQL 設計，提升預測文章的可抓取性與 AI 引用表現。

June 23, 202613 sources

摘要

在 Naly 的文章平台中，JSON-LD、網站地圖與明確的 lead/metadata 管線讓每篇已發佈的預測筆記都可被機器讀取，同時不取代編輯品質。核心觀點是，發現品質現在依賴兩個平行契約：一個供閱讀頁面的使用者使用，另一個供需要權威來源、結構化事實與穩定更新訊號的爬蟲與代理使用。Naly 的目標是讓每篇文章在首次發布時即可被索引、可被引用，並保持時間準確（截至 2026 年 6 月 23 日）。

在 Naly 中的位置

Naly 的技術堆疊已經為此做好準備： next@16.0.7 搭配 React 19.2.1 進行伺服器優先渲染，使用 drizzle-orm 與 @neondatabase/serverless 來管理關聯式文章資料，以及以 @vercel/blob 提供穩定的媒體 URL。GEO 目標不是獨立的 SEO 子系統；它是發佈流程的一部分，使用同一個權威文章模型同時服務人類與機器。

目前的設計錨點是文章發布邊界：一篇貼文必須在頁面標記、metadata 區塊、網站地圖匯出與文章摘要之間產生一致訊號。若任一通道偏離，同一篇文章可能被 Googlebot、AI 助理與內部分析解讀為不同內容，導致行為不一致。

在 Naly 內，表示以下資料路徑是耦合的：

  • 來自 drizzle 後端紀錄的文章主體與來源圖譜
  • 透過 Next server components 的頁面渲染與 metadata 處理
  • 透過 sitemap.xml， news-sitemap.xml，以及圖片 metadata
  • 透過先回答式 lead 與明確的來源 URL 陣列來準備引用

技術機制

Naly 應為每篇文章實作一個包含五項可預測輸出的發佈合約。

  1. 權威文章模型 每篇文章應提供穩定欄位：canonical URL、標題、standfirst/lead、發佈日期、更新日期、作者物件、分類/主題標籤、主圖片 URL、來源 URL 與語言。這是 Google 與 AI 面向解讀的核心。對於預測內容來說，來源 URL 特別重要，因為它們讓外部系統能將觀點與可驗證輸入區分開。

  2. 伺服器端 metadata 產生 generateMetadata 在 page.tsx/layout.tsx 中使用僅伺服器邏輯，確保爬蟲可見的標籤儘可能包含於初始 HTML。Next.js 文件明確支持此伺服器端模型，並指出 metadata 擷取可在不同產生路徑間快取，減少重複的資料庫/API工作。對高流量頁面而言，這能使發佈時間延遲可預測。

  3. JSON-LD 注入 NewsArticle 在 app 頁面中渲染一個 <script type="application/ld+json"> 嚴格

  4. JSON-LD 區塊，作為具有穩定 ID 與必要欄位（headline、datePublished、dateModified、author、image、mainEntityOfPage、必要時包含 isPartOf）的物件。Next 的 metadata 指南明確偏好 JSON-LD 作為結構化表示，並在元件文件中記錄了以 script 為基礎的結構化實體資料模式。 loc， lastmod並在必要時於 URL 層加入圖片與新聞擴充欄位，以協助專門化索引。為圖片密集內容提供專用輸出有助於維持發現一致性。

  5. Answer-first lead 優化 對於 AI 與搜尋面向，將 lead 段落視為同時服務使用者與機器的資源。使用相同的短 lead 作為 Open Graph description 與短篇答案入口，同時保留完整正文於文章原網址。這會建立一致的訊號路徑：首句回應對齊人類、機器人與歸屬抽取器。

一個精簡的發佈流程如下：

  • 在資料庫持久化文章與來源圖譜。
  • 從單一標準化 selector 建立 metadata、lead 與 schema 負載。
  • 在同一個發佈交易系列中輸出頁面 HTML、JSON-LD 與網站地圖列。
  • 在貼文更新時重新驗證或清除快取。

文獻觀點

Google 文件指出，結構化資料可讓爬蟲大規模理解頁面事實，同時警告符合資格是有條件且不保證的。官方指南一再強調建議使用 JSON-LD，且只要標記符合規範、具代表性且不誤導，才可出現在 rich results 中。

Google 也明確說明網站地圖是發現輔助工具，而非保證。即使格式正確，網站地圖仍可協助大型或新上線站點暴露內容，並可攜帶內容特定提示（例如圖片/新聞），但最終是否被索引仍取決於爬蟲後續抓取與可見性品質。

在 schema 語意上，schema.org 將 NewsArticle 定義為專為報導與背景新聞內容設計的子類型，當 Naly 類型的文章報導具體更新時，這是最自然的對應。

從平台端來看，Next.js 指南一致：metadata 最適合由渲染時期的伺服器負責，JSON-LD 是受支援且明確的結構化描述方法。該生態系也提供了適用於大量 URL 的網站地圖路由慣例與產生 API。

在 RAG 文獻中，一項關於代理式檢索的結構化連結資料研究指出，Schema.org/連結式表示可提升檢索品質，尤其在與比純文字更豐富的可導航性並用時更明顯。另一項近期 RAG 上下文研究則發現，格式與上下文一致性會實質影響 grounding 行為。這些研究共同支持 Naly 的論點：文章 metadata 品質不只是外觀優化，而會實質改變下游消費方式。

設計權衡

  • 新鮮度與快取穩定性：伺服器端 metadata 需要在編輯時快速刷新，而快取路由產物不應在每次請求時震盪。
  • 最小可行標記與完整性：加入必要欄位能提升合規性，但過度建模可能在來源資料延遲時產生過時或錯誤連結。
  • 爬取指引與信任訊號：更廣的網站地圖集合可提升覆蓋率，但過多低價值 URL 可能稀釋後續索引品質。
  • 可讀性與機器可讀性：lead-first 使用者體驗仍為主，但同一段文字在下游系統解析時也必須忠實還原。
  • 簡單性與未來延展性：先上線嚴格的必要欄位與穩定型別，待有證據支持再逐步演進到更豐富的實體圖譜。

失效模式

  • 結構性失效：JSON-LD 格式不正確或缺少必要欄位會導致 rich-result 不符合資格，並降低 AI 解析信心。
  • 語意漂移：若可見 lead/正文與結構化資料 description 出現分歧，系統可能將 Naly 內容視為低可信度或誤導。
  • 時間戳不一致： dateModified 時間延遲會讓預測文章出現過時的時效行為，而這類時間在業務上極為關鍵。
  • 網站地圖熵值： lastmod 過期的優先值、過大的網站地圖，或被 robots 阻擋的路徑，都可能讓新鮮內容對爬蟲不可見。
  • 過度最佳化但不可驗證的聲明：若結構化欄位包含不可驗證敘述，即使標記語法正確，也可能被品質檢查懲罰。
  • 版本鎖定不一致：混合式渲染路徑（快取路由處理器＋動態編輯）可能造成 metadata 分裂腦與 URL 快照不一致。

實作說明

對於 Naly，實際推進應採取分階段且可預測的方法：

  • 在變更渲染前，先在文章領域模型加入 required metadata schema。
  • 新增單一 JSON-LD builder 函式，使用型別安全輸入與穩定排序。
  • 在寫入時標準化 lead、來源 URL 與圖片 URL。
  • 新增 generateMetadata 以支援動態文章級標籤並 app/sitemap.ts 此外 app/news-sitemap.ts 配合明確的變更時窗。
  • 在圖片對發現有實質影響時，輸出專用圖片參考。
  • 新增 CI 檢查，驗證 JSON-LD 有效性與結構化資料規範符合性。
  • 加入 Canary 儀表板：網站地圖新鮮度、schema 解析成功率與 lead 對正文一致性。

此設計與現有的 Naly 執行元件相容，且實作範圍僅限於發佈時程式碼路徑，與團隊目標一致：在不替換既有內容流程的前提下，最大化信任、留存與可發現性。

參考資料

Sources