結構化資料標記產生器是一個瀏覽器端工具,可將單一頁面的可見事實轉換為 JSON-LD 程式碼片段,適用於三種 Schema.org 類型之一 —— WebSite、Article 或 Organization —— 讓發布者無需 API、上傳或注入程式碼即可批次建立結構化資料。對於需要在多個模板上加入結構化資料的網站,實務上的做法是在目前的瀏覽器分頁中,為每個頁面模板產生一個聚焦的 JSON-LD 物件,將產生的指令碼複製到對應的 CMS 或 HTML 檔案中,然後驗證實際發布的 URL,而不只是驗證複製出來的片段。在此情境下,批次作業並非單一按鈕即可處理多個頁面;而是一個受控、可重複的工作流程,由發布者決定哪個模板接收哪種類型,以及哪些事實會出現在指令碼中。
瀏覽器中的批次結構化資料標記工作流程
批次作業的核心概念是「重複」,而非自動化。開啟產生器、選擇符合特定頁面模板的 Schema.org 類型、輸入在目標頁面上已可見的事實、複製 JSON-LD 指令碼,然後貼到對應的模板中。由於 結構化資料標記產生器 完全在目前的瀏覽器分頁中執行,發布者可以掌控哪些內容會被標記,以及哪個頁面會接收標記。一個內容網站典型的批次執行流程如下:首頁一組 WebSite 片段、關於頁一組 Organization 片段,以及每個部落格文章模板一組 Article 片段。工作會透過在多個模板上重複相同的三個步驟來擴展,而不是上傳試算表並等待伺服器回傳 ZIP 檔。
若想更廣泛地了解在沒有 API 時,本地工作流程為何重要,請參閱 無需 API 產生結構化資料標記:本地 JSON-LD 工作流程。
產生之前需要先收集的欄位
三種模板需要不同組合的屬性,產生器會省略任何空白的選填值,而不是輸出空字串。在開始之前先收集這些事實,可以避免批次作業中途發生表單錯誤。下表顯示每種類型所需的內容,以及視為選填的項目。
| Schema.org 類型 | 必要屬性 | 選填屬性 | 驗證注意事項 |
|---|---|---|---|
| WebSite | name、canonical URL(絕對路徑)、description | — | 必要文字會經過修剪,不得為空。 |
| Article | headline、canonical URL(絕對路徑)、description、巢狀 Person 作者含 name、datePublished | image(絕對 URL) | datePublished 必須是符合 YYYY-MM-DD 格式的真實西曆日期;像 2026-02-30 這類數值會驗證失敗。 |
| Organization | name、URL(絕對路徑)、description | logo URL(絕對路徑)、sameAs URL(每行一個) | sameAs 項目會逐一解析、正規化並去除重複。 |
三種類型都會嵌入固定的 context https://schema.org 以及所選的 type。每個 URL 欄位都會拒絕相對路徑、javascript: URL 與格式錯誤的值,因此在開始批次作業之前先收集好規範的絕對 URL 較為省時。如需 Article 模板背後的欄位定義,Schema.org — Article 參考文件記載了產生器所使用的必要與建議屬性。
一次為一個頁面產生 JSON-LD 片段
下列有序清單涵蓋單一頁面模板。對每個你想標記的模板重複相同的工作流程 —— 這種重複正是本工具所支援的批次模式。
- 在瀏覽器分頁中開啟結構化資料標記產生器,並選擇 WebSite、Article 或 Organization。所選類型對應的欄位會隨即顯示。
- 只輸入在目標頁面上已可見的事實與絕對 URL。必要文字欄位會經過修剪,且不得留空;URL 欄位必須以 http:// 或 https:// 開頭。
- 對於 Article,請以 YYYY-MM-DD 格式輸入發布日期。產生器會驗證其是否為真實的西曆日期,因此即使數字格式正確,2026-02-30 也會被拒絕。
- 對於 Organization,請將 sameAs URL 每行一個輸入。每一行會在指令碼序列化之前,個別進行驗證、正規化並去除重複。
- 檢查產生的 JSON-LD 指令碼。該指令碼會將資料包裹在 application/ld+json 區塊中,並對引號、反斜線、換行、小於符號及 JavaScript 行分隔字元進行跳脫處理,以確保在貼入 HTML 時不會意外終止 JSON-LD 元素;輸出內容採用 JSON.stringify 建構,而非手動字串串接。
- 將指令碼複製到對應的頁面模板,然後使用 Google 的 Rich Results Test 驗證最終發布的 URL,並檢查 Search Console,而不是只驗證複製出來的片段。
產生器強制執行的規則,讓你避免無效的標記
由於產生器在本機執行,並會明確地拒絕錯誤的輸入,批次作業傾向於提早發現問題,而不是產出看似正常、稍後卻失敗的標記。必要文字會經過修剪,不得為空,這代表一旦欄位留空,name、headline 或 description 為空的情況會立即被抓到。URL 欄位必須是絕對的 HTTP 或 HTTPS —— 相對路徑、javascript: URL 與格式錯誤的值會在輸入時即明確失敗。Article 日期會以真實的西曆日期進行驗證,而不僅是符合日期格式的字串,因此即使像 2026-02-30 這樣的數值,其數字格式符合 YYYY-MM-DD,也會被拒絕。選填的 image、logo 與 sameAs 屬性在空白時會被省略,而不是輸出為空字串,這可以避免空白屬性誤導驗證工具與下游解析器。
Organization 的 sameAs 項目以每行一個的方式輸入,接著進行解析、正規化並去除重複,因此即使貼上兩次相同的個人檔案 URL,最終也只會保留一筆紀錄。該工具絕不會將結果當作程式碼執行,因此即使輸入值中包含關閉 script 的序列,在貼入 HTML 時也不會終止 JSON-LD 元素。測試期間會根據來源定義檢查八個屬性錨點:WebSite 的 name 與 URL;Article 的 headline、author 與 datePublished;以及 Organization 的 name、logo 與 sameAs。這些檢查合計可在指令碼被複製之前,抓出最常見的批次作業錯誤。
驗證發布的 URL,而不只是片段本身
語法有效的 JSON-LD 只是其中一項要求,即使驗證工具確認複製出來的片段,也無法證明該標記所描述的頁面,是訪客實際能閱讀的內容。結構化資料簡介 摘要了 Google 目前的指引,內容指出:結構化資料必須代表主要的可見內容、使用適當的特定類型、納入相關搜尋功能要求的屬性,並避免隱藏、無關、誤導或捏造的資訊。產生器無法檢查目標頁面,因此發布者仍須負責確保兩者對應。
將指令碼貼入模板並發布之後,請將實際的 URL 透過 Google 的 Rich Results Test 進行測試,並在 Search Console 中查看相關的查詢。每次進行重大內容變更後,請一併檢視產生的數值與實際呈現的頁面,並讓標記與訪客實際能閱讀的內容保持同步。加入結構化資料並不保證會出現複合式結果、排名提升、索引,或被納入 AI 回答中;搜尋功能可能會變動、支援的屬性可能與更廣泛的 Schema.org 詞彙有所不同,而是否符合資格取決於指令碼之外的內容與政策要求。驗證工具可以確認語法與部分必要屬性,但無法證明這些聲明是否屬實、是否為最新、是否可見,或是否放置在正確的規範頁面上。
產生器未涵蓋的部分
了解工具的邊界,是健康批次工作流程的一部分。此聚焦版本不會產生 Product 評論、LocalBusiness 營業時間、Recipe 營養資訊、JobPosting 薪資、Event 票券、醫療資料、評分,或其他較高風險的結構化資料。它不會抓取 URL、將程式碼注入網站、驗證 CMS,或在頁面內容變更後維護標記 —— 因此批次作業在片段貼上並驗證完畢時即告結束,並非等到網站日後被編輯才算完成。需要 dateModified、具時區的時間戳記、多位作者或發布者物件的發布者,應在片段產生後,依據準確的來源資料補上這些屬性。對於超出三種模板之外的結構化資料,請使用官方各類型的專屬文件,而不是將本工具勉強擴展到其範圍之外。
如需更深入的了解,請參閱 免註冊的批次 URL 產生器:預期功能。