內(nèi)容更新了但爬蟲就是不抓檢查一下 sitemap 的 lastmod一個真實的排查案例網(wǎng)站上線兩個月百度收錄為零。更詭異的是——明明內(nèi)容一直在更新爬蟲日志顯示 Bytespider 和 Baiduspider 都來過但就是只抓首頁子頁面一個都不碰。排查到最后問題出在一個幾乎沒人注意的字段上sitemap.xml 里的lastmod?，F(xiàn)象爬蟲來了但只抓首頁先從服務(wù)器日志看爬蟲行為nginx access log# Baiduspider 訪問記錄 [21/Jul/2026:14:36] GET / HTTP/1.1 200 [27/Jul/2026:11:19] GET / HTTP/1.1 200 [28/Jul/2026:11:57] GET / HTTP/1.1 200 [29/Jul/2026:13:54] GET / HTTP/1.1 200 [01/Aug/2026:04:05] GET / HTTP/1.1 200 [01/Aug/2026:04:05] GET /xiaohongshu_v2.jpg HTTP/1.1 200 # Baiduspider-render 渲染時抓圖片 # Bytespider 訪問記錄 [02/Aug/2026:22:03] GET /sitemap.xml HTTP/1.1 200 [02/Aug/2026:22:13] GET /robots.txt HTTP/1.1 200規(guī)律很明顯Baiduspider 反復(fù)抓首頁GET /偶爾帶 render 爬蟲深度渲染但從不深入子頁Bytespider 只抓 sitemap.xml 和 robots.txt抓完就走了子頁面/methodology.html、/products.html 等一個都沒被訪問過按經(jīng)驗這種抓首頁但不深入通常有三個嫌疑robots.txt 誤攔、頁面內(nèi)鏈?zhǔn)А⒒蛘摺猻itemap 的新鮮度信號過期了。排查先排除常規(guī)嫌疑1. robots.txt 檢查User-agent: * Allow: / Sitemap: https://www.example.com/sitemap.xml全放行沒問題。2. 頁面可達(dá)性檢查curl -s -o /dev/null -w %{http_code} https://www.example.com/methodology.html # 200子頁面本身沒問題3. 爬蟲 UA 內(nèi)容一致性# 瀏覽器 UA 和爬蟲 UA 拿到的字節(jié)數(shù)對比 curl -sL -A Mozilla/5.0 https://www.example.com/ | wc -c # 105414 curl -sL -A Bytespider https://www.example.com/ | wc -c # 105414 curl -sL -A Baiduspider https://www.example.com/ | wc -c # 105414三個一樣CDN 沒有對爬蟲截斷內(nèi)容。根因sitemap 的 lastmod 過期了最后回到 sitemap.xml 本身。一看就明白了urlsetxmlnshttp://www.sitemaps.org/schemas/sitemap/0.9urllochttps://www.example.com//loclastmod2026-07-21/lastmod!-- ← 問題在這 --/urlurllochttps://www.example.com/methodology.html/loclastmod2026-07-21/lastmod/url.../urlset8 個頁面的 lastmod 全部停在 7 月 21 日但網(wǎng)頁文件的實際修改時間是 8 月 3 日。也就是說內(nèi)容更新了但 sitemap 還在對爬蟲說這個站 7 月 21 號之后沒變過。而爬蟲尤其 Bytespider的工作機(jī)制是先訪問 sitemap.xml比較lastmod和它緩存里的上次抓取時間只有 lastmod 比上次更新才去抓對應(yīng)的內(nèi)容頁lastmod 沒變 → 認(rèn)為內(nèi)容沒更新 → 跳過所以日志里的現(xiàn)象就完全解釋通了8 月 2 日 22:03 Bytespider 來抓 sitemap.xml看到 lastmod 還是 7 月 21 日覺得沒有新內(nèi)容掉頭就走了。你更新的那些 HTML 頁面它根本沒機(jī)會看到。修復(fù)更新 lastmod 并驗證把 sitemap.xml 里所有l(wèi)astmod改成最新日期和實際內(nèi)容更新時間一致# 修改前先備份cp/var/www/html/sitemap.xml /var/www/html/sitemap.xml.bak# 更新 lastmod8 個頁面全改成 2026-08-03# 建議用腳本逐個替換不要手寫避免格式錯誤改完驗證三個層面1. 服務(wù)器文件層面grep-clastmod2026-08-03/lastmod/var/www/html/sitemap.xml# 8全部更新成功2. 線上訪問層面curl-shttps://www.example.com/sitemap.xml|greplastmod# 8 個 2026-08-033. CDN 緩存層面curl-sIhttps://www.example.com/sitemap.xml|grep-icf-cache-status# 如果是 DYNAMIC說明 CDN 不緩存這個文件爬蟲每次都能拿到最新版無需清緩存# 如果是 HIT需要在 CDN 面板 Purge 一下否則爬蟲拿到的還是舊文件這一步很關(guān)鍵如果你的 sitemap 在 CDN 里被緩存了cf-cache-status: HIT光改服務(wù)器文件沒用爬蟲拿到的是 CDN 里的舊副本必須 Purge。如果顯示 DYNAMIC說明每次回源改完立即生效。復(fù)盤為什么這個坑容易踩階段你以為的狀態(tài)爬蟲看到的狀態(tài)更新 HTML內(nèi)容更新了頁面變了如果它來抓的話不更新 sitemap沒關(guān)系反正有 sitemaplastmod 還是舊的 → 判斷無新內(nèi)容 → 不抓更新 sitemap lastmod通知爬蟲有新內(nèi)容觸發(fā)對內(nèi)容頁的重新抓取根因是sitemap 的 lastmod 是爬蟲判斷是否值得抓取的核心信號它必須和實際內(nèi)容更新時間同步。內(nèi)容改了lastmod 不跟著改等于把更新藏起來了。排查清單可直接復(fù)用遇到內(nèi)容更新了但收錄沒動靜按這個順序查# 1. 爬蟲到底來沒來、抓了什么# 服務(wù)器日志里分別統(tǒng)計兩個爬蟲的訪問路徑grep-ibaiduspider /var/log/nginx/access.log|awk{print $7}|sort|uniq-cgrep-ibytespider /var/log/nginx/access.log|awk{print $7}|sort|uniq-c# 如果只有 / 和 /sitemap.xml沒有內(nèi)容頁 → 大概率是 lastmod 問題# 2. sitemap lastmod 是否和內(nèi)容更新時間一致curl-shttps://www.example.com/sitemap.xml|greplastmod# 3. 服務(wù)器上 HTML 文件的真實修改時間ls-la/var/www/html/*.html|head# 對比 lastmod如果 HTML 比 lastmod 新 → 問題確認(rèn)# 4. 改完驗證 CDN 緩存狀態(tài)curl-sIhttps://www.example.com/sitemap.xml|grep-icf-cache-status經(jīng)驗總結(jié)lastmod 必須和內(nèi)容同步更新——每次改完頁面順手更新 sitemap 里對應(yīng)條目的 lastmod30 秒的事CDN 緩存是隱藏坑——改完一定要查 cf-cache-statusHIT 就 Purge爬蟲日志是最好的診斷工具——抓了什么路徑比來了多少次信息量大得多只看次數(shù)很容易被爬蟲來過誤導(dǎo)更新 sitemap 后可以主動提交——搜索引擎站長平臺的手動提交/資源提交功能配合新 lastmod能加速爬蟲的重新抓取收錄慢的時候與其懷疑內(nèi)容質(zhì)量不如先確認(rèn)爬蟲有沒有真正看到你的更新。一個過期的 lastmod能讓所有內(nèi)容更新都白做。作者達(dá)哥專注 GEO 技術(shù)研究和 AI 落地實踐。延伸閱讀 官網(wǎng)https://www.matrixengine.site/ 百度百科https://baike.baidu.com/item/矩陣引擎重慶智能科技有限公司?? 知乎https://www.zhihu.com/people/da-ge-ai-zhuan-xing CSDNhttps://blog.csdn.net/matrix_E 百家號搜索「達(dá)哥AI轉(zhuǎn)型」 sitemap_lastmod陷阱
內(nèi)容更新了但爬蟲就是不抓檢查一下 sitemap 的 lastmod一個真實的排查案例網(wǎng)站上線兩個月百度收錄為零。更詭異的是——明明內(nèi)容一直在更新爬蟲日志顯示 Bytespider 和 Baiduspider 都來過但就是只抓首頁子頁面一個都不碰。排查到最后問題出在一個幾乎沒人注意的字段上sitemap.xml 里的lastmod?，F(xiàn)象爬蟲來了但只抓首頁先從服務(wù)器日志看爬蟲行為nginx access log# Baiduspider 訪問記錄 [21/Jul/2026:14:36] GET / HTTP/1.1 200 [27/Jul/2026:11:19] GET / HTTP/1.1 200 [28/Jul/2026:11:57] GET / HTTP/1.1 200 [29/Jul/2026:13:54] GET / HTTP/1.1 200 [01/Aug/2026:04:05] GET / HTTP/1.1 200 [01/Aug/2026:04:05] GET /xiaohongshu_v2.jpg HTTP/1.1 200 # Baiduspider-render 渲染時抓圖片 # Bytespider 訪問記錄 [02/Aug/2026:22:03] GET /sitemap.xml HTTP/1.1 200 [02/Aug/2026:22:13] GET /robots.txt HTTP/1.1 200規(guī)律很明顯Baiduspider 反復(fù)抓首頁GET /偶爾帶 render 爬蟲深度渲染但從不深入子頁Bytespider 只抓 sitemap.xml 和 robots.txt抓完就走了子頁面/methodology.html、/products.html 等一個都沒被訪問過按經(jīng)驗這種抓首頁但不深入通常有三個嫌疑robots.txt 誤攔、頁面內(nèi)鏈?zhǔn)А⒒蛘摺猻itemap 的新鮮度信號過期了。排查先排除常規(guī)嫌疑1. robots.txt 檢查User-agent: * Allow: / Sitemap: https://www.example.com/sitemap.xml全放行沒問題。2. 頁面可達(dá)性檢查curl -s -o /dev/null -w %{http_code} https://www.example.com/methodology.html # 200子頁面本身沒問題3. 爬蟲 UA 內(nèi)容一致性# 瀏覽器 UA 和爬蟲 UA 拿到的字節(jié)數(shù)對比 curl -sL -A Mozilla/5.0 https://www.example.com/ | wc -c # 105414 curl -sL -A Bytespider https://www.example.com/ | wc -c # 105414 curl -sL -A Baiduspider https://www.example.com/ | wc -c # 105414三個一樣CDN 沒有對爬蟲截斷內(nèi)容。根因sitemap 的 lastmod 過期了最后回到 sitemap.xml 本身。一看就明白了urlsetxmlnshttp://www.sitemaps.org/schemas/sitemap/0.9urllochttps://www.example.com//loclastmod2026-07-21/lastmod!-- ← 問題在這 --/urlurllochttps://www.example.com/methodology.html/loclastmod2026-07-21/lastmod/url.../urlset8 個頁面的 lastmod 全部停在 7 月 21 日但網(wǎng)頁文件的實際修改時間是 8 月 3 日。也就是說內(nèi)容更新了但 sitemap 還在對爬蟲說這個站 7 月 21 號之后沒變過。而爬蟲尤其 Bytespider的工作機(jī)制是先訪問 sitemap.xml比較lastmod和它緩存里的上次抓取時間只有 lastmod 比上次更新才去抓對應(yīng)的內(nèi)容頁lastmod 沒變 → 認(rèn)為內(nèi)容沒更新 → 跳過所以日志里的現(xiàn)象就完全解釋通了8 月 2 日 22:03 Bytespider 來抓 sitemap.xml看到 lastmod 還是 7 月 21 日覺得沒有新內(nèi)容掉頭就走了。你更新的那些 HTML 頁面它根本沒機(jī)會看到。修復(fù)更新 lastmod 并驗證把 sitemap.xml 里所有l(wèi)astmod改成最新日期和實際內(nèi)容更新時間一致# 修改前先備份cp/var/www/html/sitemap.xml /var/www/html/sitemap.xml.bak# 更新 lastmod8 個頁面全改成 2026-08-03# 建議用腳本逐個替換不要手寫避免格式錯誤改完驗證三個層面1. 服務(wù)器文件層面grep-clastmod2026-08-03/lastmod/var/www/html/sitemap.xml# 8全部更新成功2. 線上訪問層面curl-shttps://www.example.com/sitemap.xml|greplastmod# 8 個 2026-08-033. CDN 緩存層面curl-sIhttps://www.example.com/sitemap.xml|grep-icf-cache-status# 如果是 DYNAMIC說明 CDN 不緩存這個文件爬蟲每次都能拿到最新版無需清緩存# 如果是 HIT需要在 CDN 面板 Purge 一下否則爬蟲拿到的還是舊文件這一步很關(guān)鍵如果你的 sitemap 在 CDN 里被緩存了cf-cache-status: HIT光改服務(wù)器文件沒用爬蟲拿到的是 CDN 里的舊副本必須 Purge。如果顯示 DYNAMIC說明每次回源改完立即生效。復(fù)盤為什么這個坑容易踩階段你以為的狀態(tài)爬蟲看到的狀態(tài)更新 HTML內(nèi)容更新了頁面變了如果它來抓的話不更新 sitemap沒關(guān)系反正有 sitemaplastmod 還是舊的 → 判斷無新內(nèi)容 → 不抓更新 sitemap lastmod通知爬蟲有新內(nèi)容觸發(fā)對內(nèi)容頁的重新抓取根因是sitemap 的 lastmod 是爬蟲判斷是否值得抓取的核心信號它必須和實際內(nèi)容更新時間同步。內(nèi)容改了lastmod 不跟著改等于把更新藏起來了。排查清單可直接復(fù)用遇到內(nèi)容更新了但收錄沒動靜按這個順序查# 1. 爬蟲到底來沒來、抓了什么# 服務(wù)器日志里分別統(tǒng)計兩個爬蟲的訪問路徑grep-ibaiduspider /var/log/nginx/access.log|awk{print $7}|sort|uniq-cgrep-ibytespider /var/log/nginx/access.log|awk{print $7}|sort|uniq-c# 如果只有 / 和 /sitemap.xml沒有內(nèi)容頁 → 大概率是 lastmod 問題# 2. sitemap lastmod 是否和內(nèi)容更新時間一致curl-shttps://www.example.com/sitemap.xml|greplastmod# 3. 服務(wù)器上 HTML 文件的真實修改時間ls-la/var/www/html/*.html|head# 對比 lastmod如果 HTML 比 lastmod 新 → 問題確認(rèn)# 4. 改完驗證 CDN 緩存狀態(tài)curl-sIhttps://www.example.com/sitemap.xml|grep-icf-cache-status經(jīng)驗總結(jié)lastmod 必須和內(nèi)容同步更新——每次改完頁面順手更新 sitemap 里對應(yīng)條目的 lastmod30 秒的事CDN 緩存是隱藏坑——改完一定要查 cf-cache-statusHIT 就 Purge爬蟲日志是最好的診斷工具——抓了什么路徑比來了多少次信息量大得多只看次數(shù)很容易被爬蟲來過誤導(dǎo)更新 sitemap 后可以主動提交——搜索引擎站長平臺的手動提交/資源提交功能配合新 lastmod能加速爬蟲的重新抓取收錄慢的時候與其懷疑內(nèi)容質(zhì)量不如先確認(rèn)爬蟲有沒有真正看到你的更新。一個過期的 lastmod能讓所有內(nèi)容更新都白做。作者達(dá)哥專注 GEO 技術(shù)研究和 AI 落地實踐。延伸閱讀 官網(wǎng)https://www.matrixengine.site/ 百度百科https://baike.baidu.com/item/矩陣引擎重慶智能科技有限公司?? 知乎https://www.zhihu.com/people/da-ge-ai-zhuan-xing CSDNhttps://blog.csdn.net/matrix_E 百家號搜索「達(dá)哥AI轉(zhuǎn)型」