2019年SEO趨勢是什麼?「機器學習、物聯網、使用者體驗」影響下的SEO

0
764

2019 年的 SEO 除了受機器學習技術、IoT(物聯網)產業發展的影響,另外也受到了大環境考驗──「假新聞漫天飛,落入有心人士手中操弄」──對於這樣的風潮,2019年搜尋引擎演算法有什麼變動趨勢呢?讓我們從回顧2018年的SEO大事件,並且綜合搜尋行銷的演變,來預估2019年SEO的趨勢吧!

>>>下載完整版2019 SEO趨勢/策略,收藏慢慢看。

1. 網域公信力更吃重

打擊假新聞,建立有公信力的網站

在這個人人都可當媒體人的時代,要辨別消息的真與假實在很難。尤其許多「風向操作」團體,可以利用空穴來風的消息,操弄社會輿論甚至是選舉結果。基於這個現象越來越嚴重,2018年3月Google宣布「Google新聞決策」(Google News Initiative),9月更近一步與 Facebook、Twitter 聯手合作,同意一起在歐洲共同打擊假新聞。自然 Google 會從自家的產品動刀,Google Search 在去年就發生了核心演算法的調整,希望能大幅度提升 Google Search 的搜尋品質,在搜尋這一環阻擋假消息被看到。

若你是長期關注搜尋行銷的人士,應該有被去年八月發生的核心演算法更動(暱稱 Medic Update)被嚇到。許多大型網站在這一波演算法更動中,流量權力板塊大洗牌。為什麼會有這個演算法更動呢?我們可以大膽推測:現在全世界在為資訊爆炸造成的「假新聞氾濫」現象,努力找防治手段,而Google,身為一個世界資訊傳播的重要來源,在去年八月祭出核心演算法更新,希望能讓使用者在搜尋「YMYL(Your Money Your Life)」資訊時,能得到更正確、更公正的解答,避免假消息在 Google Search 上流竄。

什麼是YMYL(Your Money Your Life)關鍵字詞?

YMYL指的是「攸關於人身財產安全的資訊」,包括了健康、財務、不動產、教育,這些一但下決定,就可能會影響未來生活的指引。你可能會發現,當搜尋「疾病名稱」、「會計名詞」、「貸款」⋯⋯這些關鍵字詞時,出現在 Google 前幾名的,通常都是政府、銀行、醫院的官方網站,或是維基百科、大型媒體網站。

YMYL Keywords Example
YMYL關鍵字詞舉例:流感疫苗、營業所得稅、幼兒補助

Google八月核心演算法(aka. Medic Update)對台灣 Search 市場的影響是什麼?

健康知識網站

健康知識搜尋市場,若將每個網站攤開來看,你會發現在每一間都在8月1日開始全面流量大洗牌,幾家歡樂幾家愁。也可以看出 Google 這樣的調整,其實讓健康市場走向零和趨勢,已具有規模的傳媒可以贏者全拿。另外細看這些流量,也可看到 Google 在10月初有一波調整,似乎企圖將「誤殺」的流量救回,但也有網站流量一去不復返。

投資理財網站

在8月的演算法調整中,投資理財資訊網站或多或少因此受到影響,但來到了2019年初,初步檢視大多數投資理財行網站流量已回穩。不過仍然「大者恆大」,大型媒體網站流量、排名穩定,不動如山。

YMYL Economy&Money 財經類型網站
財經媒體網站流量洗牌

 

如果我的網站在Medic Update之後搜尋流量一瀉千里,該怎麼辦?

Medic Update 調整,從精神上來看,是在於「網站整體的權威度」上,給予更高的重要度。於是任何可以提高網站權威的做法,都可以幫助網站重回流量。這麼說來有點空泛,但是基本上可以從以下方向來努力:

  • 提升品牌力(提升首頁被搜尋的次數)
  • 提高內容公信度(補充內容、補充知識來源、補充作者資訊、補充版權說明)
  • 增加高品質外部連結(讓網站曝光於合作網站、產出優質內容鼓勵分享)
  • 擋住可疑的外部連結(利用Search Console禁止連結工具)

延伸閱讀:

Google 2018八月的演算法更新「Medic Update」,awoo建議可以試著在網站內做出的改變

禁止反向連結 – Search Console 說明

以上四種方式,根據不同產業會有不同差異,無法說執行哪種一定對你有效。但是 awoo 的合作夥伴在執行完上述幾點後,下滑的流量也起死回生了!如果你因為這次的更新苦惱了一陣子,建議您從今天開始,也朝這四個方向加強品牌的權威度,對品牌經營更是有利無害。

 

2. 內容經營符合顧客消費歷程

因為數位技術的發達,行銷的管道五花八門,其實幾乎沒有顧客的購物歷程是一模一樣。就算是同種商品,有些顧客會花幾個禮拜到幾個月去搜尋資訊才決定購買,也有些客戶幾小時之內就決定下單,其中「搜尋」的行為,也會因為不同產業、不同客群而有差異。所以,搜尋管道策略不能只看片面,而要去思量「到底在何種情境下使用者會搜尋?」,反推「關鍵字」,思考「著陸頁面」,優化「轉換」。SEO 不再是「關鍵字排名」這麼簡單。

範例:上班好鬱卒,看同事買了多肉植物放在桌上好像容易照顧又療癒…

實體店面購買劇情

先搜尋「多肉植物」,發現多肉植物有好多分類!這時也認識了一些線上購物的店家,點進去看價錢,發現線上購物店家價錢偏高,於是繼續搜尋「多肉植物價格」,這時發現其實可以去實體花市逛逛,價錢更實惠,而且直接去還可以直接買,也是一個假日跟朋友一起去的好去處。

 

內容經營重點:

 

線上購買劇情

搜尋「多肉植物 價格」時,發現一些不錯的網路商店,照片真的很吸引人!但是之前跟這些品牌完全不熟悉,該馬上下單嗎?先忍住做做功課,看看這些網路賣家的評價吧!

內容經營重點:

後續照顧劇情

買完多肉很開心,但是照顧上發現了一些問題⋯⋯例如:葉子變軟了,沒有當初買回來那邊厚實,這是哪裡出了問題?或者是,買完一盆發現太棒了,還想做一些進階的變化,像是植物搭配做成禮物送給朋友,這時候就是「內容行銷」出場的時候了!

內容經營重點:

延伸閱讀:How search enables people to create a unique path to purchase – Think with Google

3. 注意地區性搜尋(Local Search)特徵

根據 Google 的保守估計,其實有 30% 的手機搜尋都帶有「地區意圖」,除了「直接帶有地理位置」的關鍵字詞外,有些字就算不打入「地區關鍵字」,仍可以觸發 Google 的 Local Search 特徵。像是搜尋「天氣」,其實背後的最可能意圖就是想看附近的天氣,於是 Google 推斷這背後是想要知道手機定位附近的天氣,自然會帶出「Local Search」的搜尋結果。

地區性搜尋特徵(Local Search):天氣

雖然 Local Search 並不是新消息,但是過去一年,Google 對搜尋結果頁面時常有改版,用更大的版面來顯示 Google 自己系統運算出來的資訊,像是「Local Pack(地區圖版位)」、「Knowledge Panel(知識版位)」、「Carousel(輪播版位)」、「Hotel Results Box(旅館結果區塊)」⋯⋯這些版面越來越常出現,用手機搜尋時,甚至把原本的自然搜尋結果都壓到最下方了。這對搜尋行銷有什麼影響?透過 SEO 有機會讓自己的網站出現在這些特別版面上嗎?

哪些特性的關鍵字詞特別受 Local Search 特徵的影響?

如果你的商業性質與下面列出的特性有關,那就更要特別注意 Local Search 對你的影響:

  • 客群通常只侷限在某一特定區域(例如:美髮沙龍)
  • 旅遊相關(例如:民宿)
  • 實體活動或展覽(例如:婚禮場地)
  • 會因為不同地理位置而有差異的現象(例如:天氣)

爭取 Local Search 的曝光,我該怎麼做?

以下簡單從 SERP(搜尋結果頁面)的版位來區分:

Local Pack(地區圖版位)

也就是搜尋時會出現「地圖資訊」、「店家資訊」的區塊。大致來說,可以透過經營「Google 我的商家」(Google My Business)來讓你的店家在使用者搜尋時,更容易出現在頁面上。經營「Google 我的商家」的另外一個好處是,使用者用「Google 地圖」查詢時,你的商家也可以清楚顯示在上面。

Local Pack 版位
 
Google 我的商家優化經營重點:

Knowledge Panel(知識面板)

Knowledge Panel 通常會在使用者搜尋「品牌名相關詞」時出現,在消費者購物歷程中,可能會出現在「想要更近一步了解這個品牌」這個階段,所以能否得到信任感是一大重點。而 Knowledge Panel 通常還會因為你是「 當地商家 」還是「大品牌(Google 認為)」*註1 而有不同樣式;兩種差別如下:

Google Knowledge Panel 出現樣式

若是當地商家,會直接出現你的「我的商家卡」,這邊的調整重點可以參照上一段「Google 我的商家優化經營重點」。若你打入自身品牌字,出現的是另外一種「大品牌卡」,也可驗證 Google Knowledge Panel,向Google 提出請求修改。

延伸閱讀:Structured Data | Search | Google Developers

 

*註1:除了大品牌,另外地標名稱、人物、組織⋯⋯等不限地區限制的物件,也會出現這種樣式。但本篇文章先聚焦於「商業店家」,故略不提其他情況。

Carousel(輪播版位)

目前常見的輪播版位有 *註2:

  • 圖片輪播
  • 專有名詞的分類輪播
  • 地區推薦行程輪播
  • Q&A頁面的輪播
  • 圖片搜尋的輪播選項(以 Bubble Snippet 型態出現)
  • Youtube 影片輪播
  • Knowledge Panel 中的「其他人也搜尋了以下項目」
  • 食譜輪播
  • 內容摘要(以 Bubble Snippet 型態出現)

