網站的結構化資料標記產生器是一個專注的工具，可在您的瀏覽器中產生 JSON-LD 腳本，準備貼到您網站的單一頁面中。該腳本遵循 Schema.org 詞彙，並封裝在 application/ld+json 元素中，讓解析器（包括 Google）能夠讀取，而無需將其執行程式碼。產生器僅支援幾種範本類型 — WebSite、Article、Organization — 並詢問已出現在目標頁面上的事實：標題、描述、標準網址，以及（針對文章）以 YYYY-MM-DD 格式表示的真實發布日期。它接受絕對的 HTTP 或 HTTPS 網址，省略空白的可選欄位，跳脫引號、反斜線、換行符號和小於符號，並使用 JSON.stringify 序列化結果，而非手動串接字串。產生器絕不會將結果執行程式碼，因此當該片段稍後貼到您的 HTML 時，輸入的結束腳本序列無法終止 JSON-LD 元素。不會傳送任何資料到伺服器、不會注入到您的 CMS，也不會針對您的線上頁面進行驗證，直到您自行貼上片段並檢查已發布的網址。
為每個頁面角色選擇正確的類型
只要將每個頁面對應到其邏輯角色，而非到處複製貼上相同的腳本，三種類型的產生器對大多數小型網站來說就已足夠。首頁和任何全站搜尋入口通常使用 WebSite 類型。編輯頁面 — 部落格文章、新聞報導、長篇指南、新聞稿 — 使用 Article 類型。Organization 類型適用於公司關於頁面、聯絡頁面，以及應在整個網域一次性聲明法定實體的全站頁尾品牌區塊。如果您的 CMS 在已帶有全站 WebSite 腳本的標頭的網址上呈現文章，則兩個腳本可在同一份文件中共存；兩者描述不同的實體，並由解析器獨立讀取。
| 頁面角色 | 範本類型 | 需要收集的必要事實 |
|---|---|---|
| 首頁、網站入口、全域品牌區塊 | WebSite | 名稱、標準網址、描述 |
| 部落格文章、新聞報導、長篇指南 | Article | 標題、標準網址、描述、作者姓名、發布日期 |
| 關於頁面、聯絡頁面、頁尾法定實體 | Organization | 名稱、網址、描述 |
在開啟產生器之前需要準備的事實
在您操作表單之前，請在另一個分頁開啟目標頁面，僅記下讀者在該頁面上可看到的事實。對於 WebSite，這包括品牌名稱、訪客在網址列中看到的標準網址，以及首頁上已存在的一或兩句描述。對於 Organization，除了上述三項外，還包括您實際在標頭中發布的標誌絕對網址，以及您從網站連結到的任何官方社群個人檔案。對於 Article，請收集標題、標準網址、描述、作者署名中顯示的名稱，以及 YYYY-MM-DD 格式的發布日期 — 此工具會拒絕符合數字模式但並非真實西曆日期的字串，因此像 2026-02-30 這樣的值會明顯失敗，即使它看起來像日期。可在不削弱腳本的情況下留空的可選欄位包括文章圖片網址、Organization 標誌網址，以及 Organization sameAs 清單。
| 範本 | 必填欄位 | 選填欄位 |
|---|---|---|
| WebSite | name, url, description | 必填以外無其他欄位 |
| Article | headline, url, description, author.name, datePublished | image |
| Organization | name, url, description | logo, sameAs |
如需快速參考每個欄位的含義和邊界，請參閱結構化資料標記產生器欄位與規則速查表。
如何為您的網站使用結構化資料標記產生器
- 開啟結構化資料標記產生器，並從類型選擇器中選擇 WebSite、Article 或 Organization，讓表單顯示該實體的相關欄位。
- 在另一個分頁中閱讀目標頁面，並記下名稱、描述、標準網址，以及（針對 Article）YYYY-MM-DD 格式的真實發布日期。
- 僅使用這些可見的事實填寫表單，凡是需要網址之處，皆使用絕對的 HTTP 或 HTTPS 網址；相對路徑、javascript: 網址以及格式錯誤的值會明顯失敗，而不會被靜默接受。
- 若沒有準確的內容可填，請將選填的 image、logo 和 sameAs 欄位留空；產生器會省略空白的選填屬性，而非輸出空字串。
- 對於 Organization sameAs，請將每個個人檔案網址分別貼在獨立的一行 — 此工具會解析、標準化並去除重複項目，使最終清單不含重複項。
- 在預覽窗格中檢查產生的 JSON-LD 腳本，確認 https://schema.org 內容、選定的 @type，以及安全的腳本包裝，然後複製該腳本。
- 將腳本貼到目標頁面範本中 — 可在文件 head 或 body 末尾 — 然後發布或儲存。
- 使用 Google 的 Rich Results Test 驗證線上網址，然後在任何重大內容變更後重新檢查，使標記持續符合訪客實際看到的內容。
將 JSON-LD 腳本放置於頁面中
JSON-LD 可以放在 head 或 body 末尾；只要 script 元素屬於已轉譯 HTML 的一部分，而非在文件載入後由 JavaScript 注入，兩種放置方式皆有效。包裝類型為 application/ld+json，腳本主體是單一 JSON 物件，開頭為 { "@context": "https://schema.org", "@type": "...", ... }。如果同一頁面承載多個實體 — 例如，列出近期文章的首頁 — 請將每個實體作為獨立的 script 元素，並使用各自的 @type，而非將其巢套或合併為一個。請勿將 JSON-LD 包裝在 HTML 註解、iframe 中，或在轉譯時執行的內聯 JavaScript 字串中；結構化資料解析器可能看不到隱藏在可執行程式碼中的標記，而產生器刻意跳脫小於符號和 JavaScript 行分隔字元，使輸入的結束腳本序列在貼入 HTML 時無法終止 JSON-LD 元素。
發布後驗證線上網址
語法正確的腳本僅是首要條件，而產生器無法檢查其所產生的聲明是否真實、最新或顯示於頁面上。頁面上線後，請將公開網址貼到 Google 的 Rich Results Test，以查看該網址符合哪些結構化資料功能，以及解析器認為缺少哪些屬性。然後開啟 Search Console，在強化功能或索引報告中檢查該網址，以確認搜尋引擎實際儲存的內容。在任何標題變更、作者變更、發布日期修正或標準網址變更後，請重新執行兩項檢查；標記必須與訪客實際閱讀的內容保持同步。Google 關於結構化資料的說明文件明確指出，標記應符合可見內容、使用適當的特定類型，並避免藏、不相關或捏造的資訊 — 產生器無法強制執行該符合性，而新增結構化資料本身並不保證複合式結果、排名提升、索引或被納入人工智慧回答中。
三類型產生器的限制與何時該擴充
一個專注的三類型產生器刻意僅支援 WebSite、Article 和 Organization。它不會產生含評分的 Product 評論、LocalBusiness 營業時間、Recipe 營養資訊、JobPosting 薪資、Event 優惠、醫療資料或其他高風險結構化資料。它也不會擷取網址、將程式碼注入您的網站、驗證 CMS，或在頁面編輯後保持標記同步 — 一旦您將腳本從瀏器複製出來，發布者即負責放置與維護。如果您的網站需要 FAQPage、BreadcrumbList、HowTo，或包含 dateModified、時區感知時間戳記、多位作者或 publisher 物件的更富 Article，請先產生基本腳本，然後根據準確的來源資料手動新增缺少的屬性，而非捏造數值。對於超出三種範本以外的結構化資料，權威類型定義 — 包括schema.org/Article、WebSite 和 Organization — 描述了該工具未提供的更廣泛詞彙和屬性。
如需更深入的探討，請參閱在 Mac 上的 Hreflang 產生器：三步瀏覽器工作流程。