2017年1月8日 星期日

年營收 35 億美金的 Steam 如何再一次優化網站?

在網站製作中, 我最推崇幾個網站:

1. IMDB: 在 Web 1.5 中, 實現使用者導向與內容技術最好的典範,  尤其是對 Keyword 在搜尋的應用, 更是早期的投入者.

2. Steam: 利用資料與功能來強化使用者體驗, 並真的以社群為導向的 "電子商務網站", 且真的是站在消費者這邊.

3. Milanoo: 對於產品分類與選項, 有其獨道之處, 尤其是 "聚焦" 在特殊產品是相當便利的使用者介面.

前一陣子看到 Steam 的改版, 雖然他們一直在改版, 但這次的改版更令我驚豔, 雖然我知道大家提到 Steam 都是聚焦在他們是個很獨特的 "數位內容" 消費網站, 但也因為這些是數位內容, 使用者經驗更是重要.

雖然我知道有不少人不知道甚麼是 Steam, 要介紹也介紹不完, 但大家只要知道, 即使是 Amazon 執電子商務牛耳, 但遇到遊戲產業的數位內容消費, 還是落後 Steam 一大截, 更不要說 Sony 的 PS Store 與 Microsoft 的 Xbox 商店, 當然硬是要說比 Steam 大的就是 Apple 的 Appstore 與 Google Play 有關遊戲部份, 雖然商品方向也不太一樣.

而 Steam 的網站設計有一個跟大部份網站不一樣的地方, 就是絕大多數的網站在努力簡化網站的流程與功能, 而 Steam Store 是反其道而行, 把網站的功能強大化, 來迎合玩家對尋找, 判斷, 購買遊戲的須求.

太多的電子商務網站, 想要做的就是一直推銷商品, 不太介意商品是不是真的消費者所要的, 只要賺到錢, 剩下的問題就是場商與產品的問題, 但 Steam 一直是想辦法讓玩家找到自己想要的遊戲, 所以大部份的電子商務網站 "個人化", "資料探勘(Data Mining)" 都是做假的, 通常只是聊備一格的裝飾品, 而 Steam 這部份倒是以這為重心.

所以這次 Steam 的改版, 更增強了一些功能:

1. 個人化介面: 選單可以自訂, 甚至廣告的內容可以自訂, 推薦的方式可以自訂, 幾乎可以打造屬於自己的 Steam 首頁了.

2. 個人行為輔助: 不只是前面提資料探勘結果的 "探索佇列", Steam 把買過的, 最近更新的, 沒興趣的, 不是 Highlight 提示或是過濾引藏, 讓 Wishlist 或相反的 No Interest 當作介面的強化, 不再只是種清單而已, 而那些最近瀏灠, 推薦早就是標準配備了.

3. 好友是最好的推銷員: 現在在首頁就可以看到好友在玩甚麼, 想買甚麼, 當然每一個商店頁本來就可以看到那些朋友想買或已經在玩,  這些都可以強化消費動機, 畢竟遊戲是一起玩是最好玩的.

4. 鑑賞家的強化: 以社群為中心的行銷, 當然不是用甚麼廣告代言人, 而是找出社群的意見領秀做領頭羊, 無論是推薦或是吐嘲, 一點也不避誨.

5. 即時的資訊: 有時會讓使用者更有意願留下來, 是提供無窮無盡有意義的資訊, 而 Infinite Scrooll (無限捲軸) 是一個最簡單的出發, 但更多的即時資訊的聚合有時才會讓使用者一直看, 一直看, 怎樣找出有意義的即時資訊給使用者, 無論是好友或是個人等等所觸發, 都須要規劃者認真去思索.

當然做這麼多, 最困難的不只是把這些功能做出來, 而是在完全不攜牲速度的前提下, 這不只是對技術須求有很高的挑戰, 而是真的認真思考 "可行性" 分析這件事, 尤其是大部份網站的功能須求, 都是由行銷所提出, 而技術端無法找到一個方法去達到 "使用者體驗" 優化的標準, 而 Steam 有很多小細節對技術人員都是很好的參考, 每一項設計都是相當有趣的.

