SEO電子報第十二期 – 2020.07.01~2020.07.15

SEO電子報第12期

這期電子報的內容滿多不錯的資訊,Google新版的”How Google Search Works” 我覺得是每位SEO都該讀的東西;另外第三集的Podcast可以聽到John怎麼用Neural Network來形容排名系統,相當值得細細品味。

如果你還沒訂閱,這邊幫你表格移上來了! 臉書上越來越少內容的部分原因就是因為我把心力都放到Email上了,不想錯過的話就交出你的電子郵件信箱吧~


文件更新 – Google搜尋的運作方式

Google有一個網頁在講”How Google Search Works”。有人注意到這份文件上的內容最近被修改了許多,雖然沒有什麼太驚為天人的新訊息出現,但可以從Google一些用詞的變化看出他們試著釐清的問題。

如果你沒從來沒讀過這個網頁,建議一定要看看,可以幫助你打好基礎觀念;如果你是比較資深的SEO人員,可以看看這篇Google文檔修改前後的比較整理,從一些新增/刪除/修改的部分會發現Google對外說明SEO上有趣的演進。

其中我最感興趣的Google新增了一段在解釋「Document」、「URL」、「Page」、「Version」的不同,這和第二集podcast中Gary解釋document的部分相呼應。這幾個名詞的不同拿去問專業的SEO人員可能也不一定能夠解釋的好,值得一讀!


結構化資料測試工具將被取代

Structured Data Testing Tool (SDTT, 結構化資料測試工具)將終止服務,取而代之的是Rich Results Test(RRT, 複合式搜尋結果測試工具)。

兩者最大的差別在於,SDTT可以測試任何的schema markup,不管在搜尋結果上有沒有任何外觀的改動,舉例來說,schema裡有個”VideoGame“的標記,網頁加上這個標記並不會造成任何搜尋外觀上的不同。這一頁可以用SDTT來看代碼是否安裝正確,但在RRT上只會顯示不符合條件。

連結: 官方公告 / 結構化資料測試工具 / 複合式搜尋結果測試工具


測試「結構化資料」的替代工具

上面這項更新可能多數人並不在意,但國外有些SEO或開發者認為網頁的語意(semantic meaning)才是Schema Markup重要的那部分,搜尋結果外觀的加強只是附加的好處。Google的立場則是支援沒有外觀變化的schema容易造成站長們的困惑。

如果要測試其他的schema markup可以考慮使用下面這些工具,有些有相當不錯的視覺化圖表。


新版Screaming Frog (v13)正式上線

Screaming Frog v13推出,新增了幾個很酷的功能,包括:

  • 相似內容分析 – 看出哪些網頁上的內容可能相似,而有重複性問題
  • 拼音與文法校正 – 找出文法和拼音錯誤,也包括中文! (但滿鳥的)
  • 更多的連結資料 – 包含連結所在的位置(header, footer, etc)
  • 染前後HTML比較

連結: 官方公告


Google Discover文章的「種類」

Google Discover是在使用者沒有搜尋動作的情形下由Google主動推薦文章。有人發現可以透過“Send Feedback” > “System Logs > Card Category”看到Google推薦這篇文章給你的原因。

圖片來源與討論

例如上圖的推薦原因是 “URL_TO_URL_RECOMMENDATION_UPDATE“。這些名稱背後的確切意思可能只有Google工程師才知道,但有人整理了一個表單放上他所看到的所有Discover種類,相當有趣。


WordPress插件「Web Stories」開放測試中

Web Stories (前身為AMP Stories)的Wordpress插件現在進入Beta測試階段,有興趣的人可以去玩玩,個人覺得是個呈現內容很好的方法。

如果還不知道Web Stories是什麼,可以參考我以前寫的這篇AMP Story文章,最近我把以前一篇李奧貝納和The North Face的SEO案例重新做了一次,歡迎看看!

連結: Web Stories for WordPress插件


Martin Splitt AMA (別再說2 wave indexing了)

Martin Splitt在Reddit上辦了一場AMA (Ask Me Anything),裡面回答了很多Javascript與SEO的問題。

其中一個值得注意的點是,Martin說他不再用”two-wave indexing”這個譬喻了,因為這造成更多的困惑,而且讓很多人對JS Site避而遠之。基本上現在每個網頁都會有rendering的過程,且網頁等待render的中位數時間只有五秒左右。

連結: Reddit討論串


[官方公告] Google如何使用檢舉報告

Gary Illyes寫了一篇文章”How spam reports are used at Google”,在討論Google如何使用搜尋中的用戶檢舉報告。

如果用戶發現了那些使用黑帽SEO的網站,可以透過Spam Report將其舉報給Google知道。但Google並不會一個一個去審查,他們主要是用這些檢舉來優化其spam detection演算法,因為這樣才是更能規模化的方法。

連結: 官方公告


GSC支援Regex篩選 (又取消了)

GSC的篩選功能相當為人詬病,只能簡單的「等於」或「包括」。最近有人發現在GSC的使用文件裡新增了一段Regex Filter的說明,但過幾天就被移除了,讓很多SEO白歡喜一場。

圖片來源

如果你需要處理GSC的資料, 比較簡單的方法是將GSC連結到Data Studio或者Google Analytics,這兩個工具都有支援Regex。


SEO迷思終結者: 抓取預算(Crawl Budget)

這集的迷思終結者系列在討論抓取預算(crawl budget)。Martin在影片中提到抓取預算不是一個中型或小型網站需要特別在意的議題,Google的立場是在有限的資源下,盡可能去抓取網際網路上的資訊。

什麼類型的網站應該被抓取的更頻繁(crawl demand)、Googlebot拜訪網頁時的速度該怎麼限制(crawl rate)…等等, 都可以在這支影片中聽到官方答案。


Google Search Podcast EP.2 & EP.3

這是第二和第三集的”Search Off the Record”,裡面相當多乾貨,第二集Gary講了六月初Google索引發生問題背後的原因,以及解釋”Document”是什麼(跟前面的how search works相呼應);第三集John花了一些時間講「排名因素」,他把Google的排名譬喻為一個神經網路(neural network),認為排名應該要整體來看,而不該只專注在某個因素上,或認為那些因素比較為重要。


如果你有因為電子報受益的話,歡迎留個言或寄信跟我說~ 不然總有在對空氣說話的感覺,我現在知道以前台上老師的感受了XD

在〈SEO電子報第十二期 – 2020.07.01~2020.07.15〉中有 10 則留言

    1. Hi Lan, 很好的問題! 我的理解是: JS Site本身沒有不好的地方,但JS Site容易放大SEO的問題。例如網站速度,一般的網站也會有速度慢的情況,但JS site更容易出現這樣的問題(server-side rendering, unused JS code…)。所以面對JS架構的網站,在做SEO健診時會特別注意其中幾個項目,但不會直接說它就是不好。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *