結構化資料疊加策略：同一頁面能放多種 Schema 嗎？

結構化資料是什麼？為什麼同一頁面需要多種 Schema

結構化資料是提供給搜尋引擎的「內容說明書」，讓 Google 與其他 AI 系統能精準理解頁面上每個區塊的意義。同一個頁面通常不只包含一種內容元素，例如文章頁同時有導覽路徑、作者資訊、常見問答，每一種都需要對應的 Schema 類型來標記，才能完整描述頁面內容。

先建立一個基本認知：Schema.org 是一套共通的詞彙表，用來標記網頁上的實體與關係。當搜尋引擎爬蟲造訪你的頁面時，它讀取的原始 HTML 是雜亂的標籤與文字，無法直接判斷哪一段是文章標題、哪一段是麵包屑、哪一個區塊是問答。結構化資料就是在 HTML 中加入一套明確的語意標記，讓機器可以辨識。

一個典型的部落格文章頁面，至少包含三種不同的內容元素：文章本身的標題與內文（Article）、頁面頂部的導覽路徑（BreadcrumbList）、文末的常見問答區塊（FAQPage）。這三種元素各自需要不同類型的 Schema 來標記，因此產生了一個實務上的核心問題：同一頁面可以同時放多種 Schema 嗎？答案是可以的，而且這是 Google 官方允許且鼓勵的做法，前提是每一種類型的標記都必須對應頁面上實際存在的內容。

接下來的章節會先建立 Schema.org 與 Google 支援類型的背景知識，再說明官方規則與實作方式，最後補上驗證流程、錯誤排除與 AI 搜尋時代的應用價值。

Schema.org 與 Google 支援的標記類型概覽

Schema.org 是由 Google、Microsoft、Yahoo 與 Yandex 共同維護的開放詞彙表，收錄了涵蓋人物、組織、事件、產品、文章、常見問答等數百種實體類型。Google 從中挑選並支援部分類型用於複合式搜尋結果（rich results），支援清單會隨政策調整。

理解 Schema.org 與 Google 支援範圍的差異，是規劃多重 Schema 疊加的第一步。Schema.org 收錄的詞彙非常廣泛，但 Google 只對其中一部分提供複合式搜尋結果的資格。標記了 Schema.org 但非 Google 支援的類型，不一定會產生錯誤，但也不會獲得特殊顯示效果，只能作為語意描述供其他系統解讀。

以下是幾個常用且 Google 有明確支援的類型，以及它們適用的頁面類型：

• Article：新聞文章、部落格文章、撰述文章，是最基礎的文章型標記，適用於所有內容型頁面。
• BreadcrumbList：麵包屑導覽路徑，適用於所有多層級架構的網站頁面。
• FAQPage：常見問答區塊，適用於含有明確問答結構的頁面，但 2023 年 8 月起 Google 限縮顯示範圍，僅限於政府、醫療、健康等可信賴網站。
• Organization：組織或公司資訊，適用於全站，通常放在首頁或聯絡頁面。
• Product：產品資訊，適用於產品頁或服務頁面，是電商網站的必要標記。
• WebSite：網站整體資訊，可搭配 SearchAction 標記站內搜尋功能，通常只放在首頁。
• Review 與 AggregateRating：評論與評分，適用於產品頁、餐廳頁、課程頁等含有使用者評價的頁面。

這些類型是後續章節討論疊加策略的核心組合元素。若想了解更完整的 Schema 類型分類與中文語意對照，可以參考Schema 中文意思與進階類型判斷流程。

同一頁面放多種 Schema 的官方立場與規則

Google 官方文件明確表示，同一頁面可以同時使用多種結構化資料類型，但每一種類型都必須對應頁面上實際存在的內容，且須各自符合 Google 結構化資料指南與品質政策。沒有「頁面只能標記一種 Schema」的限制，疊加是合法且常見的實作方式。

依據 Google 搜尋文件與結構化資料指南，共有三個核心原則：

第一個原則：內容真實存在。所有標記的內容都必須是用戶在頁面上可以看到的。不能為了取得複合式搜尋結果而標記頁面上沒有出現的評論、問答或產品資訊。這是最容易違反也最容易被 Google 以人工方式處罰的項目。隱藏標記（hidden text）屬於垃圾內容政策，與 CSS 隱藏文字不同，結構化資料若標記了用戶看不到的內容，同樣會觸犯此規範。

