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

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

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), 這件事永遠跑不掉.

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

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, 或許對網站的架構會更完善, 這就明天再說了...

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 是相當重要, 真的要去認真面對的事, 甚至手機版就是要用這角度去開發, 即使只有這三年, 但, 你的網站難道在三年後還會繼續使用原本的版型嗎? 所以這一點也不算是做白工.

前九個協定/標準統整介紹, 決定 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~~~~

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, ...

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

TrackBack, 決定 SEO 的 25 項標準與通訊協定系列 IX

MovableType: https://movabletype.org/documentation/trackback/specification.html

今晚是聖誕夜, 雖然想要早點寫完來看 Netflix 在 Sense8 拍的聖誕夜特輯, 但也要先寫完才放心, 但既然今晚是聖誕夜, 就來寫三個聖誕夜鬼魂的故事, LinkBack...

看過 "Christmas Carol/小氣財神" 的人應該都知道這故事, 雖然你不見得是看狄更森 (Dickens) 的原著, 但經過無數多次的改編, 很多人都知道這三個陰魂不散的鬼魂一直敲著我們, 一直連在我們背後 (Link Back).

這個 Linkback 有三個標準 (或加一):

1. Tackback (Ping), 由 Six Apart 所提出, 透過 HTTP Post 直接發出.
2. Pingback,  透過 XML-RPC 的格式發出  Back Link Ping.
3. Webmention, 由 W3C 所提出, 透過 HTTP POST 再加上認證的機制

這個 LinkBack 是個很好的東西, 是將資料的源頭串接起來, 在論文的觀點就是 "Reference/參考", 當然有時只是種延伸, 當有人寫出一篇不錯的文章, 就會有人想要回應, 而當然後面寫的人可以加註來源或網址, 就可以往前回去看, 但有了 TrackBack 這種機制, 就可以知道後面或前面的人是怎麼提及, 怎麼寫的, 此時就可以加上來源, 讓資訊能夠更流通, 讀者可以更了解全貌, 事實得已檢驗.

但為甚麼後來就沒人用呢? 當然就是那群萬惡的黑帽 SEOer.....

Google 計算網站價值, 最初用的就是 PageRank (PR) 這概念, 也就是 Reference 的觀點, 一個網站被提及或連結越多次, 這網站就越有價值, 而 Trackback 在 Blogging 時的效果就是你在你的文章提到一個網頁時, 系統就會自動或半自動發出 Trackback 的訊息給原網站知道, 原網站就可以建立一個連結連到後來寫的網站.

這種 Link Building 連結建立很快的就立刻被黑帽所使用, 發出大量不是真的 "引用" 來建立大量的外連, 最後大部份的系統在不受其擾的情形下關掉 Trackback, 而這協定也因為沒人再用就這樣死亡了.

雖然有人提出加入一些更嚴謹的回頭檢驗的機制, Pingback 相較之下比 Trackback 更不容易被 Spam, 但這種 LinkBack 機制已經被很多人恐懼較少使用, 最後實務上還是用得人不多.

此時 W3C 就接手了, 在 Social Web Working Group 的運作下, 在今年一月 12 日提出一個草案, 透過能夠 Verification (確認) 的機制來證明, 再加上 Vouch 做為 anti-spam 的機制, 應該就會好很多了, 但因為目前還是太新, 真的開發出來用得還是不多, 這能不能夠有效就看未來了.

那還有一個加一的 LinkBack 呢? 這個是透過瀏灠者的瀏灠器, 將上一頁閱讀的網頁回傳回去, 雖然這個幾乎是沒有人不實作, 但現在因為 Google 把 Search 的 Referral 全部跳轉後, 已經無法知道讀者是因為搜尋甚麼進來, 因此這個 Linkback 雖然沒有死, 但也是半殘了....

嗯, 今晚的耶誕夜不知道大家過得如何呢? 希望 SEOer 能夠更多愛一點讀者, 多愛一點網站, 不要再做虛假的事, 讓這個社會能夠更有意義的運作, 然後, Merry Xmas....... 希望接下來的耶誕節 "未來" 鬼魂是我們期望看到的...., 不要跟我一樣把 "未來" 拿掉了.

PingBack: http://www.hixie.ch/specs/pingback/pingback
Wemention: https://www.w3.org/TR/2016/WD-webmention-20160112/

Author, 決定 SEO 的 25 項標準與通訊協定系列 IIX

Rel-Author in MicroFormats: http://microformats.org/wiki/rel-author

應該有人發現本來這個系列是叫 "決定未來 SEO 的 25 項標準與通訊協定系列", 但 "未來" 這兩個字被偷偷拿掉了, 因為若是真的要全部寫正在進行的未來, 可能就我的能力還是不夠, 且我發現還是不少人對 "基礎" 不夠, 因此就改了題目.

原本除了這個題目之外, 本來是想寫有關 Web 的 Authorship 的問題, 尤其現在這網路, 最大的問題之一是假新聞充斥的狀況, 因此也是考慮寫一系列的文章, 但這題目也是太難, 或者是跟  技術關聯不大, 因此也就放棄.

但話說我還是想把有關 Author, News 等等的真實性機制做點強調, 因此就來討論有關 "Author" 的這個概念.

在目前現行運作的格式中, 有兩個有關 Author 的用法:

<meta name="author" content="Hege Refsnes">
<a href="http://erin.example.com/" rel="author">Erin Smith</a>

一個是放在 Head, 一個是放在 Body, 一個是講現在的網頁, 一個是講連過去的網頁, 放在 Head 自然不會有任何作用, 但放在 Link 就不一樣, 只是事實上瀏灠器也沒有針對這部份做特別的呈現 (Render).

既然不會被看到, 就不會有人刻意會去用, 但 Google 在 2011~2014 年曾經為了推 Google+ 做為 Profile 時, 有推過 Rel-Author 出現在 SERP (Search Engine Result Page) 中, 如下圖:

但後來就沒有努力推了, 這或許是最大的問題, 但為了打擊假新聞, 這個 Authorship 的概念會不會被再提及, 應該機會很高..

雖然這個 Author 因為 Knowledge Graph 的關係有出現在 SERP 上, 但這個對大部份的 SEO 是一個相當困難的挑戰, 而幾乎是 "個人品牌" 的經營了.

只是未來這個 Author 會在 SEO 會扮演甚麼樣的角色, 讓我們拭目以待.

圖源: https://moz.com/blog/will-google-bring-back-google-authorship
圖源: https://contentequalsmoney.com/rel-author-and-publisher/

Robots.txt, 決定 SEO 的 25 項標準與通訊協定系列 VII

網站: http://www.robotstxt.org/

Robots.txt 或許是最早製定給搜尋引擎用的 Protocol, 若不算 ODP (Open Directory Project) 這個不算協定的東西, 這從 1994 年就開始, 也就是肯定跟 Google 無關的東西 (終於~~)

Robots Exclusion Standard 主要是為了排除機器人的爬蟲爬到不該爬的資料所設計, 所以是以 "排除" 做設計, 但裏面只有兩個主要的 item:

1. User-Agent: 刻意指那個搜尋引擎
2. Disallow: 排除那些目錄與網址

除外還有些沒有成為標準的項目:

3. Craw-Delay: 希望幾秒再來抓下一個網頁
4. Allow: 予許那些目錄與檔案, 在某些觀點很像 sitemap
5. Sitemap: 說明 sitemap 放在那, 這之前說過
6. Host: 建議使用那個網域

但這些都是為了搜尋引擎設記的, 對於會遵循的搜尋引擎自然不是問題, 但有些中國的搜尋引擎是不太管這些標準的.

在網站而言, robots.txt 是基本的, 至少對  Google 是有效的, 但這有時很難精確到每一個網頁對搜尋引擎以不同的控制, 因此就有了 name 為 robots 的 metadata, 像 Google 甚至有更多控制的選項, 以及對不同 Crawler 的方式, 如:

<meta name="googlebot" content="noindex">
<meta name="googlebot-news" content="nosnippet">

除了 robots.txt 以及 meta data 外, 事實上也可以透過 HTTP 的 Header 來傳遞資訊, 例如:

X-Robots-Tag: noindex

這部份的選項更多了, 如下圖:


不得否認的 Robots.txt 雖然是基本, 但也是可有可無, 因為這算是進階的控制, 而對於沒有注意到的人, 影響不大, 但對於想要進一步排除與控制搜尋引擎的人這是相當重要的, 但這要小心, 因為我曾看過有人不小心把 meta data 就設成 robots noindex, 然後就發生整個網站不被搜錄的慘劇 (不要笑, 我知道是你).

RSS, 決定 SEO 的 25 項標準與通訊協定系列 VI

最新 RSS (?) : http://www.rssboard.org/rss-2-0-1

上一篇講到 Sitemap 現在觀點已經不是一個好的 Protocol/Format, 因為現在網站已經太大, 或者是搜尋引擎已經夠好了, 所以須要的是補足搜尋引擎的不足, 也就是 "提示/Notification" 搜尋引擎新的內容就可以.

而的確 sitemap 的四種方式其中一項也是透過類似 ping/submit 的方式去告訴搜尋引擎有那些內容是新的, 或是修改過的, 但這項功能已經被黑帽 SEOer 玩壞了, 現在搜尋引擎不只限制數量, 甚至有時也沒用了, 這也是 SEO 的悲哀之一.

因此 sitemap 沒有時間戳記, 而在 1999 到 2001 年的時候, 有一個標準被制定, 就是 RSS, 從 RSS 0.9X, RSS 1.X, RSS2.X 等等, 這個跟很多協定不一樣, RSS 的版本有時是獨立的東西, 甚至不完全向下相容, 所以到最後都獨立存在, 而 RSS 有一個最大的用途, 就是 Notification.

RSS 可以是 Rich Site Summary, 也可以是 RDF Site Summary, 更可以是 Really Simple Sydication, 就可以知道這是一個以實用為主的實作, 來去定義 "Feed" 這個格式, 最主要的是為了當時的 Blog (部落格) 開發出來的, 但現在已經包含新聞, 頭條, 影片, 語音等等的內容.

因為這個 "Feed" 的概念, 很合適做為搜尋引擎或相關 Crawler (爬蟲) 做為索引的依據, 所以很快的變成 Sitemap 可以用的格式之一, 且經過幾年的發展, 也有一支獨立成 ATOM, 雖然 RSS 也 Extened (延伸) 了不少內容.

下表就是 RSS 與 ATOM 主要的差異, 也多少看到包含的內容.

其中 RSS 原本只是必要 title, link, description, 之後延伸出 language, copyright, managingEditor, webMaster, pubDate, lastBuildDate, category, generator, docs, cloud, ttl, image, rating, textInput, skipHours, skipDays 等等的 Element.

且 RSS 是架構在 XML 上面的, 因此除了最常 "Enhance" 上去的 dc (Dublin Core), 要加甚麼 NameSpace 都不是問題, 所以後來最有名的 FeedBurner, 也有了自己的格式, 而 FB (FeedBurner) 被買走之後, Google 也在上面加了給廣告, 新聞等等的元素.

因為 RSS 有時間戳記, 就真的可以給搜尋引擎很大的線索去 Indexing 索引網站, 所以有時我都建議使用 RSS 做 Sitemap 比用 sitemaps 這格式更有效率與意義.

只是在台灣, 真的認真用 RSS 的人真的不多, 尤其是在利用其他元素來做資訊, 例如縮圖, 分類, 都很少人實作, 然後最有趣的我還看過某家媒體還很認真的把 pubDate 用中文表示

難道他們不知道 RSS 的目的是用來 Machine Readable, 因此要遵循 RFC 822 嗎?

或許部落格 (Blog) 已不再是未來發展的重點, RSS 也隨著使用人越來越少淡出舞台, 但或許 SEO 的存在, 讓 RSS 還是有延續的空間因素之一.

Site Maps, 決定 SEO 的 25 項標準與通訊協定系列 IV

定義: https://www.sitemaps.org/

說到 Sitemaps 是一個很有趣的歷史, 從這邊可以看出整個網站的變化史.

這邊說的 Sitemaps 是指給機器讀取 (Machine Readable) 的網站網址結構, 是用來給搜尋引擎抓取資料所使用, 使用 XML 的方式將之列表, 協助搜尋引擎更完整的抓取網站做為檢索使用.

這個 Sitemaps 可以透過很多方式跟 Search Engine 講:

1. Sitemap Ping Submit: 透過一個參數傳遞給搜尋引擎
2. Robots.txt: 寫在 robots.txt, 如 Sitemap: http://www.example.com/sitemap-host1.xml
3. meta-data: 寫在 head 的 site, 如  <link rel="sitemap" href="/sitemap.xml" /> (現在變得很重要)
4. 透過介面提出: 這也是大部份人所使用的

這聽起來很完美, 但事實上 Sitemaps 怎樣也只是一種輔助搜尋引擎的工具, 若你的網站不大, 也不常更動, 基本上可以不用去管 Sitemap 的事, 但相對的是網站到很大的地步, 又很常更動的時候, Sitemaps Protocol (通訊協定) 的維護又是一個相當傷腦筋的事.

 Sitemaps 是一個透過 XML 來去列出網址 (url), 其他 sitemap, 包含說明這資料的更新週期 (changefreq) 與優先權 (priority) 的檔案, 而這檔案可以被 gz 壓縮, 但最多的資料不能超過 50000 筆資料與 50MB.

基本元素如下表, 但這個直接去網站看也可以:

只是這邊會有一個很大的問題, 現在的網站很少小於 50000 頁, 而若真的是拆開成 sitemap 不同檔案, 也會有很多個, 且網址本身的變化很快, 甚至最大的問題, 很難去了解網站的更新週期與優先權, 到最後很多網站這個都寫一樣或者不寫.

但最大的問題不是上面這幾個, 而是 sitemap 唯一的時間戳記是這檔案的時間, 且還是 Optional (可選擇), 而如何告訴搜尋引擎那些是新的, 那些是舊的就無從下手, 而有人的確是把最新新增與更動照時間排, 但這不是一個很好的作法.

sitemaps 在 SEO 是個基礎工, 一個好的 SEOer 是會無所不用其極的告訴搜尋引擎做對的事, 包含利用 sitemaps, 就像上面說的四種方法, 除了第一種較少人使用外, 後三種有沒有每一種都做, 就是決定一個好的 SEOer 是否有做好基本工的徵兆.

即使 Sitemap 這個 protocol 存在如此多的問題, 還是得做, 但事實上我已經從不鼓勵用 sitemaps.org 定義的 sitemap 到現在建議改用不同的格式來做 sitemap, 就是 RSS/ATOM.

Open Graph, 決定未來 SEO 的 25 項標準與通訊協定系列 IV

最新標準: http://ogp.me/

雖然說 Open Graph 已經是 2014 年的東西了, 且這部份說真的並沒有直接影響到 SEO, 但在 SEO 很重要的指標 "社群/Social", 臉書是絕對重要的事情.

Open Graph 在某方面說穿了就是為了 Facebook 分享時所須要的資訊, 而這概念早在 Twitter 之類的社群網站也都有自己定義, 只是在台灣無論是 Pinterest, Twitter 都是相較較少人使用的社群網站, 因為臉書的覆蓋率幾乎是占超過 95% 以上, 這就網站經營者是相當有感覺的.

而 Open Graph 事實上只有很簡單幾個必要的項目:

1. og:url
2. og:type
3. og:title
4. og:image

其他也有可以加上去的是:

1. og:locale
2. og:description
3. og:audio
4. og:video
5. og:site_name
6: og:determiner

而這些也都有子項目可以定義, 這邊就不多說了, 而就內容 (type) 的部份還提供更多項目, 這個在某方面似乎都跟 Schema.org 的 Microdata 是重疊的, 包含:

1. book
2. web_site
3. article
4. profile

但就 SEO 的角度而言, 並不是這邊所提供的資訊, 而是這些資訊在透過 Facebook 的處理之後, 讀者若是這樣的資訊提供, 提高分享的動機, 這就影響了 Social Signal (社群訊號), 這就是這標準最重要的事.

不否認的, 尤於更多網站越來越觀注 Open Graph, 因此 crawler 爬蟲也相對的開始依賴 Open Graph 的資訊, 雖然這也是當時 Facebook 拉其他公司一起定義的原因, 這對大家都是好事, 因此 Open Graph 已經變成比任何 Soical Meta-data 更重要的原因之一.

話說 Open Graph 也是一個相當簡單的 "Standard", 但因為在實務上很重要, 到沒有人可以乎視的地步, 我相信會無聊看我文章的人, 網站早就寫好了, 只是真的有沒有做得很正確, 這又是須要有足夠經驗了.

WAI-ARIA, 決定未來 SEO 的 25 項標準與通訊協定系列 III

最新版本: https://www.w3.org/TR/html-aria/

記得在 15 年前在做 SEO 時, 有一個超強的密技, 就是把網頁做成一份可列印的, 一份無障礙的, 只是當時最主要會這樣做的原因是有幾項:

1. 讓網頁設計者重新思考網頁結構, 不是只看外觀
2. 很多設計師太習慣用圖型做說明與連結, 這對 SEO 是相當不利的
3. 對於 Title, Description, Alt 也可以做一次檢核
4. 利用邏輯定義的 HTML Tag 來架構內容
5. 這樣又會多了兩頁不同的 View

但是否是 Web Accessibility Initiative (WAI), 倒是一點也不是那麼重要, 事實上大部份的網站, 除了國家政府網站, 真的很少人會去管 "網站無障礙規範", 即使現在已經到 2.0 的草案了 (2013 年 11 月), 不可否認的, WAI 雖然不是為了 SEO 所產生, 但對 SEO 有很大的影響與幫助是真的.

只是過了那麼多年, 不只 HTML 5 又重新定義了許多概念性的 Tag, 但這幾年最大的影響倒是另一個大問題, AJAX 的大量應用, 這種會因為時間或事件所產生或改變的內容, 這對無帳礙是最大的挑戰.

更重要的問題是在 FrontEnd 前端的多樣性越來越高的發展下, 不只是看的問題, 連輸入也是一個大問題, 所以 WAI-ARIA (Accessible Rich Internet Application) 就隨之應遇而生, 其中最重要的是 "Role" 這概念的普遍使用, 這個 Role 是甚麼呢? 下面是基本的解釋:

•  Roles to describe the type of widget presented, such as "menu", "treeitem", "slider", and "progressmeter"
• Roles to describe the structure of the Web page, such as headings, regions, and tables (grids)
• Properties to describe the state widgets are in, such as "checked" for a check box, or "haspopup" for a menu.
• Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page
• Properties for drag-and-drop that describe drag sources and drop targets
• A way to provide keyboard navigation for the Web objects and events, such as those mentioned above

從這邊看得出來這個 Role 的概念不只對內容輸出的概念有更多的定義, 對輸入的方式有更多的選擇, 甚至對選擇集合的概念也有更完整的定義.

最大的特色還是在輸入 (Input),  這邊從最原本常見的 button, checkbox, password到 color, date/datetime, url, search 超過 20 種以上不同的輸入格式做定義.

但就像是標準有用是在大家一起共同遵循, 這邊包括瀏灠器 (Browser), 搜尋引擎 (Search Engine), 網站製作者 (Author) 與讀者的相互關係, 要瀏灠器商有開發出相對應的功能讓使用者有所感覺, 或者是 Google 之類的搜尋引擎因為這資訊有所對應,  網站製作者才會積極的使用, 這才會有所改變.

ARIA 1.1 雖然是上個月 11 月定下來草案, 但事實上從 2013 年一直有人在推, 但說有 Best Practice 都還太早, 倒是已經慢慢的開始影響或成為搜尋引擎的 Ranking Factor (排名因子), 對於一些較為領先 (Advanced) 的 SEOer 早就在使用, 甚至變成檢核工具項目之一.

你的網站已經開始用 ARIA 了嗎? 即使不要管台灣那個意義不高的無障礙標章, 但為了 SEO 做總是沒錯的...

WAI: https://www.w3.org/WAI/

WAI-ARIA Overview: https://www.w3.org/WAI/intro/aria

無障礙網頁開發規範: http://www.handicap-free.nat.gov.tw/Accessible/Category/7/1

JSON-LD, 決定未來 SEO 的 25 項標準與通訊協定系列 II

最新版本: https://www.w3.org/TR/json-ld/

有人說, HTML (Hyper Text Markup Language) 不過是個 SGML (Standard Generalized Markup Language) 的子集合, 而 JSON-LD (Javascript Object Notation - Linked Data)  還不過是個 RDF (Resource Description Framework) 的一種實作, 但往往有時成功的不是最大的 Scope (範疇), 而是是否有實用的可能性, 這種實用代表有人會去用, 而標準若是沒人用, 那就跟許多的碩士論文一樣了.

若是要了解 JSON-LD, 並不是要大家了解甚麼是 Javascript 才行, 反倒是理論上要知道甚麼是 RDF, 甚麼是 Microdata, 甚麼是 Linked Data

1. RDF 是一種將網頁的資料交換格式將之標準化, 而其中是把是把語意 (Semantic) 的大綱 (Schema) 將概念連結起來, 透過一個有方向的標籤結構圖, 把資源給串起來而容易了解其意義.

2. Microdata 也是用來將語意與概念讓機器能夠輕易讀取, 透過將元素定義成辭彙與描術的名稱與性質, 來讓搜尋引擎,  爬蟲與瀏灠器知道如何再利用.

3. Linked Data, 將資訊結構化後, 讓資訊更好的被語意查詢, 且能夠透過 HTTP 等 URIs 將之串接, 然後轉譯成人類可讀取的呈現內容, 也包含能夠讓其他機器取自動化取用, 更新而將資訊串接.

而 JSON-LD 的 LD 就是 Lined Data, 在概念上就是利用 Microdata 已經定義好的語義, 而使用網頁前端最常使用的 Javascript 可以輕易使用的 JSON 來封裝, 而不是使用 HMTL 的 Tag 這格式, 而讓機器更容易使用.

會發現 JSON-LD 說穿了只是不同格式的 Microdata, 但這有甚麼不一樣呢? 當然就開發者而言, Microdata 用 Tag 的方式來表現, 要同時考慮到內容與使用者看到的格式是相當麻煩的, 而 JSON-LD 就直接包裝成一個資料包, 而把如何呈現切開, 不用再去跟 HTML 的 Tag 連在一起, 這在開發就較簡單.

但除了簡單外, 重點是呈現, 因為 JSON-LD 並沒有在 Tag 描述語言中, 基本上是不呈現的, 所以若是用者角度來看是沒意義的, 但的確搜尋引擎給了他意義, 因為以 Google 而言, 透過 JSON-LD 所提供得資訊, 就能夠更豐富 SERP (Search Engine Result Page/搜尋引擎結果頁), 這才是重點.

因為當優化了 SERP, 對搜尋者更容易的抓到所要的資訊與重點, 在 Google 的 Search Console 中, Google 稱之為 Rich Cards, 在某方面說穿跟之前推的 Structure Data 就是 Microdata, 只是常常有時會多加了一點 Google 自己的須求進去.

當然在 SEO 的角度最重要的是, 在台灣的 Google 已經有些 SERP 開始使用 Rich Cards 所提供的資訊, 雖然所謂的 Mircodata 的 structured data 也是可以, 但讓工程師來選, 當然是 JSON-LD (ld+json) 方便多了...

你的網站已經開始使用了嗎?

RDF: https://www.w3.org/TR/2014/REC-rdf-schema-20140225/
JSON (RFC-4627): http://www.ietf.org/rfc/rfc4627.txt
Linked Data: https://www.w3.org/TR/2015/REC-ldp-20150226/
Micro Data: https://www.w3.org/TR/microdata/

前言, 決定未來 SEO 的 25 項標準與通訊協定系列 I

若是說實作 SEO (Search Engine Optimization/搜尋引擎最佳化) 有標準可以依循就太好笑了, 因為網路一直在變, 人的行為一直在變, 搜尋引擎也一直跟著在變, 所以或許在實作上的變化很大, 但內容是人讀的, 人寫的, 機器 (Crawler/爬蟲) 也是照一定的格式 (標準化) 去抓取, 分析, 然後趨近人的行為, 這倒是不變得道理...

當然硬是要說, SEO 最重要的標準是甚麼, 大概就是 HTML (Hyper Text Markup Language) 與 HTTP (Hyper Text Transfer Protocol) 這兩個格式與標準, 當然現在的實用早就超過這兩項標準, 事實上 HTML 已經超過 5 版, HTTP 的版本與衍生協定更多, 現在的 SEO 要考慮的東西已經越來越多.

所以有些東西的改變是許多的典範累積與轉移, 但了解這些行為模式也代表了解 SEO 的實作可能性, 因為所有的內容能夠在很多地方運作, 呈現 (Render), 都是因為大家遵循著一個共用的方式來做, 這就是標準, 若沒有了標準, 資訊不只不能交換, 更沒辦法呈現, 也無法閱讀.

這次從標準做出發, 包含介紹各個不同訂定標準的組織, 以及像臉書與谷歌這種決定使用者行為的大公司,  他們正在推動或已經使用的格式標準大家也必須追隨, 因為有太多的內容與眼球被這些主要 Domain Player 所 "控制/決定" 著.

所以無論你是程式設計師, 包含前端後端, 系統分析師, 包含資訊架構師,  以及行銷, 更重要的是內容編輯, 商品操作員, 都要去了解這些 "標準" , 因為熟悉這些語言, 你更好跟讀者溝通, 更搜尋引擎溝通, 更容易的透過搜尋引擎與瀏灠器與使用者溝通, 就像是語言一樣, 若兩個人使用不同的語言, 這溝通就會有很大的困難, 而這標準, 就是這種溝通的語言.

但不要忘記, 無論這些標準是甚麼, 重點還是在於內容, 而這內容透過人的解讀, 吸收, 使用所產生的感情才是真確的, 而只是一時想要去騙取點擊, 或許可以得到短暫的收益, 但這對人類應該把時間浪費在美好的事情上面是背道而馳的, 我就不會鼓勵了, 好, 明天待續....

實況投票的真價值

很多人以為實況投票只是一個浪費頻寬的工具, 雖然這是真的, 畢竟若只是一張圖, 上面就是幾個數字跳來跳去, 我真的不知道這是為了做甚麼? 況且這些投票, 本來就存在粉絲團本來的結構性偏差, 動員力量的問題, 甚至還有人把 "讚" 的選項做進去, 這不是刻意誤導或搞笑不然是甚麼?

當然目前做得最好的大概是蘋果的一個實況投票, 而背景不只是些數字跳動, 還有兩個子畫面來看立院會議現場與外面抗議群眾, 我覺得這是個再合適不過的實用案例了, 因為扣掉投票, 這兩個畫面本來就是個實況 (Live), 投票讓群眾更增加參與感是讓實況更加分.

當我看到一眼實況投票, 雖然第一直覺在想這還真的是白癡加搞笑的事, 是很有創意, 但就是浪費頻寬, 但我再想一下, 若這資訊不只是這些 reaction/emotion 的統計, 而是更有資訊多元的 "Dashboard/儀表版", 這個影片不只能夠讓人更輕鬆的看到事件的進行狀態, 而把大家的互動好好的整理起來, 說是能促進真正的討論也不是不可能?

當時就規劃了一下, 至少可以把這投票的狀況, 例如變化量做進去, 接著再想說能夠把留言討論的內容也做個整理就更好了, 以及把大家的頭像與立場整合進去不是更好嗎? 但這個月也是忙到上星期才稍有空檔 (或是擺脫低潮)....

只是真的要做還不簡單, 最簡單的的確是數字, 但要將之記錄做歷史儲存才能做分析, 而留言也是另一隻 API, 使用者的投票 (reaction) 又是另一隻 API, 將之搞定還不算困難, 困難的是這要如何在有限的資源去做即時分析, 這個就是須要一堆中間表與流程了..

最後在上星期的確整理出個 API 了, 只是畫面的呈現又是一門專業, 這的確不是我的專業, 因此在最後的成品前, 我還是要做一些測試與原形 (Prototype) 來做示範, 這些也是在上星期完成, 而我利用別人的投票結果來做測試的確是沒問題, 但要真的自己跑一次流程, 還真的沒那麼輕鬆.

而在昨天, 利用自己的粉絲團, 想了個題目, 就開始為這個打造一個實驗的投票, 雖然這個題目本來是要用在 "未來國會", 但因為太粗糙, 不好意思用那個粉絲團, 因此為了這個投票, 在原本已經完成的前 5 項還打造出第 6 項, 留言提到的人, 因為有時人是最容易聚焦的重點.

1. 投票即時資訊
2. 投票歷史資訊
3. 最近留言
4. 最近留言的人
5. 留言的內容
6. 留言提到的人物

但有趣的事是, 雖然我這次還沒有用任何的 Hashtag 或是特別的字來做判斷, 但已經有很多人順著題意加入 "不良" 這個字, 所以原本以為要去改變大加留言行為的想法, 似乎變成可行了, 因為不是用這種 "跳脫字(Stop Words/Escape Words)" 來做區別, 要用語意真的太困難了.

所以下一次投票就會叫妳在妳的留言, 加入 "喜歡/討厭" 之類的字做為妳講的事情是甚麼樣的想法與立場了.

說了那麼多開發的事, 回頭來講一下這種實況投票的真價值在於:

1. 即使沒有了投票, 也是有實況的價值, 投票往往是附加價值
2. 這個實況是種儀表版的概念, 能夠讓人更容易抓到這資訊觀點
3. 透過這樣的即時互動, 能夠有更帶動討論與想法的集結

雖然不否認的, 臉書對 Live 是較有刻意去擴散, 因為閱讀聽眾比較喜歡影片多於文字, 對於即時的事情多於已經過去的事情, 或許這種實況投票一下子已經被做爛了, 但或許這也是種打造未來媒體的可能性...

而新文易數最近開發的幾項功能, 也是為了創造出 "儀表版" 的實況去做開發, 就待下次的實驗了....

從網路工具來看 10 大政治人物的變遷, 是工具的變遷...

接近 10 年前的時候, 當時用搜尋引擎的網頁變化來判斷當時的 10 大政治人物, 跑出了這樣的一個表:

10 年後的今天, 利用新文易數及對應的臉書資料, 也跑了一個 10 大政治人物排行榜:

從排行榜來看, 剛好都在兩個排行上面的有馬英九, 宋楚瑜與陳水扁, 其他七個人都換掉了, 但我們今天討論的不是這些人, 而是系統的變化.

這 10 年的變化相當的大, 10 年前最主要的資訊來源是下面這幾項:

1. 網站的網頁數量
2. 部落格文章
3. 新興的網路新聞媒體
4. 搜尋量
5. 社群書籤

而在 10 年後的現在的來看, 最主要的變化是:

1. 主流媒體都上網了, 變成網路新聞的最大宗
2. 部落格文章大量減少 (很多平台都倒了)
3. 社群網站的使用者互動變成社群訊號
4. 搜尋量變得更難拿了
5. 社群書籤都沒人用了, 倒是社群媒體的文章變多了

當然最大的問題是有人會問, 這資料到底有沒有意義?

網路有一個有趣的現像: "nothing comes from nothing, nothing ever could", 也就是事出有因, 而通常這個因是因為相當大, 相當複雜, 所以有時找原因是困難的, 因此驗證的方式也是相對的困難....

尤其若是政治人物的聲量, 最容易被提及的是選舉, 尤其是預測的部份, 更因為時代的變遷有所變化, 在 2010 年之前網路的預策通常大部份的是用搜尋量來預測, 事實上有很大的落差, 還不如用傳統民調較準確, 而在 4 年前的選舉, 透過社群網站的訊息傳播來預測, 此時準確度就有很明鮮的提升, 甚至到 2014 年用社群網路的人際關係來預測, 投票數的準確率已經接近 7 成了, 而在今年的立委選舉, 甚至接近到 8 成的準確率.

畢竟人的思考是相當難捉模的, 有時顯而易見, 有時是很難掌握, 有時資料很明鮮一看只是早就已經知道的事, 但有時跑出來的結果又是令人意外, 這次的美國總統選舉更是一個相當有趣的實驗場所, 甚至更有趣的是用的工具方法說不定算出來的不是大家預期的, 但出來的結果反倒是準確的, 因為在這種大量選民的情型下, "因果" 已經很難用傳統選戰解讀.

雖然用 Voting Group 的選民結構來看, 是可以去左右政治, 但真正的政治是隨時隨地在發生, 不能只是在投票時才會存在, 才去感知, 才去監督, 所以在投票後, 投票時所用的這些工具, 也應該透過這些機制讓我們對那些政策, 或政治人物有實值的影響力與話語權, 而不是全部都從無法驗證的民調來得知民眾的想法.

像這次新文易數用的方法雖然說是很簡單, 就是從每天超過一萬篇文章, 去知道全台灣使用臉書民眾, 透過讚享評去知道大家每一個動作背後意義的改變, 進一步的計算出來, 這解空間幾乎是每天 16 億的可能性去組合出來的結果, 所以就速度與精確度是很夠的, 只是最麻煩的是只能知道結果, 無法知道因子, 除非再去做一次因子檢定, 只是這又是另一種工了.

只是一定有人問這如何得知或檢定呢? 畢竟這數量級這麼大, 又很難計算, 即使是公開每一個人都是有辦法去算, 但相對的基礎建設及處理能力是一個很高的門檻, 事實上包含我自己, 我也只能用一個方法:

這種資料並不是用來找出本來就知道的事, 因為人是相當厲害的, 就像是你看這些資料, 應該會覺得八九不離十, 但真正的重點是在那一兩成你看不出來的.

若這資料算出來跟大家預期的差很多, 通常不是計算錯誤, 不然就是方法論錯誤, 就像是我之前用林克傳說來看 "風向球" 時得到一個有趣的結論:

雖然網路聲量與正負評因為事件的發生而發生改變, 而任何有敏感度的人都會知道上升或下降的方向, 而跑出來得資料也是一樣的上升與下降, 只是到底是些微上升, 或是極劇下降, 人的判斷與系統資料有時會有兩三成的不一樣, 這兩三成就是讓我們檢驗我們不夠或未知的地方.

工具是死的, 人是活的, 透過網路工具讓我們看到沒看到的地方, 而不是讓工具去限制我們的思考, 這才是最重要的, 但發生不一樣的時候, 不是單純的拒絕, 而是要更進一步的思考, 就像是這次美國選舉那樣, 那些工具即使算出來答案是對的, 但真正的智慧是在人的解讀, 以及做為自己行為下一步的參考, 這才是資料的價值.

網路社群後的團體迷思與同溫層, 是消失還是更嚴重?

很多人以為 "同溫層" 現像是有了社群網站後才有的事, 畢竟社群網站讓這類型的現像更容易被發現與檢視, 但事實上這問題並不是現在才開始的, 在 1952 年就有人 (William H. Whyte) 提出一個心理學現像叫 "團體迷思", 來看在 Wiki 的定義是:

團體迷思（英文：Groupthink，亦作團體盲思、集體錯覺）是一個心理學現象，指的是團體在決策過程中，由於成員傾向讓自己的觀點與團體一致，因而令整個團體缺乏不同的思考角度，不能進行客觀分析。一些值得爭議的觀點、有創意的想法或客觀的意見不會有人提出，或是在提出之後，遭到其他團體成員的忽視及隔離。團體迷思可能導致團體作出不合理、甚至是很壞的決定。部份成員即使並不贊同團體的最終決定，但在團體迷思的影響下，也會順從團體。 

這種狀況會不會覺得很耳熟能詳, 說穿了就是我們常見的 "同溫層" 現像, 這種事到處都有, 不只是存在在網路族群, 更常見的在一間公司很容易有這現像, 甚至是在能夠有傳播能力的媒體公司更為嚴重 (尤其像台灣某知名媒體公司落座在一個孤立的生活圈更明顯), 但更被容易看見的是在一個政黨, 甚至是掌有權力的次級團體會有很嚴重的團體迷思 (同溫層).

當一群人有類似的凝聚力, 階層式領導, 加上擁有相同的生活經驗, 價值觀, 這個團體迷思跟本是如影隨行的去定位這群人, 尤其是在於這組織夠大或足以產生足夠阻決外部資訊的資訊量, 這聽起來幾乎是可以跟 "官僚體制" 畫上等號, 畢竟官員所接受的資訊是經過過濾, 甚至是有權力關係與壓力所產生的決策過程或思維, 這就是我們常常看到在記者會上面發言的人, 那些人講得振振有詞, 但事實上很容易被其他價值觀矛盾與戳破的原因.

事實上這類型的事, 在學術圈, 或類學術圈, 甚至是學術圈的次級組織, 是更常發生, 尤其是最近某間學校的心理系是更為明鮮, 甚至我都覺得不須要寫文章, 直接拿這部份的定義與概括來看, 我們就可以知道這次的事件就是如此:

這次某學校心理系面臨到的狀況 (事實上是從維基抄的八項誘發團體迷思的前置因素)

1. 群體高度凝聚力
2. 群體隔絕外界資訊與分析
3. 命令式領導
4. 決策規範缺乏條理
5. 群體成員背景和價值觀的相似性
6. 來自外部威脅以及時間限制的壓力
7. 團體沒有信心尋求比領導所提出的更好的方案：可能因為領導具有強大影響力
8. 成員自尊心低落：可能由於剛經歷失敗

這次某學校心理系所發生的問題 (事實上是從維基抄的八項團體迷思的表現形式)

1. 無懈可擊之錯覺：群體過份的自信和盲目的樂觀，忽視潛在的危險及警告，意識不到一種決策的危險性。
2. 集體合理化：群體通過集體將已經作出的決策合理化，忽視外來的挑戰。一旦群體作出了某個決策後，更多的是將時間花在如何將決策合理化，而不是對它們重新審視和評價。
3. 對群體道德深信不疑：成員相信群體所做出的決策是正義的，不存在倫理道德問題。因此忽視道德上的挑戰。
4. 對外偏見：傾向地認為任何反對他們的人或者群體都是邪惡和難以溝通協調，故此不屑與之爭論；或者認爲這些人或者群體過於軟弱、愚蠢、不能夠保護自己，認為自己群體既定的方案則會獲勝。
5. 對異議者施加壓力：群體不欣賞不同的意見和看法，對於懷疑群體立場和計劃的人，群體總是立即給予反擊，但常常不是以證據來反駁，取而代之的是冷嘲熱諷。爲了獲得群體的認可，多數人在面對這種嘲弄時會變得沒有了主見而與群體保持一致。
6. 自我審查：成員對於議題有疑慮時總是保持沈默，忽視自己心中所產生的疑慮，認為自己沒有權力可以去質疑多數人的決定或智慧。
7. 全體一致的錯覺：這是群衆壓力和自我壓抑的結果，是使群體的意見看起來是一致的，並由此造成群體統一的錯覺。表面的一致性又會使群體決策合理化，這種由於缺乏不同的意見而造成的統一的錯覺，甚至可以使很多荒謬、罪惡的行動合理化。
8. 心靈守衛（"mindguards"）：某些成員會有意地扣留或者隱藏那些不利於群體決策的資訊和資料，或者是限制成員提出不同的意見，以此來保護決策的合法性和影響力。

所以從這次某間學校的心理系所發生的事情, 就外在的角度看起來, 即使沒有 100% 的吻合, 已經是八九不離十了, 即使他們是心理系, 也很難擺脫所有人只要是人, 在面對這問題所表現出一樣的現像.

有時我們不能怪 "某間學校心理系" 所發生的問題, 因為這種事我們只要是人, 都很難避免, 回頭想想我們的公司, 我們的單位與學校, 我們的朋友圈與交際區, 甚至是我們的臉書也常常發生這現像.

只是這問題如何解決呢? 此時 Wiki 的資料就沒有用了, 因為現在網路社群後, 這現像更為複雜:

1. 透過網路的資訊量, 已經超過一個人可以接收與吸收的範圍

2. 透過臉書的演算法, 更加深同溫層的效應.

3. 透過網路, 我們比原本的小團體, 更容易篩選到贊同自己聲音, 略過反對自己的話語.

4. 人的偏見會造成高道德的話語被傳播, 或是相反的更批判的聲音被放大.

5. 人的偏見也會造成團體的壓力, 且這壓力會透過手機的 Line 的群組有更大的強制性.
6. 整體的網路雖然不至於有很強力的 "沉默螺旋", 但小團體的網路會很糟糕.
7. 社群網路的機制, 讓人更容易加入與屏壁這些事, 甚至有人是有意識的在做這樣的事.
8. 當人已經習慣用社群的時間軸看事情, 就難以用較全面的看不同面相的事.

這次某間學校心理系的事情, 在某方面更應該讓我們自省很多事情的適用性, 即使不須要脈絡, 我們也可以看出讓我們擔心的事持續發生, 而事實上真的要怎解決, 請待下回分解.

給政府單位資訊局處想做 UX 調整的技術基本 GA 建議

(這篇文章說是寫給政府單位的資訊局處做參考, 但主要是考量到政府單位較難像一般民間機構有很快的轉變, 或有足夠的資源去改變, 但相對若對於一些資訊化還不夠, 或資訊單位較難被重視的大型企業或研究單位也適用)

0. 不能有共用帳號:

網路最重要的是 Trust but (can) Verified, 也就是說可以盡量授權讓人能夠更方便做事, 但前題是也要知道他做了那些事, 不須要刻意去建立一個假帳號, 而是每一個人可以用習慣的個人帳號來處理事情.

但我們可以記錄與追查所有事, 看是誰做的, 通常這事很少不是居於不相信, 而是基於相信, 但尤於常常因為了解不夠, 學習不夠, 或警覺不夠會發生錯誤, 而此時若知道他做過甚麼事的話就可以回溯 (Roll Back), 但若一組帳號登入的密碼被一個人以上知道, 我們就不知道誰做的, 或是有甚麼可以協助與防範的.

1. 讓所有單位的 Google Analytics 帳號可以有資訊單位一個以上的人來協助管理:

在還沒有能夠裝設同一個 GA Property 或透過 API 來整合所有的 GA 之前, 最簡單的就是有人可以看到所有的 GA, 事實上大部份的單位不只不是沒裝 GA, 不然就是仰賴場商協助分析 GA, 但事實上 SI 場商對於經營並不專長, 更不要說這個經營也是須要 Domain Know-How.

嘗試著有兩三位個可以協助各單位分析網站經營的狀況, 進一步提供意見的 Task Force (工作小組), 至少不要讓這種基本工都沒做好, 這就很糟糕了.

2. 所有單位網站至少要裝有一個共同的 GA Property

雖然 GA 從來不建議一個網站裝很多個 GA, 因為這不會讓管理更單純, 有時會讓 GA 的 Javascript 更容易有衝突, 但至少為了讓資訊部能夠好管理, 說要真的之後透過 API 來做整合之間, 共用一個 GA Property 是最簡單的方法, 雖然這對外包也是有點困難, 但透過上面第一點的方式還是可以彌補一些.

但記得 GA 很多項目都是不會看網域名或主機名, 因此不同的網域 (Hostname) 若是在同一個 GA Property 下要設 Filter (篩選器) 的 Rewrite, 把 Hostname 併入 URI (URL) 中, 不然會跑出所有網站的首頁是同一頁的現像.

3. 使用一個 Service Account 來做管理與透通

透過一個後台機制以及這個 Service Account 來授權, 可以更輕易的管理或檢視各個單位的 Google Analytics, 進一步的做分析與儀表版, 這樣才能真正發揮出網站分析工作小組的效用, 而這些都是須要資訊才能做判斷的.

這可以透過一個管理帳號來操作, 相對的也可以之後用這個方式去管帳號, 隨之的反倒是可以廢掉前面兩件事情的必要, 只是這部份須要較長時程的專案才能夠完成.

4. 建立事件 (Events)

做分析最重要的是聚合, 透過聚合後的使用者行為是最基礎的基本建設, 使用者的點擊都是有意義的, 但若這使用者訊號都是獨立事件是很難分析的, 所以我們要將之聚合, GA 的事件是最簡單的方式, 透過事件可以整合相同概念的行為, 將之分化與分類, 這是最必要的事.

依照版型去區分基本的 Head, Navigation, Breadcrumb Trail, Sidebar, Footer, Search, Tag, Extension, Basic Info 等等共用的事件, 更要以基本區塊做為 UI/UX 分析的下一環, 其中包含能夠去聚合相同的觀點, 例如 "使用者族群", "須求類型" 等等.

5. 標題, 描述, 與 Meta Data 都能夠提供有用的資訊

理論上有了事件就能夠解決大部份的使用者行為分析, 但真正要去了解使用者的須求之前更要知道這資訊的內容, 透過語意分析或事先下標籤 (Tag) 都可以知道這個資訊或這行為在做甚麼事, 只是這部份可能成本很高, 更須要有基本工, 就是建置對的標題或描述等 Meta Data 才行.

不只標題要符合現代的下標方式, Description (描述) 更是重要的是 "關鍵字" 的建立, 或是標籤的建立, 讓使用者行為與內容做結合, 前題也是這資訊內如本質已經聚焦才行, 要去用語意網路去判斷不是不行, 但不會像人一樣精確.

6. 每個網頁都要對內容, 情境, 使用者, 提供者等提供正確的標籤資訊

事件的聚合是 GA 的基本, 但只透過 GA 有時是不夠的, 夠過更多的資訊, 才能做到 "Data-Driven UX Redesign", 沒有 Data 就不叫 Data-Driven (資料驅動) 了, 要有對的資料才能做出正確的資訊.

有了這樣的配對資料, 相信不只能夠更了解人民或使用者的須求, 透過更即時的儀表版可以知道民意的趨向, 說不定從這角度才是真正的以使用者為本的分析, 相對的若是能夠把這資訊更公開, 就更可以寫出 "使用者建議" 的個人化須求分析, 讓使用者去自我調整, 自我建議, 畢竟有時使用者才更了解使用須求不是嗎?

--------------------

後記:

忘了說, 做 1 與 2 是為了因為 3 比較難完成的過渡性運作, 若有能力的資訊單位可以直接跳到 3 來直接做一個更好整合控管的系統.

而目的都是為了 4 (事件), 這對大部份的公司都是可以跳過前三項直接做的, 且大部份的公司 5, 6 都已經做得不錯, 所以當做好 4 就可以直接跳到下一階段真的去做 Data-Driven UX Redesign 了...

大數據有時只要轉個彎就能夠很實用了

有人知道我一直在思考與發展 "新媒體" 的可能性, 雖然大家都已經知道不能用 "網路" 來去劃分甚麼是傳統媒體與新媒體, 而是要以 "是否應用網路多對多的技術實現社群互動來產生價值" 來做區分, 所以也提出了個計劃:

當然這計劃不會停下來也會持續進行, 雖然這會那時實現也不確定, 或許不見得是用甚麼形式實現, 更有可能也不須要我來實現是最好啦, 但記得在 4 個月前, 寫下一個豪語:

而做到現在, 的確已經有很多 "成果" 了, 但離真的具有 "效果" 卻又還很遠, 但其中有一點最有趣的就是 "個人化".

在做個人化大家都知道是很簡單的概念, 就是若是系統能夠從一個人的閱讀記錄, 一篇篇了解這篇文章的獨特屬性, 而不是單純的從個人檔案 (profile), 或是文章分類決定一個人偏好, 尤其是透過最近的閱讀, 最新的閱讀能夠更精確的推薦給那個使用者.

這以現在的技術角度通常不是問題了, 尤其是現在與時俱進的電腦計算能力與機器學習, 以前做不到的現在都越來越簡單, 只是接下來的問題是如何拿到使用者的閱讀記錄或是如何推薦給他？

當然閱讀記錄有時可以透過臉書的動態牆分享, 對於須要大量閱讀的 "傳教士" 而言, 其平常分享的內容就足夠聚焦到他的偏好, 但其他人真的不是靠有人寫出閱讀器, 不然就是要靠 Plug-In 來追蹤了.

前一陣子有人問我是否可以做文章分類, 而新文易數當時抓資料時是以標籤 (Tag) 為目標, 並不是以分類 (Catalogue) 為目標時, 在想說要重新抓這些媒體是相當困難的, 此時就想到一個很有趣的想法:

若是虛擬一個人格 (Agent), 若是只餵食(閱讀)體育新聞時, 此時推薦出來的清單都應該是以體育新聞或其相關為主.

當時就用這概念就做了幾個機器人 (Software Agent), 就可以很輕易的把文章做分類, 只要有針對這分類的 "種子", 即使這個分類只是次分類, 如棒球, 汽車, 教育, 長照, .... 因為不是針對這些類別去做定義, 而是持續的把這相關的文章丟進去這系統, 即使若是有算不到的情形, 再經過 "工人" 的再 "餵食 (輸入)", 此時配對出來的訊號 (Signal) 會越來越高, 也越來越準.

上面就是在新文易數尚未開放的新功能 (應該也不會開放, 因為會直接寫成 API), 這篇文章雖然是屬於社會類, 但因為是國際的社會類, 又跟產業金融相關, 所以這三個數字都偏高, 若是以演算法的角度, 應該是屬於社會類與國際類, 事實上很多文章的分類本來就是很模糊, 甚至應該是網狀 (Network) 的多屬性關係 (Relation), 而不是單一的階層關係, 在這種系統就更可以表現出其 "優秀" 的地方.

此時就想到幾個有趣的地方, 若不是持續輸入一種分類的文章, 而是持續輸入一個媒體的文章, 即使這個媒體是多種分類屬性, 所以理論上最後推薦出來的應該是:

1. 可以建議這個媒體的記者該追蹤的新聞或文章

2. 可以建議這個媒體的讀者, 他會有興趣閱讀的跨媒體內容

由於這種方法可以有足夠量的樣本來輸入偏好, 所以通常會有很好的效果, 此時也利用癮科技來做實驗, 大家可以去看看效果如何, 但此時並沒有去過濾排除這個媒體, 所以出現這癮科技的文章也沒甚麼意外.

但很多網站沒有文章怎麼辦呢? 大家可以參考 "透過 Search Console API 來做關鍵字建議工具的改良" 這篇文章, 或許就直接匯入這些關鍵字, 把關鍵字當成文章, 此時就可以持續與大量的輸入, 且可以跟上時事, 準確度就很高, 這系統就變成可以推薦這網站值得發展的方向.

除了個人化, 分類, 媒體編輯, 網站經營外, 甚至可以輸入某立委 (政治人物) 的相關新聞, 以及這政治人物在粉絲團發表的文章, 就會跑出 "那些新聞值得這立法委員值得深入追蹤的建議清單", 畢竟身為立委助理 (或政治人物) 每天要去看新聞來培養自己風向球的敏感度是很辛苦的, 若能夠把較具影響力或社群有較多回應的去做篩選, 再找到是這個政治人物的守備範圍或有關系的訊息, 這樣是很有幫助的.

以現在大數據的分析中, 大部份的困難不是沒有資料, 而是有龐大的次級資料 (不是直接對應問題答案的資料), 若是大家已經有做出個人化的推薦, 可以嘗試看看轉個彎, 透過資料的整合就可以產出很有趣的應用.

而很多有關媒體, 立委之類的資訊, 這邊已經整理出不錯的資訊, 可以直接透過 API 匯入大家的編輯後台或 Dashboard (儀表版), 有興趣的可以找我介接, 希望對大家的工作有幫助.

很少人注意到的十件最重要標題製作要點 (不是殺人那種, 但不知道可是會死人？)

以 SEO 的角度, 若是以網站內容與結構的角度來看, 第一重要的網域, 其次是接下來的網址, 而排第三的就是標題了.

但標題這東西大家都只聚焦到如何寫出一個標題殺人法吸引讀者的騙術(?), 事實上除了那些騙點擊的招式之外, 還有更多基本功要做的, 尤其是技術部份, 或者是 SEO 部份, 甚至是網站經營部份都須要知道的 Know-How, 畢竟這才是讓網站可長可久的事情.

就我的經驗來看, 打開 Search Console (以前叫 Webmaster Tools) 能夠沒有 "錯誤" 的是少之又少, 大部份的人看到才發現該做的事情有那麼多, 但實際上因為太多事情沒做, 到最後只能掌握 "未來避免錯誤", 把錯誤數控制在一定的數字範圍, 過去的就讓他過去, 畢竟有太多事情處理不完.

其中最常犯的錯誤就是標題, 尤其是不同的網頁 (網址) 擁有相同的標題, 畢竟在 "制式" (Canonical) 網址在被廣為所知之前, 一個網頁因為不會改變內容的參數太多, 不太可能用網址來決定網頁的 Uniq (獨特性), 用標題的不同反倒是對於有認真經營的人是較好的線索, 但實際面有太多只是做表面功夫的系統整合商不會去管這種事, 而業主更沒有這種知識, 所以到最後網站經營變得相當困難.

既然標題是如此的重要, 所以我們在 "製作標題" 時, 須要注意到甚麼事情呢?

1. 次序 (階層):

標題有時比較像是英文地址, 從小到大, 不像中文地址是從大行政區寫到小巷弄, 而是從細節開始寫起, 但實際上也不完全如此解適, 應該是以越接近這網頁 (HTML) 完整語意的標題要放越前面, 越後面放的可較廣的層面, 例如分類等等, 最後才是網站名稱.

2. 序號 (索引鍵): 

在 HTML 改善中有一個很重要的項目要重複的標題, 這以 SEO 來說可以是致命性的錯誤, 但在於有時候網站內容不完全是由編輯所撰寫時, 遇到相同的命名是很常見的事, 為了避免這事情發生, 通常會在標題加入序號, 也就是在資料庫使用的索引鍵, 因為這是唯一 (Uniq) 的, 所以重覆的機會就不太會發生了.

3. 分隔與符號:

標題是如此重要所以也要盡量避免讓搜尋引擎判斷錯誤, 所以有時須要做一些處理讓搜尋引擎更好去辨識, 畢竟中文的斷字沒有那麼簡單, 因此利用一些標點符號, 或是空白等分隔, 不只讓使用者更好去閱讀區別, 更重要的是能夠精確的定位關鍵字.

4. 輔助關鍵字與分類:

說到關鍵字的確是 SEO 的重點, 因此通常除了給人看的 H1, H2 的標題外, 給機器看 head 的 title, 有時可以加入一些原本不存在真正標題的關鍵字, 或者是加入情境的分類, 這樣可以更延伸語意, 畢竟下標不是那麼簡單, 尤其是現在越來越多人習慣用問句做標題 (?), 或者是用匿稱去稱乎別人, 此時真正的關鍵字就不見了? 不放在 H1 或 og:title, 放在 head 的 title 倒也是另一種方式.

5. 字數長度:

標題的字數雖然有限制, 但從精確的語意標題開始擴大成大綱或情境, 最後用相同的站名或用來區分的序號, 雖然可能或超過 20 字, 但問題並不大, 因為最前幾個字足以讓人與機器辨視就可以了, 但還是要控制在一定數字之內, 以中文字的角度最好是低於 40~50 字, 甚至應該說屬於這單頁的語意的確還是要在 20 字內.

6. Sitemap 的一致性:

會出現標題的地方很多, 除了剛說的 H1, og:title 或 head.title, 在 sitemap (機器讀取用的) 或 RSS 也會有出現標題的地方, 有時搜尋引擎會抓 head.title 做為標題, 有時也會跑去抓 sitemap 的 title, 若不想要出錯, 就要保持一致性, 雖然有時刻意不一致也是有其運用的情境.

7. 變動性 (訊息, Javascript):

在有了瀑布流或訊息的機制, 利用 Javascript 去修改標題的場合越來越多了,  雖然這個對搜尋引擎不會有作用, 但對於臉書在分享時是可以指到對的網址是有幫助的, 也包含能夠提示使用者有沒有新的訊息進來, 也在於利用 Javascript 在做導引時有效, 是很好利用的方式.

8. Schema:

除了上面說的四種 Title 外, 還有第五種, 就是在 Schema.org 定義下的 Title, 尤其是現在由於利用 JSON-LD 的實作也越來越多, 以及 Google 的使用廣泛, 這部份也相對重要, 當然這也是跟內容屬性的相關性很強, 不同的內容有不同的使用情境與設計, 無論是保持一致性或是針對不同情境下標, 都是可以的.

9. 其他 Meta-Data:

當然除了前面幾種 Title 外, 一個好的網站還是要完整的滿足較多的社群有較多的 Title, 甚至若是被收錄成新聞網站後, 新聞網站更有其 sitemap 與 meta data 來去協助不同的使用情境有不同的用處, 此時考慮的地方要更多了.

10. 連結網址的標題:

除了網頁自身的標題, 出現標題更多的場合是在連結的時候, 雖然透過 Open Graph 等 meta data 可以定義社群使用狀況或是搜尋引擎使用, 但更多無法操控的是外部連結的標題, 尤其這在很多情型是 Anchor Text (錨點文字), 在意義上是更高的, 而至少網站可以利用內部連結及其相關的錨點文字定義標題, 讓使用者更願意去點擊, 這在使用者情境是相當重要的.

11. 目標對像的語氣與情境:

前面說了那麼多種類的標題 (Title), 應該就會知道不同的標題有不同的使用範籌, 而下標題不只是那種騙點擊的那種標題殺人法的一種, 而應該是一種連續性的情境, 讓讀者能夠深入內容, 深入答案, 從而能夠更進一步的深層閱讀, 透過這種資訊的串連能夠讓讀者獲得要的資訊, 這才是一個好的資訊的價值所在.

當然上面的 10 點 (及多塞的一點結論) 標題製作要點, 要讓大家知道的只是大綱, 事實上裏面有太多的細節, 這個就要透過長期的內容寫作, 社群經營, 技術實作一點點的補足, 雖然那種標題殺人法的確是短時間內有效, 但最後還是很可能是效用越來越低, 較為實際的是與時俱進的基本功, 這才是網站製作經營的本質.

透過 Search Console API 來做關鍵字建議工具的改良

在三四年前 (2012 年底) 時, 總覺得 Google Analytics 不是那麼好用, 畢竟有很多東西不是靠設區間, 設目標, 設事件, 設轉換就可以做到, 事實上那時這些功能不是沒有或者沒那麼完善, 但那時至少就 SEO 的角度來看有個很大的功能: 知道使用者是用那個關鍵字進來....

到 2016 的現在, 這個功能已經像廢物一樣, 因為 Google "基於隱私" 的關係, 不讓經營者看到搜尋關鍵字, 也就是在登入狀態, 雖來 Log 可以知道使用者的來源是 Google, 但是用那個關鍵字是無法得知的, 在 2013 年之前, 還是有六七成的關鍵字是可以看得到, 但到現在, 連 6~7% 都沒有了, 我曾做過一張表, 就是算這幾年無關鍵字 (No Provided) 的變化, 從下面就看得出來, 在 2011 年 10 月開始執行這政策, 現在可能只剩 2.5% 可以看得到了.

