SEO電子報第六十二期 – 2022.08.01~2022.08.15

[新聞] 第四次產品評論算法更新及影響

Google在7/27公告開始推出了第四次的產品評論算法更新 (Product Reviews Update, PRU)，原本預計算法更新推出都需要好幾週，但這次卻在8/2就完成。

SEO社群普遍認為這次的PRU有點奇怪，除了僅用六天時間就完成，各大排名追蹤工具也顯示波動並不劇烈，但仍有人回報其評論網站受到了影響。無論如何，從去年四月第一次到現在已有了四次產品評論算法更新，代表Google對「高品質評論」的重視不可小覷。

連結: 產品評論算法更新 (第一次  / 第二次  / 第三次) / Google高品質評論指南

[新聞] 商品搜尋結果中的「退貨期限」

有眼尖的國外網友在搜尋產品時發現SERP上出現了｢平均運送時間｣、｢退貨期限｣...等資訊。但有趣的是，這些資料並沒有在該產品頁上提到，而是來自Google Merchant Center裡的「購物體驗評量表 (Shopping Experience Scorecard)」中。

「購物體驗評量表計畫」於今年二月推出，商家能透過Google Merchant Center上傳產品相關資訊 (如平均退貨費用等4項指標)，Google將可能針對符合特定條件的商家給予徽章，甚至讓商家在「購物」分頁中獲得顯眼的刊登位置。

由於公告中說到這個分數可能會是個"boost in ranking"，且「購物體驗評量表」所需的資料又是由商家主動上傳，社群就有人在討論是否會有商家謊報、上傳假數據，來操縱排名的嫌疑？針對此事，Google的發言人Alan Kent回覆：｢Google有辦法驗證商家提供的資訊是否正確，倘若商家試圖提供錯誤的資訊，將被排除在此次的計畫之外。｣

連結: SER對於Shopping Experience Scorecard的報導

[新聞] 新結構化資料 - 優缺點

Google推出了一個新的結構化資料 - 「優缺點 (Pros & Cons)」，讓使用在在搜尋結果上，就能看到一項產品評論的優點和缺點。

這個新的搜尋外觀在六月多第一次被人注意到，但在最近才正式宣布支援其結構化資料。在官方公告中，Google說他們會辨別網頁上的優缺點資料，並可能自動將其呈現在搜尋結果上 (儘管沒有加上結構化資料)，但如果能主動透過結構化資料提交優缺點能幫助Google了解。

// Pros & Cons 結構化資料範例

<script type="application/ld+json">
  {
    "@context": "http://schema.org",
    "@type": "Product",
    "name": "Cheese Knife Pro",
    "review": {
      "@type": "Review",
      "name": "Cheese Knife Pro review",
      "author": {
        "@type": "Person",
        "name": "Pascal Van Cleeff"
      },
      "positiveNotes": {
        "@type": "ItemList",
        "itemListElement": [
          {
            "@type": "ListItem",
            "position": 1,
            "name": "Consistent results"
          },
          {
            "@type": "ListItem",
            "position": 2,
            "name": "Still sharp after many uses"
          }
        ]
      },
      "negativeNotes": {
        "@type": "ItemList",
        "itemListElement": [
          {
            "@type": "ListItem",
            "position": 1,
            "name": "No child protection"
          },
          {
            "@type": "ListItem",
            "position": 2,
            "name": "Lacking advanced features"
          }
        ]
      }
    }
  }
</script>

值得注意的是，只有editorial product review (編輯評論)頁面可以加上這個結構化資料，不適用在產品頁或一般的顧客評論頁面上。另外，這個新的功能目前僅支援10個語言，中文還不是其中之一。

[技巧] 規模化判斷 Redirect Mapping

Redirect Mapping是網站搬遷的一個重要步驟，目的是將舊網址與新網址做配對並設定301 redirect，讓去到舊網址的流量可以被帶到正確的位置。中小型的網站搬遷，或者是網址結構一樣的情況下，要製作一份Redirect Map不難；但當網址架構改變，再加上網頁數量龐大的情況，就很令人頭痛。

這篇文章教了兩個方法，在遇上後面這種情況也可以有效率的辨別舊網址該去到哪裡。第一個是上期介紹過的Fuzzy Matching，上傳兩串網址，透過網址的相似性判斷哪兩條URL應該被配對在一起。回傳的結果並不是永遠正確，因此還是要檢視一下Similarity Score (相似性)太低的組合是否正確。

另外一個方法是先下載網站搬遷前有排名的關鍵字，然後利用Google搜尋keyword site:www.newdomain.com，從SERP上看Google把哪個網頁排在第一，也就可能是最相關的網頁，最後再利用Python搭配上付費API將上述的步驟規模化。

上面兩個方法在原文中作者有提供Python的代碼，並不算難，推薦大家有空可以玩玩看!

連結: Redirect at scale

[分析] 新的 Google Tag 系統

Google 在八月初發布了一篇公告，說他們將會用一個 "Google Tag" 來整合管理所有不同的 tags。例如有一個 AW-567890 (Google Ads的標籤) 和一個 G-123456 (GA4的標籤)，兩者將可結合在一起，由同一個 Google Tag 管理。

目前可以從GA4和Google Ads進到Google Tag管理介面將不同的標籤整合。

整合標籤對中小型網站的影響不大，要有非常複雜的標籤管理和資料收集需求才會看出其益處。整合標籤除了會分享事件偵測(event detection)、跨網域追蹤(cross-domain measurement)...等之外，還會分享其覆蓋範圍。