*註2:會因為手機語言設定、搜尋引擎地區設定不同,而可能有不同的 UI 介面,甚至有不同的版位,這邊以中文(繁體)台灣地區為主。想要看最新的版位,可以切換到英語介面,甚至使用 VPN,有機會可以被 A/B Testing 到另外的版型。

Google 搜尋的 Carousel 輪播版位
我的網站有可能在 Carousel 輪播版位中嗎?

畢竟這是許多是 Google AI 所蒐集、整理的資料,所以並不是都能透過優化自己來促使 Google 顯示。但仍有幾個方向我們可以掌握:

總結以上,順應 Google Search 越來越多版面都是 Google AI 所搜集、歸類,你必須準備好兩個方向:

一、經營 Google 自家提供的平台,盡可能補充詳實的資訊

二、為 Google 機器學習鋪路,在自家的網站中加上適合的語意標籤(無論是Google發布的結構化資料,或是遵行 HTML 標籤原有的語意架構)

 

4. 結構化資料不停更新中

2018 年到現在 Google Structured Data 仍不斷改版,看得出 Google Search 將更依賴這些結構化資料,最終將會影響搜尋結果。結構化資料是什麼呢?簡單來說,就是透過在 HTML 文本中加入 Google 認可的標記,方便 Google 可以暢行無阻了解你的頁面內容。截至目前,官方文件所列出的結構化資料共有 28 種,這邊列出適用於大部分網站的項目:

類型

說明

適合使用的頁面

Article 文章

幫助文章出現在「Top stories」中,展示文章「Rich snippet」。又分為AMP、NON-AMP類型。

新聞、部落格文章

Breadcrumb 麵包屑

Google 利用麵包屑來分類資訊。幫助網頁出現「Breadcrumb Trails」。

除了首頁外,網站中所有可被分類、有階層關係的頁面

Carousel 輪播

幫助搜尋結果出現「Carousel」樣式。

在含有「網址清單」的整合頁面(Summary Page),例如「文章列表」、「活動清單」、「某道菜的食譜清單」。或是整合資訊頁面(all-in-one-page),例如「熱門6大鹹派食譜」。

Corporate Contact 聯絡資訊

幫助 Google 的 Knowledge Graph 出現公司組織的聯絡資訊、聯絡時間、聯絡地區、公司網址。

公司或組織網站中所有頁面。

Event 活動

幫助 Google 了解活動時間、活動類型,並讓活動出現在 Google Search 活動版位。