雖然 Steam 的網站開發也曾發生過災難, 例如曾經開放使用者下標籤, 但沒有去聚焦而過於發散後失去意義, 但或許 Steam 是個社群網站, 很快的就調整腳步去改善, 因此可以證明 Steam 並沒有失去創新的精神, 只是這過程能夠更好, 幾乎是每一個網站經營管理開發者須要一起學習的.

只是台灣應該沒有一個電子商務網站有做到 35 億美金, 但透過 Steam 的經驗, 或許能夠讓我們學習, 即使有些是很難複製的, 但我相信透過使用者導向, 資料導向的優化與設計, 先行者給我的啟發就很有意義了.

網址: http://store.steampowered.com/about/newstore2016/

我的 2016 年記....

若我們的見面是以年為單位的話, 下次你見到我時問 "你最近過得如何?", 或許用這篇可以跟你講我 2016 年整體而言過得如何? 也就是我在 2016 年最值得題的 10 件事:

1. 新文易數

從 2014 年末寫到現在, 新文易數一直在改版, 2016 年嚴格說是改版較少的一年, 但遇到 Facebook API 一直 "改變", 很多 API 不能用得情形也得一直修改, 由其是針對 "正負向" 的計算, 到依人物, 議題一起比較的排行榜, 甚至比較媒體在社群的表現, 多少還是有點進展, 只是經營過網站的人就知道一件事: "維護一個系統是相當不容易的".

2. 未來國會, 未來新聞, 未來政論

而在 2015 年底時打造了一個 "未來國會" 這樣的平台, 覺得相當有價值, 因此很想繼續做類似的事情, 因此嘗試用相同的模式再次創造 "未來新聞" 這平台, 雖然已經做出成果, 但最後還是被腰斬沒有公開 (果然辦公室政治很複雜), 雖然因此情續低潮了好幾個月, 而再打起精神做 "未來政論" 這計劃, 而這計劃還在執行中, 希望能夠做出對社會有意義的東西.. (事實上也是自己想用啦~~)

3. 工作的開始與結束

因為同時在很多公司上班 (累~~), 雖然有一半都很穩定, 但相對的有一半是不穩定的, 有幾個是做三年五年以上, 甚至是快 10 年 (9年) 的, 但也有一個是不到一年就被腰斬的 (這很少見), 最後是有兩到三個工作在 2016 年結束, 一個是從 2014 年的姊妹淘, 一個是做不到一年的風傳媒, 但也因此開始了關鍵評論網的旅程, 也獲得了很大的成果.

4. 遊戲: Pokemon Go, Civ6, Clickers Hero, Royal Clash

遊戲一直是很好浪費時間的美好事情之一, 2016 的年度大作 "文明帝國六" 是不可能漏掉的精神時光之屋, 而 Pokemon Go 能說是讓 "走路" 增加情趣的遊戲, Clickers Hero 是填空無聊時間的最佳遊戲, Royal Clash 是能夠在 3~5 分鐘決定有好心情好轉或持續低落的真槍實彈, 雖然很想否認, 但這部份花掉的時間是有一定的比例.

6. Netflix

另一個 "浪費時間與生命的美好事物" 比例的就是電影與音樂, 2016 最大的改變就是 Netflix 終於到台灣了, 也因此多看了一堆美劇與少量的電影, 當然雖然有 Hinet-MOD 與 Spotify, 但相對的豐富度還是有段距離, 在此推薦朋友 Netflix, 把第四台剪掉吧.....

7. 台灣輕旅行 

旅行的時間總是可遇不可求, 大概是在連續假期時才比較有機會吧, 2016 年出遊了三次, 去了關西 (小叮噹), 花蓮, 及滿洲跟埔里, 而本來有一次想再去花蓮, 想要騎機車在山間的感覺, 但後來颱風來攪局只好放棄了.

8. 騎腳踏車

若是說今年有甚麼不一樣的, 大概就是騎腳踏車吧, 因為沒機會方便的打桌球之後, 就只好換個項目運動, 幸好有 Ubike, 河濱公園的夜騎一直是很愜意的, 雖然沒有真的建立成為好習慣, 但也騎到淡水過一次, 感覺相當不錯, 希望 2017 能夠增加頻率阿....

