服務器日志分析可以對爬網優先級提供無與倫比的見解，使搜索引擎優化團隊能夠微調爬網預算管理以獲得更好的排名。

大多數網站運營商都不知道web服務器日志的重要性。他們不記錄，更不用說分析他們網站的服務器日志了。尤其是大型品牌，它們無法利用服務器日志分析，無法挽回地丟失未記錄的服務器日志數據。

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

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

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

雖然服務器日志是在每個請求網頁的實例中創建的，包括用戶瀏覽器請求，但搜索引擎優化只關注bot服務器日志數據的使用。這與涉及GDPR/CCPA/DSGVO等數據保護框架的法律考慮有關。由于沒有用戶數據用于SEO目的，原始的匿名web服務器日志分析仍然不受其他潛在適用法律法規的影響。

值得一提的是，在某種程度上，基于谷歌搜索控制臺爬網統計數據，類似的見解是可能的。然而，這些樣本的數量和時間跨度有限。與谷歌搜索控制臺（GoogleSearchConsole）不同的是，它的數據只反映了過去幾個月的數據，而只有服務器日志文件才能提供清晰、宏觀的SEO長期趨勢概述。

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

請求客戶端的IP地址。

請求的準確時間，通常基于服務器的內部時鐘。

請求的URL。

HTTP用于請求。

返回的響應狀態代碼（例如，200、301、404、500或其他）。

來自請求實體的用戶代理字符串（例如，搜索引擎bot名稱，如Googlebot/2.1）。

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

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

Inthisexample:

150.174.193.196istheIPoftherequestingentity.

[15/Dec/2021:11:25:14+0100]isthetimezoneaswellasthetimeoftherequest.

"GET/index.htmlHTTP/1.0"istheHTTPmethodused(GET),thefilerequested(index.html)andtheHTTPprotocolversionused.

200istheserverHTTPstatuscoderesponsereturned.

1050isthebytesizeoftheserverresponse.

"Googlebot/2.1(+http://www.google.com/bot.html)"istheuseragentoftherequestingentity.

"www.example.ai"isthereferringURL.

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

協助從合法機器人（如Googlebot、Bingbot或YandexBot）產生的理想搜索引擎機器人流量中過濾出沒有SEO意義的不良機器人流量。

為爬網優先級提供SEO見解，從而使SEO團隊有機會主動調整和微調爬網預算管理。

允許監視并提供發送到搜索引擎的服務器響應的跟蹤記錄。

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

為了準確地衡量除了主要搜索引擎之外，網站的哪些部分正在被優先排序，在執行日志分析時，必須對機器人程序流量進行過濾。根據目標市場的不同，重點可能是谷歌、蘋果、必應、Yandex等搜索引擎機器人。

特別是對于內容新鮮度至關重要的網站，這些網站被重新爬網的頻率會嚴重影響它們對用戶的有用性。換句話說，如果內容變化得不夠快，用戶體驗信號和有機搜索排名就不可能充分發揮其潛力。

只有通過服務器日志過濾，才有可能準確地衡量相關的搜索引擎bot流量。

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

這種分配可以通過可靠的啟動時間、高度響應的web服務得到積極的刺激，這些服務專門針對持續體驗進行了優化。這些步驟本身就有助于SEO。但是，只有通過分析覆蓋較長時間段的完整服務器日志，才有可能確定所有可爬網登錄頁的總容量之間的重疊程度，通常是較小數量的相關登錄頁，優化和可索引的SEO登錄頁在站點地圖中有代表性，谷歌在爬行、索引和排名方面經常優先考慮。

這種日志分析是技術SEO審計的一個組成部分，也是發現預算浪費程度的唯一方法。無論是可爬行過濾、占位符還是精簡內容頁、開放的暫存服務器還是網站的其他過時部分，都會繼續影響爬行，最終影響排名。在某些情況下，例如有計劃的遷移，通過SEO審計（包括服務器日志分析）獲得的見解通常決定遷移的成功與失敗。

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

可索引SEO登錄頁和Google定期爬行頁面之間的高度重疊是一個積極的SEOKPI。

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

過多的非200OK服務器響應會對有機搜索可見性產生負面影響。

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

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

請求實體的遠程IP地址。

請求實體的用戶代理字符串。

請求方案（例如，是HTTP或https或wss或其他內容的HTTP請求）。

請求主機名（例如，HTTP請求用于哪個子域或域）。

請求路徑，通常是服務器上作為相對URL的文件路徑。

請求參數，可以是請求路徑的一部分。

請求時間，包括日期、時間和時區。

請求方法。

響應http狀態代碼。

響應時間。

如果請求路徑是相對URL，則服務器日志文件中經常忽略的字段是記錄請求的主機名和方案。這就是為什么與it部門確認請求路徑是否為相對URL非常重要的原因，以便主機名和方案也記錄在服務器日志文件中。一個簡單的解決方法是將整個請求URL記錄為一個字段，其中包括一個字符串中的方案、主機名、路徑和參數。

收集服務器日志文件時，還必須包含來自CDN和網站可能使用的其他第三方服務的日志。請向這些第三方服務咨詢如何定期提取和保存日志文件。

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

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

此外，日志分析軟件或提供服務的SEO審計提供商將產生相關成本。雖然這些成本必須考慮到預算中，但考慮到服務器日志分析提供的優勢，再次證明這些成本是合理的。

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

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

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

服務器日志數據只能以有意義的方式應用，并在足夠大的容量下提供可操作的建議。服務器日志對于搜索引擎優化審計的有用性通常在6到36個月之間，這取決于網站的大小及其爬網優先級信號。

需要注意的是，未記錄的服務器日志不能在以后的階段獲取。很有可能，今天開始的任何保留和保存服務器日志的努力最早將在明年取得成果。因此，收集服務器日志數據必須在盡可能早的時間開始，并在網站運行期間不間斷地繼續進行，以便在有機搜索中表現良好。