活動頁面。(活動類型目前支援:商業活動、兒童活動、音樂會⋯⋯等等,詳細請看 schema.org 所發佈的 event types

Logo 組織識別

幫助 Google 確認公司或組織的 Logo 識別。

公司或組織網站中所有頁面。

Product 產品

幫助搜尋產品時,在 Google Search 及 Image Search 出現產品售價、評級、存貨⋯⋯等資訊。

商品頁面或比價頁面。(這邊的產品可以是課程、實體商品、服務。)

Review Snippet 評論摘要

幫助 Google 了解某樣商品、書籍、電影⋯⋯的評價分數、評論摘要。

具有「評論功能」的任何頁面。(常見有商品頁、電影介紹、食譜等)

Social Profile 社群

幫助 Google 的 Knowledge panels 出現公司或組織社群連結,例如官方 Facebook Page 的連結。

公司或組織網站中所有頁面。

Video 影片

幫助 Google 了解影片主題、內容、更新時間、影片縮圖,可能出現在 Image Search。

含有影片檔案的頁面。

Beta 版

Software App 應用程式

幫助 Google 了解 App 內容,網站與App 關聯性。

具有 App 商品的網站、介紹 App 的文章、販售軟體的頁面。

Speakable 可讀內容

幫助 Google 得知文章中「可被閱讀」的內容,可應用在 Google Assistant 相關裝置。

具有 Google News 或 Google Publisher 資格的媒體,才能在新聞頁面增加「Speakable 結構化資料」。

設置 Structured Data 要注意什麼?

5.Google 助理(Google Assistant)是下一個品牌曝光管道

去年11月感恩節過後,Amazon 發佈消息表示自家語音助手產品「Amazon Echo Dot」是Amazon上銷量第一的商品,預估在2018年最後兩季,Echo Dot 銷售量達到 5 億台,而根據 Google 官方在消費電子展訪談上所說, Google 助手(Google Assistant)功能目前已經在 40 億台裝置上啟用。Google Assistant 使用者遍佈全球,Amazon 則是主打北美市場,而 Canalys 分析,目前 Amazon 佔有智慧語音市場的 75%,而 Google 則佔 25%。

“Marketing in the age of assistance”

「這是個線上助理的大時代」 Google 如是說

這個趨勢雖然是從 2016 年就開始,但 Google 當時的 Google Home,市佔率並沒有這麼高,官方也很少針對 Voice Search 有詳細的解釋文件,awoo 在 2018 年 SEO 趨勢文,也只能先從「文案語意」下手,希望能從攻佔 Featured Snippets 版面,來讓 Google Assistant 更容易抓取你的文章內容。但是隨著結構化資料官方文件在 2018 年 7 月 24 日更新,你可以發現 Google 有釋出「Speakable」的規範,並直接寫明:

“Adding markup allows search engines and other applications to identify content to read aloud on Google Assistant-enabled devices using TTS. Webpages with speakable structured data can use the Google Assistant to distribute the content through new channels and reach a wider base of users.”

(透過增加結構化資料標籤,可以讓搜尋引擎或其他 App 應用 TTS 技術,在支援 Google Assistant 的裝置上大聲地把你的內容唸出來。網頁可以利用「Speakable」結構化資料,讓 Google Assistant 幫助傳播你的文章內容,觸及更多使用者)

文件中更指出,當使用者詢問語音助手一個問題時,Google Assistant 會找出 3 篇文章,使用 TTS(Text-to-speech)技術,將有套用 Speakable 結構化資料的區塊唸出來,並且把「出處網址」、「完整原文」傳送給使用者的 Google Assistant App。

延伸閱讀:Speakable (BETA)|Google Search

使用 Speakable 結構化資料要注意什麼?

哪些類型頁面適合使用 Speakable 結構化資料?

Speakable 結構化資料語法

  • 下載完整版2019 SEO 趨勢 / 策略了解如何利用Speakable結構化資料讓內容被Google Assistant讀取

6.Search Console 資訊更透明更快速,弭平資訊落差

2018 年 1 月,Google 提出了新版的 Search Console BETA 版,在 2018 年 9 月宣布新版 Search Console 正式啟用。新版 SC 與舊版 SC 最大不同,就在於它的「測試線上網址」功能可以給你即時資料。以往網頁做了更新後(例如加上新的結構化資料),只能先使用「Google模擬器」擷取並轉譯,結果只能看到是不是轉譯完成,下載的 HTTP 回應原始碼,無法進⼀步知道 Google Crawler 對這⼀⾴的了解情況或是否有其他地方可以優化。現在只需進入「網址審查」>「檢查網址」就能知道特定網址的「收錄狀況」、「是否在 sitemap 中提交」、「是否適合行動裝置瀏覽」、「AMP版本是否有效」,若調整完,還可直接點擊「測試線上網址」,要求 Google 重新審查一遍確認結果,大幅節省時間,就算出錯也能知道大概的錯誤位置,跟舊有的「Google 模擬器」比起來指示清楚許多。

新版 Search Console,可為專一網址做檢查,並給出明確的「強化」指令。

新舊版 Search Console 差異比較

Search Console 存在的意義,就是製造一個讓 Google 可以直接與網站經營者溝通的平台。新版 Search Console 與舊版最大差異:

  • Search 成效圖表介面更易讀
  • 可以用「網址」為單位,偵測單一頁面檢索狀況
  • 清楚顯示重複頁面「Canonical」偵測結果(在2019年2月6日Google更將「成效圖表」中的網址資料集中在Canonical網址上。)
  • 以「行動版裝置」為重心
  • 提交 Sitemap 時,必須要有 Search Console 資源編輯權限
  • 搜尋流量資料從 3 個月變成 16 個月
  • 支援行動裝置來瀏覽 Search Console

新舊 Search Console 詳細差異比較如下:

舊版 Search Console

新版 Search Console

搜尋結果呈現方式

結構化資料

強化 *註1

複合式資訊卡

資料螢光筆

還未支援 *註2

改善 HTML

加速行動版網頁

強化>AMP

搜尋流量

搜尋分析

成效

連至您網站的連結

連結

內部連結

人為介入處理

安全性及專人介入處理>專人介入處理

指定國際目標

還未支援

行動裝置可用性

強化>行動裝置可用性

Google索引

索引狀態

索引>涵蓋範圍

封鎖的資源

網址審查(個別網址)

移除網址

還未支援

檢索

檢索錯誤

1. 索引>涵蓋範圍(網站整體)

2. 網址審查(個別網址)

檢索統計資料

還未支援

Google 模擬器

網址審查(個別網址)

robots.txt 測試工具

還未支援

Sitemap

索引>Sitemap

網址參數

還未支援

安全性問題

 

安全性及專人介入處理>安全性問題

Web Tools

 

 

*註1:目前偵測到「Job Posting、Recipe、Event、QA Page」才會顯示在「強化」區域。

*註2:雖然新版還未有資料螢光筆,但是在 Search 文件中,仍有出現「Data Hightlight」字樣(像是在Event 結構化資料文件),故推測未來仍可能會補上這個功能。

延伸閱讀:

從舊版 Search Console 遷移至新版 Search Console|Search Console 說明

Consolidating your website traffic on canonical URLs|Google Webmaster Central Blog

7.SSR(Server-side Rendering)確保搜尋爬蟲讀懂網頁內容

Server-side rendering 不是新技術,只是在今年 1 月 30 日 Google 官方 Webmaster 部落格有特別針對這個議題撰寫了一篇「實作」的文章:Dynamic Rendering with Rendertron ,文章中也透露了目前「JavaScript (ES6)」版本還無法被 Googlebot(Google的機器爬蟲)所支援,換句話說,若你的網站目前是用 ES6 產生內容,有可能 Google 爬蟲讀起來是一片空白(或者是 Googlebot 是可以轉譯的,但是其他家搜尋引擎無法。)那麼該怎麼辦?這邊我們大略講一下 SSR 的概念,實行上還是需要工程師們依照各家網站的框架,來適當使用 SSR。(Google 部落格中是舉 Rendertron 為例子,大概是因為這也是由 Google Chromium 團隊所主導開發,而 Rendertron 主要支援 PWA)

使用 JS 5 以上版本 Googlebot 有機會讀不到QQ

SSR(Server-side Rendering) 是什麼?
要說什麼是 Server-side Rendering 前,也許我們要從網站的「Rendering(渲染)」說起。網頁就像一個畫布,是由 HTML 語法、JavaScript、CSS 所組成,渲染就是「在畫面上形成圖樣」。HTML 可以想成是人體的骨架、基本組織,CSS 則是衣著或化妝,而 JavaScript 就像一個編劇,他決定什麼時候誰要出場,角色或是燈光要怎麼變化、甚至該怎麼跟台下的觀眾互動。如果你打開瀏覽器,基本上都可以看到由 HTML、CSS、JavaScript 三個元素共同演出的戲劇(也就是網頁上呈現的內容),但是問題來了,因為各家搜尋引擎的 Crawler 對於JavaScript 解析能力,並不是都一樣,甚至不一定都能趕上 JavaScript 快速蓬勃發展的腳步,於是有時就會變成「觀眾看得到完整戲劇」,而「搜尋引擎 Crawler 只看到空蕩蕩舞台」的狀況。

而 SSR 可以拯救這個狀況!該怎麼拯救呢?當來看戲劇的是「搜尋引擎的 Crawler」時——為了避免 Crawler 解析能力落差)——就先在 Web Server 把「HTML、JavaScript、CSS」組合起來成「類靜態」的網頁,再把這個內容丟出去給它看。*註1


