對於不太認識我的讀者，我是超過10年、自有網站(本站)，且仍然持續更新的部落客。

也建議先看一下我之前的文章 AI時代下SEO的全新遊戲規則，了解我對這個時代 SEO 與部落格的看法。

回到 num=100 這個事件，本來我想寫一篇 Threads 短文就好，結果越寫越發現這個題目不小，背後隱含的事情很多。

所以我決定將這個題目寫在部落格。

首先，什麼是 num=100？到底發生什麼事？

本來第三方SEO或流量評估工具，可以向 Google 發出 API 請求，得到 Google 對特定關鍵字詞的搜尋結果。

這些第三方工具再用撈回來的資料，做各種分析，提供服務給他們的用戶。

長期以來 (至少10幾年以上)，這些第三方工具發 API 請求時，加上 num=100 參數幾乎是一個標準做法。也就是一次可以撈特定關鍵字詞，搜尋結果的前100筆排名。

這裡一定要提一下，num 這個參數從未出現在 Google 正式文件。也就是這麼長的時間，Google 一直在「默許」外部使用 num 參數。

為什麼以前 Google 要默許外部使用 num 參數？

大家想事情一定要從商業的角度來分析。

Google 默許第三方工具使用 num=100。第三方工具每撈一次資料，這 100 筆網頁資料都會各增加一次「曝光」(impression)。

也就是網站主看到的「曝光」數據，會包含上述「撈資料」的次數。當然 Google 也知道這個情況，彼此哄抬，數據越多越好，大家都得利。

網站主看到曝光數據多 (高興)，第三方工具可以撈資料 (高興)，大家越來越依賴Google (高興)。所以為什麼 Google 過去要默許這件事。

大家要了解的是，很多數據是機器查詢所產生，並非真人查詢 (就是水份、泡沫的意思啦)。這部分我下方文章會再提及。

為什麼現在 Google 要拔除 num=100？

因為現在是 AI 時代，很多公司都在訓練大語言模型 (LLM)。要怎麼訓練？當然從 Google 一次拿100筆資料是最快的啊。

Google 當然也不可能一直讓別人白用：用自己的搜尋結果去養對手的 AI 模型。

於是終於移除了 num=100 這個參數，但仍然接受外部API請求，現在一次請求只能拿10筆資料 (也就是排名前10的連結)。

不能用 page=1, page=2 分批去拿資料嗎？

有工程背景的朋友，大概第一個問題是：不能用 page=1, page=2 分批去拿資料嗎？

確實可以分批拿資料，但不是用 page 參數，而是 start 參數。start=0 拿第1~10筆，start=10 拿第11~20筆，以此類推。

很明顯，100筆要 request 10 次，而且每一次拿到資料後，要分派給後端伺服器處理。整個運算量大概是倍數增加。

我們就以100筆要 request 10 次這個數量去評估，Google 當然也會偵測，某某主機一直發送這樣的 request pattern 過來。

當看到類似的 request pattern，Google當然會想辦法封鎖，它不會讓外部廠商一直免費撈資料吧 (而且很多是對手陣營的AI)。

即使分批去撈資料還是有問題

即使用 start=10 (第11~20筆), start=20 (第21~30筆) 這樣去撈資料，還有一個根本的問題：

Google 搜尋結果排名是隨時變動的。你時間點A 拿到第1~10筆資料，時間點B 拿到第11~20筆資料，這兩組資料「不是」直接可以銜接起來的。

(時間點B 的網站排名又重新排序了。)

也就是現在第三方 SEO 工具，對第10名以後的網頁，精準度是很低的。外部廠商頂多藉由自己的大數據和演算法，評估出第11~20名，但20名以後的網頁，就真的很難評估了。

SEO的可操作空間降低

過去，一些 SEO 顧問宣稱可以讓「第3頁以後」(第20名以後) 的網頁，通過技術手段讓排名往前。

