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 所 "控制/決定" 著.

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

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