“Google To Step Up Structured Data Support Over The Year“這篇提到John Mueller回答網友的問題，摘錄內容如下：

(Q) Are there more plans for Google to work more with structured data?…

網友問說，Google是否有更多關於結構化資料的計畫?

 

(A) On the one hand, it is very useful for us to understand the content better. It is kind of the nature to make sure we don’t misunderstand it wrong. So from that point of view, I think it is really useful. The other aspect of course is, the more sites use structured data, the more we can use it and highlight it more in the search results.

So I suspect that it is also an aspect there where the better we can understand these pages the more we kind of understand the details of where this page is relevant, the better we can show it in search. So I suspect over the course of the year we will definitely be seeing more structured data because it really helps us a lot to understand and discover and it is also something that can be used by other services as well.

John Mueller回答說，結構化資料讓Google更加瞭解網頁內容是非常有用的，很自然的可以確定我們不會誤解它。因此，我認為這是非常有用的。另一方面，如果更多網站使用結構化資料，我們就更能夠在搜尋結果用來標示。

所以我猜這也是一個觀點，透過更加瞭解其間相關性而更佳的顯示在搜尋結果上。我猜再來肯定會看到更多結構化資料，因為確實幫助我們瞭解及發現，並且也可以用在其他服務上。

最後SERoundTable的結論是：
Google will be stepping up their efforts around structured markup throughout the year because it benefits them in how they understand a web page. Google整年將會在結構化標記上更加努力，因為結構化標記可以協助Google瞭解網頁。

其實，根本不需要這段問答，也不需要SERoundTable的結論，結構化標記本來就是協助Google完成知識圖譜的重要技術。

語意標記或是結構化標記，可以讓網頁內容被搜尋引擎更加瞭解，當然也就會把結果正確的顯示在搜尋結果上。

如果你還不清楚語意標記，可以參考我們的SEO書籍~SEO超入門或是SEO關鍵問答，這兩本書都有詳細的說明。

Authorship markup是Google用來確認網站內容作者的一個標記，使用這個作者標記可以讓Google更了解作者，也可以藉此讓文章產生更好的信賴感。

但是應該怎麼做才能正確的設定Authorship Markup (作者標記) 呢? 首先我們先了解作者標記的寫法，相關的標記有兩個，一個是rel=”author”，另外一個是rel=”me”，各有不同的意義。

要進行Authorship Markup之前，都必須先有Google+的帳號，然後再依照下面三種方式之一，即可以正確的建立Authorship Markup。

#第一種建立作者標記的方法稱為2-link method。

假設你在Google+的姓名是~王小明，並且你有Twitter也是登記為~王小明，並且你有一個個人網站，其網址是~http://superwong.tw

那麼你可以在http://superwong.tw的頁面中加入下面兩個連結:

<a href=”連到你的Google+網址” rel=”author”>王小明</a>

<a href=”http://twitter.com/superwong” rel=”me”>@superwong</a>

第一個連結是建立Google Authorship的必要連結，第二個連結是讓Google知道你還有另外的頁面，是跟你有關係的。第二個連結就不是必要的，可以不使用。

在這個例子中，就是Google會知道http://superwong.tw、http://twitter.com/superwong跟Google+中的王小明是同一人所有。

但是你自己在http://superwong.tw建立連結到王小明的Google+，還不能保證Google+的王小明也承認，所以還需要一個確認的步驟。

這個確認的步驟就是需要在王小明的Google+上，要有資訊可以確認跟http://superwong.tw的關係。

這個確認的步驟有兩種方式，如下圖 : 第一種方式就是在Google+頁面的Contributor to，寫上http://superwong.tw連結 ，第二種方式就是在Google+頁面的Work Email寫上跟@superwong.tw一樣的電子郵件，例如me@superwong.tw。

你可以兩種方式都去確認，或是選擇你認為比較方便的方式。

#第二種建立作者標記的方法稱為3-link method。