*註1 類靜態只是相對於「Client-side Rendering」的說法。實際上這個網頁仍可能依據 Request 往資料庫撈對應資料,頁面內容依然是動態抓資料庫產生內容。

Dynamic Rendering 概念:根據 user agent 不同,有兩種不同路徑
(圖片來源:Deliver search-friendly JavaScript-powered websites, Google I/O 2018)
Dynamic Rendering 運行機制
(圖片來源:Deliver search-friendly JavaScript-powered websites, Google I/O 2018)

我的網站需要採用 SSR 嗎?

根據 John Mueller 在 2018 年 Google I/O(網路開發者年會)的演講,目前的 Googlebot 是使用 Chrome 41 來爬取網頁上的資料,支援的 JS 版本為 ECMAScript 5(ES5),詳細的 Chrome 41 支援哪些技術可以看這個文件。雖然目前 Googlebot 支援 ES5,但是其他搜尋引擎卻有可能不支援;若你的網頁是用Client-side Rendering 來產生網頁主旨內容(主旨內容係指 Navigator、文章內容、產品連結等),若經評估後,網頁的服務類型需要透過搜尋引擎的索引來達到更多曝光的話,則推薦使用 Server-Side Rendering 來幫助搜尋爬蟲檢索(index)你的頁面。

延伸閱讀:

Vue.js Server-Side Rendering Guide | Vue SSR Guide

ReactDOMServer – React

Angular Universal: server-side rendering

安裝完成 SSR 後,該怎麼檢查?

雖然 Google 有釋出「行動裝置相容性測試」工具,但是也是有發生「工具」顯示正常,但是在 SERP(搜尋結果頁面) 上,Google 仍以原始「JSON」的資料當作「網頁描述」的狀況。

這是從搜尋結果頁面觀察到的某個網站,它的部分內容沒有被 Googlebot 正確轉譯

8.PageSpeed Insights 網頁載入速度工具整合 Lighthouse

2018 年 11 月,Google 整合了 Lighthouse 網頁速度檢查,推出新的 Pagespeed Insights (PSI)。這次更新為第五版,主要提供資訊分為 5 大塊:

  • 欄位資料(Field Data)
  • 研究資料(Lab Data)
  • 最佳化建議(Opportunities)
  • 診斷(Diagnostics)
  • 通過稽核項目(Passed Audits)

欄位資料(Field Data)

中文的翻譯有點不直覺,你也許可以叫他「田野調查資料」更容易了解。Field Data 主要採用了「現實世界」在不同的「網路速度」、不同的「瀏覽裝置」條件下的 Chrome 的使用者數據。

這個資料有些前提:

  • 不一定每個網站都有「欄位資料」(資料可能太少了,沒有夠多的田野調查數據可以顯示)
  • 欄位資料每天都會更新,資料有效期限為過去28天
  • 「欄位資料」的結果可能與「研究資料」結果不同(因為「研究資料」中的數值為 Lighthouse 檢測工具的模擬評估值)
  • 欄位資料來源為「Chrome User Experience Report (CrUX)」(的確 Google 一直在用 Chrome 觀察你歐)