但隨著數據難以追蹤，要去操作第10名或20名以後的網頁，可行性變得極為困難。因此所謂「SEO顧問」要去操作和報價的動機，將會大幅減少。

換句話說，現在SEO的策略應該是一開始就寫一篇對讀者有用、Google也樂於推薦的文章，而不是用「技術手段」將網頁操作到前20名。

其實我是滿高興的

我創業超過10年，因為公司業務是幫客戶建置網站系統，這麼長的時間我看過太多「SEO顧問」了。

(特別括號「SEO顧問」大家應該知道是什麼意思。尤其我本身是10幾年的部落客，有沒有一種可能，長時間經營的部落客比這些「顧問」還懂 SEO。)

這些SEO顧問提供很多「技術手段」給網站主(客戶)，用三寸不爛之舌給網站主很多想像空間，然後將品牌方和網站工程方翻天覆地一頓。

最後成效不佳或成效難以評估，這些顧問拍拍屁股走了。這樣的案例我真的看過太多了。

移除 num=100 對網站經營者有什麼影響？

聊完了第三方SEO工具和所謂的 SEO顧問。移除 num=100 對網站經營者有什麼影響？

如本文上方提到，移除 num=100 降低了第10名之後、第20名之後網頁曝光的「水份」(機器查詢的次數)。

所以網站主看一下你的 Google Search Console (以下簡稱GSC)，2025年9月中之後曝光量是不是有下降。

(台灣9月底到10月連續假期很多，網站主評估時自行決定是否要排除這些日子。)

一般來說曝光量會下降，重點是下降多少？如果你降的少，恭喜，在這次重新洗牌中，你仍然屹立不搖。證明你過去的路線可能是對的。

再來是 GSC 後台的平均排名。因為第10名之後、第20名之後的網頁曝光降低，也就是排名在後的選手減少了。你的平均排名應該要上升才對。

再來是點擊次數。第三方工具撈第10名之後資料變得困難，應該對網站的點擊次數沒有直接關係。當然，現在等於是重新洗牌，點擊數還是會被影響。

我覺得不用追根究底。一樣，直接看你的 GSC 後台，點擊數有沒有降？如果有，降多還是降少？

(再次提醒，如果有連續假期的日子，評估時自行決定是否排除。)

排名在後的網頁現在難以被 AI 引用

請讀者回顧一下上方「為什麼現在 Google 要拔除 num=100？」段落。

Google 移除 num=100 就是為了要擋 AI 爬蟲。

對網站經營者來說，第10名之後、第20名之後的網頁現在難以被 AI 收錄了 (ex: ChatGPT, Perplexity AI, 等)。

AI時代有一個新名詞 GEO (Generative Engine Optimization)，指的是網站現在的目標是如何讓生成式AI引用。

也就是現在第10名之後、第20名之後的網頁難以被 AI 引用了。這個影響不只是曝光的降低，被 AI 引用減少也會影響 Google 排名。沒錯，這是一個迴圈。

排名在前的網頁 → AI 容易收錄 → AI 引用 → 再影響 Google 認為你是好的網頁 → 排名往前。

講白話就是現在是：強者越強，弱者越弱。或是強者不動，弱者越弱。

也符合我之前文章提到：AI時代的SEO，淘汰了很多「專門」用 SEO 技術獲取流量的網站。

移除數據水份是健康的

上方「為什麼以前 Google 要默許外部使用 num 參數？」段落提到：很多數據是機器查詢所產生，並非真人查詢 (就是水份、泡沫的意思啦)

更別忘了各家 AI 模型訓練的過程，都會撈取大量的 Google 搜尋資料。每一次撈取都算一次曝光。

可想而知從生成式AI開始風行，網站曝光數據的「水份」有多少。

移除 num 參數，除了網站主和品牌方可以更了解「真人」的數據，減低機器爬蟲帶來的水份。

有「水份」就代表有可操作空間，現在排名的可操作空間也大幅降低了。

結語