9. Hackathons, Workshops, Speech, Lessons

除了工作外, 去參加黑客松或 Workshop, 偶而客串當評審或講者, 一直是讓常常會有低潮的我有點翻轉的機會, 但還是一如往常的, 不會得獎是一定的, 雖然這不會是我的重點, 重點是 "吃喝玩樂" 吧.....

10. 科展, 電腦

在之前曾經想要帶著小孩來趟 "圖書館之旅", 來到各個圖書館走走, 但畢竟小孩比我還忙, 偶而抽空帶他去咖啡店走走說不定機會較高, 最後是因為科展的關係, 就用 "Live Demo" 的方式導引大兒子寫程式, 居然最後有不錯的成績, 也確定的確電腦是不用教的, 是用 "做" 的.

除了上面 10 點外, 的確有遺珠之憾, 例如今年是換手機的一年 (因為上隻手機也用三年多), 但先換到 Samsung Tab S 受不了還是換回 Sony Z3 Tablet, 陪小孩聽演奏會或聽他的演奏會, 只是 2016 相較前幾年次數較少, 本來還有個 "實況" 的一年, 就是投入實況投票與實況監看的開發, 只是相較前面無論就影響或時間都是較少.

我相信這些項目這幾年下來, 有其變, 也有其不變, 這也是人生阿....

2016年12月30日 星期五

meta tag, 決定 SEO 的 25 項標準與通訊協定系列 XV

在 Head 中, 理論上只有幾個 tag:

1. titlte
2. style
3. base
4. link
5. meta
6. script
7. noscript

這 7 個 tag 要去描述接下來真正被讀者看到, 除外都是被瀏灠器呈現 (Render) 的本體 (Body), 而 Body 有超過一百個 tag 來去 Markup 出內容, 但這幾個 head 的 tag, 說不重要是因為讀者看不到, 沒寫也沒關係, 但事實上當你考慮到 SEO 時, 又完全不是這麼一回事了.

我都說以 SEO 結構的觀點, 最重要的項目是:

1. Domain Name 網域
2. Directory 目錄
3. URL 網址
4. Title 標題
5. Description 描述
6. H1 Head1
7. 其他

當然通常第 1 項網域的改變與新增是大事, 通常網頁在討論與考慮的, 在網址之外就是標題與描述了, 而標題在 HTML Tag 中就是 head 的 title, 那緊次於這些的 "描述" 呢? 這描述就躲在 meta 裏面.

所以這個 meta 到底重不重要呢? 基本上有在用 Search Console (原本叫 Webmaster Tools) 的人知道, 都會有一個 HTML 錯誤與改善, 其中有一個就是針對描述, 也就是 meta 這個 description 的 property 的使用, 若是沒有或是太短, 就是 SEO 很糟糕的事.

事實上不只 SERP (Search Engine Result Page) 有時也會使用 Description 做為網址標題後的描述, 這往往是決定讀者會不會點進的關鍵, 而後面更不用說更不用說了, 其他的 JSON-LD (ld+json) 等等的事都是排在後面附加想要加分的項目, 有時再怎樣也不會比 title 與 description 重要.

在前面幾個也提到, 在 head 裏面可以做許多事:

1. 宣告 robots 如何讀取, 也是 meta 的一種
2. Open Graph 都是用 meta
3. RSS 也是種 link alternative
4. AMP 也是靠 head 來去宣告
5. Sitemap 也是個 link
6. JSON-LD 是種 script
7. Google News Crawler 也有自己的 meta, 如 news-keywords
8. Breadcrumb 也是可以定義在 JSON-LD 中

當然雖然不完全都是靠 meta 來做定義, 但這邊就可以看到 head 的重要性與 meta 這個 tag 的重要性, 但也如同我上一篇說的, 這些標準與協定, 幾乎是沒有獨立存在的, 幾乎是共同架構出這個網頁, 網站, 知識庫的.

我是很想排出重要的 meta element 的....

1. description
2. robots 相關
3. charset 與 
4. content 與 http-equiv
5. viewport (RWD 後)
6. Social Card/Graph (twiiter, facebook 之後)
7. 新聞使用
8. 作者與時間
9. 其他 schema

