網站建設初期，頁面數量有限，團隊人數有限，網站各類頁面元素變動不大。但到了網站建設中期，網站需求方需求變多，網站更改相比于之前更加頻繁，XX部門提的XX需求可能會影響SEO流量，若未及時發現，時間拉長，可能造成較為嚴重，甚至不可逆轉的后果。這個鍋，誰來背呢？

    這點可以通過完善需求上線流程來解決一部分，比如：任何涉及頁面變動的需求（新增頁面 & 已有頁面元素更改）在提交RD前，需求評審階段均需要SEO部門介入，確認該需求對SEO渠道的用戶拉新無影響后，在正式提交RD。

    尷尬的是，有相當比例的公司，SEO因為歷史效果種種不可控，或者 SEO并非用戶拉新的主要渠道，SEO較難搞定在PM和RD面前話語權的問題，他們可能不怎么care，老忘記評審的時候叫上SEO一起玩耍。這種情況需要具有八卦特征的SEO，沒事跟RD、PM扯扯皮，問問最近上了什么新需求…

    但是，即便在流程上能夠搞定，也是會出現頁面元素的改動，卻未及時通知到SEO的情況，比如新入職的產品提需求，不知道有這個流程。

    此外，由于SEO部門人事變動，出現老員工離職、新員工入職的情況。新入職的SEO不能快速了解網站歷史背景，老員工與新員工交接，很多細節會遺漏，導致新入職的SEO，日后會踩到本可避免的一些坑。

    一些基層SEO針對爬蟲日志，也沒有足夠的分析能力，或者需要每天手動拿軟件或shell等分析一次數據，然后在執行的SEO動作，操作復雜且效率低下。

    為解決以上兩點問題，需要有一套“及時止損機制”，用于及時發現潛在風險，并提高日常SEO效率。

    “及時止損機制”，需要人工設定N個會影響SEO的特征，程序24小時監控這些特征，如出現符合特征的元素，則及時通知SEO，并提示相應建議，程序每次檢查都做一次數據備份。并根據網站發展情況，不斷添加、刪除監控特征。

    我把“及時止損機制”分為兩部分：“爬蟲日志監控”和“頁面特征監控”

    爬蟲日志監控

    爬蟲日志監控

    上圖為“爬蟲日志監控模塊”的邏輯，分“檢查字段”、“觸發條件”、“執行動作”三個步驟。以下是幾點可能需要說明的：

    爬蟲IP的黑白名單

    根據UA為baiduspider的爬蟲，檢測IP是否為真實的Baiduspider，若為假spider，則加入黑名單，若為真spider，則加入baiduspider的白名單。

    其他主流搜索引擎，則將出現的ip統統加到對應的白名單，后期根據ip段進行排除。

    收集白名單IP，可作為日后SEO之用，比如某個SEO的小需求產品不讓上，SEO退而求其次，只針對白名單的IP顯示該元素，對正常用戶訪問不顯示等。

    提前整理站內已知頁面

    提前統計站內所有URL類型，并整理對應URL類型的正則表達式，這些正則均是統計站內已知頁面的爬蟲情況。

    因為大部分SEO包括產品經理，可能都不清除站內到底有多少套URL，所以也有必要通過日志，找到未知的URL，并進行相應的SEO動作。

    返回內容大小字段統計

    為啥要統計“$body_bytes_sent（發給來訪者的文件大小）”這個字段呢？

    因為之前經歷過幾次類似情況：某類頁面流量逐減少，經排查爬蟲日志，360Spider訪問部分該頁面，返回的文件大小為54k，并不是該頁面html文件的正常大小，詢問技術，發現不久上線的新反爬蟲策略，未把360Spider加入白名單，導致觸發反爬蟲策略，返回空白頁面。