本文開頭提到，建議讀者先看一下我之前的文章 AI時代下SEO的全新遊戲規則，了解我對這個時代 SEO 與部落格的看法。

包含 E-E-A-T 原則，包含一些心法與觀念，很高興在這次 num=100 事件後仍然成立。很多時候如何驗證你的心法與觀念是否正確，就是經由一次一次的事件來驗證。

這次 num=100 的事件之後，如果你的網站曝光量沒有大幅減少，那恭喜你，也許你的路線是正確的。

我之前文章提到：AI時代的SEO，淘汰了很多「專門」用 SEO 技術獲取流量的網站。

這次 num=100 的事件讓網站排名的可操作空間大幅降低了，對用「技術手段」爭取 SEO 的網站又是一次打擊，也證明了我當初的觀察與想法。

對網站經營者來說，尤其對長期經營又懂 SEO 的作者來說，請仔細想想，現在這個大環境反而是有利的。

首先我想直接切入我想寫這篇文章的動機。

大家應該都同意，這個時代社群跟短影片是顯學，部落格並不是顯學：回收慢、不確定性高、需要長時間的付出。

但我要表達的是，不是全部的內容都適合擺在社群。例如：有的內容本來就沒有漂亮的圖片或影片，有的內容本來就不需要立即得到網友的共鳴。

例如，這篇文章就是這樣的內容。而且我希望這篇文章是長久而穩定的流量，不像社群的時間軸概念，兩天後就好像不曾po過一樣。

所以這篇文章我決定擺在部落格，然後貼連結到社群。

AI Overviews (AI摘要) 對網站流量是一記重錘

AI Overviews (AI摘要) 大幅影響網站的流量，這應該是不爭的事實。

例如你 google「東京拉麵10選」。你的搜尋結果頁就會出現一個區塊「AI摘要」，直接將 Google 整理好的10家拉麵顯示出來。

而且這個「AI摘要」是在大部分的搜尋結果上方。可想而知，大部分使用者看到結果了，不會再往下拉。

同理，google「台北最新開幕」「台南一日遊」等 (讀者可以自己發想)，太多的搜尋字詞都會帶出AI摘要。

因此，很多網站的流量都被大幅影響 (幾十趴的衰退)。特別是「專門」用 SEO 技術獲取流量的網站，大概衰退最多，甚至已經消失了很多。

這類「專門」用 SEO 技術獲取流量的網站，不只受AI摘要影響，Google搜尋核心演算法的公開文件，也都明確指出不鼓勵這類網站。 

大家應該也發覺，201x年很多的「內容農場」，消失了很多，因為現在無利可圖了。

那傳統 SEO 還要不要做？

我把關鍵字的設定、文章 title 的文案、meta description、<h1> <h2> tag 的檢查等，暫時稱之「傳統SEO」。

傳統 SEO 還要不要做？當然要。而且現在競爭這麼激烈，傳統 SEO 已是一個基本。

但以這個時代來說，傳統 SEO 只是你基本功的一小部分，並不是目的。

我不建議太糾結在「傳統SEO」，我反而建議你創作保持品質、真誠，過程保持輕快，這樣比較好。至少心情愉快，長期的文章寫作才進行的下去。

寫文章的根本目的是產生高品質、對讀者有用的內容，而且兼顧易讀性。如果你寫文章的目的是快速回收、快速變現，這個時代可能不是這樣。

Google 的 E-E-A-T 原則

Google近幾年一再提到 E-E-A-T 原則，到撰文的現在 (2025年7月) 仍然是。

甚至在AI大量生成內容的今天，Google比以往任何時候都更重視 E-E-A-T。

先說明什麼是 E-E-A-T 原則：Experience (經驗)，Expertise (專業)，Authoritativeness (權威)，Trustworthiness (可信度)。

• 「經驗」就是你的內容是你親自體驗、第一手的經驗。
• 你的文章是不是在某些領域，有「專業」的內容，有個人獨特的洞見。
• 作者本身在某個領域是不是有「權威性」。
• 這個網站與作者是不是夠真實，有「可信度」。