上面有那些是你還沒加到呢?

2016年12月29日 星期四

Breadcrumb, 決定 SEO 的 25 項標準與通訊協定系列 XIV

Breadcrumb in schema: https://schema.org/breadcrumb
Breadcrumb in WebSchema: https://www.w3.org/wiki/WebSchemas/Breadcrumbs
Breadcrumb in WAI: https://www.w3.org/WAI/tutorials/menus/multiple-ways/
Breadcrumb in WHATWG: https://html.spec.whatwg.org/multipage/scripting.html#rel-up
Breadcrumb in HTML5: https://developer.mozilla.org/en/docs/Web/HTML/Element/nav

事實上這一系列講到這邊已經錯縱複雜了, 就像是 JSON-LD 是架構在 Linked Data 上, Linked Data 上是須要在 Microdata (Schema) 定義, WAI 也是用這些去建立起來, 而這些都是基於在 HTML (HTML5) 上, 而這些又須要 HTTP 的通訊協定才能運作, 說是已經寫成白紙黑字的標準, 有時能夠運作也是架構在許多的可能性與乎略很多複雜度才能實作的.

前一篇談到 Linked Data, 也講到 JSON-LD 是種實作, 而上面又有 LDP (Linked Data Platform) 與 JSON-LD API 的發展, 這些完全是必要知道的, 但說說跟 SEO 有很大的相關, 多少也是強說愁, 因為有那些內容與型式, 甚至是經營跟 SEO 是無關的呢?

但這邊想從 Schema, W3C, WAI, WHATWG 等等的實作中, 拉出一個很重要的概念, 就是 Breadcrumb (麵包屑), 以及所屬的 Navigation / Menu 等等的概念.

在現在的 SEO 角度來看, 能夠讓使用者繼續看下去的網站就是好的網站, 因為太多的網站都是看一頁就離開, 不是因為已經獲得解答, 而是無法獲得資訊的網站, 能夠讓使用者更進一步的得到他想要的資訊, 也就是一個網頁若能夠有好的 CTR (Click through Rate), 往往代表這個網站的價值較高, 因此對 SEO 是很好的訊號 (Signal) 或因素 (Metics).

而一個網站可以分成主要兩種頁面, 一個是內容頁, 一個是中間頁, 而中間頁包含:

1. 首頁
2. 分類頁
3. 搜尋頁
4. 標籤頁
5. 功能頁

而這些頁面的交互關係, 靠得就是連結, 而這個產生連結的方式有很多種, 就 HTML5 的角度定義了幾種:

1. Header
2. Navigation (nav)
3. Sidebar (aside)
4. foooter
5. section

以及真正的 article, 而其中的 Navigation 就是包含 menu, catalogue, breadcrumb 等等的方式, 而較具有跟這頁有直接關係可以看得出來的就是麵包屑, 麵包屑是可以清楚讓使用者知道這網頁所在的位置, 與上下層關係, 甚至是路逕.

當時的 Practice 是建議用這三種方式去實作:





而在 HTML5 之後, 麵包屑無論是用甚麼方式呈現, 都要用 <nav> 將之包起來,  像下面那樣..



在 WAI 中, 更希望加入 role, class 與 aria-label, 如下:



事實上在 Schema 與 JSON-LD 的實作下, 也該是如此:



看到這邊, 大家會不會覺得一個簡單的麵包屑, 居然如此的博大精深, 真的到處都存在, 因為事實上在 SERP 中, 已經早就導入這概念, 包含前面說的 News 的 Section.

這系列講的是 SEO 與標準的關係, 就講到這邊, 但事實上麵包屑是相當重要的事, 無論就 Semantic Web, 就 Data Mining, 就 Tag (標籤), 分類的角度, 都有不同的思維, 但說穿了這些都是為了建立知識, 讓資訊串起來, 只要是人在做資訊獲取 (Information Retrievaling), 這件事永遠跑不掉.

2016年12月28日 星期三

Linked (Open) Data, 決定 SEO 的 25 項標準與通訊協定系列 IIVX


Part of the Linking Open (LOD) Data Project Cloud Diagram, click for full and historical versions...

Linked Data: http://linkeddata.org/

