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

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

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

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

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

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

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

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

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

    爬蟲日志監(jiān)控

    爬蟲日志監(jiān)控

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

    爬蟲IP的黑白名單

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

    其他主流搜索引擎，則將出現(xiàn)的ip統(tǒng)統(tǒng)加到對應(yīng)的白名單，后期根據(jù)ip段進行排除。

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

    提前整理站內(nèi)已知頁面

    提前統(tǒng)計站內(nèi)所有URL類型，并整理對應(yīng)URL類型的正則表達式，這些正則均是統(tǒng)計站內(nèi)已知頁面的爬蟲情況。

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

    返回內(nèi)容大小字段統(tǒng)計

    為啥要統(tǒng)計“$body_bytes_sent（發(fā)給來訪者的文件大小）”這個字段呢？

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