站点运营

站点运营:Sitemap 自查,別让蜘蛛拿着一張過期或残缺的地图

Sitemap 不是上线时生成一次就能一劳永逸的文件。本文梳理站点地图常见的几種失效狀態,從 XML 格式、訪問狀態、URL 收錄范围、生成與更新时机,到提交後的效果驗證,给出一份可以照着做的自查清單,帮运营者把這份“地图”维持在真正可用的狀態。

站点运营

站点运营:Sitemap 自查,別让蜘蛛拿着一張過期或残缺的地图

Sitemap(XML 站点地图)是站点主動递给搜尋引擎的一份 URL 清單。它不能保證頁面被收錄,但能减少蜘蛛“找不到路”的概率。問题在于,很多站点的 Sitemap 是建站时生成一次、之後再也没有人看過——里面可能還留着改版前的舊地址,也可能漏掉了後来新增的全部内容。

先確認 Sitemap 目前處于哪種狀態

用浏览器直接訪問自己的 Sitemap 地址,通常就能看出問题大概出在哪一類。

  • 打不開:返回 404、403 或 5xx,蜘蛛每次訪問都是空手而归。
  • 能打開但内容陈舊:最上面還是几個月前的地址,新發布的頁面一個都没有。
  • 混入不该出現的地址:登入頁、站内搜尋结果頁、带參數的篩選頁、測試目錄,全被塞了進去。
  • 地址本身寫错:寫成相對路径、带端口、用 http 而站点已经是 https,或者域名大小寫不一致。

這几類問题不需要額外工具,人工点開看一遍就能發現大部分。

格式與訪問狀態自查

Sitemap 本身是一份 XML 文件,格式出错會让整份文件被判為無效,而不是“只跳過某一行”。自查时按下面的顺序過一遍:

  1. 確認头部的 XML 声明與 urlset 命名空間完整、标簽閉合正确。少一個閉合标簽,整份地图都可能作废。
  2. 每一條 loc 都應是完整绝對地址,包含协议和域名,不要寫相對路径,也不要把 http 與 https 混用。
  3. lastmod 尽量填真實的修改時間,不要全站统一寫当天。如果维護不過来,宁可不填,也比填错好。
  4. changefreq 和 priority 目前不是主流搜尋引擎的重要依據,填了不有害,但没必要把全站 priority 都设成 1.0。
  5. 控制文件体积。單個 Sitemap 一般建议不超過 5 萬條 URL、解压後不超過 50MB,超出就拆分。

内容范围:哪些 URL 该進,哪些不该進

  • 该進:希望被索引的正文頁、栏目首頁、必要的聚合頁。
  • 不该進:登入註冊頁、购物车、站内搜尋结果頁、带排序或篩選參數的頁面、測試與暂存目錄。
  • 谨慎處理:分頁的第二頁及以後、标簽頁與日期归档頁。數量不大时可以保留,數量庞大則容易摊薄抓取预算。
  • 信号冲突:已設定 noindex 的頁面不要放進 Sitemap,两個指令互相矛盾,只會让蜘蛛白跑一趟去確認。

生成方式與更新时机

靠手工维護的 Sitemap 迟早會過期。更現實的做法是让它跟着内容系統自動生成,並约定好触發时机:

  • 發布新内容时增量寫入,而不是等定时任務统一跑一次。
  • 頁面刪除或下线时同步移除,避免地图里留下已经 404 的地址。
  • URL 结构或域名發生變更时,重新生成全部地址,並保留舊地址的跳轉。

如果站点内容量不大,也可以固定每周检查一次,人工確認新增和刪除是否都反映進去了。

把 Sitemap 当成一份要和站点一起持續更新的文档,而不是一次性的上线任務。

提交之後怎么驗證有没有生效

提交只是開始,之後要看的是蜘蛛有没有真的按图索骥:

  1. 在搜尋资源平台的报告里看已提交、已抓取、有错誤這三類條數的變化趋势。
  2. 把服務器日誌中蜘蛛抓取的 URL 與 Sitemap 里的 URL 做個简單對比,判断覆盖情况。
  3. 如果長期“已提交却几乎没有抓取”,先回头確認 robots.txt 是否屏蔽了 Sitemap 本身或它所在的目錄。
  4. 新站或改版站可以观察一到两周。若抓取量始终没有起色,再往内容质量和内部連結方向找原因。

Sitemap 解决的是“告不告知”的問题,頁面最终能不能被收錄,還是取决于内容本身和站点整体结构。把它当作基础设施维護好,不必指望它單獨带来什么奇迹。