我們常常把資料給複製&貼上, 只是也在想, 若這些複製貼上不是只有內容, 而是導引成一個可以串接起來的資料時, 當源頭修改時, 後面的資料也是否可以同步修正呢?

Linked Data 的概念就是就透過 URIs (Uniform Resource Identifier) 與 RDF (Resource Description Framework) 的實作, 把資料給 "Linked (串接)" 起來, 讓資料變成資訊, 讓資訊變成知識的可能性, 也就是之前提到 Google 一直在推的, Knowledge Graph.

在 JSON-LD 中, 只是說把 Linked Data 用 JSON 包起來, 而後讓搜尋引擎的 Crawler 更容易知道這是甚麼樣的結構化資料 (Structured Data), 這資料透過 Schema.org (Microdata) 包含描述與使用, 也是因為透過這樣的共通定義, 讓資料再利用得以實現, 進一步的建立知識.

的確透過這樣的方式, 我們可以追溯知識的起源與結果, 但在還沒有實現 "Knowledge is the One" 時, Linked Data 是用各式各樣的 Datasets 去描述, 在上面的圖都有看到,其中也包含較知名的:

1. DBpedia: 將 Wikipedia 的資料 Linked Data 化
2. FOAF: 描述人語人之間的關係
3. GeoNames: 地理名稱
4. UMBEL: 透過 Web Ontology Language 建立最基本人工智慧須要的 Semantic Web.

只是大家看到這邊, 的確 Linked Data 很偉大, 但跟 SEO 的關係為何呢? 誠實說, 我也只是猜測, 尤其是 Knowledge Graph 這塊.

雖然不否認的 Knowledge Graph 現在是一個呈現在 SERP (搜尋引擎結果頁) 的欄位, 但由於有其連結, 一定會帶入流量, 雖然這些 Knowledge Graph 幾乎是被知名的網站所占據位子, 不是因為那些網站真的導入 Linked Data, 而是蠻多是 Google 刻意打造出來的, 但若網站本身就提供 Linked Data 時, 不否認的 Google 未來會引用的機會蠻高.

只是拉回來, 這個所謂的 Linked Data 跟之前的 Trackback 多少也是有關係的, 甚至這個還導出 seealso 及 breadcrumb 種種的 Protocol, 而能夠把資訊串連, 而這個 "連結" 也是 SEO 一個很重要的基礎不是嗎?

所以在之前, 還是先把 JSON-LD 做好, 甚至的嘗試著做 Linked Data Platform, 或許對網站的架構會更完善, 這就明天再說了...

2016年12月27日 星期二

AMP, 決定 SEO 的 25 項標準與通訊協定系列 XII

AMP Project: https://www.ampproject.org/

這在某種角度又是一個很 Hacking 的通訊協定, 甚至有時連 "標準" 都談不上, 就像是 Facebook 的 Instant Article 一樣, 雖然說是種大家一起遵守的東西, 甚至是有實用性, 但在某方面又是種為了保持優勢的大公司企圖.

雖然從很早開始, "Speed" 網站速度就是決定網站 "價值" 的一件事, 因為速度夠快, 才能夠被搜尋引擎 Crawler 抓取的夠快, 索引 Index 的夠多, 當然對 SEO 的幫助是正面的, 因此網站讀取速度一直是被做為很大的因子 Metics.

而 AMP (Accelerated Mobile Pages) 雖然是為了手機加速的通訊協定, 但現在已經有足夠多的使用者要去更嚴肅的面對, 尤其是手機的讀取往往代表的就是通訊速度不夠快, 下載時間較久, CPU 也不夠好, 執行時間也被拉長, 因此的確須要有一個能夠讓手機加速讀取的方式, 這就是 AMP.

也因為這是 Google 主導的, 因此在 Search Console (原 Webmaster) 中, AMP 是很重要的一環, 有了 AMP 頁, 一定在行動裝置的搜尋占有優勢, 但予其這樣說, 加快網頁速度的確不完全只是為了 "SEO", 這是一個內容為王, 使用者體驗為后的狀況, 沒有好的使用者體驗, 王就會失去價值.

