服務器日志分析可以為抓取優先級提供無與倫比的洞察力，使 SEO 團隊能夠微調他們的抓取預算管理以獲得更好的排名。大多數網站運營商都沒有意識到網絡服務器日志的重要性。他們不記錄，更不用說分析他們網站的服務器日志了。尤其是大品牌，無法利用服務器日志分析，并且無法挽回地丟失未記錄的服務器日志數據。

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

為什么服務器日志很重要

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

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

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

值得一提的是，在某種程度上，基于Google Search Console Crawl stats的類似見解是可能的。然而，這些樣本在數量和覆蓋時間跨度上是有限的。與僅反映最近幾個月數據的 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 服務器日志提供無與倫比的洞察力的主要原因有以下三個：

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

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

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

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

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

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

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

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

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

從哪里開始

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

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

• 請求實體的遠程 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 個月之間，具體取決于網站的大小及其抓取優先級信號。

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