老實說，我不敢說100%看懂，想要深入研究和釐清的話，非常推薦看Simo寫的文章 (雖然已比官方公告白話許多，但還是不好讀通)。這個改動與SEO本身相關性較低，但我認為是個值得關注的新聞，分享給大家。

[官方] Dynamic Rendering不是長期的解決方法

有人注意到Google在講解Dynamic Rendering的文件最上方，加上了一段紅字寫道「利用 dynamic rendering 來讓搜尋引擎能看到JS生產的內容只是的暫時的解決方法，長期來說我們還是推薦 server-side rendering, static rendering, or hydration。」

Google早期對JS的處理能力還不強的時候，推薦大家使用dynamic rendering，讓搜尋引擎可以直接接收到渲染後的內容。不過這已經是過時的資訊，在2019年五月推出evergreen googlebot (用最新版chrome作為rendering service)，Google就不再建議dynamic rendering，這點在過去Martin其實提過不少次，這次只是更新了官方文檔減少過時資訊在外流通。

如果對於幾種rendering的差別不是很了解，可以去聽第六集的podcast，或是閱讀這篇文章。

[工具] Term Suggust - 關鍵字研究免費工具

偶然看到這個由 Joe Hall 所開發的免費關鍵字研究工具 - Term Suggest，使用者輸入一個關鍵字，該工具會自動在該字後方加上a, b, c..., x, y, z，以及前方加上who, what...等字，並一個一個用Query Suggest API來看推薦的相關字有哪些。

舉裡來說，我輸入moet hennessy，工具會把moet hennessy a、moet hennessy b、what moet hennessy...等字丟進API中，再將吐回的結果整理成下面這樣的型式，工具完全免費，而且速度不慢。

這項工具免費，而且使用起來速度算快，推薦給大家。數位引擎以前曾寫過一篇文章教學怎麼將autocomplete的資料撈下來，代碼其實才短短幾行，但若能結合一些創意就能做出像 Term Suggest 這樣更有用的工具，推薦給對寫程式有點興趣的讀者們!

連結: 工具網站 / 影片介紹

[工具] Bing Webmaster Tools 複習

Bing站長工具在2020年大翻新了一波，當時推出不少讓大家相當驚艷的功能，可惜後來就沒什麼再被人提起。儘管Bing在搜尋引擎的市場份額不大，但BWT若作為一個SEO工具來說還不錯用，完全免費，而且驗證非常簡單。

最近有人在Twitter上重新整理了Bing Webmaster Tools (BWT)好用的地方，因此覺得可以把它提出來複習一下:

• 能當作網站健診工具，會列出沒有title tag、meta description太長或太短...等可以優化的方向
• 提供外部連結，除了看到自家網站的連結，甚至可以輸入對手的網站，分析對手的外部連結來源
• 根據網址來分類的網站架構，可以以subfolder為單位來看其表現或抓取/收錄狀況

數位引擎過去電子報也曾介紹過，錯過的話可以回去複習一下: 第3期、第9期、第10期、第13期、第16期、第19期。

[影片] 電商在Google搜尋突出的六個小技巧

這集影片分享了六個讓網頁的外觀，在搜尋結果上更加突出的方法。沒有新的SEO資訊，但是是個不錯的整理，影片內容也很針對電商類型的常見狀況，

1. 確保 title link 的生成方式 - 電商網站容易使用產品的屬性來自動生成標題，須小心屬性資料不存在或錯誤的情形時的標題
2. 放上高品質圖片 - 寬度最少1,200px
3. 結構化資料 - 產品資料亦可透過 Google Merchant Center
4. 降價資訊 - 僅適用於單一價格的產品頁
5. 提供產品ID - 例如GTIN，如此一來網頁可能會被放在Top Product Carousel中
6. 註冊商家檔案 - 僅限有實體店面的商家

[摘要] 網址「移除」背後的機制

這集的podcast重回早期Gary解釋搜尋引擎運作機制的深度系列。搜尋引擎要"移除"一個網頁並不向表面上的這麼簡單，因為在crawling, indexing, serving三個階段都有不同的機制，而他們各自的機制可能會互相衝突。舉例來說，若在robots.txt中disallow (crawling階段)、又在meta robots tag中放上noindex (indexing階段)，那這個網頁的"URL"可能還是會被索引。

Crawling階段沒有任何方法可以將網址移除。此外，Gary特別說他認為robots.txt就應該只被用在crawling階段，幾年前Google決定不再支援robots.txt中的noindex指令也是這個原因。

大部分真正的removal是在indexing階段發生，就算當Google在crawling階段看到x-robots-tag中有noindex、或網址本身是404，crawling階段也只是把這些資訊傳下去indexing階段做決定。

在serving階段的removal就是指GSC中的網址移除工具，這裡網址並不是真正的從索引(index)中被移除了，而只是在搜尋結果上被「隱藏」，因為要將網頁從索引移除會需要同步到所有的資料中心，這個過程可能甚至花上好幾個月。

上面這些摘要看似簡單，但實務上搜尋引擎可能會遇到很複雜的情況。例如有幾個網址彼此用hreflang串起來，其中幾個標示noindex，但其餘的並沒有。由於hreflang將它們視為同一份"document"，可能會導致所有的頁面都不被收錄。對於很多極端案例Gary甚至說他也不確定到底會發生什麼事，但唯一肯定的建議就是要避免這種 conflicting signals。

以下是幾個Gary以前深入探討搜尋引擎原理內容，有興趣可以回頭聽聽:

• Canonicalization & Dupe Detection
• Serving & Hreflang
• Query Parsing & Query Understanding
• Serving Index
• Caffeine
• Rendering

連結: 逐字稿