在 Search Console 已經有足夠完善的文件與 Validation 驗證的工具與錯誤檢核的機制, 這邊不太須要說, 但該討論的是, 在 AMP 做的時候, 我們還能夠思考甚麼?

的確在前端這概念雖然推出沒多久, 但這困難度與重要度就足以把這工作項目區分出來, 就是前端(工程師), AMP 雖然也是個前端, 但思考的方式跟很多前端不一樣, 即使也是有很多是一樣的, 尤其是一個最麻煩的衝突點:

使用者體驗 > 開發者體驗 > 易於開發

現在的前端有太多的 Framework, 這些架構都是為了加速開發, 且有更不錯的體驗, 只是這個體驗有時會使用太多的記憶體與 CPU 的資源, 雖然這些也都會降低使用者體驗, 但大部份的開發者與讀者有時會太著重炫麗的表現, 而沒有注意到是否有太多讀者並沒有真的提高使用者體驗.

但不得不否認的, AMP 到底是個過渡性的協定與標準, 還是以後會持續下去, 我個人是不看好, 但有些概念的確是好的, 可以做為參考, 但有些是的確會被淘汰的, 就像是上面那個衝突點, 這是沒有絕對的對錯, 但你要知道你自己在甚麼樣的角度去做這事情.

只是現在, 為了使用者, 真的要去考慮到速度, 所以用這個角度來看, AMP 是相當重要, 真的要去認真面對的事, 甚至手機版就是要用這角度去開發, 即使只有這三年, 但, 你的網站難道在三年後還會繼續使用原本的版型嗎? 所以這一點也不算是做白工.

2016年12月26日 星期一

前九個協定/標準統整介紹, 決定 SEO 的 25 項標準與通訊協定系列 XI

在開始寫時, 就在想一個有趣的問題:

我還有時間寫嗎?

現在我手上有 N 個工作, 重點是有一個大計劃, 除外還有很多小計劃把我的時間瓜分掉, 所以答案應該是 "沒有時間寫", 但此時要換一個問題:

我還須要成長與反思嗎?

這答案是肯定的, 因為這樣重新壓擠自己的時間去延伸閱讀, 思考到反芻, 就前幾次的經驗證明我每寫一次就在這議題有更進一步的感受.

而我一直覺得台灣缺少的就是這類的 Open Document, Open Practice 的 Working Group 去認真的討論, 實踐, 每次都是個案, 每次都是見招拆招, 每次都是很片斷的淺短評論, 有多少人真的去踏實的去實作, 去系統化的解決問題?

回頭來看我須要學習的東西太多了, 無論是 Search Engine Optimization, Open Data, Data Mining, ... 雖然說穿了都是 Data, 但我知道我的基礎工還是不夠, 須要一直不斷的學習, 但在於時間不夠的情況下, 或許把整個 Data Science 的 Scope 縮到最小, 就是 SEO, 因此, "決定未來 SEO 的 25 項標準與通訊協定系列" 就這樣子出來了.

在想即使寫得不夠好, 但至少當成是自己的 Roadmap, 也給初學者一個 Roadmap 或許或多或少對自己, 對大家有點幫助.

目前已經寫的是下面九篇文章:

  1. JSON-LD: 更輕易的描寫網頁的 Schema
  2. WAI-ARIA: 定義出對行動障礙者的網頁互動
  3. Open Graph: 讓網頁被社群網站所使用
  4. Site Maps: 讓搜尋引擎更好知道如何索引網站
  5. RSS: 讓網站被其他機器讀取時間, 標題與大綱
  6. Robots.txt: 避免搜尋引擎索引到不該讀取的網頁
  7. Author: 讓網頁有作者宣告, 而建立作者的威信
  8. Trackback: 讓網頁知道被其他的網頁所使用, 提及
  9. Google News Sitemap: 讓 Google 的新聞爬蟲更精確抓取

這些協定與標準, 是透過許多 Working Group 所製定出來的, 包含 W3C, Google, Facebook 或其他單一組織, 從這些標準制定的過程與背後, 可以看到許多的思維, 即使有些是很商業的導向, 但也是架構在 "須求" 的角度去出發, 才能獲得共鳴, 協定與標準才能產生意義, 就像是我多的, IC 能夠再利用不是封裝的概念 (Encapsultion) 而已, 而是必須大家共同使用一本 IC Book 才行, 知道 7400 的 Nand 腳位是如何安排, 才能組合這些資訊的運作, 發揮效用.