第二種方法比較複雜，他是透過一個author biography page (也就是作者介紹頁面)，如果你的網站沒有這個作者介紹頁面，就不適合使用這個方法。

我們使用上面的相同例子，假設你的網站http://superwong.tw中有一個作者介紹頁面http://superwong.tw/about，那麼你就可以在文章頁面中，建立一個連結如下:

<a href=”http://superwong.tw/about” rel=”author”>王小明</a>

然後在作者介紹頁面http://superwong.tw/about中，建立一個連結如下:

<a href=”連到你的Google+網址” rel=”me”>王小明的Google+</a>

然後你還必須在Google+上進行確認，在Contributor to寫上http://superwong.tw即可。

#第三種建立作者標記的方法是以電子郵件來確認。

第三種方法是當你有跟網域一樣的電子郵件，如這個例子中 me@superwong.tw，跟你寫文章的網站的網域superwong.tw一樣。

你就可以在文章頁面寫上~ 作者<a href=”mailto:me@superwong.tw”>王小明</a>，然後在Google+上王小明的工作email也是me@superwong.tw，那麼Google就能夠確認這個作者的關係。

當你的確認動作都完成之後，你就可以使用Google Rich Snippets Tool去看看是否正確，如果正確的話就會出現如下圖的訊息:

如果顯示正確的話，並不是馬上就會出現在搜尋結果上，必須經過數周不等的時間，你才可以在Google搜尋中看到如下的內容 …

(本文轉載自台灣SEO搜尋引擎技術學院)

最早在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可能把你的資料精華「浮」到上面來了，使用者不再需要點選進去你的網站去尋找，雖然讓使用者更方便了，但是卻傷害了網站的流量，就如同百貨公司一樣，Google把使用者最可能需要的東西搬到百貨公司門口，使用者只需要到門口就把東西拿走了，根本不需要再到百貨公司裡面閒逛，當然對於百貨公司來說是很大的傷害。

這篇”Will Google Hurt Your Site By Improving Itself?“就提到了這個問題，例如下圖，當你搜尋[how old is dolly parton]，問Google到底歌手桃莉芭頓幾歲了，Google就會告訴你 … 答案是66歲。你不再需要去努力的爬文，才能找到答案。

之前的文章”SEO : 什麼是 Search Engine Optimization ?“說到~SEO是將網站的資料，清楚的呈現給搜尋引擎，讓搜尋引擎能夠更順利的處理資料，SEO所得到的成果也就是搜尋引擎根據你的貢獻度來回報給你。

但是，現在是否可能SEO所得到的成果卻是無法獲得回報呢?

如同Yelp事件一樣，Google希望得到Yelp的資料，但是卻會讓Yelp流量降低，而Yelp只希望從Google獲得流量，卻不想提供資料給Google。這樣的發展，對於Google跟網站是雙輸的局面。

如下圖，Yelp提供美國各地的店家資訊，有些類似台灣的iPeen 愛評網。

Google的成功是否會是SEO的失敗? 對於某些如Yelp類型的網站而言(提供商家資訊並且獲得商家的廣告贊助)，答案是可能的。而對於不只提供資訊，還銷售商品的網站而言，就沒有太大的影響。

但是是否這些提供商家資訊的網站，就應該排斥讓Google擷取資料呢? 當然不是，「清楚的呈現給搜尋引擎，讓搜尋引擎能夠更順利的處理資料」當然還是最好的原則，但是必須除了提供商家資訊之外，要能夠有額外無法取代的「加值服務」。

如果只是商家資訊，太多競爭者也可以建立相同的網站，就算商家資訊無法從你的網站抓取，也可以透過其他管道取得，或是從頭人工輸入。單純的「商家資訊」並無法建立競爭門檻，只有無法取代的「加值服務」才能創作價值。

Google讓使用者的資料可以直接顯示在搜尋結果上，是無法避免的結果，網站不能因為如此而排斥Rich Snippets，或是語意網相關的標準。

