提到「html5網站設計」，很多人第一時間會想到的是HTML5新增了哪些標籤、能不能做出動畫效果、跟舊版HTML比起來差在哪裡。但從搜尋引擎最佳化的角度來看，html5網站設計真正的價值，其實藏在一個比較少被講清楚的地方：語意標籤（semantic tags）跟schema.org結構化資料之間該怎麼互相搭配。這篇文章不整理HTML5功能清單，也不談無障礙輔助設計，而是專門拆解語意標籤跟結構化資料這兩層技術之間的分工與搭配方式，希望讓看完的人能理解，為什麼「用了HTML5」跟「用對了HTML5」對搜尋引擎來說是兩件不同的事。
在正式拆解之前，先建立一個前提：HTML5語意標籤跟schema.org結構化資料，處理的是兩個不同層次的問題。語意標籤處理的是「這段內容在頁面的哪個位置、扮演什麼角色」，結構化資料處理的是「這段內容具體是什麼東西、有哪些屬性」。搞懂這個分工，才不會誤以為只要把div都換成語意標籤，SEO的技術面就做完了。
HTML5語意標籤解決的是「結構」問題，不是「意義」問題
header、nav、main、article、section、footer這些語意標籤，本質上是在告訴瀏覽器與搜尋引擎爬蟲：這個區塊是導覽列、這個區塊是主要內容、這個區塊是頁尾資訊。相較於過去全部用div堆疊、只靠class名稱辨識用途的寫法，語意標籤讓爬蟲在解析頁面結構時，能更快速、更準確地區分出哪裡是核心內容、哪裡是輔助資訊，這對爬取效率與內容主體辨識確實有幫助。
但語意標籤能提供的資訊，終究停留在「結構層級」。舉例來說，一個用article標籤包起來的區塊，爬蟲知道這是一篇獨立完整的內容單元，卻無法從標籤本身得知這篇內容的作者是誰、發佈日期是哪一天、屬於哪個分類，如果是商品頁面的話，價格跟庫存狀態又是什麼。這些更細緻、更明確的「意義」層級資訊，語意標籤本身並不負責傳達。
這也是為什麼很多網站明明已經導入HTML5語意標籤，卻在搜尋結果的呈現上跟純div寫法的網站沒有太大差異。因為搜尋引擎能夠更順利地解析頁面架構，但那不等於搜尋引擎已經明確知道頁面裡每一段內容具體代表什麼意義。
schema.org結構化資料補上的正是「意義」這一塊
schema.org是由多家主要搜尋引擎共同維護的一套詞彙標準，用來描述網頁內容具體是什麼類型的東西，例如一篇文章、一個商品、一則評論、一個常見問答集、一個組織資訊。透過這套標準化的詞彙，網站可以用機器能夠明確解讀的方式，把「這是什麼」講清楚，而不是只靠爬蟲自己去猜測跟推論。
舉例來說，同樣是一段包含商品名稱、價格、庫存狀態的文字，如果只靠HTML5語意標籤呈現，爬蟲頂多知道這是頁面主要內容區塊裡的一段文字；但如果搭配schema.org的Product類型標記，爬蟲就能明確解讀出「名稱」「價格」「幣別」「庫存狀態」分別對應到哪些具體數值，不需要再靠語意推測。
換句話說，語意標籤負責讓爬蟲順利抵達與解析內容區塊，結構化資料則負責讓爬蟲精確理解區塊裡每一項資訊的身分與屬性。兩者搭配起來，才是完整的技術SEO基礎工程，單獨做好其中一項，效果都會打折扣。
JSON-LD是目前主流建議採用的標記格式
schema.org結構化資料實際上有幾種不同的標記語法可以選擇，包括微資料（microdata）、RDFa、以及JSON-LD。微資料與RDFa的做法，是直接把結構化資料的屬性寫進既有的HTML標籤裡，跟語意標籤混在一起；JSON-LD則是把整段結構化資料獨立寫成一個script區塊，跟頁面上實際顯示的HTML標籤分開存在。
目前多數主要搜尋引擎都建議優先採用JSON-LD，原因在於它跟頁面視覺結構完全脫鉤，工程團隊在調整HTML5語意標籤或改版頁面版型時，不需要擔心動到結構化資料的標記；反過來說，行銷或SEO人員要更新結構化資料的內容，也不需要動到前端工程師寫的語意標籤，兩邊可以獨立維護、互不干擾。
這種「分離但呼應」的搭配方式，正好回應了前面提到的分工邏輯：語意標籤持續負責頁面結構的呈現，JSON-LD結構化資料則獨立負責把每個區塊的具體意義講清楚，兩者透過內容本身互相對應，而不是寫在同一段標籤裡互相依賴。
語意標籤跟schema類型該怎麼互相對應
實務上比較常見的搭配方式，是先確認語意標籤劃分出的區塊性質，再挑選對應的schema類型去描述那個區塊裡的內容。舉例來說：
- 用article標籤包起來的部落格文章區塊，通常會搭配Article或BlogPosting類型的結構化資料，補上作者、發佈日期、更新日期等屬性
- nav標籤裡呈現的階層式導覽，如果同時反映網站的頁面層級關係，可以搭配BreadcrumbList類型，把導覽路徑的每一層明確標記出來
- footer裡如果放了公司名稱、地址、聯絡電話等資訊，適合搭配Organization或LocalBusiness類型，讓這些身分資訊有機會被更明確地解讀
- section裡如果是常見問答形式的內容，可以考慮搭配對應的問答類結構化資料，把問題與答案的對應關係標記清楚
要特別提醒的是，搭配schema類型的前提，永遠是頁面上「真的有」對應的可見內容，結構化資料只是把已經存在的內容用機器可讀的方式重新描述一次，而不是無中生有地標記出頁面上根本沒有顯示的資訊。
語意標籤與結構化資料不一致時常見的技術錯誤
在實際導入的過程中，語意標籤跟結構化資料兜不起來，是最常出現的技術債之一。第一種常見狀況，是結構化資料裡標記的內容，跟頁面實際顯示的內容對不上，例如標記了某個價格，但頁面上顯示的其實是另一個數字，這種不一致除了造成使用者混淆，也可能讓搜尋引擎對這個頁面的資料可信度打上問號。
第二種常見狀況，是巢狀結構寫錯，把原本應該分開標記的兩種不同類型資料，硬塞進同一段結構化資料裡，或是同一個屬性重複標記了兩次、數值卻不一致。這種錯誤通常不會讓頁面「壞掉」，但會讓結構化資料的可信度降低，反而失去原本想補強的效果。
第三種狀況則跟語意標籤本身有關：一個頁面理論上只應該有一個main標籤，代表這個頁面唯一的主要內容區塊，但實務上常見改版過程中不小心留下第二個main、或是把原本應該用section區分的多個子區塊全部塞進同一個article裡，導致語意結構本身就混亂，連帶讓對應的結構化資料也難以正確歸位。
第四種狀況，是網站改版或內容更新之後，忘記同步更新結構化資料，導致舊的標記內容跟新的頁面內容脫節。這種問題不容易在畫面上被肉眼發現，通常要透過檢查工具才會浮現，也因此特別容易被長期忽略。
結構化資料能帶來的效益，以及該有的合理期待
結構化資料對搜尋引擎最直接的幫助，是讓爬蟲能更準確地理解頁面內容的性質與屬性，這件事本身有助於內容被正確分類與索引。至於是否會因此出現比較豐富的搜尋結果呈現形式，最終仍然是由搜尋引擎依照自己的判斷邏輯決定，結構化資料只是提高了被考慮的機會，並不是加了標記就一定會出現特定的呈現效果。
也因此，結構化資料應該被理解成一項基礎的技術建設，而不是能直接換來排名提升的捷徑。網站內容本身的完整度、可信度、跟使用者需求的貼合程度，仍然是決定排名表現的核心因素，結構化資料扮演的角色，是讓搜尋引擎更容易「讀懂」這些已經存在的內容價值，而不是取代內容本身的品質。
對正在規劃或調整html5網站設計的團隊來說，比較務實的做法，是先確認語意標籤的結構是否合理、清楚，再逐步針對真正需要被明確標記的內容類型，例如文章、商品、組織資訊，補上對應的JSON-LD結構化資料，而不是急著把所有能標記的類型全部塞進頁面，反而增加了維護與出錯的負擔。
常見問題
HTML5語意標籤本身可以取代結構化資料嗎？ 不行。語意標籤負責的是頁面結構的劃分，結構化資料負責的是內容意義的明確標記，兩者處理的層次不同，無法互相取代，理想狀況是兩者搭配使用。
導入結構化資料一定要用JSON-LD格式嗎？ 微資料跟RDFa在技術上也能運作，但JSON-LD因為跟視覺HTML標籤脫鉤、維護上比較獨立，是目前多數主要搜尋引擎建議優先採用的格式。
加了schema標記之後，多久會看到搜尋結果呈現上的變化？ 這件事沒有固定時間表，會受到網站被重新爬取與索引的頻率影響，而且是否出現特定呈現形式最終仍由搜尋引擎判斷決定，不建議把它當成能預期在特定時間內看到效果的操作。
舊網站要重新導入語意標籤與結構化資料，工程量會很大嗎？ 要看原本網站的架構複雜度，如果原本大量使用div堆疊、缺乏清楚的區塊劃分，調整起來確實需要一定的工程時間；建議先盤點頁面架構，找出真正需要優先處理的頁面類型，分階段導入會比一次全站重寫更務實。
如果不確定自己網站目前的html5語意結構跟結構化資料標記狀況如何，也可以透過免費網站健診，讓專人先了解現況再給具體建議；如果想當面討論網站的技術架構規劃，也提供全台免費到府諮詢服務，用比較輕鬆的方式聊聊網站現階段適合怎麼調整。