PageSpeed 欄位資料(Field Data)區塊

首次顯示內容所需時間(First Contentful Paint,FCP)是什麼?

首次顯示內容所需時間,計算了從瀏覽器送出網址後,透過網路傳送,網頁主機反應送出資料,再透過網路回送到使用者的瀏覽器,瀏覽器開始從 DOM rendering 第一個 bit 的總共花費時間。簡單來說,就是瀏覽網頁的人第一次看到部分頁面內容的經過時間。

首次輸入延遲 (First Input Delay,FID)是什麼?

首次輸入延遲其實就是使用者第一次與頁面互動時,所花費的時間。例如:頁面載入部分畫面後,瀏覽者第一次點擊頁面上的連結後,網頁反應(也就是開始前往連結位址)的時間。為什麼頁面正在載入時,點擊頁面上按鈕或是連結的時候,有時候瀏覽器都沒有反應呢?有時候是因為瀏覽器正忙著解析、執行網頁的其他 JavaScript 檔案,無法馬上執行其他的頁面互動事件,造成塞車的狀況。

延伸閱讀:First Input Delay | Web | Google Developers

為什麼要有欄位資料(Field Data)?

因為網站是給人看的,最終還是要回歸到「現實狀況下」當地使用者的統計資料,才能更客觀知道網頁目前的載入速度對「實際當地的使用者」是夠不夠的,避免拿明朝的劍斬清朝的官。例如我們曾經看過某個外國行動版網站,欄位資料(Field Data)顯示「這個網頁的載入速度較為緩慢」,但是「根據 Lighthouse 分析的研究資料計算得出的速度分數為 91分」,深入了解後才知道目前當地的行動網速基礎建設真的比較慢,就算許多速度優化的項目都有執行了,實際上用戶還是受到網速限制,速度體驗還是較差的。

無論是 FCP 或是 FID,因為這兩個指標都可以增強「使用者加載感知」,FCP 很重要,是因為它可以讓瀏覽者清楚知道頁面「真的正在進行載入」。而 FID 則是想要從「使用者跟網頁互動時的反應速度」,試圖提高使用者體驗;簡單來說,FCP 指標是確保網頁有「良好的第一印象」(載入快),而 FID 指標是確保網頁有提供「流暢的互動」(反應快)。

研究資料(Lab Data)

Lab Data 是什麼呢?簡單來說就是由「Lighthouse」這個實驗室出來的檢測結果!若有看 awoo 在 2018 年所整理的 SEO 趨勢,可以看到我們已經開始在介紹「Lighthouse」這個 Google 大力推薦的開源檢測工具,沒想到 11 月已經全面整合進入 Google PageSpeed 中了,多了許多進步空間!

PageSpeed 研究資料(Lab Data)區塊

研究資料(Lab Data)這個區塊使用 Lighthouse 分析引擎,模擬「行動裝置」載入的過程。他取用了 6 個指標來評估網頁載入的分數(由0-100分),分為三個區間:快速(90分以上)、平均(50-89分)、緩慢(49分以下)。簡單介紹六個指標:

指標

意義

首次內容繪製(First Contentful Paint)

進入網頁後,產生第一個文字或是畫面所花費的時間。這是這重要的里程碑,因為它讓瀏覽者有「頁面真的正在載入」感。

首次有效繪製(First Meaningful Paint)

通常會設定「hero element」,進入網頁後載入完成這個「hero element」所花的時間。雖然每個網頁的「hero element」不一定相同,但基本上是抓取「裝置的初版面出現基本layout、基本layout上的文字也展現出來」的時間,例如出現網頁最上方導覽列。詳細可看參考文件。

速度指數(Speed Index)

繪製網頁內容的速度有多快。Lighthouse 是使用 Speedline 這個模型來決定你的速度指數。

首次 CPU 閒置(First CPU Idle)

瀏覽者首次與網頁互動時,頁面反應時間。

可互動時間(Time to Interactive,簡稱 TTI)

頁面載入程度到可以與它正常互動,過程中所經的時間。根據文件,是採取「頁面反應時間降低到 50ms 以下時,所經過的時間」。

預估輸入延遲(Estimated Input Latency)

網頁載入最忙碌的前 5 秒,預估瀏覽者跟你互動時最長需要等待多久。Lighthouse 會以 50ms 當作評分給分。

 

參考資料:

First Contentful Paint | Tools for Web Developers | Google Developers

User-centric Performance Metrics | Web Fundamentals | Google Developers

Time to First Meaningful Paint: a layout-based approach

Speed Index – WebPagetest Documentation

First CPU Idle | Tools for Web Developers | Google Developers

Time to Interactive | Tools for Web Developers | Google Developers

為什麼要有這麼多指標來觀察網頁載入速度?

根據 W3C 所發佈的「Paint Timing」文件所講:因為載入是一個過程,而非單一時刻完成,所以並無法有單一指標可以代表整個「使用者體驗」,在不同的時間點(moment)所發生的事件,都會影響使用者對於這個網頁的體驗是「快」或是「慢」。所以才需要這麼多指標來檢視網頁載入的表現。其他關於速度優化作法會陸續在 awoo Blog 撰寫專文介紹,就不在這邊多贅述,詳細也可以先閱讀 Tools for Web Developers | Google Developers 手冊,依據「Recommendations」這一部分來做調整方向。

