為什麼服務器日誌對 SEO 很重要

已發表: 2022-01-11

大多數網站運營商都沒有意識到網絡服務器日誌的重要性。 他們不記錄，更不用說分析他們網站的服務器日誌了。 尤其是大品牌，無法利用服務器日誌分析，並且無法挽回地丟失未記錄的服務器日誌數據。

選擇將服務器日誌分析作為其正在進行的 SEO 工作的一部分的組織通常在 Google 搜索中表現出色。 如果您的網站包含 100,000 個或更多頁面，並且您希望了解服務器日誌如何以及為什麼會帶來巨大的增長機會，請繼續閱讀。

為什麼服務器日誌很重要

每次機器人請求託管在 Web 服務器上的 URL 時，都會自動創建一個日誌記錄條目，以反映該過程中交換的信息。 當覆蓋一段較長的時間時，服務器日誌成為接收請求和返迴響應歷史的代表。

服務器日誌文件中保留的信息通常包括客戶端 IP 地址、請求日期和時間、請求的頁面 URL、HTTP 響應代碼、服務的字節量以及用戶代理和引用者。

雖然在每次請求網頁時都會創建服務器日誌，包括用戶瀏覽器請求，但搜索引擎優化只關注機器人服務器日誌數據的使用。 這與涉及 GDPR/CCPA/DSGVO 等數據保護框架的法律考慮有關。 由於 SEO 從未包含任何用戶數據，原始、匿名的 Web 服務器日誌分析仍然不受其他可能適用的法律法規的限制。

值得一提的是，在某種程度上，基於 Google Search Console Crawl 統計數據可以得出類似的見解。 然而，這些樣本在數量和覆蓋時間跨度上是有限的。 與僅反映最近幾個月數據的 Google Search Console 不同，它是專門的服務器日誌文件，提供清晰、全面的長期 SEO 趨勢圖。

服務器日誌中的寶貴數據

每次機器人請求服務器上託管的頁面時，都會創建一個日誌實例，記錄許多數據點，包括：

  • 請求客戶端的 IP 地址。
  • 請求的確切時間，通常基於服務器的內部時鐘。
  • 請求的 URL。
  • HTTP 用於請求。
  • 返回的響應狀態碼（例如，200、301、404、500 或其他）。
  • 來自請求實體的用戶代理字符串（例如，搜索引擎機器人名稱，如 Googlebot/2.​​1）。

典型的服務器日誌記錄示例可能如下所示：

150.174.193.196 - - [15/Dec/2021:11:25:14 +0100] "GET /index.html HTTP/1.0" 200 1050 "-" "Googlebot/2.1 (+http://www.google.com/bot.html)" "www.example.ai"

在這個例子中：

  • 150.174.193.196是請求實體的 IP。
  • [15/Dec/2021:11:25:14 +0100]是時區以及請求的時間。
  • "GET /index.html HTTP/1.0"是使用的 HTTP 方法 (GET)、請求的文件 (index.html) 和使用的 HTTP 協議版本。
  • 200是服務器返回的 HTTP 狀態碼響應。
  • 1050是服務器響應的字節大小。
  • "Googlebot/2.1 (+http://www.google.com/bot.html)"是請求實體的用戶代理。
  • "www.example.ai"是引用 URL。

如何使用服務器日誌

從 SEO 的角度來看，Web 服務器日誌提供無與倫比的洞察力的主要原因有以下三個：

  1. 協助從來自合法機器人（如 Googlebot、Bingbot 或 YandexBot）的理想搜索引擎機器人流量中過濾掉對 SEO 沒有意義的不受歡迎的機器人流量。
  2. 提供有關抓取優先級的 SEO 見解，從而使 SEO 團隊有機會主動調整和微調他們的抓取預算管理。
  3. 允許監視並提供發送到搜索引擎的服務器響應的跟踪記錄。

虛假的搜索引擎機器人可能會令人討厭，但它們很少影響網站。 有許多專業的服務提供商，如 Cloudflare 和 AWS Shield，可以幫助管理不良機器人流量。在分析 Web 服務器日誌的過程中，假搜索引擎機器人往往扮演次要角色。

為了準確衡量網站的哪些部分在主要搜索引擎之外被優先考慮，在執行日誌分析時必須過濾機器人流量。 根據目標市場，重點可以放在搜索引擎機器人上，例如 Google、Apple、Bing、Yandex 或其他。

特別是對於內容新鮮度是關鍵的網站，這些網站被重新抓取的頻率會嚴重影響它們對用戶的有用性。 換句話說，如果內容變化沒有足夠迅速地被採納，用戶體驗信號和自然搜索排名就不太可能充分發揮其潛力。

帶有三個搜索引擎徽標的圖形，代表各自的網絡爬蟲。
只有通過服務器日誌過濾，才能準確衡量相關的搜索引擎機器人流量。

雖然 Google 傾向於抓取所有可用信息並定期重新抓取已知的 URL 模式，但其抓取資源並非無限。 這就是為什麼對於包含數十萬個著陸頁的大型網站，重新抓取周期取決於 Google 的抓取優先級分配算法。

這種分配可以通過可靠的正常運行時間、高度響應的 Web 服務得到積極的刺激，並專門針對快速體驗進行了優化。 僅這些步驟就有利於SEO。 但是，只有通過分析涵蓋較長時間的完整服務器日誌，才有可能確定所有可抓取登錄頁面的總量之間的重疊程度，通常較少的相關、優化和可索引的 SEO 登錄頁面在站點地圖以及 Google 經常優先考慮的抓取、索引和排名。