為什麼要提 E-E-A-T？

因為這就是現在 Google 評價一個網站的標準：你的內容有獨特的經驗，你在某些領域是專家、很專業，你和你的網站很真實、可信賴。

SEO 的遊戲規則已經徹底改變。早已不是在文章中塞多少關鍵字，或是跟他站建立多少反向連結 (早年有一個說法是「交換連結」)。

什麼是GEO？要如何看待GEO？

AI時代來臨，出現了一個新名詞 GEO (Generative Engine Optimization)，指的是網站現在的目標是如何讓生成式AI引用。

我先提供一個專家的公開談話。2025年8月底的 WordCamp US 大會上，Google搜尋的主管 Danny Sullivan 說「Good SEO is good GEO.」

他的意思是，照著你原本好的觀念與習慣，寫對讀者有用、友善的內容，把握住 E-E-A-T 原則，這就是一個好的 GEO。

對讀者有用的本質沒變，並不需要做一些特別的事(也沒有這樣的事)，去達成 GEO。

這跟我的理解相符，現在Google搜尋的主管，公開直白地講出來了。

把握 E-E-A-T 原則，寫出真實、專業、對別人有用的內容，自然你的 GEO 就會好。

請善用AI輔助你寫作

請正確使用AI，例如 ChatGPT 或 Google Gemini 等工具協助你寫作。

我直接講重點：AI輔助，真人寫作。

你可以使用 AI 工具發想新文章要寫的主題，生成文章大綱，或是做一些市場或社群調研，等。

善用 AI 工具已經幫了大忙，但絕對不能將 AI 的產出直接複製貼上。把自己經營成內容農場，沒有任何意義。

結語

SEO 的遊戲規則已經徹底改變。請再想一遍上面的 E-E-A-T 原則：你是誰？你的風格與專業是什麼？你和你的網站是否可信任？

最後想給有心經營部落格的朋友們一些信心。

如果你喜歡文字寫作，但沒有很想每天去迎合社群演算法：社群式的語言、漂亮的圖片、吸睛的影音。

部落格類型的自媒體，是可以讓你好好靜下來，寫一篇自己喜歡的文章。而且如我文章開頭提到，很多內容本來就不需要社群式的語言，立即的吸睛。

就如同這篇文章，我選擇擺在部落格。我希望這篇文章是長久而穩定的流量，我沒有要立即在社群上吸引眼球、得到共鳴。

還有一點值得高興的是，我文章中也有提到：AI時代的SEO，淘汰了很多「專門」用 SEO 技術獲取流量的網站。

對一些部落格作者來說，現在這個大環境反而是有利的。

接續閱讀：Google 拔掉 num=100 造成SEO數據大地震！不只對AI爬蟲築起高牆，更是SEO生態的再次洗牌

從 Chrome 85 開始，在 Android Chrome 開啟網頁，長壓網頁上的一個連結，如果這個連結的目標網頁是所謂的快速網頁的話，長壓後跳出的小視窗上面會有 “Fast page” 的字樣。

Google 在幾個月前公布，他們以後會以 Core Web Vitals (名稱是Google取的，中文可以翻譯為「網站使用體驗核心指標」) 作為評估網頁品質的一套規範。Core Web Vitals 的細節讀者可以暫時不用研究，大概是包含了網頁的載入時間，行動裝置上的版型，和使用體驗。一個網頁是否為快速網頁，就是 Google 依照 Core Web Vitals 來判斷的。

上方連結的原文中有一段

“Fast page” labelling may badge a link as fast if the URL (or URLs like it) have been historically fast for other users. When labelling, historical data from a site's URLs with similar structure are aggregated together. Historical data is evaluated on a host-by-host basis when the URL data is insufficient to assess speed or is unavailable, for example, when the URL is new or less popular.