因此在當時做的網事 ( http://web.mas.ter.tw/ ), 透過關鍵字的變化來做到 "關鍵字建議工具" 是非常好用的, 但隨著 No Provided 的增加, 曾改成為透過落點頁 (Landing Page) 來去推測, 雖然沒有那麼直接, 還是有相當的實用價值, 只是在某方面感覺無論就準確度或者是直覺度還是差了一點.

雖然說很早 Google Analytics 就把 Search Engine Optimization (SEO, Webmaster Tools) 的報表整進去, 所以這幾年我隔一段時間都會去看看 GA 有沒有把 SEO 這部份開放 API, 若是有的話就太好了....

而等了很久還是等不到, 反倒是 Google 這段時間突然重視起這個 Webmaster Tools, 不只改名成 Search Console, 且原本很少更新功能變成幾乎一段時間就有新東西, 就像這個月就加了 json-ld (ld+json) 的工具 (Structured Data Testing Tool), 也定名為 Rich Card, 但除外, 在年初就有聽過 API 也隨之改善, 不只是只有做些 "管理" 的新增刪除, 重點是能夠把最重要的搜尋結果透過 API 可以取得.

雖然有在用 Search Console 的人都知道, 他們的資料都會晚個三四天, 但某方面已經是夠用了, 所以把當時網事寫出來的 "關鍵字建議工具" 做個改版, 但與其說是改版還不如說是完全不一樣, 因為 GA 是以埋的碼 (javascript GA code) 為單位, 但 Search Console 是以網站為單位, 甚至 http 與 https 就是不一樣, 且更重要的是, 在 Search Analytics 中有 GA 沒有的曝光量 (Impressions) 與排名, 及就可以算出 Click Through Rate (CTR) 了.

但先不管排名與 Impression, CTR, 單單就點擊這點就很夠了, 雖然這個數量只有 Google, 不包含 Yahoo/Bing, 只是基本上我們的確可以慢慢忽略 Yahoo 了.

下面兩張表上面是原本透過 GA 抓到, 下面是透過 SC (Search Console) 的 API 抓的, 從這邊就可以看到其變化, 這資料是用 "新文易數" 來做舉例:

從這邊就可以看出來在不到 10% 的資料, 要算出個有意義的資料真的太困難了, 除非偶而會有爆量的關鍵字, 在被稀釋之後的資料跑出來, 不然就是沉在看不到的地方, 相對透過 SC 的資料, 唯一的問題是只能抓到三天前的資料外, 完整度都相當足夠, 原本看不到的都看到了.

當然除了可以從 Clicks 來看, 還可以從 Impressions 的角度來看, 且在這邊應該要分開兩種 Impressions, 一種是使用者會點擊而爭取到流量的關鍵字, 另一種是跟網站屬性差很多的關鍵字, 即使曝光再高, 但點擊通常是 0 這種關鍵字是沒有意義的, 所以本來就應該從這三種角度來看, 自然我也寫出了三種不同的報表來實驗.

基本上在 SC 的觀點, 這些查詢都是總量, 的確是不會影響到 "隱私權" 的問題, 這時候至少 Google 已經不會被罵說想把這種資料拿來自己賺錢用了, 對網站經營者倒是個很大的福音, 有興趣嗎? 就招喚你們的工程師吧 (別忘了幫他們加薪) ....

從社群的各個角度來看媒體

最近很喜歡在相關的課程說一個很重要的觀點:

"大數據是一種最準確但也是偏差最大的一種觀察研究方法, 準確是因為資料的取得可以很客觀且巨量, 這樣的資料才能做到誤差最小, 但若是只用一種角度去看或是一種方法去搜集, 這種巨量的資料反倒是造成巨量的偏見"

不要說是社群只是眾多經營媒體的觀點與數字的一種, 單單從臉書社群來看媒體, 也是有各式各樣的觀點與數字, 更不要說我們只用粉絲團來看媒體的經營, 即使是臉書使用者的資料都能搜集到, 若沒有去了解各個面向, 誤會說不定會比正確理解來得機會高, 但若不用這些資料來去觀察, 那又可能是種刻版印像的放大, 只會讓你又犯了一次次的決策錯誤.

在兩年前嘗試著用林克傳說做了一個社群排行榜, 那個系統跟這次用新文易數做基礎的社群排行榜最大的差別是:

林克傳說能夠取樣各種媒體, 但就單一媒體的資料不夠完整, 而新文易數是能夠算到單一媒體的所有資訊, 但不在列表的就無法反應出來.

現在新文易數的確已經收錄超過 70 個媒體的資料, 尤其是前 30 大原創性高的新聞網站都收錄其中, 雖然說 30 名以後的媒體一定有問題, 但相對的前 10 名應該不會在名單之外, 我們來看這樣的社群排行榜會是怎樣的結果:

若是以總數來看, 第一名是東森新聞雲, 幾乎第二名蘋果的兩倍, 而第三名到第五名是自由時報, 壹週刊與雅虎不相上下, 但跟第二名也是差兩倍, 第六七名則是三立新聞網與中時電子報, 而除外在前十名的是東森新聞, 動網與聯合新聞網.

這是以總數來看, 這個總數是這媒體在七天內刊出的新聞, 每則新聞有其按讚, 分享與評論, 將之加總起來, 雖然在取樣與區間或多或少有時間差, 但理論上大家的條件與範圍都是一致不會差太多.

而從讚享評總數來看會讓一些新聞數沒有那麼多的小媒體吃虧, 若是用單一則最高的觀點來看, 擠進前 10 名的媒體是風傳媒 (事實上總量原本是第 11 名), 被擠下去的是動網, 且是跌到第 24 名, 如此可知道動網的社群很強, 但因為是專業媒體, 族群被限制住, 所以最大的數量就沒辦法很高.

雖然綜合新聞媒體總量與最高值是占便宜的, 但在平均就很吃虧, 所以若是以前 10 名的角度, 前面 11 個媒體還能擠進去的只剩東森新聞雲, 壹週刊跟東森新聞, 這三個媒體有甚麼共同點呢? 等一下再說...

中位數指的是所有新聞排序後, 讚享評排中間的那則新聞數字, 此時不只只剩動網與東森新聞雲在前 10 名, 甚至前 30 名也只有這兩個媒體加上風傳媒與三立新聞網, 畢竟要能夠讓有一半的新聞都能動, 不只是靠內容, 記者與編輯自己也要能夠參與社群才能做得到.

眼尖的讀者有看到系統有一個 "嗨文率", 這數字是相當有趣, 計算方式很簡單, 就是 "按讚/(分享+評論)", 這個數字越高代表的是讀者看完之後很喜歡按讚, 但不會想要分享與評論, 這代表的是甚麼呢? 通常代表的是這些文章即使是有趣, 好玩, 新鮮, 但很難對社會, 對生活有所影響, 甚至不會去討論與推薦, 會造成嗨文率高有兩種可能性:

1. 農場文太多
2. 社群帶動強

而剛剛說到同時總數高, 且平均值也高的三個媒體就是東森新聞雲, 壹週刊跟東森新聞, 這三個媒體正巧是總數高且嗨文率也高的三個媒體, 雖然在嗨文率上, 動網是比這三個媒體足足多出一倍, 我們知道動網是個內部社群凝聚力相當夠的專業媒體, 而這三個媒體不完全是這因素, 代表的是另一個因素機會較高了.

若是這嗨文率高是這因素, 那若嗨文率很低的原因又是甚麼, 同時也是有兩種很大的因素:

1. 文章多是乾貨, 很硬
2. 此媒體完全無法帶動社群

所以若是把嗨文率從小排到大的話, 我們很清楚的是立報, 端新聞, 風傳媒等媒體不是很專業, 就是新聞多有份量, 造成大家的分享與討論機會很高, 不然就是像台視或中央社那樣, 社群跟本嗨不起來, 就不用想會有人按讚了.

應該有人有看到表格中有個 "長尾指數", 這代表著這媒體是否有網路媒體可帶動的長尾效應, 還是極度利用炒作議題所造成的結果, 數字越高代表越長尾, 而這部份的計算與意義, 倒是等到畫出一張圖後再來解釋比較方變, 敬待下回分解.......

最後, 媒體的社群表現, 尤其是只看讚享評的數字, 說穿了用再多種的數字來看也只是眾多面相的一種, 跟真正的導流, 或者是所有流量, 甚至是媒體的收益, 往往每一個環結每一個媒體都是u有不一樣的轉換率, 雖然這資料的準確度再高, 也是種有偏差的觀察, 只是對於要去參與社群經營的媒體工作人員, 卻是相當有用的, Have Fun~~~~

連結: http://tag.analysis.tw/media_social.php

New SEO KPI 的規劃

很多人一直問我, SEO 這工作最主要的 KPI 是甚麼? 我通常會說有兩大表相:

1. 搜尋引擎帶進來的流量數
2. 搜尋引擎帶進來的流量占比

這兩個主要 KPI 的成長量 (月成長與年成長) 就可以決定 SEO 的效果, 但這個做為檢核的機制是不錯, 但要做為做事的導引卻是相當困難, 所以我再補充了幾個可以量化的點:

1. 搜尋引擎的索引總數
2. 外部連結的數量與連結頁數
3. 內部連結的數量與分布
(4). HTML 的錯誤數
(5). 搜尋引擎的錯誤數

只是無奈這部份 Google 都沒提供較好的 API, 某方面只能用 csv 匯入資料來作業...

在一年半前 (2014 年 1 月), 想出了一個有趣的方法來檢核 SEO KPI, 也就是:

"搜尋引擎進來的關鍵字與落點頁, 是否具有長尾效應?"

雖然這個用人工去算是相當困難的, 但相對的若是用 Google Analytics API 來做並不困難, 因此後來做了 seokpi.analysis.tw 這系統, 就可以從分布圖定義出簡單的 "Index (指數)" 來去比較這個網站是否從一般行銷方式的 80/20 慢慢的進步到長尾, 然後配合最前面的兩個搜尋流量與占比, 這四個數字定義出一個最終 KPI.

但一年半過了, SEO 的改變也相當多, 面向與思維也越來越廣泛與複雜, 用這四個數字來做最終 KPI 的基礎已經不夠了, 因此也在想說如何進一步的改良這個 SEO KPI, 來去協助大家的進步.

而一年多來最大的概念改變在於:

1. 使用者在網站的訊號變得是一個重要的因子
2. 網站內容會依網站結構有不同的使用者訊號比較
3. 搜尋引擎帶進來流量是否有真正的價值
4. 搜尋引擎行為對網站的影響 

要去計算到上面幾件新思維改變, 就代表網站分析前題是要做到下面三件事:

1. 要去區分內容頁與中介頁, 與內部搜尋結果頁對搜尋引擎的差異
2. 不同來源與搜尋引擎來源對使用者行為的差異來證明
3. 如何區分 Short Click, Long Click, Pogosticking, Next Click 與 Next Search 的來源

雖然最後的指標, 也終也是使用 Click Through Rate, Time On Site/Page per Session, Bounce Rate/Exit Rate 這三種類型的指標來去計算其效益, 只是對於 SEO 操作的人, 真的要去區分上面與計算出這幾種來源與類型, 來去比較這之間的差異, 有些不是可以靠苦工做得到的, 甚至有時不是靠單純的 GA 操作就可以得到的.

當然在某方面甚至不是只靠 Google Analytics, 或是只是用檢視的區分與比較, 說不定是只靠 GA 是做不到的, 但相對的, 但畢竟是否能夠用幾個基本的 Customized 的方式就可以做到基本的計算, 畢竟真的要不只用 GA 的普遍性是更困難的.

但話說, GA 雖然是一個很重要的角度, 但除此之外還有一個更重要的是 On-Page Analysis, 而這部份大家真的可以去使用 Awoo 的 SEO Tools, 如 天下無狗 與 球來就打, 這也是一個很基礎的項目, 也不要忘記了...

而這次的 New SEO KPI, 整體的演算法雖然都已經想好 (聽說是在去年就想好了), 但那時會實作出來大家可以給個建議, 畢竟這次的複雜度不輸給一年半前的挑戰阿...

未來電視

電視, 或者說是螢幕, 甚至是網頁 (Web), 是一種讓人看到資訊的介面, 但與其說是傳遞影音的內容, 更具概念性的意涵是: 人的眼界可以透過這個 "Windows/視窗" 來去穿越, 穿越時間, 穿越空間, 穿越思考, 甚至可以穿越人性的一個 "設備".

這樣說也有點太過於抽象或流於概念化, 但事實上從電視的發展到現在, 也沒多久, 只是未來的可能性越來越高, 只是這個絕對不是把定義放在 "影音", 甚至是靠 "規格" 來去思索, 就像是下面我在 2006 年寫的 Web 8.0 Road-map 一樣, 這是一種文明演化的可能性:

Web 1.0 網站與網頁的開始:  [名言] 給我 Web (1.0), 我給你全世界.
Web 2.0 非同步顯示與使用者互動: [名言] 沒有 2.0 就不叫 Web.
Web 3.0 語意網路與自動化/自主化: [名言] 還要去想今天做甚麼? 這問 Web 3.0 就好.
Web 4.0 全影顯示與腦波輸入的開始: [名言] 連紅綠燈都變 Web 了, 那有甚麼不是 4.0?
Web 5.0 身體內嵌 Agent: [名言] Web 5.0 是天生的, 不是後來創造的.
Web 6.0 網路 Cyborg 的串聯: [名言] 抵抗是無意義的, 所有都會被 Web 6.0 整合.
Web 7.0 Deep Thought: [名言] 宇宙是由 Web 7.0 創造的, 是一個終極實驗.
Web 8.0 此時還有人嗎? [名言] GUT 可能要 11 維時, Web 8.0 就終結一切.

雖然說這些都是靠技術去實現, 就像是現在的電視從 SD 到 FHD, 到 UHD, 從 4K, 8K 到 16K, 在某些方面是種數量的變化, 是種規格的改變, 但真正的代表是種可能性擴展, 也就是說讓內容創作者可以從體驗, 到感知, 到應用所有元素去實現所有的想像.

只是這樣的想像須要一步步去完成, 不可能一促而及, 就像是 Internet 的發展即使再快, 但有很多過程與中間技術, 無論是有繼續使用或沒有人在用的技術, 但要去實現過程都是很辛苦的路, 或許我們來嘗試著列舉幾個未來須要突破的事:

1. 螢幕之間的溝通: 每次看到一些未來展望的影片, 都有跨螢幕的觀看的體驗, 所以大家都覺得這應該很簡單, 但事實上現在還沒有較好的協定與方式去讓兩個螢幕去做溝通, 那就更不用說是協同了.

2. 人身份的辨識: 雖然這理論上是最簡單的, 但目前大部份都是要靠搖控器來操作選項輸入, 雖然說靠 Camera 可以做, 而離實務上還很遠, 但現在有 iBeacon 等等都是候選.

3. 3D: 無論是 VR 或是 3D, 離真正的裸視還有段距離, 雖然有些已經有高單價特定環境的解決方案, 但要能夠普及或較寬鬆的環境設備可能還須要一些開發技術.

4. 內容的選擇: 無論是用甚麼方式來看, 重點還是在內容, 只是這內容是如何去選擇, 是永遠的單線執行, 還是依人的想法回饋改變, 這背後的演算法會是甚麼, 會讓人的視野更廣更深, 還是讓人更淺薄更好操控?

5. 與社會的互動: 雖然電視是個看穿出去 "窗戶", 但能不能演化成為一個可以互動的 "門", 可以透過電視去參與社會, 甚至讓人與人之間能夠有更多樣性的互動, 都是 "未來電視" 的可能性.

6. 資訊呈現的架構與連結: 常常看到很多看起來像 "Prototype" 的 Demo, 資訊的整合與呈現似乎是相當吻合場景與須求, 但這才是最困難的, 要去跟那些既有資訊連結, 無論是內部與外部, 透過辨識情境, 都沒這麼簡單.

7. 內容的產出: 在非線性與非單一視野的觀影經驗慢慢成型, 但挑戰的是內容要如何製作, 如何產出, 從腳本的製作, 影像的拍攝, 甚至剪接的方式也會變得不一樣, 內容製作者要如何面對這挑戰, 做出經典範本讓大家學習, 這才是更須要時間.

8. 社群的連結: 除了內容, 除了社會, 人最多的訊息是來自於社群, 也就是朋友, 在未來, 類社群, 類影像的訊息溝通會扮演很重要的角色, 畢竟真正讓人悸動的還是人, 不是內容.

而上面幾個要克服的事, 都可以從很多角度或面向來看, 主要是以人, 內容, 機器, 架構與系統商這幾個層面, 而這些層面要考量的是下面幾點:

A. 人的角度: 2, 4, 5, 8
B. 內容的角度: 3, 4, 5, 7, 8
C. 機器的角度: 1, 2, 3, 8
D. 架構的角度: 1, 2, 4, 5, 8
E. 系統商的角度: 4, 6

當然這只是主要的, 事實上未來電視要發展, 本來就是種多面向的事情, 要把這些整合實作出來, 沒這麼簡單, 甚至可能要像 IP 一樣, 走到現在已經到 IPv6 了, 而未來電視要走到第幾版才會真正合乎人性呢? 這就要看大家的投入與參與, 或者只是個使用者都會影響到未來....

公民記者在未來國會的角色

今天 (2016-02-25) 在立法院有一個座談會，來談 "公民記者" 在國會立法院的角色與定位，最主要是因為前一陣子 "壓克力" 事件造成很多 "誤解"，所以副院長蔡其昌趕快辦這場座談會來滅火與澄清，也強調 "立法院將開放國會作為理念積極實踐" ，從這邊可以看得出這個新國會的確是蠻不一樣的，雖然一開始還沒有認真的去思考與規劃，但至少已經可以從社會氛圍看到國會不再是封閉，不再是威權。

只是從這次的座談會來看，倒是大家有些共識：

1. 記者不該去區分身份，無論是國會記者，商業記者，非主流媒體記者，網路記者或公民記者。
2. 記者須要登記，而這登記是為了可以找到負責任的追尋，而不是資格的審查。
3. 立法院的設備與空間有限，除了對於常駐的記者有優先登記使用外，其他應該以先來後到的自律方式來使用。

而我在這邊徵求 YuTin Liu 的同意，轉錄他在當場的發言摘要：

1. iVod 應該使用第三方分流, 設備常開多視角同時播不分會議不斷線, 媒體不必再問此會議會不會直播. 直播記錄主張CC0充分授權.
2. 開放國會「空間」開放，固定入口單一窗口, 憑身分證/護照(外媒)登記不審查, 就該可以進立院採訪.
3. 最小成本的場地優化, 撤桌子改輕便椅子, 現場會議室至少可容納50~100人, 先到先坐不抽籤不登記空間不夠應該使用轉播延伸會議空間.

而這邊幾點的想法跟我蠻類似的，所以讓在他後面發言的我只好提出另外幾點：

1. 國會不只是不該限制與區分記者的身份，應該要嘗試著提供資源讓記者使用，甚至可以讓在會場外或議場外的記者與編輯能夠互動，來提高記者會或議會的品質，讓新聞能夠更有價值。

2. 國會圖書館或資訊室要能夠提供資訊或資源來讓立法委員與記者，或是所有在場的人，能夠對議題與法案能夠有更深入的資訊，尤其是提供工具來聚合見與多元呈現完整的資訊。

3. 導入新科技的資訊架構，如 RFID 來掌握資源與人員的狀況，來提升使用效率，如電視牆的有效利用可以促成跟公民的遠距參與互動，國會更應該使用網路讓科技在開放國會扮演讓公民參與更有效。

的確，公民記者這議題在這次的國會改革應該只是個契機才對，須要認真檢討的不只是記者在國會應該扮演甚麼樣的角色而已，而是未來國會如何透過新聞記者，或者是國會監督者與解讀者，如何讓我們這個國家每一個公民都能夠參與這個社會，這個政治，這個國會，這才是重點。

事實上有時我覺得所謂的議長中立，國會聽證權都是架構在這個立法院真的能夠聽到民意嗎？或是人民除了投票與沒事打電話給立委助理外，真的沒有其他政治參與的方法嗎？這點若沒辦法做到，很多事情都是假的。

尤其今天有人提出 "國會公園化"，來讓大家有更多的機會與動機來立法院走走，而不是只靠少數的記者來做中間人，甚至也不是只靠立委與立委助理單方面的思考與執行，距離你上次去立法院或地方議會，是那時候呢？這才是我們該深思的問題與目標。

2016 的 29 項 SEO 重點

雖然一直說, 會影響 SEO 的因素是數千種, 即使這不是開玩笑, 但這樣的數目不是可以讓人做事的步驟, 倒是有點像 Check List, 只是真的要縮到幾百種也一定有所缺漏, 所以有時須要系統去協助, 像最近 awoo 的 SEO Tool 就是可以協助的工具....

但對於已經在 SEO 深入的從業人員, 每次看這麼多東西是有點累, 其中有些因素是是老生常談, 甚至有些是已經過時, 所以在想鞤助大家用架構的思索看一下若是今年要做 SEO, 重點會是那些? 尤其是正在改變, 正在加重的項目.

雖說想要摘重點, 但隨便列出也有 29 項, 這些主要來源是一些文件, 建議書所整理出來的, 把相同概念的將予以統合, 或者有些甚至不合適台灣的排除, 分成八個大項目來說, 這樣應該會比較好理解:

A. 網站內容

1. 影片內容就 ROI 與品牌

內容雖然一直是重要的, 但影片內容在 2016 也越來越重要 (雖然 2015 也是這樣說), 但就現在已經實證影片內容對 ROI, 對品牌效果更甚文字內容, 甚至已經是沒有影片的內容會不會就意義少很多呢?

2. 聚合內容 (懶人包) 會比新聞更有效果

雖然說內容很重要, 但導引讀者來看內容更重要, 不只是解釋性新聞, 資料新聞學, 都是種導引, 其中包含聚合整理的懶人包也會變成視聽者的主軸.

3. 語意網路的應用更廣泛

語意網路從 2005 年講到現在, 現在已經超過 10 年了, 從 Tag (標籤) 的廣泛使用, 語意網路無論在內容, 在內部連結或使用者導引已經不再只是想法, 而是相當實用的事, 甚至會取代既有的分類概念, 變成不可或缺的事.

4. 內容 (文章) 越多 (越長) 越好

有在經營新聞網站的人應該知道, 文章內容太少, 或者是無法讓 Google 找到重點的新聞是不會收錄在新聞的 (但還是會收錄在網頁), 現在太多網站用無限分頁, 無限瀏覽等等技巧增加點擊或時間, 但沒有同時增加內容, 或許這也是這時代的問題, 但相對的由於 Content / HTML Ratio 的重要性越來越重要, 內容 (文字) 在很多情形被乎略, 這也是種用搜尋引擎扭轉時代的力量嗎?

5. 獨特的圖片

不只是文要附圖, 現在很多網站的圖是隨便找別人的圖放上去, 在未來原創的圖片往往代表你對文章品質的要求, 每次都從圖庫找想吸睛的美圖, 就可能是沒有意義的內容農場文章, 從這個角度來看這也是種解決的方式, 但也有可能過兩年沒效果, 表示所有小編都能夠畫新圖?

6. 重覆內容太多會被消失

雖然 Google 說不會懲罰重覆內容, 但演算法中對於能夠過濾掉相同或類似的內容給使用者, 這絕對是好的使用者經驗, 但對於文章重覆授權, 或是沒去認真編輯整理的網站, 這就是個很大的警訊, 這件事從去年年底就開始, 之後相信會更明鮮.

7. 從關鍵字到主題性內容

在內容創作上不該只是注意關鍵字而已, 而是一連串的主題性報導, 這其中也包含內部連結的完整性, 其中也包含導引的過程, 所以須要的是把關鍵字, 標籤 (Tags) 如何包成主題, 甚至成為一個專欄專題, 都是很好的應用方式.

B. 使用者搜尋行為

8. 要想辦法攻占 Google Now, Siri 等 Agent (代理者)

雖然這些數位助理 (Digital Assistance) 大部份用的也是搜尋引擎的結果, 但若能夠找到使用者須求並能夠去界接起來, 不只能夠增加一個管道, 這也代表的 SEO 做得相當好, 當然中文這部份還是沒有做得很好, 但應該會越做越好.

9. 語音搜尋越來越重要

相對的要把新創的字能夠被大家使用, 甚至為了增加語音辨識的口語化搜尋, 要了解文字的關鍵字與口語的差異, 在手機的使用及便利上, 透過語音搜尋的數量越來越多, 而語音搜尋除了字詞關係, 更要記的語助詞.

10. 搜尋關鍵字會越來越像人發問

不只是語音輸入, 即使是文字輸入, 由於越來越多人為搜尋引擎的無所不能而當成是一個擬人化的代理者, 因此關鍵字與關鍵字之間不再只是 "and/or", 而是變成一個完整的問句機會相當高, 甚至還包含主客觀, 正負評的問法, 相對的, 文章內容或導引是否能夠有個相對應的來付和, 是編輯者與 SEO 專員要去思好建立的.

11. 自動完成 (Auto Complete) 聚焦內容

由於在搜尋的輸入列越來越多已經有自動完成的功能, 使用者可能在打前面兩三個字的時候, 就被導引到會有自動完成的關鍵字, 所以要花心思在去獲得這些搜尋引擎導引使用者的流量, 會獲得更多的流量.

C. 手機的影響 (Impact)

12. 手機的優化比桌機重要

已經有很多網站手機的使用比例超過五成, 甚至是八成, 尤其是考慮到覆蓋率的情型下, 只使用手機的人已經遠超過桌機的人, 所以手機的優化不只是在 UI/UX 而已, 在 SEO 也是更重要, 其中也包含 RWD 這部份.

13. App 的 Deep Link 會越來越重要

雖然這部份只對在手機上搜尋才有效果, 但不得不否認的增加一個曝光的機會在兵家必爭的 SEO 是不能放棄的, 尤其是應用 App 給使用者的網站更形重要, 雖然在台灣的中文部份搜尋出現的機會還是較少, 建議還是要開始準備.

14. 搜尋會越來越 Local, 尤其是有位置的資訊與有定位的使用者

由於現在的智慧型手機 GPS 的準確度與速度越來越強, 且 Google Local 的完整度也一直在優化, 地點與地址都搜尋也越來越依賴 Google 與 Google Maps, 在這兩方向的進步下, 搜尋不只是內容與條件受到地理資訊會更明鮮, Google 肯定在未來也會如此做.

15. AMP (Accelerated Mobile Page)

不只是手機, 不只是使用者體驗, 不只是網站結構, 不只是網路速度, ... AMP 是一個很好的概念, 但這部份會不會成功沒有人知道, 但可以肯定的是 Google 一定會努力推, 所以至少會有段時間會是很夯的題材, 而要不要實作, 可能還是要看有沒有資源去做.

D. 社群訊號

16. 社群內容會被容易索引 (Index) 到

這邊說的社群訊號不只是 Like, Share, Comment, Tweet, Pin, ..... 在社群網站的內容已經不會被 SNS 認為是不可外洩的財產, 在於社群網路越來越公開的情形下, 透過搜尋引擎的流量的來源也被認為是相對重要的事, 所以社群內容的資訊已經可以很容易索引到的情形下, SNS 真的不只是社群流量的出口, 更是搜尋引擎流量的源頭.

17. 臉書搜尋會讓使用者導引到該有的地方

除了 Google 以外, 像臉書 Facebook 的搜尋也會慢慢成為一個引流的地方, 雖然 SNS 即使再怎樣不希望流量出去, 所以才會想要用 Instant Articles 來鎖住, 但除了內容網站, 還是有很多網站是無法硬是留下的, 最後臉書還是具有導引的功能, 而從臉書內部的流量, 除了粉絲頁外, Facebook 也一直改善搜尋, 只是最後這塊會是如何 SEO, 也是在於社群與內容交互應用的場域, 這策略將也會變得很複雜.

18. 社群的個人還是變成導向或索引內容的方向

社群的本質還是在於人, 也是個人, 廠商再怎麼多也沒有個人這麼多, 不只讓搜尋引擎認同, 要做夠有口皆碑後, 有源源不盡的連結與內容在產生, 若這又能夠被 Google 索引到, 這不是對 SEO 工作人員是多好的事情嗎? 但只是這最後是好事與壞事, 還是取決於產品與服務的評價結果, 這也是該小心的.

E. SERP (搜尋引擎結果頁)

19. 特化的搜尋結果會越被看見 (新聞, 地點, 影像)

除了廣告外, Google SERP 的結果頁還有 Rich Answer 與包含新聞, 地點, 圖片, 影片的搜尋結果, 這部份在雖然 Google 本身還是有自己的新聞, 地圖, 圖片, 影片等搜尋, 但放在主要的 SERP 還是會帶來很大的流量, 且這通常是在第一頁, 雖然這也是表示網站除了網頁外, 更要顧及其他媒質, 才能夠有最大的覆蓋效果.

20. Rich Answer

Rich Answer 出現在 SERP 的比例越來越高, 但這也往往代表這不只是 wiki 而已, 很多有 Rich Snippet  (Structured Data) 也可以參與戰局, 這點也跟 Google Now 有所相關, 最能夠讓使用者得到精確但完整的答案除了是深化網站內容與結構外, 知道 Google 有那些去做這塊, 或是怎去做這塊, 也變成兵家必爭之地, 雖然台灣並還沒真的開打.

21. 常態分配, 長尾分配, t 分配變得複雜

有時不是討論網站是在 SERP 的第一名, 或是前幾名, 而是想辦法讓使用者在這邊找到答案, 在很多情形下, 很多 SERP 使用者不只會點擊到第 10 名, 還會繼續翻頁, 但相反的, 有不少的頁面前三名就囊括所有的流量, 討論第幾名已經不是那麼有用, CTR 比名次還來得重要, 即使第一名也不代表是讓使用者就找到答案的情形下也不見得會穫得流量, 如何讓使用者認為這是答案, 除了從網站內容下手外, SERP 是不能忽視的.

22. 搜尋點擊的回饋

去年 Google 已經提出新的專利與演算法, 針對使用者對搜尋點擊回饋後的排名改變, 雖然這早就不是新聞, 甚至這也是 Yahoo 最被詬病的一環, 但 Google 提出的方法就複雜許多了, 包含 After Search, 等等, 畢竟 Google 也一直在 User Experience Optimization (SXO).

F. 網站使用者經驗

23. 使用者經驗與 CTR

這好像有點 OP 了, 雖然已經提過, 也不須要提三次, 只是這部份比以往更重要, 這邊不只是 CTR, 包含其他 Time On Site, Pages per Sessions, Bounce Rate 這基本概念外, 針對內容頁與中間頁的 UXO 變得相對重要, 只是這部份應該還要花更多時間的去籬清與定義.

24. 忠誠度與會員經營

除了上面的 UX, 從 GA 可以看到各種角度的使用者狀態, 包含忠誠度, 造訪週期, 點擊總數等等跟使用者行為有關的資訊, 這慢慢的也會變成 SEO 的因子, 甚至會員專屬內容占所有網頁瀏覽的比例也會變成一種參考後, 誰說經營內容不用管會員或使用者的?

25. Navigation 不要只是放廣告

無論上側邊欄或 Header/Footer 等等跟 Navigation 有關的事, 雖然這乍看之下跟內容無關, 甚至內容網站早就投降全部放上廣告, 但不代表正常的網站可以仿效或完全不管, 雖然美感是使用者經驗的一環, 但也不代表可以完全凌駕, 好好的思考 "內容以外" 不是代表只思考著如何放廣告而已, 有更多的事是要幫使用者想, 相信若真的做對, 使用者也會對網站有所回報.

G. 網站技術

26. HTTPS

網站就純技術部份而言是最不重要的, 但整個 SEO 有那個環節跟技術無關, HTTPS 不是新的技術, 但若還沒打算今年做的人是不是已經打算放棄網站經營了?

27. HTML5

不要說 Flash, 不要說 Java, 這場戰爭好像一面倒了, 雖然前端 Front-End 變成顯學, FE Framework 也不用討論了, 但離真的讓使用者經驗與 Search Engine Friendlily 的中間還有段路要走, 最保險的就是 HTML5 了吧?

28. 網站速度

最無聊, 最實在的因子就是網站速度, 這不只考驗著投資者, 經營者, 工程師, 也在挑戰搜尋引擎, 挑戰讀者, 以前這點有時是不值得一提, 但現在不同了.

29. 外部連結的懲罰越明顯, 要隨時注意排除 (其他)

不要以為大家都在做白帽 SEO, 就我所知還是有一大票的人在做黑帽 SEO, 甚至去陷害別人, 這邊不是要叫大家去陷害別人, 而是不要被別人陷害, 畢竟有太多為了 SEO 而 SEO, 偷內容的人, 此時往往也會帶你網站的連結, 若那個網站被 Google 認定是不良網站, 就很可能會牽聯到你.

30. Page Quality, Rank Brain

順帶一談, 網頁品質與智慧排名已經是去年的熱門關鍵字, 且這邊說的上面 29 件事或多或少也是跟這件事有關, 所以理論上是沒必要說了, 但還是建議大家去看相關的文件, 因為還提到上面 29 件事沒提及的事, 不代表不重要, 只是代表 SEO 又是一個無窮無盡的事了... 唉...

公道伯經驗(III): 要找怎樣的人才能夠寫出好政策?

Lukasik: 「我在高層，你在基層，所以你根本不曉得當時發生了什麼事，以及我們為什麼要這樣做。」

Crocker: 「我在基層，你在高層，所以你根本不曉得當時發生什麼事，以及我們到底在做什麼。」

上面這兩句是取自於 "創新者們: 掀起數位革命的天才、怪傑和駭客" 這本書的章節, 講的是 Internet 網際網路發展的過程與歷史, 他們在討論到底 Internet 是不是為了因應核戰威脅而產生, 上面這兩個對話, 真的是很好的註解, 但不是在講台灣的現狀, 只是大家應該很能感同深受, 因為這確實也存在我們台灣的政治與官僚體系.

這個現像嚴不嚴重? 大家都很清楚, 不然就不會有空心菜的說法出現, 當然另一個已經完全不知民意是甚麼的就不用管了, 但這個問題難道不能解決嗎? 也不是沒有辦法! 因此在做政策的投影片時, 初稿的作者是相當重要的, 其中有設定下面五個條件去尋找作者:


1. 找第一線有在做事正在實作的人

所謂的高手藏於民間是假的, 真正知道怎麼做事的人往往一直在做事, 或許他的思維不夠全面, 但多找幾個做事的人就可以找到最 "精實" 的解決問題的方法, 相反的, 找 10 個或 100 個官員, 他們能夠產出的都是是不切實際的報告, 而且都是抄來抄去...

只是台灣的很多氛圍就是一直叫人進入舒適圈, 去做管理階層, 或是去做行銷包裝的人比較容易獲得較高的報酬, 但最後去了解事情與做事的人幾乎就沒有了, 或者是很難傳承, 這樣說台灣有競爭力是很困難的, 更何況最後訂定決策的人對事情又是一知半解, 這樣能做出好決策是相當困難的.

2. 不找官大學問大的人

官大學問大的問題不只是上面的問題, 也不只是下面的錯誤權威/假權威的問題, 雖然說所謂官員能夠看得較全面, 相對的離現實較遠, 最麻煩的還是你相信 "官員能夠公開公平的評斷" 嗎? 當然這問題若是把政治與資訊開放, 公開就能夠有相當程度的改善, 甚至公平也能夠受到正面回饋, 但事實上現在的政策或決策的制定不是不公開, 而是不能公開, 因為往往向某種程度利益的傾斜.

雖然要把事情有全面的思維, 但這個全面的思維又不是靠真正意見的徵集或者是公開的討論, 到最後還是偏向少數人就能做決定, 或是這個過程與因素過於黑箱, 而最後看到的是官樣文章, 一個只有正面的政策鼓吹, 而不是正負面衡量的思考過程, 這樣的政治只會讓人更寒心, 與人民距離越遠.

事實上人民早就看穿這個 "官樣文章" 的狀況, 這也是須要再一次 "政治革命" 的原因, 只是我們也期望這個政府能夠擺脫這問題, 真的找能夠解決問題的第一線實作人員, 不是又找幾個高階經理, 高級官員, 資深學者, 若這些人能夠在這樣的圈圈找到問題, 台灣早就沒問題了, 而我們知道問題一直在那邊沒有解決, 這個絕不是換個總統政黨輪替就可以圓滿解決, 甚至說不定這新政府又來 "官大學問大", 這樣又持續這情形了...

3. 平常就對這議題有在發聲的人

雖然不是每一個實際下來做事的人都能知道問題與解決方式, 或者能夠清楚的知道問題在那, 甚至到提出真正好的解決方法是有落差的, 這邊所說的提出問題, 可能的解決方式, 甚至是實際的政策, 也都是須要經驗的累積, 須要長時間的跟人討論與互動才行...

雖然這點跟前兩點若是要同時交集是相當困難的, 甚至只能要求 : "管理與決策不是他全部的職務", 或是 "只要他不是完全不碰第一線", 能夠同時存在就了不起了, 甚至若還要符合下面這兩點整個就是不可能, 這或許是台灣的悲哀, 所有人都要成為經理人, 所有人都要成為官員... 最後變成這種狀況要如何改變?

而對這個議題有在發聲, 代表她平時會觀注這問題, 嘗試著解決, 甚至是去幫助他人, 這種人的意見是相當重要的, 畢竟更期待的是因為知道她從平常實作的累積經驗, 而有傳教士的精神, 若我們不能幫忙推一把就太可惜了.

4. 每個領域有其專精, 避免假權威

有一個名詞叫 False Authority, 這句話的是權威的誤用, 當然不只是官大學問大是一個誤用, 重點是因為台灣能夠長言善道的人太少, 而整個社會與媒體幾乎把資源聚焦在某些人的身上, 所有的問題都問這些人, 從天文到地理, 從棒球到國防, 事實上這些人不是說沒有足以成為權威的專家, 但不是所有領域都可以的.

或許也是 "關係" 的關係, 從政治圈, 到媒體圈, 台灣整個都似乎被這些 "專家" 所把持著話語權, 到最後 "高手藏於民間" 後就沒下文了, 因為這些圈圈很小, 本身是有很大的限制又無法開放, 即使有人有專業的素養與想法可以提出, 甚至下來做, 但被這個 "裙帶關係" 的既得利益者框住, 要能夠突破是相當困難的, 或許靠的是更多的資訊, 以及更能夠流動與透通的網路機制可以解決也說不定.

5. 能夠跳脫既有框架, 符合網路時代

所以除了上面四點之外, 更希望這個政策能夠建立一個更大架構, 更透明公開的思維, 或者是解決方法, 靠的是就是演化極快的網路時代, 因為一個理論, 到實現, 到成為產品, 到專案, 進一步成為想法與政策, 若不是透過網路, 這流程可能是從 10 年到 20 年以上, 但透過網路的溝通討論的效率, 已經不只是紅色三倍速, 而是十倍速的時代了.

當然有時這個第五點是單純的, 因為要符合前四點, 表示那個人除了有在做事, 更能夠公開提出方法與跟人討論, 基本上表示他一定能夠熟淰的使用網路, 只是他能不能做出跳脫既有框架, 對於各種解決方法不會有太多的成見, 而去判斷思考, 有時也很難檢驗, 只能從他平常的文章與做為下手.

-------------------------------

這次的實驗也是個開端, 上面說的五點也是存在這社會很大的問題, 但公道伯粉絲團經營之初較少被人重視, 所以要去徵初稿找到最佳人選也不是那麼容易, 甚至有時因為客觀條件與因素離真正實踐還有大段距離, 但這幾點一直是我緊記在心, 也請找人的盡量以這五點去尋找.

畢竟我們不能期待別人幫你解決這社會的問題, 好像是這是別人的事而不是跟你有關, 但事實上這個社會的很多事, 都是從自己做起, 從小事做起, 先要求自己再要求別人, 這社會才會改變, 造成社會改變的, 絕不是只有 "投票" 而已, 而是從我們持續的參與社會做起....