SEO 多少也是須要這樣, 管理一個網站也是須要這樣, 經營一間公司更不用說, 治理一個國家更也須要這樣的概念, 建立系統, 建立制度, 建立標準, 建立溝通管道, 建立工作模式, 建立連接格式, ... 有這樣的 Standard 與 protocol, 才可能會有 Open Goverment, Open Social, Open Business, .....

不知道這九篇對大家有沒有幫助, 聽說很多人覺得看了之後還是更看不懂, 這可以肯定不是大家的問題, 而是我的問題, 畢竟我的文筆很糟也不是一天兩天了, 即使有人覺得我一篇這樣跟本寫不到一千字, 跟我平常就寫出兩三千字差很多, 雖然我不否認有可能是江郎才盡, 但主要也是要趕在 12 :00 前寫完真的是有點辛苦.

只是現在面臨一個問題就是接下來與 SEO 相關的協定與標準, 不是過大不然就是關聯度不高, 不然就是很難寫, 來試試看想接下來還能寫的有那些題目:

1. HTML Logical Tags
2. HTML5 New Tags
3. HTTP Error Code
4. AMP
5. Instant Article (Social Signal)
6. Link Data (Knowledge Graph)
7. Twitter Card and Other Social Signal
8. JSLD-API
9. Schema.org
10. .........

現在已經不像以前可以找資料一面唸個兩三小時, 再來花一個小時去寫了, 從找資料到寫出來可能要在半個小時到一個小時之內, 這些題目的挑戰已經過於巨大, 畢竟我不是為了寫而寫, 而是為了自我學習而寫, 雖然知道無法跟前幾屆那樣寫得精彩已成事實, 而明天大家能不能看到我的文章, 我現在也沒有把握, 只能說, Have Fun~~~~

2016年12月25日 星期日

Google News Sitemap, 決定 SEO 的 25 項標準與通訊協定系列 X

Sitemap News: http://www.google.com/schemas/sitemap-news/0.9/sitemap-news.xsd

這個 XML 的 Namespace 可能對大部份的人都不重要, 除非是對新聞網站, 因為這個 Sitemap 出現的結果不是在一般搜尋, 而是新聞搜尋....

為甚麼對大多數人都不重要呢? 因為要被 Google 認定是新聞網站是要經過申請的, 而這申請相當不容易, 台灣也只有幾十個網站被認為是新聞網站 (事實上也是這麼多而已), 所以也只有這些網站做得到.

若申請成功的話, 的確有很多事情要做:

1. Google News Crawler 有專屬的 sitemap
2. metadata 也有專屬的 name, 其中包含 news-keywords
3. 在 Publisher Center 設定分類
4. 在 Publisher Center 設定編輯嚴選之類的, 包含 App
5. 之後在 Search Console 可以看到 News Crawler 的錯誤

而這個 News Sitemap 的專屬 Tag 也沒有多少個:

1. publication: (name, language)
2. access
3. genres
4. publication_date
5. title
6. keyword
7. stock_tickers

這些都是寫在 sitemap 的, 也是去 search console 去 submit, 然後 crawler 就會自動抓了, 但這都不是問題, 問題是出的問題 (繞口令?), 也就是 Crawler Error 的如何解決, 常用的問題有這三種:

1. Article too long
2. Article too short
3. Fragmented Article


但這邊就不詳細解釋要如何解決問題了, 雖然大部份就可以去查 Google 那些有說跟沒有說一樣的官方說法.

只是拉回來要問的是, 真的有人在用 Google News Search 嗎? 當然這邊指的 News Crawler 會出現在 Google News 上面, 甚至在一般的 SERP 因為偶而會有一個欄位是給新聞使用, 而這個是保證在第一頁的, 說不重要還是很重要, 因此還是要想辦法解決 Sitemap News 的 Error 與 News Crawler 的 Error, ...

畢竟沒有人嫌流量太多的, 不是嗎? 

LinkWithin

Related Posts Plugin for WordPress, Blogger...

熱門文章