這樣的日誌分析是技術 SEO 審計不可或缺的一部分，也是揭示抓取預算浪費程度的唯一方法。 無論是可爬網過濾、佔位符還是精簡內容頁面、開放的登台服務器或網站的其他過時部分，都會繼續損害爬網並最終影響排名。 在某些情況下，例如有計劃的遷移，尤其是通過 SEO 審計（包括服務器日誌分析）獲得的洞察力，通常會決定遷移的成功與否。

此外，日誌分析為大型網站提供了關鍵的 SEO 見解。 它可以提供Google 需要多長時間重新抓取整個網站的答案。 如果該答案恰好是決定性的長 - 幾個月或更長時間 - 可能需要採取行動以確保可索引的 SEO 登錄頁面被抓取。 否則，網站的任何 SEO 改進很有可能會在發布後的幾個月內被搜索引擎忽視，這反過來又會導致排名不佳。

由三部分組成的維恩圖顯示了 google 抓取的內容、您的 XML 站點地圖和您的 SEO 登錄頁面之間的重疊。
可索引的 SEO 登錄頁面與 Google 定期抓取的內容之間的高度重疊是積極的 SEO KPI。

服務器響應對於提高 Google 搜索的可見性至關重要。 雖然 Google Search Console 確實提供了對最近服務器響應的重要一瞥，但 Google Search Console 提供給網站運營商的任何數據都必須被視為具有代表性但有限的樣本。 雖然這對於識別嚴重問題很有用，但通過服務器日誌分析，可以分析和識別所有 HTTP 響應，包括任何可能危及排名的定量相關的非 200 OK 響應。 如果它們過多，可能的替代響應可以指示性能問題（例如，503 Service Unavailable 計劃停機時間）。

顯示 503 和 200 狀態代碼的抽像圖形。
過多的非 200 OK 服務器響應會對自然搜索可見性產生負面影響。

從哪裡開始

儘管服務器日誌分析具有潛力，但大多數網站運營商並沒有利用所提供的機會。 服務器日誌要么根本沒有記錄，要么經常被覆蓋或不完整。 絕大多數網站不會在任何有意義的時間段內保留服務器日誌數據。 對於任何願意（與競爭對手不同）收集和利用服務器日誌文件進行搜索引擎優化的運營商來說，這都是個好消息。

在計劃服務器日誌數據收集時，值得注意的是，服務器日誌文件中至少必須保留哪些數據字段才能使數據可用。 以下列表可被視為指南：

  • 請求實體的遠程 IP 地址。
  • 請求實體的用戶代理字符串。
  • 請求方案（例如，是對 http 或 https 或 wss 或其他東西的 HTTP 請求）。
  • 請求主機名（例如，HTTP 請求是針對哪個子域或域）。
  • 請求路徑，通常這是服務器上的文件路徑作為相對 URL。
  • 請求參數，可以是請求路徑的一部分。
  • 請求時間，包括日期、時間和時區。
  • 請求方法。
  • 響應http狀態碼。
  • 響應時間。

如果請求路徑是相對 URL，服務器日誌文件中經常忽略的字段是請求的主機名和方案的記錄。 這就是為什麼請務必與您的 IT 部門核實請求路徑是否是相對 URL，以便主機名和方案也記錄在服務器日誌文件中。 一個簡單的解決方法是將整個請求 URL 記錄為一個字段，其中包括一個字符串中的方案、主機名、路徑和參數。

收集服務器日誌文件時，包括源自 CDN 和網站可能使用的其他第三方服務的日誌也很重要。 請諮詢這些第三方服務，了解如何定期提取和保存日誌文件。

克服服務器日誌分析的障礙

通常，為了應對保留服務器日誌數據的迫切需求，提出了兩個主要障礙：成本和法律問題。 雖然這兩個因素最終都取決於個人情況，例如預算和法律管轄權，但都不必構成嚴重的障礙。

雲存儲可以是一個長期的選擇，物理硬件存儲也可能會限製成本。 大約 20 TB 硬盤的零售價低於 600 美元，硬件成本可以忽略不計。 鑑於存儲硬件的價格多年來一直在下降，最終存儲成本不太可能對服務器日誌記錄構成嚴重挑戰。

此外，還會產生與日誌分析軟件或提供服務的 SEO 審計提供商相關的成本。 雖然這些成本必須計入預算，但鑑於服務器日誌分析提供的優勢，再次證明其合理性是很容易的。

雖然本文旨在概述服務器日誌分析對 SEO 的內在好處，但不應將其視為法律建議。 此類法律建議只能由符合法律框架和相關管轄權的合格律師提供。 GDPR/CCPA/DSGVO 等多項法律法規可在此背景下適用。 尤其是在歐盟運營時，隱私是一個主要問題。 但是，出於 SEO 的服務器日誌分析的目的，任何與用戶相關的數據都無關緊要。 任何無法根據 IP 地址最終驗證的記錄都將被忽略。

關於隱私問題，不得使用任何未經驗證且不是已確認搜索引擎機器人的日誌數據，而是可以根據相關法律建議在規定的時間段後刪除或匿名化。 一些最大的網站運營商定期採用這種久經考驗的方法。

什麼時候開始

剩下的主要問題是何時開始收集服務器日誌數據。 答案就是現在！

服務器日誌數據只能以有意義的方式應用，並在足夠多的情況下提供可操作的建議。 服務器日誌對 SEO 審核有用的臨界質量通常在 6 到 36 個月之間，具體取決於網站的大小及其抓取優先級信號。

需要注意的是，後期無法獲取未記錄的服務器日誌。 今天開始的任何保留和保存服務器日誌的努力很可能最早在明年取得成果。 因此，收集服務器日誌數據必須儘早開始，並在網站運行期間不間斷地持續下去，並旨在在自然搜索中表現良好。

本文中表達的觀點是客座作者的觀點，不一定是 Search Engine Land。 工作人員作者在這裡列出。