很多人開始預測「SEO是屬於Web2.0的舊產物」、「SEO在Web3.0時代即將失效」。這些說法到底是否正確呢? 我們來仔細分析一下。

要瞭解這些說法是否正確之前，需要先知道什麼是Web3.0?

什麼是Web3.0?

Web1.0與Web2.0大家應該耳熟能詳的是 : 「Web1.0是單向的、Web2.0是雙向的」、「Web1.0讓使用者可以透過Web找到需要的資訊、Web2.0讓使用者與使用者之間可相互溝通並分享資訊」。

但是Web3.0的定義，就稍微有點複雜，因為Web3.0最早是指Tim Berners-Lee所說的Semantic Web (語意網)，我們在近期語意技術探討(一)就提過了，這就是當時所指的Web3.0。

但是近期所說的Web3.0又有些不同了，其實他應該是Web3而非Web3.0，不過大家都把Web3當成Web3.0，所以變成Web3.0就是Web3。這個Web3是以太坊聯合創始人Gavin Wood於2014年提出，他指的是一個去中心化(decentralized)的網路。

去中心化(decentralized)的網路跟目前的網際網路(Internet)差異確實不小，因為網際網路是中心化管理的，有上層管理IP的發放，管理網域名稱的使用，如果網際網路變成去中心化，亦即這些東西會存在區塊鏈的架構下，不同的網域名稱系統、不同的網站架構等等。

所以Google在Web3的網站會扮演什麼角色，就決定了SEO的命運，也就是SEO是否重要，不是決定在Web3，而是決定在Google。這篇文章「無法忽視熱潮！Google組神秘Web3 團隊，靠中心化起家的巨頭力拚找到新路徑就說到了Google開始在Web3上有所動作」，就代表了認為SEO將不再重要的說法，可以消除大半的疑慮了。

Google與Web3

不過，我們也不能完全認為Google開始研究Web3，就完全認為SEO依然重要，我們還是必須真正瞭解Web3的本質，才能做出正確的判斷。Web3到底是什麼? Google到底打算如何在Web3上發展?  從Google的Web3服務來看，Google應該是要從Web3的雲端服務來切入，提供區塊鏈的開發環境。

我們先來理解Gavin Wood所說的Web3到底是什麼? Gavin Wood編寫了第一版的以太坊(Ethereum)及以太坊的技術黃皮書，並發明了 Solidity 語言。先不管以太坊跟Solidity是什麼，可以先理解他是以區塊鏈為基礎的產物，Web3的去中心化概念也由此而生。所以理解區塊鏈就可以理解Web3了。

這篇”什麼是區塊鏈 (Blockchain)? 可以取代資料庫嗎?“，解釋了區塊鏈以及特色，結論是區塊鏈會與資料庫融合，但是沒有必要取代資料庫，因為各有其存在的必要。就像數位設備的出現，還是沒有取代紙張一樣。

因此我們可以清楚的知道Web3與目前的網際網路，沒有誰取代誰的問題，也都有存在的必要，某些應用需要Web3，某些應用需要傳統的網際網路。而Web3的網站只是可以提供區塊鏈上的服務或功能，網站本身的特性還是沒有太大的差別。

SEO不會因為Web3而消失

這篇”Googler Says Web 3.0 Won’t Kill SEO“提到，任何用在目前網際網路的搜尋，同樣會用在Web3。根本沒有SEO會在Web3消失的問題。

“My point is the technical things you do will evolve but the general aim of SEO will remain and will have new tools and processes.” 在技術面會有所關連，但是SEO上仍舊會一樣，只是會有新的工具及流程。意思就是SEO本質不會改變，會有變化的是技術。

“The best way to sum what is being pushed as the web3, in my opinion: it’s a way to store, access and transfer some types of information, by using “public databases”. Web3是一個使用公開資料庫來儲存、存取、轉移資訊的方式。

Web3與網際網路並沒有你死我活的地步，兩者一樣是可以融合，而無須取代。

如果你有不同的看法，歡迎交流。

“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關鍵問答，這兩本書都有詳細的說明。

這篇”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更瞭解的話，會有更驚人的搜尋流量。

Google在”Introducing Data Highlighter for event data“宣佈，開始推出更方便的工具使得網頁可以提供結構化的資料，但是剛開始只支援英文，並且只提供事件(event)類型的結構化資料工具。

以下是這個Google Data Highlighter的影片說明:

並且當你設定成功Data Highlighter之後，等Google正確的抓取之後，你就可以在Google管理員工具中看到這些結構化資料的抓取結果，如下圖。

但是這篇”Google’s Data Highlighter: What If It Conflicts With HTML Markup?“則提到了，這個Google Data Highlighter會不會弄亂了原本已經有標記的網頁內容? Google的John Mueller 針對這點解釋說:「對於SEO來說，標記不要出現衝突的情況是很重要的，如果真的產生資料不一致的情形，那麼你就無法期望出現你期待的樣子，因此如果你擔心Data Highlighter會弄亂你的安排，最好還是先經過測試再來使用。」

所以Google Data Highlighter雖然可以很便利的幫你標記內容，但是因為目前還只有活動事件的標記，因此大多網站都採取觀望的態度，並且正式使用到你的網站之前，最後先確定不會搞亂原先的標記。

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

2012年應該可以說是自從有SEO以來，大環境改變會最激烈的一年，如果沒有順應變化而變革的話，可能會遭受空前的打擊 …

