在 Google 大力推行以及 Let’s Encrypt 的支持下
相信會有越來越多網站選擇增加 HTTPS 的支援，甚或直接只使用 HTTPS 協定連線
在網站導入 SSL/TLS 的過程中，網址也必然會有所變動
可能增加了 HTTPS 連入的管道，也可能從 HTTP 轉變為 HTTPS 單一選擇
在社群導入的情況下，量化的數字是最容易被在意的
在網址轉換的過程中，同一個網頁會變成有新舊兩個網址
而 Facebook 按讚數 的計算基礎是網址為基礎，造成即使兩個網址指向同一個頁面卻還是被 Facebook 分別以新舊網址計算按讚數
鸚鵡自己也在移轉的過程中遇到這個問題，在處理的過程中慢慢嘗試及摸索
倒也是搞懂了 Facebook Like Button 處理和判斷的方式
算是有個解決方案，其實不難只要抓到幾個原則
本文僅提供解決方案，沒有相關的修改或修改教學
先說明以下三個重點
- Facebook 對於讚按數的處理是以 標準網址 做為基礎
標準網址 的認定方式如下
A. 網頁中定義的中繼標籤 og:url 聲明的 url
B. 若網頁中沒有定義 og:url 則使用該網頁的 url - Facebook 網路爬蟲(crawler) 會遵循 HTTP 301 或 302 重新導向
重新導向完成後再依照 第1點 的模式做 標準網址 的判定 - Facebook 網路爬蟲(crawler) 也遵循 rel=canonical 標準連結元素
若頁面包含這個標籤，優先將 rel=canonical 設定的 url 視為標準網址
並重新連結到指定的頁面後再依照 第1點 的模式做 標準網址 的判定
情境模擬
原始網址: http://example.com (100 個讚)
新的網址: https://example.com (0 個讚)
都對應同到一個頁面
在兩個網址的頁面中都設定 中繼標籤 og:url
<meta property="og:url" content="http://example.com" />
且保持兩個網址都可以各別顯示同一個頁面
這時候使用 https://example.com 連線 Facebook 的 Like button 會顯示 100個讚
這樣說起來好像很簡單
是的，就是這麼簡單！
但這樣的設置會讓搜尋引擎將兩個網址分別各自編入 index 中
在搜尋結果中使用各自的排名。會造成分散流量的情況，不利於 SEO
以 Google 為例，在 Google Search Console 中的建議是
當使用者使以 http://example.com 連結時
使用 HTTP 301 或 302 導向重新導向到 https://example.com
或者在頁面中使用 rel=canonical 標籤聲明標準網址為 https://example.com
但這兩個設定也都會被 Facebook 所遵循
對 Facebook 來說都會造成 迴圈導向(redirect loop) 的情況
https://example.com 透過 og:url 聲明標準網址 為 http://example.com
http://example.com 卻重新導向回 https://example.com
解決這個問題的方法就是
針對 Facebook 的 網路爬蟲(crawler) 不送出 HTTP 301 或 302 重新導向
而是顯示網頁(即便網頁內容只有 og:url 和相關的中繼標籤 )
並且也不會在網頁中使用 rel=canonical 標籤聲明其他網址為標準網址
這樣就可以讓 Facebook 正確的顯示舊網址的按讚數
Facebook 網路爬蟲(crawler) 的識別字串
facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)也可以只判斷
facebookexternalhit/1.1
另一個是跟廣告有關的是：Facebot