快速網頁的判斷是長期累積的資料分析，也就是說，要長期都是快速網頁，才會有 “Fast page” label。如果是新網頁、或是流量不夠的網頁，Google 會依照同一網站類似網頁的數據，來判斷新網頁/流量不夠的網頁是不是快速網頁。也就是說，會有一個全站分數。

Chrome 85 (Android版) 開始有標記快速網頁的功能。如果讀者是 Android 手機，看一下手機裡 Chrome 的版號。也可以長壓任何一個 Wikipedia 連結，測試看看 “Fast page” label 有沒有出現。

Again，工具的使用是其次，我們要了解的是 Google 的態度和方向。目前看來 Core Web Vitals (網站使用體驗核心指標) Google 是會繼續進行下去。這次的 “Fast page” label 網頁載入速度當然也是 Core Web Vitals 的一環，行動版網頁的使用體驗和速度，仍然是 Google 關注的重點。

larry 覺得這個問題是典型的看似簡單，但真要探究下去，又很有內容的題目。本篇文章就來跟讀者分享一下 larry 對這個問題的看法。

網頁的流量來源不一定是自然搜尋，也可能是其他來源

網頁的流量來源不一定是自然搜尋，也可能是其他來源，例如社群媒體。

這可能是這一題最簡單快速的答案。GA 的後台 → 行為 → 網站內容 → 所有網頁。「次要維度」選來源/媒介。它會幫你把網頁依照自然搜尋、社群、廣告等不同來源，分不同筆資料列出來。

因為 Google Search Console，或 GA 後台的 Search Console，只管自然搜尋來源的流量。所以我們可以看一下有興趣的網頁是不是有來自社群的流量、廣告的流量，還是其他網站 referral 的流量。

Search Console 只管網頁是到達頁的流量，整體流量還是要看GA

Search Console 只管一個網頁是 1) 自然搜尋 2) 到達頁，以上兩者同時成立的流量。

Search Console 只管自然搜尋的流量這很簡單，大家都知道。但還有一個條件是到達頁，就 larry 的經驗來講，很多朋友還不那麼清楚。

也就是，例如有網頁 A，B，C。網頁A、B 的 SEO 很好，流量很高，而且網頁A、B 都有站內連結到網頁C。因為網頁C 符合用戶某方面的需求，所以很多用戶從網頁A、B 點到網頁C。

此時網頁C「並不是」到達頁，Search Console 裡網頁C 的資料會很少，但 GA 裡網頁C 的流量會很高。

換句話說，單看 Search Console 的話，只能看到一個情境裡片面的資訊。

也要了解 GA 的歸因模式

GA 預設的歸因模式為最終非直接點擊 (Last Non-Direct Click)，流量來源的判定也是用最終非直接點擊 (參考文章：多管道程序)。

例如，一個使用者自然搜尋 (organic) 點進去你的網頁A，這個使用者將你的網頁A 存到書籤，隔天從書籤點開網頁A，此時網頁A 的兩次點擊來源都是 organic。

雖然第二次是從書籤點開網頁A，流量來源應該記為 direct，但因為最終非直接點擊的歸因模式，第二次點擊來源還是記為 organic。

只有當 GA 真的找不到該使用者之前的點擊來源時，才會記為 direct。

回到原題：SEO普通但流量卻不錯。當你有這樣的網頁時，看一下主要流量來源是自然搜尋、社群、還是廣告。想一想如果多種管道都有使用者來，最終非直接點擊會怎麼歸因。

搜尋引擎不是只有 Google

當然以目前來講，搜尋引擎 Google 是大宗，但別忘了還有其他搜尋引擎，例如 Yahoo、Bing。

在 GA 的後台 → 行為 → 網站內容 → 所有網頁。「次要維度」選來源/媒介。看一下你的網頁，自然搜尋的來源，都是 google/organic 嗎？