哪些大環境有激烈的改變? 就是2011年的四個變化，第一個是Google與Facebook的社交網路之爭，第二個是Google與Apple的行動平台之爭，第三個是Google對於於網路內容品質的規範改變 (也就是Google Panda Update)，第四個是Google與其他搜尋引擎對於Microdata的支援。

這四個重大的改變將會成為2012年操作SEO的重要準則，也就是你必須把「社交」、「行動」、「品質」、「語意」謹記在心，才能擬定出成功的SEO策略。

相關內容你可以參考:

2012年10個行動與社交搜尋的思考

2012年的行動搜尋優化 (Mobile SEO)

SEO與Google Plus比較，是否搜尋行銷已經不再有效?

Google+的資料是否被Google搜尋偏好?

應該如何避免被Google Panda演算法處罰?

回顧2011年SEO重要事件，預測2012年可能變化

但是我應該如何針對「社交」、「行動」、「品質」、「語意」四個準則來進行呢? 以下是實務上的建議:

(1) 應該針對多個社交網路進行網站推廣，如Facebook、Google+、Twitter、Plurk、funP … 等等。

為什麼要針對這麼多的「社交網路」呢?

因為不要把雞蛋放在一個籃子，我們不知道任何一個「社交網路」會不會變化得讓我們不能持續活動，所以最好維持幾個「社交網路」的運作。

但是我們也知道，許多人會對於「社交網路」存有疑問: 「我們在Facebook上弄了半天，不是沒有吸引多少人，就是吸引進來的人沒有消費意願，怎麼辦?」

其實主要是誤會了「社交網路」的意義，「社交網路」不是只有刊登你的廣告文，「社交網路」不是吸引人們進來買東西的，「社交網路」是用來跟網友進行社交活動的，當他在不經意間的經常看到你的logo、或是習慣了你的產品訴求之後，當他需要的時候會去想到你的產品。

因此「社交網路」的投資報酬率，會跟產品類型有關係，有些少數產品類型確實可以很快的看到回收，但是大多的產品類型都不太可能具有高的投資報酬率。

另外的問題是: 「不是只有刊登廣告文，那麼要刊登什麼呢?」這個跟實體世界交朋友一樣，交朋友應該聊什麼? 實在沒有一定的規範，只能自己去摸索出一套方式了。

「社交網路」的最後一個經常被質疑的問題是: 「我怎麼知道哪些人是目標客戶?」

如果跟「社交網路」上的人社交半天，才發現他們根本不是我的客戶群，那豈不是很虧嗎? 根本在浪費時間嗎?

應該如何鎖定「社交網路」上的目標呢? 方式有很多，我們舉一個例子，要增加你的企業粉絲頁的曝光度，可以透過「管理群」的社交擴展來達成。

如果你的企業粉絲頁有三個管理者，當這些管理者的朋友數越多，這三個管理者的分享內容或是按下讚的內容，就會被朋友看到。

所以聰明的去增加管理者的朋友數，並且針對目標客戶群去進行，就可以增加你的企業粉絲頁的曝光度。

除了使用「社交網路」去推廣網頁之外，還必須讓你的網頁能夠很容易的讓使用者Like或是+1，如下圖 …

(2) 如果你的客戶可能在行動設備上瀏覽，那麼你就必須思考Mobile SEO策略。

哪類企業的客戶會在行動設備上瀏覽? 大多是具有實體店面的企業。而沒有實體店面的企業，至少也必須思考平板設備上瀏覽網頁的順暢度。

談到策略，可能許多人又不知如何是好，其實很簡單，主要就是思考「應該如何讓搜尋者可以很快的在行動設備上找到你的網站，或是實體商店資訊，並且順利的瀏覽網頁」。

在桌上電腦跟行動設備搜尋或是瀏覽，有什麼不同呢?

第一個原因是: Googlebot-Mobile，因為這個Google的特殊機器人會去抓行動設備專用的網頁，所以最好有行動設備專用的頁面。

第二個原因是: 行動設備通常是持續登入Google狀態下，會有個人化的問題，搜尋結果的排序可能會跟未登入時不同。

第三個原因是: 行動設備進行搜尋時，通常希望在最少操作下，可以看到搜尋內容。

第四個原因是: 行動設備的螢幕大小限制，正常網頁畫面不適合瀏覽。

所以你就必須思考上面的問題，讓行動設備搜尋者可以順利完成他的需求。

(3) 你的網頁最好能夠符合Google Panda Update的品質規範。

關於Google Panda Update的內容，我們已經談過很多，就不再贅言。

(4) 你的網頁最好能夠開始使用Rich Snippets。

為什麼要符合Rich Snippets? 如下圖，使用Rich Snippets可以讓許多訊息直接顯示在SERP上，不需要點選進入網頁。

如果你能夠就以上的項目進行審視你的網站，並且進行改善，相信在2012年可以讓你的網站增加許多曝光的機會。

你希望成為台灣SEO搜尋引擎技術學院的學員嗎? 歡迎參加SEO達人基礎實務班，可以比別人更早一步瞭解更多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可能把你的資料精華「浮」到上面來了，使用者不再需要點選進去你的網站去尋找，雖然讓使用者更方便了，但是卻傷害了網站的流量，就如同百貨公司一樣，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擊垮，也會被其他競爭者取代。