最早在2010年的這篇文章”Semantic Web 與 Best Buy“，就說到BestBuy已經在2009年使用GoodRelations當成他們的語意策略之一，並建議您必須在事件還沒到不可掌握時，趕緊進行所有的萬全準備。

我們大約在去年的SEO達人入門學習課程中，也就跟學員說如果你的網站屬於商務網站，要開始規劃導入GoodRelations。

當時的GoodRelations與Schema.org的Microdata還是兩種不同的東西，而現在Schema.org已經整合了GoodRelations了。

以下是宣佈的部分說明內容:

Effective immediately, the GoodRelations vocabulary (http://purl.org/goodrelations/) is directly available from within the schema.org site for use with both HTML5 Microdata and RDFa. Webmasters of e-commerce sites can use all GoodRelations types and properties directly from the schema.org namespace to expose more granular information for search engines and other clients, including delivery charges, quantity discounts, and product features.

大致是說，這個整合已經即刻生效，你可以使用這些標記在HTML5 Microdata以及RDFa上，你可以直接在schema.org namespace上使用所有GoodRelations的types與properties，以便可以釋出更多的頁面資訊給搜尋引擎或是其他客戶端的程式。

GoodRelations被整合進去Schema.org代表什麼意思呢? 就是Google、Bing、Yahoo都支援的意思囉，只要你的網站使用了GoodRelations，就可以被這些搜尋引擎更好的對待，更沒有錯誤的處理你的網站資料。

如果你不相信我們說的，這篇”E-commerce SEO Using Schema.org Just Got A Lot More Granular“也說了，代表的是這些搜尋引擎可以更精細的擷取你的產品資訊 (因為GoodRelations主要是針對產品資訊而來的)。

還記得在去年的時候，我們上課就說過，雖然現在GoodRelations還沒有變成業界百分之百接受的標準，但是未來一定會變成標準，果然現在已經納入Schema.org。

現在經過了快兩年的時間，如果當時上課的學員有開始規劃GoodRelations進他們的商務網站的話，現在已經可以翹著二郎腿等著收成囉。

但是如同我們在”如果你不了解Schema.org，現在還來得及!“說的，越早使用則可以越早享受好處，如果你現在還不趕緊瞭解Schema.org與GoodRelations，那麼時間可是不等人的。

如同我們昨天在”不要忽略了Outbound Link Effect“說，把「眼前很重要」的操作做好，只能讓你「生存」，能夠做到「未來很重要」的事，才能夠提高競爭門檻而讓你「茁壯」。跟著我們的分析來進行，可以讓大家不只「生存」還能夠「茁壯」。

接著兩天的兩件證明，都說明了掌握趨勢就可以走在大家的前面。我們後續再來好好找個時間，再來談談GoodRelations的相關細節內容。

在”語意(Semantics)將會成為下一個SEO的重要元素“曾經說到，如果你還不瞭解microdata、microformats、RDFa … 等等這些標準的意義，如果你還不清楚如何使用這些標記，你可能就會在未來幾年的SEO行銷上居於劣勢。並且也在”SEO 3.0是什麼? 其實早就不是新鮮事!“說到，我們多年前說的樣貌，就是現在國外專家所說的SEO 3.0。

這篇”Getting Started With Semantic SEO“更清楚的告訴大家，是時候該注意Semantic SEO了，也就是在你的SEO策略中，要好好考慮如何把語意套到你的網站中。

文章中提供了幾個網路上可以參考的資源:
Semanticweb.com
Schema.org
Structured-Data.org
Semanticweb.org

以及有幾個可以使用的工具:
Google’s Structured Data Dashboard (Google Webmasters提供的工具)
Rich Snippets Testing Tool (Google提供的工具)
WordLift (WordPress的外掛) ~ 目前好像還有bug。
Open Calais (可以透過Drupal與Wordpress使用) ~ 必須申請API才能使用。

其實Semantic SEO看起來很高深，其實非常簡單，就是把你的資料用適當的語意標籤標記起來，只要你認識什麼是語意標籤，知道哪些資料應該標記起來，就可以逐步的在Semantic SEO上獲得好處。我們在”如果你不了解Schema.org，現在還來得及!“說過，你只要去瞭解Rich Snippets (複合式摘要片段)，就會知道應該怎麼做，並且可以預期知道他的好處。

我們已經在Semantic SEO講了太多年了，資深的讀者應該都已經感受到帶來的好處，如果還沒有開始動作的，現在還不算太晚。

以下是原本可以在Google Webmasters，成功傳送的Geo sitemap結果:

但是現在變成這個樣子:

原因就在於Google已經不支援Geo sitemap了，但是仍舊可以支援KML檔案。

什麼意思呢? 我們來看看Google的Susan Moskwa在Google+上的說法:

We still support KML files.  We previously supported an extension to the Sitemaps protocol where you could include tags in your XML Sitemaps that contained geo-specific information in addition to the URL of your KML file. We no longer support those geo-specific XML tags in Sitemaps, but you can still submit the URLs of your KML files in a standard Sitemap format.

意思就是說以往把geo tag放在XML檔案中，來說明KML檔案的位置，現在這個geo tag已經不再被Google支援，但是你可以把KML檔的URL放在一般的sitemap當中。

如果你不知道什麼是KML (Keyhole Markup Language)，你可以參考KML Tutorial，他主要是用來描述實體物件在地圖中的訊息，長像如下:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Placemark>
    <name>Simple placemark</name>
    <description>Attached to the ground. Intelligently places itself
       at the height of the underlying terrain.</description>
    <Point>
      <coordinates>-122.0822035425683,37.42228990140251,0</coordinates>
    </Point>
  </Placemark>
</kml>

那麼我們把KML中的訊息讓Google知道有什麼用處呢? 主要就是讓Google Earth 或是Google maps可以顯示正確的名稱、描寫、以及正確的位置。這個在進行在地搜尋優化 (Local Search Optimization)是非常重要的事情。

當然如果你已經完成KML檔案的處理，當然就不需要再多次傳送，但是如果你必須更新資料，就不能再使用Geo sitemap的方式傳遞，並且如果你使用Schema.org的格式，其實也可以將在地資料包括在網頁中，而不需要再使用KML的方式來描述。

什麼叫做Google採用第三方Rich Snippets的結果? 什麼叫做Google不僅使用網站的Rich Snippets，並且還用來串聯網站間的資料?

作者舉了一個例子，他使用ColdPlay當關鍵字來搜尋，看到了如下圖的結果:

也就是上圖的紅色圈起來的資料，不是來自於ColdPlay.com，而是來自於Ticketmaster.com 與 Vividseats.com 網站。

如果你使用ticketmaster coldplay進行搜尋，你可以看到如下圖的結果:

如上圖，你就可以看到資料來源的展示情況。

所以Google把別站的Rich Snippets的資料，拿去給別站使用了，這個表示兩件事情~ ticketmaster.com獲得了Google的信賴，以及Google透過某些機制，知道這些資料是有關係的。

什麼機制讓Google知道之間的關係呢? 我們來看下圖:

使用Google Rich Snippets Testing Tool來看tickmaster.com的資料

可以看到頁面的標記使用

就是因為使用了正確的標記，讓Google可以串聯相關的資訊，加上信賴度的關係，使得你的網頁資料可能變成別的網頁可以擷取的資料。

所以Microdata是否重要，應該就不言可喻了。

但是如果你仔細看ticketmaster的網頁資料的話，他的節目單內容是使用Javascript來顯示的，因此你無法在網頁原始碼看到Coldplay的演出內容，因此你可以看到另外一個範例，就是Google確實會去執行Javascript的結果 …

但是如”Google可以索引AJAX與Javascript內容?“所說的，你千萬不要認為Google也會處理你的Javascript，這是必須有先決條件的，也就是Google已經「有能力」去抓到「某些」動態內容，但是必須值得Google這麼做，或是你的環境配合。

所謂Rich Snippets (複合式摘要)，就是指自然搜尋結果列表中，Google為了讓搜尋者能夠更清楚的瞭解列表到底是什麼網頁，而顯示比原先更多資訊的區塊。

原本自然搜尋結果列表中，顯示的描述內容稱為snippets (片段或是摘要)，但是死板的snippets可能只像下圖一樣 …

但是如上圖顯示的訊息可能無法滿足搜尋者的需求，因此Google就在「某些情況下」，提供如下的snippets

如上的snippets就稱為Rich Snippets (複合式摘要)，搜尋者可以看到有多少人的reviews，並且可以看到該條列的網頁有四顆星的等級，還可以直接看到商店的地址與電話 … 等等訊息。

因為提供的訊息比普通的snippets更加rich，所以才會稱為Rich Snippets。

那麼「某些情況下」是什麼情況呢? Google如何決定何時顯示一般的Snippets，何時顯示Rich Snippets呢?

我們先來看看Google介紹Rich Snippets的影片:

影片說到Rich Snippets主要是要讓搜尋者更清楚瞭解相關性，因此具有Rich Snippets的列表可以更突出的顯示給搜尋者看到。只需在網頁上加入正確的標記，就能夠顯示Rich Snippets。

除了以上的影片之外，你還可以觀賞一系列的Rich Snippets相關影片。

我們在”如果你不了解Schema.org，現在還來得及!“也說到過，Rich Snippets (複合式摘要片段)就是指透過特別的標示而讓搜尋引擎抓出來的資料段，這些特別的標示就是如Schema.org在推動的Microdata之類的標準。

想要在自然搜尋列表中顯示Rich Snippets (複合式摘要)，就必須正確的使用複合式摘要標記，例如微資料 (Microformats)、微格式 (Microdata) 以及 RDFa (RDF-attribute)等等。

並且有些人使用了Rich Snippets的標示，但是卻發現一直沒有正常的顯示，關於這點疑問，可以從以下的影片獲得解答 …

Matt Cutts提到，只要你正確的使用標記，並且已經使用Rich Snippets工具確認，就算沒有顯示也不必擔心，因為大約必須等待一兩個月的確認作業，才會在自然搜尋中顯示出來。

你的網頁是否已經正確的使用schema.org之類的語意標記呢?

你的網頁是否需要顯示Rich Snippets (複合式摘要)呢?

如果需要顯示，但是你還沒有任何動作的話，你的網頁被點選的機率可能就會逐漸的降低囉。

在這篇”Microdata是什麼? 為何可以讓Google、Bing、Yahoo攜手合作?“說到，Schema.org就是推動Microdata，他就是HTML5的一部份，其目的就是要讓機器可以自動的了解網頁內容，並且簡化RDFa與Microformats的複雜度。

另外在這篇”語意(Semantics)將會成為下一個SEO的重要元素“也強調，如果你還不瞭解microdata、microformats、RDFa … 等等這些標準的意義，如果你還不清楚如何使用這些標記，你可能就會在未來幾年的SEO行銷上居於劣勢。

也許你會認為我們說的不算，那麼我們再來看看這篇”Schema.org – Why You’re Behind if You’re Not Using It…“，更是舉了許多例子來說明，現在許多搜尋結果都陸續出現所謂的Rich Snippets (複合式摘要片段)。

什麼是Rich Snippets (複合式摘要片段)?

Rich Snippets (複合式摘要片段)就是指透過特別的標示而讓搜尋引擎抓出來的資料段，這些特別的標示就是如Schema.org在推動的Microdata之類的標準。

Google也提到: “Google 一直致力提供使用者最實用且最具參考價值的搜尋結果。如果搜尋結果的摘要內容越詳細，就越容易幫助使用者判斷該網頁與他們想搜尋的資料的相關性。透過複合式摘要，在網站上提供結構化內容 (例如評論網站或商家資訊) 的網站管理員即可標記該網站的內容，讓這些加上標記的文字能代表某種類型的資料，例如餐廳名稱、地址或評分。”

例如下圖，就顯示出使用者對於產品的評等，以及產品價格的範圍

如下圖箭頭指出各種類型的Rich Snippets (複合式摘要片段)

這些Rich Snippets (複合式摘要片段)就能夠提供使用者當成點選的重要參考。

所以如果你不了解Schema.org，現在還來得及!  因為越早使用則可以越早享受可能的好處。

關於語意相關的內容，我們以前的文章已經談過很多，你可以先參考一下比較近期的文章:
Search needs a shake-up : 搜尋的未來應該如何呢?
Microdata是什麼? 為何可以讓Google、Bing、Yahoo攜手合作?
Semantic Web 與 Semantic Search (語意網與語意搜尋)
Metaweb 被 Google 併購，語意搜尋會有何變化?
Semantic Web 與 Facebook
Semantic Web 與 Best Buy
SEO – Common Tag 通用標籤與搜尋引擎優化

上面總共談到了幾個跟語意標籤有關的標準，例如Microdata、RDFS、RDFa、Microformats、Common Tag、Goodrelation，這些標準都已經被各大搜尋引擎所接受，並且許多網站已經紛紛開始採用。

這篇舊文章”The Value of Semantic Tags“就說明了這些標記的價值，這些標記已經是歷史悠久的標準，但是因為語意網的需求越來越迫切，所以才開始受到更多的重視。

文章中說到的標記價值如下:

Automated link insertion : 自動連接
Information filtering : 資訊過濾
Different typographic conventions in different languages : 不同語言間的排版
Translation control : 翻譯控制
Intelligent search and replace : 智慧型搜尋及替代
Automated processing : 自動處理

其實以上說到的標記價值，也就是因為「讓電腦自動擷取正確的內容」，「讓電腦自動瞭解內容」而來的。

因此什麼網站需要語意標籤(Semantic Tag)? 當然只要你希望能夠在搜尋排名佔有一席之地的網站，都必須使用語意標籤。

想要使用語意標籤，就必需瞭解Microdata、RDFS、RDFa、Microformats、Common Tag、Goodrelation這些標準，並且知道這些標準的差異與能力。

網路上許多文章都有談到這些標準，市面上也有許多中英文書籍寫到這些標準，但是卻都是片片斷斷的，無法讓讀者能夠獲得全面的瞭解，就算能夠初步瞭解，也還是無法實際應用，因此我們將在[台北]SEO達人養成密集班中，在最短的時間內讓入門者完全掌握語意標籤的實際使用。

瞭解這些語意標籤是今年最重要的SEO議題，也歡迎對於此議題有興趣的讀者，多多發言參與討論囉。

Microdata是一種結構性的標示，可以用來表示網頁內容的語意。

Google、Bing、Yahoo近日宣佈了Schema.org來共同推動Microdata格式，這些格式有些是新的格式，也有些是舊的格式。

所謂Microdata，其實是HTML5的一部份，他的目的是要讓機器可以了解網頁內容，並且簡化RDFa與Microformats的複雜度。

所以跟之前提到的”Semantic Web 與 Best Buy“也是同樣的道理，都是為了讓搜尋引擎可以順利解析網頁資料。

那麼為什麼要用Microdata呢? 為什麼搜尋大咖會共同推動呢? 最主要原因還是因為Microdata的簡單，並且屬於HTML 5的一部份，因此不會像RDF(Resource Description Framework)之類的那麼困難。

例如原本簡單的HTML如下:

<div>
 <h1>Avatar</h1>
 <span>Director: James Cameron (born August 16, 1954)</span>
 <span>Science fiction</span>
 <a href="../movies/avatar-theatrical-trailer.html">Trailer</a>
</div>

以上的HTML並不能讓搜尋引擎知道你在說什麼，因此如果我們改成以下:

<div itemscope itemtype="http://schema.org/Movie">
  <h1>Avatar</h1>
  <span>Director: James Cameron (born August 16, 1954)</span>
  <span>Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html">Trailer</a>
</div>

以上的itemscope、itemtype都是microdata的語法，就可以指出這段內容是在談電影，然後搜尋引擎就可以從裡面的文字”Avatar”去跟電影關聯。

再進一步的還可以寫成如下:

<div itemscope itemtype ="http://schema.org/Movie">
  <h1 itemprop="name">Avatar</h1>
  <div itemprop="director" itemscope itemtype="http://schema.org/Person">
  Director: <span itemprop="name">James Cameron</span> (born <span itemprop="birthDate">August 16, 1954)</span>
  </div>
  <span itemprop="genre">Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

這樣就可以知道，電影名稱是Avatar、導演是James Cameron、類型是科幻電影 …. 而不需要讓搜尋引擎自己去猜測每個字串的意義。

說了半天就是我們在2009年說過的Common Tag一樣，不同的是格式稍微不同，這次更是各大搜尋引擎都支援，所以Microdata目前已經算是最簡便使用的語意標籤格式了。

Microdata是HTML 5的一個子集，用來讓機器可以順利解讀網頁資料的標籤格式。

最近Google推出的Recipe Search，就是使用Microdata的一個例子，如下:

當你切換成英文介面後，就可以看到左側的”Recipes”選項，並且你還可以看到以下的內容，顯示了烹煮的時間是25分鐘，熱量924.3卡

這些都是因為使用了「搜尋引擎了解的格式」。

所以面對各大搜尋引擎支援Microdata這件事情，我們應該有何策略來因應呢，當然就是必須先瞭解，然後在適當的位置加上適當的標籤格式，至於詳細的作法，後續我們會再另文深入來探討，敬請期待囉。