結構化資料（Structured Data）是一段寫在網頁原始碼裡、給搜尋引擎看的標準格式標籤。它不會改變讀者看到的畫面，但會明確告訴 Google：這頁是一篇文章、作者是誰、發布日期是哪天；或者這是一份食譜、烹調時間 30 分鐘、有 128 則評分。Google 讀懂之後，才有機會把你的頁面顯示成帶星等、帶圖片、帶麵包屑導覽的「複合式搜尋結果」（Rich Results），而不是一條普通的藍色連結。
對不會寫程式的部落客來說，最短路徑是：用 WordPress 的 SEO 外掛（Yoast SEO 或 Rank Math）自動輸出 Organization、WebSite、Article、BreadcrumbList 這四組基本標記，再用 Google 的「複合式搜尋結果測試」驗證，最後在 Search Console 追蹤成效。整個流程可以完全不碰一行 JSON。
但有件事得先講清楚：網路上大量教學仍在教人加 FAQ Schema 和 HowTo Schema 來換搜尋結果版位——這兩種在 Google 搜尋已經完全不會顯示了。所以這篇會先把 2026 年「還有效」與「已失效」的類型分清楚，再進實作，免得你花半天做了一件不會有結果的事。
結構化資料到底在做什麼？
搜尋引擎讀一個網頁時，看到的是一堆文字和 HTML 標籤。它可以猜「2026/09/06」大概是日期，但猜不出這是發布日、修改日還是活動日期；可以猜「4.8」是個數字，但猜不出這是評分、價格還是重量。
結構化資料的作用，就是把這些猜測變成明確宣告。用 schema.org 這套共通詞彙，你直接寫成「datePublished 是 2026-09-06」「ratingValue 是 4.8」，機器就不用猜了。
Google 的 John Mueller 在 2026 年 1 月談到結構化資料對搜尋與 LLM 的價值時，講得很直白：「Some features thrive with structured data… Pricing, shipping, availability for shopping is basically impossible to read in high fidelity & accurately from a text page.」（有些功能非常依賴結構化資料⋯⋯購物的價格、運費、庫存，基本上不可能從一段文字裡高精度且準確地讀出來。）
反過來說，能從文字裡輕鬆讀懂的東西，加標記的邊際效益就低。這是判斷「哪些該加、哪些不必加」的核心原則，後面會一直用到。
另外，結構化資料是基本功之上的加分項，不是替代品。如果你的標題階層、語意標籤本身就是亂的，先把那一層補起來會更划算——這部分可以參考 為什麼 HTML 標籤是 SEO 最被忽略的基本功？。
先確認現況：這些 Schema 已經拿不到複合式搜尋結果了
2023 到 2026 年之間，Google 陸續砍掉了一批結構化資料功能，官方說法是為了「簡化搜尋結果頁面」。這些類型的標記本身沒有錯誤，只是 Google 搜尋不會再用它們產生任何特殊版位。
| 類型 | 狀態 | 時間點 |
|---|---|---|
| HowTo（步驟教學） | Google 搜尋不再顯示，說明文件已移除 | 2023 年 9 月 14 日 |
| FAQPage（常見問題） | 先限縮至權威政府與健康網站，之後全面停止顯示，說明文件於 6 月移除 | 2026 年 5 月 7 日 |
| Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing | 停止顯示，並自 Search Console 報告與複合式搜尋結果測試中移除 | 2025 年 9 月起 |
| Practice Problem（練習題） | 說明文件淘汰，工具與報告支援移除 | 2025 年 11 月起 |
幾個需要注意的細節：
- FAQ 標記本身沒有變成違規。你可以留著給其他搜尋引擎或 AI 系統讀，只是不該再期待 Google 給你版位。文章裡放「常見問題」段落對讀者依然有價值——這篇文章結尾也有一段 FAQ——但那是內容價值，不是 Schema 換來的。
- Book Actions 沒有被砍。Google 在 2025 年 11 月移除了它的淘汰標示，確認仍有搜尋功能使用這組標記。如果你看到把 Book Actions 列為「已全面退場」的整理，那份資料已經過時。
- 這些變更不影響排名。Google 明確表示這是搜尋結果版面的簡化，跟排名系統無關。
從這張表可以看出一個模式：被砍掉的幾乎都是「小眾、視覺化的 SERP 功能」，留下來的則是描述實體與關係的基礎類型。Mueller 的建議也是同一個方向——把力氣放在長期穩定、描述「這是什麼」的結構化資料，而不是追短期的視覺版位。
部落客真正該加的四組結構化資料
不需要幾十種類型全上。對一個內容型部落格，下面四組覆蓋了絕大部分價值，而且都能被外掛自動處理。
1. Organization（或 Person）：宣告網站是誰的
這組告訴 Google 你的品牌名稱、logo、官網、社群帳號。個人部落格可以改用 Person。
Google 的建議很明確：「建議將這項資訊放在首頁或有關貴機構簡介的單一頁面」，例如「關於」頁面，「你不需要在網站的每個網頁中都加入這項資訊」。官方也提醒「並沒有所謂必要屬性」，只要加上適用的欄位即可。
| 欄位 | 填什麼 | 注意事項 |
|---|---|---|
| name | 品牌或個人名稱 | 跟網站上顯示的一致 |
| url | 首頁網址 | 用正式版本，含不含 www 要跟 canonical 一致 |
| logo | logo 圖片網址 | 不得小於 112 × 112 px，網址必須可被檢索與索引，且在白底上看得清楚 |
| sameAs | 社群或其他平台的品牌／個人頁網址 | 可放多個，用來串起同一個實體在網路上的分身 |
| contactPoint、email、telephone、address | 聯絡方式 | 有才填，沒有就略過 |
sameAs 特別值得花時間填。它的作用是把「www.wudelay.com 的 Wudelay」和「Threads 上的 Wudelay」「Instagram 上的 Wudelay」連成同一個實體。在搜尋引擎與 AI 系統都往「理解實體」方向走的現在，這是成本極低但語意收益明確的一項。
2. WebSite：讓網站有個可被引用的節點
描述整個網站的名稱與網址。單獨看它作用不大，但它是其他標記可以參照的錨點——外掛輸出的 Schema 通常會讓每一頁的 WebPage 指回同一個 WebSite。
3. Article / BlogPosting：每一篇文章的核心標記
這是部落格最主要的一組。Google 支援 Article、NewsArticle、BlogPosting 三種類型，一般部落格文章用 BlogPosting 或 Article 都可以。
值得注意的是：Article 沒有強制必要屬性，Google 的說法是「建議根據內容適用情況加入屬性」。但實務上，下面這幾個欄位缺了會明顯削弱標記的意義。
| 欄位 | 填什麼 | Google 的具體要求 |
|---|---|---|
| headline | 文章標題 | 建議用精簡標題，「部分裝置可能會截斷冗長的標題」 |
| image | 文章代表圖 | 建議提供多張，涵蓋 16:9、4:3、1:1 三種長寬比；寬 × 高至少 50K 像素；網址必須可被檢索與索引 |
| datePublished | 首次發布時間 | ISO 8601 格式，建議附時區，例如 2026-09-06T14:30:00+08:00 |
| dateModified | 最後修改時間 | 同樣使用 ISO 8601 格式 |
| author | 作者，型別為 Person 或 Organization | 應包含 author.name 與 author.url；name 只放名字，不要塞職稱、發布者名稱或敬語；多位作者要各用一個獨立的 author 欄位，不要寫成一串字串 |
author.name 那一條是新手最常踩的。「Wudelay 主編 王小明」是錯的，「王小明」才是對的；職稱可以另外放在 jobTitle，發布者放在 publisher。
4. BreadcrumbList：麵包屑導覽
告訴 Google 這頁在網站階層中的位置，搜尋結果的網址列會顯示成「首頁 > SEO > 這篇文章」，而不是一串長網址。
兩個實作重點：
- 必須至少有兩個 ListItem，每個要有 position（整數）、name（顯示文字）、item（網址；最後一項可以省略 item）。
- 這項功能只在電腦版搜尋結果顯示。Google 在 2025 年 1 月更新了說明文件，把適用範圍註明為電腦版。手機上加了不會出現，但仍有助於 Google 理解網站結構，還是值得加。
如果同一頁有多條路徑可以抵達（例如同時屬於兩個分類），Google 允許在同一個 script 裡用陣列放多組導覽路徑。
再依內容類型追加
上面四組是地基。如果你的內容剛好落在下面這些類型，再往上加一層：
- Recipe：食譜文，可帶出料理時間、熱量、評分。
- Product：有在賣東西才用，可帶出價格、供貨狀態、評分。
- VideoObject：頁面有嵌入自製影片時。
- Event：活動報名頁。
- LocalBusiness：有實體店面。
反過來，純知識型的部落格文章不需要硬套 Product 或 Review。標記必須真實反映頁面內容，這點 Google 寫在一般指南裡：「請勿為網頁讀者看不到的內容加上標記」、「請勿為不相關或容易誤導使用者的內容加上標記」。
三種格式怎麼選：JSON-LD、Microdata、RDFa
結構化資料有三種寫法，Google 三種都讀，但態度不一樣。
| 格式 | 寫法 | Google 立場 | 適合誰 |
|---|---|---|---|
| JSON-LD | 獨立的一段 script，跟 HTML 內容分開 | 建議使用；官方說「巢狀資料項目可透過更簡易的方式表達」 | 所有人，尤其是新手 |
| Microdata | 把屬性寫進既有的 HTML 標籤裡 | 支援，但要改動內容結構 | 已有大量既有標記的舊站 |
| RDFa | HTML5 擴充屬性，同樣寫進標籤裡 | 支援 | 特定框架或既有實作 |
對新手，答案只有一個：用 JSON-LD。理由很實際——Microdata 和 RDFa 是把標記纏在 HTML 裡，改版面就可能弄壞標記；JSON-LD 是一整塊獨立的 script，貼上、修改、刪掉都不會動到讀者看到的內容，出錯也好排查。
兩個常被問到的技術點，Google 文件都有明確答案：
- 放 head 還是 body？都可以。官方描述是「嵌入在 HTML 網頁的 <head> 和 <body> 元素內 <script> 標記中」。
- JavaScript 動態插入的算不算？算。Google「能夠解讀以動態方式插入網頁內容的 JSON-LD 資料」，包含由 JavaScript 或內容管理系統插入的。這也是為什麼 WordPress 外掛的做法沒問題。
路線 A：用 WordPress 外掛（不寫程式的預設選項）
如果你的站在 WordPress 上，這是應該優先走的路。SEO 外掛不只是幫你生成一段代碼，而是自動維護整個網站的 Schema——每發一篇新文章都會自動帶上正確的日期、作者、圖片，不用手動同步。
Yoast SEO 與 Rank Math 的差別
| 比較項目 | Yoast SEO | Rank Math |
|---|---|---|
| 預設輸出 | 一個 @graph 物件，核心包含 WebPage、WebSite、Organization（或 Person），再依頁面類型延伸 Article、BreadcrumbList、Person、Product、ImageObject、Review | 依全域設定自動套用預設 Schema 類型，可在單篇編輯畫面覆寫 |
| 免費版類型數量 | 以自動輸出的核心 graph 為主，額外類型透過整合外掛擴充（WP Recipe Maker、The Events Calendar、Seriously Simple Podcasting、WooCommerce SEO） | 官方文件列出免費版支援 28 種類型，Pro 再多 9 種 |
| 單篇文章調整 | 透過 Schema 設定調整內容類型 | 在 Gutenberg 工具列點 Schema 圖示開啟 Schema Generator，用表單填欄位 |
| 付費才有 | 更細的類型控制與整合 | Schema Templates 與顯示條件、Custom Schema Builder、進階編輯器、代碼驗證、單頁多個 Schema |
結論很簡單：兩個都夠用，但不要兩個一起裝。已經在用其中一個就繼續用，不必為了 Schema 換外掛。真的要選，Rank Math 的表單式 Schema Generator 對新手的心理門檻比較低；Yoast 的 @graph 架構在跨頁面實體關聯上比較完整。
Yoast 的 @graph 為什麼重要
Yoast 官方的技術文件把設計理念寫得很清楚：「The core of our approach is to output a ‘base script’ — a @graph object rendered in JSON-LD — which describes the WebPage, the WebSite, and the Organization.」並且「These pieces are contained in one or more @graph objects, which enables us to cross-reference pieces by ID.」
白話講：與其把所有資料層層包在一起，不如把每個東西寫成獨立節點、各自給一個 @id，然後互相指來指去。Article 指向作者 Person 的 @id，WebPage 指向 WebSite 的 @id，形成一張圖。這比一堆各自獨立、彼此不認識的標記，更能讓機器建立「誰寫的、屬於哪個站、屬於哪個品牌」的完整關係。
裝好之後要做的四件事
- 設定網站身分。在外掛的一般設定裡選「機構」或「個人」，填名稱、上傳 logo（記得不小於 112 × 112 px）。這決定了全站的 Organization / Person 標記。
- 填社群連結。外掛的社群設定會轉成 sameAs。有幾個填幾個。
- 確認文章預設類型。Yoast 在「內容類型」設定、Rank Math 在 Schema 全域設定，把「文章」的預設設成 Article 或 BlogPosting。
- 確認作者頁面有內容。author.url 通常指向作者彙整頁。如果那頁是空的或被 noindex，這個連結的價值會打折。
最容易被忽略的陷阱：重複標記
這是新手第二常見的坑：外掛已經自動輸出 Article 了，你又照網路教學手動貼一段 Article JSON-LD 到主題檔或頁尾。結果同一頁出現兩個 Article 節點，日期、作者、圖片還可能互相打架。
Google 通常不會因此懲罰你，但它得自己決定要相信哪一份，你等於白做一次工還增加了不一致的風險。動手加任何標記之前，先做這件事：用複合式搜尋結果測試跑一次你的頁面，看看已經有什麼。先看現況，再決定要補什麼。
路線 B：手寫 JSON-LD
不是 WordPress、或想完全掌控輸出內容時，就自己寫。實際上比想像中簡單——JSON-LD 就是一個有固定欄位名稱的物件。
一篇部落格文章的完整範例，放進 head 或 body 任一處都可以：
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “BlogPosting”,
“headline”: “結構化資料怎麼加？Schema 標記新手實作指南”,
“image”: [“https://example.com/img-16×9.jpg”, “https://example.com/img-4×3.jpg”, “https://example.com/img-1×1.jpg”],
“datePublished”: “2026-09-06T09:00:00+08:00”,
“dateModified”: “2026-09-06T09:00:00+08:00”,
“author”: [{ “@type”: “Person”, “name”: “王小明”, “url”: “https://example.com/author/ming” }],
“publisher”: { “@type”: “Organization”, “name”: “Example”, “logo”: { “@type”: “ImageObject”, “url”: “https://example.com/logo.png” } },
“mainEntityOfPage”: “https://example.com/seo/structured-data-schema-guide”
}
</script>
麵包屑再加一段獨立的 script：
<script type=”application/ld+json”>
{
“@context”: “https://schema.org”,
“@type”: “BreadcrumbList”,
“itemListElement”: [
{ “@type”: “ListItem”, “position”: 1, “name”: “首頁”, “item”: “https://example.com/” },
{ “@type”: “ListItem”, “position”: 2, “name”: “SEO”, “item”: “https://example.com/seo/” },
{ “@type”: “ListItem”, “position”: 3, “name”: “結構化資料怎麼加” }
]
}
</script>
手寫時的三個檢查點：
- 逗號。JSON 最後一個項目後面不能有逗號，這是新手最大宗的語法錯誤來源。貼進 JSONLint 或 VS Code 掃一次再上線。
- 用直引號。從 Word、Google 文件或聊天視窗複製過來的代碼，引號常常變成全形或彎引號（「」、“”），JSON 會直接解析失敗。
- 日期要跟頁面顯示的一致。頁面寫「2026 年 9 月 6 日更新」，dateModified 就不能停在三年前。
另外，如果你的頁面連 Google 都還沒收錄，結構化資料再完美也不會有任何效果。收錄問題請先處理掉：網站沒被 Google 收錄？6 個檢查步驟。
驗證：兩個工具，用途完全不一樣
很多人只知道其中一個，結果測出「沒有偵測到任何項目」就以為自己寫錯了。這兩個工具檢查的東西根本不同。
| 項目 | 複合式搜尋結果測試（Rich Results Test） | 結構定義標記驗證工具（Schema Markup Validator） |
|---|---|---|
| 誰提供 | schema.org | |
| 檢查什麼 | Google 目前支援的複合式搜尋結果類型，以及能不能通過該類型的資格 | 所有 schema.org 標記的語法正確性，不做 Google 專屬驗證 |
| 會顯示什麼 | 可產生哪些複合式搜尋結果、預覽畫面，以及必要／建議屬性的問題 | 解析出來的完整標記結構與語法錯誤 |
| 什麼時候用 | 想確認能不能拿到搜尋版位 | 標記在 Rich Results Test 裡沒出現，或想確認整段語法有沒有寫壞 |
Google 自己的建議順序是：「建議您先從複合式搜尋結果測試開始，瞭解 Google 能為您的網頁產生哪些複合式搜尋結果。如要進行一般結構定義驗證，請使用結構定義標記驗證工具測試所有類型的 schema.org 標記，無須進行 Google 專屬驗證。」
典型情境：你加了 Organization 標記，跑 Rich Results Test 卻顯示「未偵測到項目」。這不代表你寫錯了——只是 Organization 在多數情況下不會被 Google 呈現為特殊的複合式結果項目。這時改用 Schema Markup Validator，就能看到標記其實好好地在那裡。
另外還有第三個工具：Search Console 的網址檢查工具。差別在於前兩個測的是「這段代碼本身對不對」，網址檢查測的是「Google 實際抓到的那一版是什麼」。如果你的標記是靠 JavaScript 產生的，這個差別會很關鍵。
上線之後：用 Search Console 追蹤
測試工具一次只能看一頁。全站狀況要看 Search Console 的複合式搜尋結果報告，它會按類型分別列出：
- 有效項目：「沒有任何重大問題，且可在 Google 上顯示為複合式搜尋結果的項目」。
- 無效項目：「至少有一個重大問題，導致無法以複合式搜尋結果的形式顯示」。
對應到欄位就是：缺少必要屬性 = 重大問題 = 直接失去資格；缺少建議屬性 = 非重大問題，仍然有資格，只是呈現品質會打折。
報告裡有一句話值得記住：「一個問題可能會影響不同網頁的結構化資料項目，或是單一網頁的多個結構化資料項目。」也就是說，看到「1,240 個項目有錯誤」時先別慌，通常是同一個範本錯誤被複製到全站——改模板一個地方，1,240 個一起修好。這也是為什麼外掛路線比逐頁手動更省事。
還沒把 Search Console 裝起來的話，那是所有 SEO 工作的前置條件：SEO 實戰篇【零】：先裝好你的「儀表板」。
新手最常犯的 5 個錯誤
1. 標記的內容，頁面上看不到
Google 一般指南的第一條就是「請勿為網頁讀者看不到的內容加上標記」。常見狀況：文章裡根本沒有 FAQ 區塊，卻加了一堆問答標記；或標記寫「烹調時間 30 分鐘」，頁面上完全沒提到。這在 Google 眼中不只是無效，還可能被視為垃圾內容。
違規的後果，官方寫得很清楚：語法正確的結構化資料仍可能「無法在 Google 搜尋中顯示為複合式搜尋結果，或遭標記為垃圾內容」，嚴重的話網頁會受到人工判決處罰。
2. 自己給自己打星等（self-serving review）
這是評論摘錄最嚴格的一條規則：如果接受評論的對象能控制自己收到的評論——例如商家用嵌入式小工具張貼自家評論——那麼 LocalBusiness 和 Organization 就不能使用星等功能。評論必須來自獨立的使用者。
部落客最容易踩到的版本是：寫一篇自家課程或電子書的介紹頁，順手加上 4.9 星的 aggregateRating。這正好落在禁止範圍內。
如果是評測別人的產品，那是合法的 Review，但也有規格要求：author 必須在 100 字元以內、要有 itemReviewed 且帶有效的 name、reviewRating 要有 ratingValue。彙總評分則要 ratingValue，加上 ratingCount 或 reviewCount 其中之一。還有一個很容易忽略的細節：小數點要用句點不要用逗號——寫 4.4，不要寫 4,4。
3. 屬性貪多但每個都不完整
Google 的建議是「提供較少的建議屬性，但個個完整無誤」。與其把 20 個欄位都填一半，不如把 8 個核心欄位填到準確。
4. 圖片網址無法被檢索
Article 的 image 和 Organization 的 logo 都要求網址「必須可供檢索和建立索引」。如果你的圖片放在被 robots.txt 擋掉的目錄、需要登入才能看，或是用 CDN 的臨時簽名網址，Google 抓不到，這個屬性就等於沒填。
5. 加了就等排名上升
下一段專門講這件事。
加了結構化資料，排名會變好嗎？
直接回答：不會。結構化資料不是排名因素。
Google 的立場一直很一致——結構化資料影響的是「你的頁面在搜尋結果長什麼樣子」，不是「你排第幾名」。即使因為濫用而受罰，後果也是失去複合式搜尋結果，不是排名下滑。
那為什麼還要做？三個理由，按實際價值排序：
- 版位面積與點擊率。排名沒變，但你的結果多了縮圖、麵包屑、星等，在同一頁上就是比較顯眼。這是間接效益，不是排名效益。
- 資格門檻。某些搜尋功能沒有標記就完全沒資格進入，這不是「加分」而是「入場券」。購物類的價格、庫存資訊尤其明顯，因為那些資料如 Mueller 所說，本來就很難從文字裡準確讀出來。
- 降低機器理解的歧義。隨著 AI Overviews 這類功能把「顯示網頁」變成「詮釋網頁意義」，明確宣告實體與關係能減少系統誤判你在講什麼。但要注意：這是提高被正確理解的機率，不是保證被引用，目前沒有官方文件承諾標記能換來 AI 引用。
換句話說，結構化資料是把已經做好的內容「講清楚」，不是讓平庸的內容變好。內容本身的品質仍然是主軸——這部分可以參考 SEO 實戰篇【下】：網站內容－讓 Google 和讀者都看得懂；技術面的收錄與架構問題則在 SEO 實戰篇【上】：技術架構篇。
一份可以照著跑的實作順序
- 先測現況。把首頁和一篇代表性文章丟進複合式搜尋結果測試，看看外掛或主題已經輸出了什麼。
- 補全站身分。在 SEO 外掛裡設定 Organization 或 Person、logo、社群連結（sameAs）。
- 確認文章預設類型。把文章的預設 Schema 設成 Article 或 BlogPosting，並檢查作者頁面有內容、日期正確。
- 確認麵包屑有輸出。主題有麵包屑功能就開啟，外掛通常會自動附上 BreadcrumbList。
- 只在有需要時追加類型。食譜文加 Recipe，商品頁加 Product，其餘不要硬套。
- 重測一次。Rich Results Test 看資格，測不到就改用 Schema Markup Validator 確認語法。
- 兩週後看報告。到 Search Console 的複合式搜尋結果報告看無效項目，優先修「必要屬性缺少」的那些。
這套流程的關鍵在第 1 步和第 6 步。跳過測試直接貼代碼，是重複標記與語法錯誤的主要來源。
常見問題
結構化資料和 meta description 有什麼不一樣？
meta description 是一段給人看的敘述文字，Google 可能拿來當搜尋結果的摘要，也可能自己另外抓一段。結構化資料則是給機器讀的欄位化資料，用來判斷頁面「是什麼類型」以及各項屬性的值。兩者用途完全不同，不能互相取代。
加了結構化資料，多久會看到效果？
Google 必須先重新檢索並處理你的頁面，才可能顯示複合式搜尋結果，官方沒有承諾任何時程。可以用 Search Console 的網址檢查工具主動要求建立索引來加速，但即使處理完成，Google 也保留「不顯示」的決定權——通過測試代表有資格，不代表一定會出現。
還需要加 FAQ Schema 嗎？
就 Google 搜尋而言不需要，自 2026 年 5 月 7 日起這項功能已不再顯示，說明文件也已移除。標記本身不算違規，如果你希望其他搜尋引擎或 AI 系統讀到，可以保留。但文章裡的「常見問題」段落本身仍然值得寫——那是給讀者的價值，跟能不能拿到 Schema 版位是兩件事。
一個頁面可以放多段 JSON-LD 嗎？
可以。你可以用多個 script 標籤分別放 Article 和 BreadcrumbList，也可以用 @graph 把多個節點包在同一段裡並用 @id 互相參照——Yoast 走的就是後者。真正要避免的不是「多段」，而是「同一個東西被描述兩次而且內容不一致」。
不是 WordPress 的網站怎麼辦？
手寫 JSON-LD，或用網站平台內建的功能。多數現代平台都有內建的 Schema 設定；靜態網站或自製前端則直接把 script 寫進版型檔，讓文章的標題、日期、作者從資料來源動態帶入，避免每篇手動維護。核心原則跟 WordPress 完全一樣：標記內容必須跟頁面上實際顯示的一致。
結構化資料寫錯了會被 Google 處罰嗎？
單純的語法錯誤或欄位缺漏不會被處罰，結果只是拿不到複合式搜尋結果。真正有風險的是違反內容指南——標記讀者看不到的內容、標記不相關或誤導性的資訊、冒用他人身分。這類情況除了失去版位，網頁還可能受到人工判決處罰。