第二個原則：各自符合指南與政策。每一種類型都有自己的必要屬性與品質要求。例如 Product 類型需要標記價格與庫存狀態，FAQPage 需要符合問與答的格式規範，Article 需要標記 headline 與 author 等屬性。疊加多種類型時，不是「整包一起通過」就好，而是每一種類型都必須獨立通過該類型的驗證標準。

第三個原則：不需要隱藏其他類型。同一頁面可以同時符合 Article、BreadcrumbList、FAQPage 等多種條件，這些條件各自獨立，互不排斥。Google 會依據頁面上的標記判斷是否授予各類型的複合式搜尋結果資格，彼此之間沒有衝突。

有兩個常見的誤解需要澄清：第一，有人認為標記多種 Schema 會讓 Google 混淆頁面的主要目的，實際上只要每種類型都對應正確的區塊，Google 不會因為類型多元就降低判斷準確度。第二，有人擔心多種 Schema 疊加會被視為垃圾內容，實際上只要符合上述原則，疊加是正常且合理的做法。

三種標記格式與疊加適配性比較

Google 支援三種結構化資料格式：JSON-LD、Microdata 與 RDFa。其中 JSON-LD 是官方明確建議的格式，也是進行多重 Schema 疊加時最不容易出錯的選擇。三種格式在疊加適配性上有明顯差異。

JSON-LD 以獨立的 script 區塊嵌入 HTML 的 head 或 body 中，不會干擾頁面內容的閱讀順序與呈現。在同一頁面疊加多種類型時，JSON-LD 可以選擇用一個 script 區塊搭配 @graph 陣列包裝所有類型，或是以多個獨立 script 區塊分別放置。即使其中一個區塊的 JSON 語法有誤，也不會影響其他區塊的解析。

Microdata 與 RDFa 則是以 HTML 屬性（例如 itemscope、itemtype、property）直接在內容元素上標記。當同一頁面需要標記多種類型時，Microdata 必須在每個對應的 HTML 元素上加上屬性，巢狀結構容易產生衝突，且標記與內容高度耦合，後續維護任何一邊都會牽動另一邊。

以下是三種格式在多重 Schema 疊加情境下的比較：

從這個比較可以確認：JSON-LD 在疊加適配性上明顯優於另外兩種格式。若網站已經使用 Microdata 或 RDFa，建議規劃改版時逐步轉移到 JSON-LD，尤其當你需要疊加多種類型時，轉移的效益會非常明顯。

多重 Schema 疊加的實作方式

實作多重 Schema 疊加有兩種方式：第一種是在同一個 JSON-LD script 區塊內使用 @graph 陣列包裝多個類型，第二種是在頁面放置多個獨立的 JSON-LD script 區塊。兩種方式都被 Google 接受，差異在於管理方式與可讀性。

選擇哪一種方式取決於團隊的維護習慣與頁面的複雜度。以下分別說明兩種方式的寫法與適用情境。

@graph 陣列包裝多類型的寫法與範例

@graph 是在同一個 JSON-LD 區塊內，以陣列形式列出多個 Schema 物件。所有類型共用同一個 script 標籤，適合頁面結構固定、不需要頻繁增減類型的網站。維護時只需管理一個區塊，但這個區塊會隨著類型增加而變長，需要留意可讀性與版本控制。

以下是一個文章頁同時標記 Article、BreadcrumbList 與 FAQPage 的 @graph 範例：

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "多重 Schema 疊加實作指南",
      "author": {
        "@type": "Person",
        "name": "Kevin Lin"
      }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "首頁",
          "item": "https://9iseo.com.tw"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "SEO 技術",
          "item": "https://9iseo.com.tw/articles"
        }
      ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "同一個頁面可以放多種 Schema 嗎？",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "可以，但需符合各類型的適用條件與內容政策。"
          }
        }
      ]
    }
  ]
}

每個 @graph 內的物件都必須有獨立的 @type，且 @id 可以不重複。這個寫法的優點是集中管理，Google 在 Rich Results Test 中也會以單一 URL 一次驗證所有類型。

多個獨立 JSON-LD script 區塊的寫法與範例

多個獨立 script 區塊是在頁面分別放置各自獨立的 JSON-LD，每個區塊只負責一種類型。適合頁面功能不斷擴展、不同團隊各自維護不同 Schema 類型的情境。例如 SEO 團隊維護 Article 與 BreadcrumbList，內容團隊維護 FAQPage，各自更新各自的區塊，互不幹擾。

以下是多個獨立 script 區塊的範例結構：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "多重 Schema 疊加實作指南",
  "author": {
    "@type": "Person",
    "name": "Kevin Lin"
  }
}
</script>
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [...]
}
</script>
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [...]
}
</script>

兩種寫法各有適用情境：@graph 適合所有類型由同一位開發者或團隊統一管理的情況，多 script 區塊適合大型網站中不同類型由不同團隊各自維護的情況。如果其中一個 script 區塊發生 JSON 格式錯誤，多 script 區塊的寫法可以讓其他類型的標記不受影響，這在 @graph 寫法中較難達成，因為整個區塊會一起失效。

常見可疊加的 Schema 組合與使用情境

不同頁面類型有各自適合的 Schema 疊加組合。以下依據頁面類型列出常見的組合方式，並說明每一種類型標記的內容對應，幫助你判斷自己的頁面應該疊加哪些類型。

選對組合的關鍵在於：先盤點頁面上實際存在哪些內容區塊，再為每一種區塊選擇對應的 Schema 類型。不必為了豐富標記而硬加，頁面上沒有的內容就不應該標記。

以下針對前兩種最常見的組合提供更詳細的說明。

文章頁疊加組合範例

文章頁是多重 Schema 疊加最典型的應用場景。一篇標準的部落格文章頁面，至少包含文章本體、麵包屑導覽與常見問答三種內容元素。

Article 類型負責標記文章的核心資訊，包括標題、作者、發布日期、修改日期等必要屬性。麵包屑導覽路徑則反映出網站架構，Google 在搜尋結果中會顯示路徑，有助於使用者理解頁面在網站中的位置。FAQPage 則標記頁面底部常見問答區塊，若你的文章有 Q&A 格式的段落，就可以用這個類型標記。

關於 FAQPage 疊加，特別注意 Google 在 2023 年 8 月調整了顯示政策，目前僅限於政府、醫療、健康等可信賴網站可以在搜尋結果中顯示 FAQ 複合式結果。若你的網站不屬於這些類別，標記 FAQPage 仍然有助於 AI 解讀，但不會取得搜尋結果的特殊顯示。

產品頁疊加組合範例

產品頁的疊加組合以 Product 類型為核心，再輔以 BreadcrumbList 與 Review（或 AggregateRating）。Product 類型需要標記產品名稱、影像、價格、庫存狀態等屬性，確保 Google 能正確顯示產品資訊。

BreadcrumbList 在產品頁中標記商品分類路徑，例如「首頁 > 服飾 > 男裝 > 襯衫」，讓使用者與搜尋引擎理解產品在整體架構中的位置。

Review 與 AggregateRating 只能標記頁面上實際顯示的評論內容。若頁面沒有評論區塊，就不應該標記。AggregateRating 需要以實際的評分數據為基礎，不能自行捏造評分數字，這屬於嚴重的資料品質問題。

若你對 Review Schema 的實作細節有興趣，可以參考What is Schema？Review Schema 星級評分實作教學。

結構化資料驗證與 QA 流程

多重 Schema 疊加後的驗證流程分為三個階段：上線前使用 Rich Results Test 檢測單一 URL，上線後透過 Search Console「增強功能」報告監控各類型錯誤，再用 URL 檢查工具確認 Google 已檢索並解析標記。三個階段缺一不可。

驗證不是一次性工作，而是持續性的品質管理。網站改版、內容更新、模板調整都有可能影響已上線的結構化資料。

Rich Results Test 與 Search Console 增強功能報告的交叉使用

Rich Results Test 是上線前的第一道關卡。輸入 URL 或貼上程式碼，Google 會立即檢測所有結構化資料類型，並顯示每一種類型是否具備複合式搜尋結果資格。如果某種類型缺少必要屬性，測試結果會直接指出缺少哪一個欄位。多重 Schema 疊加時，Rich Results Test 會針對每一種類型分別顯示結果，因此你可以逐一確認每種類型都通過驗證。

Search Console 的「增強功能」報告則負責上線後的持續監控。這個報告會列出每一種複合式結果類型的有效項目數、錯誤項目數與警告數。當 Google 重新檢索頁面後發現標記有問題時，錯誤會出現在這裡。建議每週至少檢查一次，並設定電子郵件通知，確保錯誤發生時能即時處理。