任何我們能叫得出名字的搜尋引擎 (包含 yahoo, bing, baidu)，用戶數都是非常高的。也許你的網頁在其他的搜尋引擎 SEO 還不錯，而帶來流量。

將有興趣的網頁設定為「目標」

將有興趣的網頁設定為「目標網址」類型的目標，然後在 GA 後台 → 轉換 → 目標 → 反轉目標路徑，就可以看到使用者都是從哪幾個站內網址，到達這個目標網址 (參考文章：站內搜尋 & 目標流程)。

另外讀者也可以參考不同目標流程，同一目標網址的設定，來追蹤使用者的站內行為。

例如目標網址同樣是「結帳完成頁」，不同的目標流程可以追蹤使用者，是經由站內優惠活動的 landing page，完成購買。還是經由站內的某一篇文章，完成購買。

結論

如文章開頭所敘，這個問題是典型的看似簡單，但真要探究下去，又很有內容的題目。它沒有所謂的標準答案，因為每個網站的情境都不一樣。

文章內容提到的幾點，都是讀者可以參考，來看這個問題的角度。

有心經營的部落客，都很在意自己文章的 SEO (搜尋結果排名)，因為這就是自然搜尋的流量來源。所以常常會 google 一下幾組關鍵字，看看今天自己的文章排名如何。

larry 也經歷過常常 google 自己設定的關鍵字的階段，但其實 SEO 「不是」經營部落格的主要指標。這有點像是特效好的電影不見得好看，場面大的電影不見得好看，這些都不是一部電影好不好看的指標。

那什麼是經營部落格的本質？

第一，搞清楚自己的角色，你是誰？別人認為你的定位是什麼？哪些領域是你真的有獨到的經驗和看法？注意「獨到的經驗和看法」。

第二，搞清楚你的讀者是誰。可由 GA 數據猜想你的讀者是那些族群，配合第一點所敘你原有的調性，調整你撰文的架構和走向，希望能找到你和讀者的共鳴。

過度「陷入」SEO 還有一個問題，如果你是部落客A，每天一直搜尋一組關鍵字，看是否部落客B，部落客C 的文章排名超過你。因為沒有人能保證一篇文章，每天的搜尋排名在哪，在這情況下，你不是在跟部落客B、部落客C 競爭，你變成是在跟 Google 競爭了。

SEO 只是一個工具，不是你經營部落格的本質，讀者可以想一想我這篇文章要表達的意思。糾結於錯誤的指標，不但消耗自己的心力，經營的方向也會走偏。

前幾天 Google WebMaster 官方部落格介紹了改善網站在搜尋結果頁顯示的幾個方法
https://webmasters.googleblog.com/2019/09/more-controls-on-search.html

一樣，我們要先清楚翻譯，snippets, 或是 text snippets, 翻成「網頁摘要」。
上面 WebMaster 文章引用了 Google 另外一份文件
https://support.google.com/webmasters/answer/35624

這份 35624 號文件提到搜尋結果頁的網頁標題和網頁摘要是由 Google 產生的，所以搜尋結果的網頁標題有可能跟你網站真正的網頁標題是不同的！

如何寫好網頁標題的原則在 35624 號文件有，讀者自行研讀，我們這邊不重複。重點是 35624 號文件提到有兩個方式可以被動的建議 Google 產生你想要的網頁摘要：

1. 結構化資料，也就是複合式搜尋結果。
2. 中繼說明標記 meta description

有這些背景知識之後，我們回到上面 WebMaster 文章。它舉例如果找食譜，圖片或評分會比 text snippets 重要。如果找音樂會，event 就比其他元素重要。而以上皆可由結構化資料來達成。

到此為止，讀者應該可以感覺到結構化資料非常重要。回到標題，這次 Google 提出兩種新方法來標記 html (也就是被動的建議 Google)

1. Using robots meta tags

例如 WebMaster 文章提到的範例

<meta name="robots" content="max-snippet:50, max-image-preview:large">