9.確定行動版網站 SEO

這一兩年有非常多 awoo 的朋友來問:awoo 的手機 SEO 怎麼做?有特別針對行動版網站的 SEO 嗎?這邊可以明確的告訴大家,其實無論手機 SEO 或是桌機 SEO,許多規範都是基本共通的。

尤其你的網站是 RWD 響應式設計,無論哪種裝置都是使用同一套網址,更是如此。Google 的 Support 指南目前更是全面為「行動裝置」撰寫,無需太擔心是否行動版 SEO 有其他特別規範。但是,若手機版網頁是使用「獨立網址」或是「動態服務」產生的呢?

動態服務

按照「使用者代理程式」(也就是文章前面有提到的 User-agent),來決定給予不同裝置不同內容。

  • 利用 Vary HTTP 標頭:網站伺服器發送提示表明,在他們決定是否透過快取來提供網頁時,會「將使用者代理程式納入考量」。(Google官方:有效的 Vary HTTP 標頭是我們用來檢索此類網址的其中一種指標。)
  • 經常維護和更新「使用者代理程式清單」:既然動態服務會依照「不同人來看」,給予「不同網頁內容」,那麼當然要經常維護「訪客名單」,已確保不同訪客看到的是最適合他的內容。這邊列出 Google 官方檢索器清單(也就是 Google官方的使用者代理名稱清單)讓大家參考。

獨立網址(有人稱為大小網)

通常手機桌機版同個頁面內容,但是網址不同,就可以歸類在此範圍。例如「m.awoo.com」與「www.awoo.com」或是「www.awoo.com」與「www.awoo.com/m/」。

通常手機搜尋表現出了問題的狀況,常是這種類型的。尤其是新增一個子目錄作為手機版網頁狀況(「www.awoo.com」與「www.awoo.com/m/」),為什麼呢?有可能是 Googlebot(smartphone)不了解哪個網址是適用於手機(畢竟屬於在整個網域的子目錄之下),也可能 Googlebot 一直被導到桌機專用的網址,也有可能在手機版網頁上你並沒有執行所有的 SEO 項目調整。

無論可能原因為何,你可以優先做這些準備:

  • 頁面上使用「rel=”canonical” 和 rel=”alternate” 元素的 <link> 標記」,讓桌機網址指向對應手機網址,手機指向對應桌機網址。
  • 提交「包含手機/桌機對應網址」的 Sitemap
  • 主機端設定「雙向重新導向」(也就是手機網址用桌機開可以自動導到桌機;反之亦然。)(使用 HTTP 重新導向時,盡量使用使用 302 狀態碼)
  • 為手機版網域新增「Search Console」資源,例如新增一個「m.awoo.com」資源,檢查收錄狀況、確保轉址正確。(注意!根據2019/2/27官方部落格更新,現在可以在Search Console中新增「domain層級」的資源囉!)
2019年2月27日Search Console新變動:整體網域的資源

為什麼特別要設定「雙向重新導向」?

我們可以先看 Google 官方說什麼:對於 Googlebot,我們並未指定任何偏好設定,建議網站管理員在決定重新導向政策時,將使用者一併納入考量。最重要的是提供正確且一致的重新導向功能,亦即重新導向到電腦版網站或行動版網站上的相同內容。如果配置有誤,有些使用者可能根本無法看到您的內容。

再來看台灣網路使用者行為:根據 Appier 營運長在 2017 年的報告,51% 的台灣人擁有超過 4 個裝置,⋯⋯台灣、香港、日本新加坡的電腦網路使用量普遍較高,⋯⋯即使在手機、平板上看到廣告,但在填單、註冊或購買,仍多傾向在電腦上完成。

綜合以上,建議可先從「Google Analytics」中觀察,例如網站用戶是否在桌機上轉換比較高?手機版瀏覽量高,但是轉換率偏低?或是直接從產品面向觀察,你的商品服務是屬於要「深思熟慮才下單」的產品嗎?若你歸納出跨裝置互相影響的確很重要,例如,「使用者會從 Line 裡面貼的網址,回家會用桌機瀏覽細看」這樣的消費行為特性,那你一定要設定「雙向重新導向」,保證無論使用者從「哪個網址進入」、「哪個裝置開啟」,都能得到最完美的使用者體驗。

除了行動版網頁用不同技術架設,會有需要特別注意的點,還有什麼項目是手機版網頁 SEO 一定要注意的?

這邊列出幾個大重點,前面的文章已經大致提及:

  • 結構化資料標記
  • 網頁載入速度
  • 行動裝置相容性測試

或許有人會問,那 AMP(Accelerated Mobile Pages)呢?

