這篇”Google: You’re Really Dead, Really“說，Amy Wilentz這位美國作家，生於1954年，但是Google卻把她的生日弄成1927年，並且說她已經於1996年過世 (如下圖)。

這個已經不是第一個被Google弄錯的人，Madhav Prasad Ghimire這位尼泊爾的學者，生於1919年，也被Google弄成1909年出生，於1959年過世 (如下圖)。

為什麼會發生這種錯誤呢? 作者推論原因是，可能還有另外一位相同姓名的人，其資料被張冠李戴了，或是Google根本抓到的資料就是錯誤的，也可能從Wikipedia抓到的資料是錯誤的，但是後來Wikipedia更正後，Google並沒有跟著更新。

如下圖: Wikipedia的舊資料確實也是寫~ Madhav Prasad Ghimire生於1909年，於1959年過世。但是後來Wikipedia已經修正錯誤資料，只是Google的Knowledge Graph資料並沒有更新。

所以上述的幾種發生錯誤的原因中，也相同的會出現一般搜尋資料中，例如你要搜尋「pisa」，可能就有許多完全不同的資料都叫~pisa。例如Google也可能抓取了某些信譽良好的網站資料，但是這些網站資料也可能出錯，當然Google就跟著錯了。例如Google的回訪抓取，如果沒有抓到更新的資料，當然就無法更正了。

所以如果我們的網站資料沒能讓Google了解，當然就無法出現在使用者的搜尋中。所以我們從Google的烏龍事件應該記取什麼教訓呢?

(1) 應該使用語意標記，如microdata，讓機器可以順利解讀資料。
(2) 應該讓Google更頻繁的回訪，抓取更多更正的資料。
(3) 應該把更多相關網頁正確的串聯，讓Google知道網頁的相關性。

曾經有許多人說: 我的網頁根本不需要SEO，就可以有不錯的搜尋流量，但是卻不知道，如果能夠透過 SEO讓Google更瞭解的話，會有更驚人的搜尋流量。

最早在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講了太多年了，資深的讀者應該都已經感受到帶來的好處，如果還沒有開始動作的，現在還不算太晚。

Knowledge Graph也有人翻譯成~ 「知識圖譜」或是「知識圖表」。

但是還是覺得「知識結構圖」或是「知識關係圖」比較能夠表示這裡Graph的真正意含。

因為「圖譜」已經在許多領域有既定的用法，指的是有系統性分類的圖集，而「圖表」則跟graph意義差更遠。

graph的意義是指: A graph in this context is a collection of “vertices” or “nodes” and a collection of edges that connect pairs of vertices. A graph may be undirected, meaning that there is no distinction between the two vertices associated with each edge, or its edges may be directed from one vertex to another … 意思就是由「節點」與連接節點的「邊」所組成，具有方向性或是沒有方向性的結構，稱之為graph。

「節點」就是vertices或是nodes，「邊」就是edges。 例如下圖就是一個沒有方向性的graph:

下圖就是一個具有方向性的graph:

為什麼Google要把knowledge跟graph加在一起? 知識具有graph的什麼特性呢?

知識(knowledge)是由訊息(information)而來的，訊息就好像是「節點」，而訊息跟訊息之間的「邊」就是關係，這個關係可能有方向性，也可能沒有方向性。透過「邊」的連接，就讓「節點」與「節點」產生了某些關係。

例如，我們來看看下面的影片介紹

上面的說明中，提到一個例子，我們想知道諾貝爾獎有多少女性得主?

我們就可以從「諾貝爾獎」這個節點出發，找到關係為「得獎者」的節點，並且這個「得獎者」的節點必須是具有「女性」屬性。

而這些資料其實原本就在Google的資料中心，只是沒有解構出「節點」、「邊」、與「屬性」，現在Google推出knowledge graph，表示已經完成了一部分的graph關係，並且可以解析使用者的query (查詢)，瞭解使用者到底想問什麼。

例如你搜尋~ tallest building in the world (世界最高的建築)，你就可以看到如下的內容，左邊是一般的搜尋結果，右邊是特別整理出來的knowledge panel (知識面板)，這個右邊的面板並不是所有的問題查詢都會出現。

但是如果你想查詢~ greatest president in the world (世界最偉大的總統)，對不起 … Google也不知道。

其實這些東西，很早WolframAlpha就已經提供了。

如下圖，如果你一樣搜尋tallest building in the world … WolframAlpha直接給你答案。

但是如果你問wolframalpha ~ greatest president in the world (世界最偉大的總統)，他會告訴你不合邏輯，因為總統是以國家為單位，沒有一個人是世界的總統 … 哈，還蠻有道理的。

如果你問~ greatest president of United States (美國最偉大的總統)，他會避重就輕，只回答你 美國的總統，因為他不知道誰是美國最偉大的總統。

所以許多訊息談到Google knowledge graph，都把這個東西說得太出神入化了，其實Google在這個時間點推出來，有點在提醒大家不要只是一直注意Facebook IPO的味道。

Google在”Introducing the Knowledge Graph: things, not strings“說到，一個完美的搜尋引擎是要真正瞭解你要什麼，並且給你真正想要的東西。意思就是我們Google是一個完美的搜尋引擎，不要只注意Facebook。

但是Google也還算誠實，他也說到”And we can now sometimes help answer your next question before you’ve asked it, because the facts we show are informed by what other people have searched for.” 我們『有時候』能夠在你還沒有提問之前，就知道你想問什麼，因為我們呈現給你的事實是其他人已經搜尋過的。

所以，Google能提供的是已經大家經常詢問的問題，或是已經有人整理過的，Google並沒有那麼厲害自己去推理出來各物件的關係，也許以後可能，但是現在只能做到一小部分。

這篇“Google Launches Knowledge Graph To Provide Answers, Not Just Links“也說到，Google knowledge graph是一個big change (大的改變) 沒有錯，但是還不至於讓使用者有振奮的感覺。

Google目前已經對於五億個物件(object)整理出來35億個事實(fact)，並且大多屬於下列的類型: 演員、導演、電影、藝術品或是博物館、城市或是國家、島嶼、湖泊、燈塔、音樂專輯或是音樂團體、星球或是太空航空器、雲霄飛車或是摩天大樓、 運動團體 … 等等，也就是目前Google knowledge graph並不是所以問題都能夠回答。 其實Google knowledge graph的技術，我們在”搜尋引擎的語意趨勢，你準備好了嗎?“就談過了，他就是透過Semantic Web而產生的結果。

還有一個同樣的老問題，為什麼只有英文的內容才有呢? 除了因為中文的複雜度比較高之外，沒有足夠的可結構性資料來產生適當的物件(object)與事實(fact)也是一個問題，還有一個更重要的問題是~ Google是美國的公司。所以，要等到有中文內容的Google knowledge graph，大概還有得等了。

以下是原本可以在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這件事情，我們應該有何策略來因應呢，當然就是必須先瞭解，然後在適當的位置加上適當的標籤格式，至於詳細的作法，後續我們會再另文深入來探討，敬請期待囉。