有 max-snippet, max-image-preview 等可以設定。Google 有定義，規格請自行搜尋。WebMaster 文章提到

“Preview settings from these meta tags will become effective in mid-to-late October 2019 and may take about a week for the global rollout to complete.”

2019十月中，十月底這個方式才會開始生效。

2. Using the new data-nosnippet HTML attribute

防止部分 html 產生 snippets, 如 WebMaster 文章提到的範例

<p><span data-nosnippet>Harry Houdini</span> is undoubtedly the most famous magician ever to live.</p>

可以將某一段 html 標記為避免產生 snippets. 這個方式會在今年稍晚 (later this year) 開始生效。

最後 WebMaster 文章附註，結構化資料「不會」被上面兩個方式 (meta robots 與 html data-nosnippet) 所限制，可以想成結構化資料造成的效果是在上面兩個方式之上。

結論

本篇文章附的 Google 35624 號文件很重要，是觀念上的釐清。結構化資料也很重要，Google 一直在推，在演進。至於這篇 WebMaster 文章提到的兩個新方式，larry 覺得參考就好，原因 1) 實務上用不太到 2) 還不知道什麼時候生效。但這篇 WebMaster 文章的第一二段的一些觀念可以參考。

Google於 4/16 發布的這篇官方部落格文章，larry認為是精彩而重要的
https://webmasters.googleblog.com/2019/04/instant-loading-amp-pages-from-your-own.html

首先，Google 在官方 Webmaster blog 多次提及 AMP 網頁。Google 「並沒有」說支援 AMP 的網頁搜尋結果排名會上升，但多次提及 AMP 網頁，各位老闆可以自行推敲 AMP 網頁是否重要。這篇官方部落格裡有一句

“We believe that privacy-preserving instant loading web content is a transformative user experience”
翻譯：我們相信同時考量到隱私權的快速載入網頁，是一種革命性的使用者體驗。

所以大家可以知道，google對於快速載入網頁這一路會繼續做。再來他提到 AMP 網頁的代價是 (先不論業主所花的工程 cost) URL 裡總是 google.com/amp 開頭，再接你的網址名稱，例如 https://www.google.com/amp/s/your_site.com/your_page_address

google.com/amp 開頭這件事已經有很多客戶/用戶反應 (為什麼不是他們的網址名稱開頭)。在這篇官方部落格 Google 提出一個 solution: Signed Exchange

Google AMP 官網上有一句講得比較清楚
https://blog.amp.dev/2018/11/13/developer-preview-of-better-amp-urls-in-google-search/

“Allow the browser to treat a document as belonging to the publisher's Origin. This allows a publisher to use first party cookies to customize content, execute service workers, and measure analytics.”

他的意思就是說，即使來源 (origin) 是 google.com/amp, 這項新的技術可以讓瀏覽器認為目前這張網頁來源是業主本來的網址 (因為 Google AMP 是抓業主的網頁去 cache, 所以現在來源是 google.com/amp)

舉例來說，業主的 AMP 網頁收錄到 google 後是網址A, 業主的原網頁網址是網址B. 如果網址A和網址B是 Signed Exchange, 當使用者 request 網址A, 瀏覽器顯示的會是網址B, 並且同時網址A的 cookie 和 js code 等都還在運作。

目前 Signed Exchange 技術還在 developer preview 階段，瀏覽器支援也不普及 (尤其是非 chrome 的用戶)。但 Google 往這一路的方向是確定的，實作上 larry 是建議讀者先等這項技術成熟後，再花 cost 實作。

本篇摘錄 Google Webmaster Blog 兩篇重要的文章：
行動優先索引 mobile-first indexing
https://webmasters.googleblog.com/2018/12/mobile-first-indexing-structured-data.html

新版 Search Console 計畫中的幾項功能
https://webmasters.googleblog.com/2019/01/focusing-on-new-search-console.html

行動優先索引 mobile-first indexing

Checking for mobile-first indexing

