SEO 網站優化 SEO 趨勢與應用

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

awoo Intelligence

2019-02-21

(更新日期: 2024-02-07)

2019 年的 SEO 除了受機器學習技術、IoT（物聯網）產業發展的影響，另外也受到了大環境考驗──「假新聞漫天飛，落入有心人士手中操弄」──對於這樣的風潮，2019年搜尋引擎演算法有什麼變動趨勢呢？讓我們從回顧2018年的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 前幾名的，通常都是政府、銀行、醫院的官方網站，或是維基百科、大型媒體網站。

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

健康知識網站

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

投資理財網站

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

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

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

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

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 地圖」查詢時，你的商家也可以清楚顯示在上面。

Knowledge Panel（知識面板）

Knowledge Panel 通常會在使用者搜尋「品牌名相關詞」時出現，在消費者購物歷程中，可能會出現在「想要更近一步了解這個品牌」這個階段，所以能否得到信任感是一大重點。而 Knowledge Panel 通常還會因為你是「當地商家」還是「大品牌（Google 認為）」而有不同樣式（除了大品牌，另外地標名稱、人物、組織⋯⋯等不限地區限制的物件，也會出現這種樣式。但本篇文章先聚焦於「商業店家」，故略不提其他情況。）

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

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

Carousel（輪播版位）

目前常見的輪播版位有 *註1：

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

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

我的網站有可能在 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 結構化資料」。

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

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 存在的意義，就是製造一個讓 Google 可以直接與網站經營者溝通的平台。新版 Search Console 與舊版最大差異：

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

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

舊版 Search Console		新版 Search Console
搜尋結果呈現方式	結構化資料	強化 *註2
	複合式資訊卡	強化 *註2
	資料螢光筆	還未支援 *註3
	改善 HTML	無
	加速行動版網頁	強化＞AMP
搜尋流量	搜尋分析	成效
	連至您網站的連結	連結
	內部連結	連結
	人為介入處理	安全性及專人介入處理＞專人介入處理
	指定國際目標	還未支援
	行動裝置可用性	強化＞行動裝置可用性
Google索引	索引狀態	索引＞涵蓋範圍
	封鎖的資源	網址審查（個別網址）
	移除網址	還未支援
檢索	檢索錯誤	1. 索引＞涵蓋範圍（網站整體）2. 網址審查（個別網址）
	檢索統計資料	還未支援
	Google 模擬器	網址審查（個別網址）
	robots.txt 測試工具	還未支援
	Sitemap	索引＞Sitemap
	網址參數	還未支援
安全性問題		安全性及專人介入處理＞安全性問題
Web Tools		無

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

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

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）

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 往資料庫撈對應資料，頁面內容依然是動態抓資料庫產生內容。

我的網站需要採用 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）你的頁面。

安裝完成 SSR 後，該怎麼檢查？

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

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 觀察你歐）

首次顯示內容所需時間（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 中了，多了許多進步空間！

研究資料（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，許多規範都是基本共通的。

延伸閱讀：Mobile SEO必學！行動版網站健檢Search Console幫你做

尤其你的網站是 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層級」的資源囉！）

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

我們可以先看 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 個網頁功能：