Google的成功是否會是SEO的失敗? 如果答案是的話，那麼你的網站必須思考，為什麼這麼沒有競爭優勢? 你的網站體質必須更加強化，否則就算沒有被Google擊垮，也會被其他競爭者取代。

根據這篇”Google Acquires Cuil Patent Applications“，作者說到他很訝異，因為這些專利內容都只有關於Cuil的界面，而沒有談到真正Cuil的特點，也就是據宣稱可以更快速及便宜的建立更多的索引內容。

Cuil與Google最大的不同在於排名系統，Google透過站內連結分析(link analysis)等指標指定網頁的優先等級，也叫做網頁排名。而Cuil則透過搜尋查詢分析網頁內容的重要性，換句話就是結果自動分類(classification)與群聚(clustering)。

這個曾經被認為是Google挑戰者的Cuil竟然就這樣的關燈走人了，可見搜尋市場的競爭性。

以下是Google買下的專利列表:

(1)
Apparatus and Method for Displaying Search Results with a Variety of Display Paradigms (以各種不同方式展現搜尋結果的設備與方法)
Invented by Tomas Costello
Assigned to Cuill, Inc.
US Patent Application 20090240672
Published September 24, 2009
Filed: July 24, 2008

(2)
Apparatus and Method for Displaying Search Results Using Tabs (以Tabs方式展現搜尋結果的設備與方法)
Invented by Tomas Costello and Louis Monier
Assigned to Cuill, Inc.
US Patent Application 20090240685
Published September 24, 2009
Filed: July 24, 2008

(3)
Apparatus and Method for Displaying Search Results Using Stacks (以堆疊方式展現搜尋結果的設備與方法)
Invented by Tomas Costello
Assigned to Cuill, Inc.
US Patent Application 20090241044
Published September 24, 2009
Filed: July 24, 2008

(4)
Apparatus and Method for Displaying Search Results with Configurable Columns and Textual Summary Lengths (以可組態欄位與文字總結長度展現搜尋結果的設備與方法)
Invented by Tomas Costello and Edward Lau
Assigned to Cuill, Inc.
US Patent Application 20090241018
Published September 24, 2009
Filed: July 24, 2008

(5)
Apparatus and Method for Displaying Search Results with an Associated Anchor Area (以相關錨點區域展現搜尋結果的設備與方法)
Invented by Tomas Costello and Edward Lau
Assigned to Cuill, Inc.
US Patent Application 20090241058
Published September 24, 2009
Filed: July 24, 2008

(6)
Apparatus and Method for Displaying Search Results with Various Forms of Advertising (以各種廣告形式展現搜尋結果的設備與方法)
Invented by Tomas Costello and Edward Lau
Assigned to Cuill, Inc.
US Patent Application 20090241065
Published September 24, 2009
Filed: July 24, 2008

(7)
Apparatus and Method for Displaying Search Results with a Menu of Refining Search Terms (以搜尋詞精簡的選單展現搜尋結果的設備與方法)
Invented by Tomas Costello
Assigned to Cuill, Inc.
US Patent Application 20090241066
Published September 24, 2009
Filed: July 24, 2008

上面的幾個專利確實都是跟搜尋結果的展現方式有關係，Google為什麼需要這些專利呢?

如果你仔細閱讀其中的專利內容，你會發現這些專利幾乎都有一個共通點，就是希望可以把許多不同意義的搜尋詞搜尋結果，有效率的顯示出來。

也就是跟語意網路有關係，當一個字詞有多個意義的時候，Google希望他的展現方式是有以上專利的保護，或是希望透過上面的專利造成其他競爭者的門檻。

更進一步的意義應該是，Google對於多義搜尋結果的演算法應該已經可以浮出抬面，因此後續應該會有更多相關的新界面或是新服務出現。

什麼叫做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，現在還來得及!  因為越早使用則可以越早享受可能的好處。