Google 兩年前就開始「行動優先索引」，到目前為止 (上面 Webmaster Blog 日期是 2018/12/19)，Google 行動優先索引了世界上超過一半的網頁。

Search Console 的 網址審查 (URL inspection tool) 可以檢查你的網頁是否已經是行動優先索引。輸入你的網址後 -> 涵蓋範圍 -> 檢索代理程式，看是否為 Googlebot 智慧型手機 (Googlebot smartphone)

Missing structured data on mobile pages

如果你的網頁在桌面版有 structured data，在手機版沒有，Google 現在又以手機版為準，structured data 在收錄時有可能會遺失。

Google 建議確認你的網站手機版的 structured data 仍然存在 (使用手機模擬工具)。

Missing alt-text for images on mobile pages

確認你手機版網頁的 image alt text 仍然存在。

新版 Search Console 計畫中的幾項功能

Crawl errors in the new Index Coverage report

“it's normal that Google crawls URLs which don't exist, it's not something that needs to be fixed on the website.”

這句滿重要的：Google 「不一定」會照著你的網站架構去爬網頁。
(相關文章：Google推出改善網站在搜尋結果頁顯示的新方法)

舊 Search Console Crawl Errors (檢索錯誤) 報告將被移除，將會持續優化新 Search Console 涵蓋範圍 menu 對於 issue 的辨認與處理。

Sitemaps data in Index Coverage

新版 Sitemap menu 會強化影像和影片的資訊。
在涵蓋範圍 menu 將可以選擇你要使用哪一個 sitemap file.

Using the URL inspection tool to fetch as Google

網址審查工具將會顯示更多資訊 HTTP headers, page resource, the JavaScript console log, and a screenshot of the page

網址審查工具將不只是查詢，更可以要求重新處理網頁。

User-management is now in settings

使用者管理在左側 menu「設定」。

Structured data dashboard to dedicated reports per vertical

去年已經新增了幾個複合式搜尋結果 (Rich Results) 類型的 menu (Jobs, Recipes, Events and Q&A)，會持續再新增複合式搜尋結果類型。

不支援複合式搜尋結果的 structured data 將不會再出現在 Search Console.

Google 官方部落格公佈了新版 Search Console 即將上線，目前還不能跟目前運行的版本直接切換。下方是新版測試版的位置，目前是沒辦法新增資源 (如果知道怎麼新增資源的大大麻煩告知一下 larry)
https://search.google.com/search-console
(後來接到了新 Search Console beta 版的測試邀請 ~ )

優化的功能除了介面以外，主要包含這四大塊

• Search performance (成效報表)
  https://support.google.com/webmasters/answer/7576553?hl=zh-Hant
  重點是它將會保留 16 個月的資料 (目前是 90 天)
• Index Coverage (索引涵蓋範圍狀態報表)
  https://support.google.com/webmasters/answer/7440203?hl=zh-Hant
  a. 將會有一個 Page details 欄位協助你診斷每個頁面索引的問題。
  b. 當你需要請其他部門或外包廠商看問題時，將會有一個 share button, 方便你把問題 share 給可以修正的人。
  c. 當你修正了索引的問題後，有一個 validate fix button, 可以馬上驗證你修正的結果如何。
  d. 本報表 (Index Coverage) 非常適合有提交 sitemap 的網站。
• AMP status (AMP 狀態報告)
  https://support.google.com/webmasters/answer/7450883?hl=zh-Hant
• Job posting (徵人啟事狀態報告)
  https://support.google.com/webmasters/answer/7552505?hl=zh-Hant

以下是 larry 歸納的幾個亮點

• 全新的 UI (這真的是要改了
• 成效報表保留 16 個月的資料。
• 更容易的 debug 有索引問題的網頁。
• Google 持續在推 AMP 網頁，既然 Google 在推，對 SEO 會有什麼影響，各位懂的。
• Google for Jobs 台灣有服務，但台灣似乎沒什麼人在用，所以這持保留態度。