關於這個項目,我們客觀認為,還沒幫你的網頁施作 AMP 技術前,並不能保證「整體流量提升」或是「轉換率上升」,況且 AMP 存在的目的是為了「加快網頁載入,提升使用者體驗,進而減少跳出提升轉換」,如果網站原本「載入速度快」、「UI/UX設計良好」,那是否有須馬上使用 AMP?我們的想法是:不一定。以下列出正反兩方的論述,可以讓大家去考量成本、評估現況,再來決定是否要使用 AMP:

使用 AMP 優點:

正方代表「決勝電商變革:Yahoo奇摩拍賣成功案例分享」,資料統計來源:台灣 Yahoo 奇摩拍賣

  • 即點即載入:速度真的很快
  • 搜尋「新聞型關鍵字」會在 SERP(搜尋結果頁面)上有 AMP 輪播版位

使用 AMP 缺點:

反方代表「Google AMP帶來更多流量?統計:只有1/3出版商的流量增加」,資料統計來源:美國數位出版分析公司 ChartBeat

  • 前端需重新刻符合 Google 規範的 JS,投入成本高(AMP 對於 JS 規範限制多)
  • AMP 格式的廣告收入不一定跟著提高(因為 AMP 限制了廣告格式)
  • AMP 頁面顯示在 Google SERP 上時,是使用「Google.com」的網域顯示的。例如:https://www.google.com/amp/s/…

我的網站適合使用 AMP 嗎?

  • 考慮產業別(即時新聞型網站,建議必用)
  • 考慮原本廣告提供者是否支援 AMP 規範
  • 考慮投入 AMP 技術成本,甚至可考慮分階段上 AMP
  • AMP 上線後,務必與原本的手機版網頁並行,觀察兩者轉換率差異

最後,雖然與 SEO 沒有直接關聯,但行動版網站的「UI/UX設計」非常重要

手機瀏覽網頁時,載入速度、UI/UX 會大大影響能否在短短幾秒就說動你的顧客,能否多瀏覽幾頁網站,能否對你的品牌產生印象。2018 年 12 月份,Google 發佈了 108 頁的「零售電商 UX 聖經」(UX Playbook for Retail),提出了 25 個零售電商必須注意的 UX 設計原則(甚至還有 Checklist 讓你檢查),如果你的網站一直有 A/B Test 的習慣,真的建議可以好好測試看看,這些設計原則又分在以下 6 個網頁功能:

  • 首頁/Landing Page
  • 導覽列
  • 搜尋功能
  • 產品分類頁
  • 轉換
  • 表單提交優化

參考文件:UX Playbook for Retail

除了零售電商外,Google 也發佈了「旅遊業」、「金融」、「不動產」、「新聞內容媒體」、「獲取名單」的 Playbook,建議可以參考看看:

News (新聞)、Content (內容)

https://services.google.com/fh/files/events/pdfnewsux_playbook.pdf

Finance (金融)

https://services.google.com/fh/files/events/pdffinanceux_playbook.pdf

RealEstate (不動產)

https://services.google.com/fh/files/events/pdfrealestateux_playbook.pdf

LeadGenaration (客戶名單獲取)

https://services.google.com/fh/files/events/pdfleadgenux_playbook.pdf

Travel (旅遊)

https://services.google.com/fh/files/events/pdftravelux_playbook.pdf

大體來說,SEO 作為一個「獲取名單」、「獲得新使用者」的行銷工具,也許單純做 SEO 的優化師,並不需要想那麼遠(而且也的確不是 SEO 的專業範疇),但是好不容易獲取流量了,使用者沒有留下來也是枉然;這也並不是單純做好 SEO 就能全面兼顧到的部分:

每種行銷管道都有他的強項,無論你決定在不同階段要怎麼打、用哪種行銷手段幫助你,重點就是「獲取流量/名單」-> 「建立對品牌信任」-> 「購買(轉換)」->「獲取忠誠戶資料」 ->「再行銷,刺激繼續回頭」

首先「將銷售漏斗開最大」(SEO自然流量或廣告付費流量),再「有效利用這些流量」,踏實的做好每個顧客歷程階段、好好運用不同的網路行銷工具,最終才能讓商業如飛輪生生不息滾動起來!如果只注意其中一個環節,或是單一行銷管道,等於將雞蛋放在同一籃,風險大,也可能浪費得來不易的流量。

如果對其他行銷管道有興趣,或是對於該怎麼利用數據分析綜合使用行銷工具,建議可繼續閱讀:

Google Adwords > 為什麼要做網路行銷、數位廣告?五大理由告訴你!

Inbound Marketing > 電商行銷人不可不知的Inbound Marketing

Email > EDM是垃圾(Spam)還是黃金?來了解E-mail行銷怎麼做吧!

A/B Testing > Google Optimize安裝教學- 免費又好用的A/B Test工具!

數據分析>開啟網站分析之門-學習Google Analytics吧

歡迎在留言告訴我們的想法,一起來討論吧!

下載完整版2019 SEO 趨勢 / 策略,收藏最詳盡的SEO趨勢與因應方法!

更多關於數位行銷、SEO、網站分析,歡迎

訂閱awoo成長駭客行銷誌


更多關於數位行銷、SEO、網站分析,歡迎

訂閱awoo成長駭客行銷誌