URL 檢查工具的用途是確認單一頁面的實際狀況。透過 URL 檢查工具要求 Google 重新檢索頁面，也可以查看 Google 實際在頁面上解析了哪些結構化資料，比「增強功能」報告更精細。

這三個工具的交叉使用方式如下：新頁面上線前，用 Rich Results Test 逐一確認每種類型的標記正確；上線後到 Search Console 觀察「增強功能」報告是否有錯誤；若發現錯誤，用 URL 檢查工具重新檢索頁面並追蹤修正後的狀態。

多重 Schema 常見錯誤與排除

多重 Schema 疊加的錯誤可以分為三個層級：語法錯誤、語意錯誤、政策違規。三個層級的嚴重程度與修正方式不同，判斷錯誤屬於哪一層級是排除問題的第一步。

最常發生的狀況是：頁面明明已經加上標記，但 Google 沒有顯示複合式搜尋結果。此時先到 Search Console 查看錯誤訊息，再判斷錯誤屬於哪個層級，接著依照對應的方式修正。

語法錯誤 vs 語意錯誤 vs 政策違規的判斷方式

語法錯誤指的是 JSON 格式本身的問題，例如缺少逗號、括號未閉合、屬性名稱拼字錯誤、缺少必要屬性等。Rich Results Test 會直接顯示語法錯誤的位置與說明，這是最容易修正的錯誤層級。修正方式就是依照錯誤訊息調整 JSON 格式。

語意錯誤指的是標記類型與頁面實際內容不符。例如使用了 FAQPage 類型，但頁面根本沒有問答區塊；或是標記了 Review，但頁面上的評論不是真實使用者撰寫。Rich Results Test 不一定會顯示這類錯誤，因為程式碼本身格式正確，但 Google 在人工審查或品質評估時會認定為不實標記。

政策違規則是更嚴重的行為，例如標記頁面上看不到的內容、使用不支援的類型意圖騙取複合式搜尋結果、或是標記誤導性的資訊。政策違規可能導致 Google 對網站採取人工處罰，最嚴重的情況下會移除整站的複合式搜尋結果資格。

判斷錯誤層級的流程如下：先在 Rich Results Test 或 Search Console 查看是否有明確的格式錯誤訊息，若有則為語法錯誤；若格式正確但 Google 仍在「增強功能」報告中標記為無效項目，則可能是語意錯誤，此時需檢視頁面實際內容與標記內容是否一致；若內容一致但 Google 判定為違規，則需檢查是否符合該類型的所有政策條件。

若不確定某一類型的必要屬性與政策限制，建議回到 Google 官方文件重新確認，也歡迎參考FAQ Schema 2026 實作教學瞭解 FAQPage 的完整政策條件。

結構化資料在 AI 搜尋時代的疊加價值

ChatGPT、Perplexity 與 Google AI Overviews 等 AI 引擎在回答問題時，仰賴結構化資料來理解與引用網頁內容。多重 Schema 疊加能讓 AI 更精準地辨識頁面中的不同資訊單元，提升被正確引用的機率。

傳統搜尋引擎透過結構化資料取得複合式搜尋結果資格，AI 搜尋引擎則以結構化資料作為理解頁面的重要線索。當 AI 需要回答某個問題時，它會從已索引的網頁中尋找答案來源，而結構化資料讓 AI 更快速地判斷「哪一個區塊是問題、哪一個區塊是答案、哪一個區塊是評論、哪一個區塊是產品規格」。

多種 Schema 疊加的價值在於：AI 可以依照不同的對話意圖，引用頁面中正確的資訊單元。以文章頁為例，若同時標記 Article 與 FAQPage，當使用者問「部落格文章的作者是誰」時，AI 可以讀取 Article 的 author 屬性找到答案；當使用者問「FAQ 中的第一個問題」時，AI 可以讀取 FAQPage 的 mainEntity 找到對應的問答內容。若只有單一類型的標記，AI 解讀頁面的彈性受到限制。

需要再次強調的是：《結構化資料不是排名保證》。Google 官方文件多次說明，結構化資料不會直接影響搜尋排名，主要價值在於取得複合式搜尋結果資格、提升點閱率，以及在 AI 搜尋時代讓引擎更精準理解與引用頁面內容。疊加多種 Schema 的效益在於提升「被理解的程度」，而非「排名的順序」。