做站点运营时，大家习惯盯着頁面上的标题、正文和内鏈，却很少打開浏览器開發者工具里的 Network 面板。服務器返回的响應头虽然不直接顯示给訪客，但它會告诉浏览器和搜尋引擎這個頁面是什么類型、能不能索引、要不要缓存。几個字段配错，可能让整站抓取出問题。

一、Content-Type 與字符集

响應头里的 Content-Type 應该同时声明 MIME 類型和字符集，例如 text/html 加上 charset=utf-8。如果只寫 text/html 而頁面實际使用 UTF-8，浏览器可能靠猜测来解碼，出現乱碼；搜尋引擎解析时也可能出現标题、摘要截断或乱碼。

另一個常见問题，是把 HTML 頁面返回成 application/octet-stream 或 text/plain，導致浏览器直接下载文件或顯示源碼，訪問体驗和抓取都會受影响。

• 頁面里的 charset 声明是否與响應头一致，不要一個说 UTF-8、一個说 GBK。
• 模板是否混用了不同编碼，特別是老站点迁移過来的栏目。
• 图片、附件、PDF 的 MIME 類型是否正确，不要全部塞成 text/html。

二、X-Robots-Tag：藏在头部里的 noindex

X-Robots-Tag 可以在响應头里控制索引和抓取，作用類似頁面里的 meta robots，但優先級很高，而且不一定能在頁面上看到。最常见的誤配是：測試环境加了 noindex，上线时只删了頁面里的 meta，忘了删响應头；或者 CDN、反向代理统一加了一條 noindex，结果整站被挡。

反過来，有些站点想屏蔽後台或附件目錄，却把 noindex 加在了全站响應头里，核心内容也跟着一起被忽略。

• 確認 noindex、nofollow、noarchive 的作用范围是單頁、目錄還是全站。
• 检查源站、CDN、WAF 是否各自加過一组头，最终响應里可能叠加。
• 用 curl -I 查看最终响應，而不是只看源站配置。

三、缓存與重定向相關头

Cache-Control、Expires、ETag、Last-Modified 决定浏览器和 CDN 怎么缓存頁面。設定過長的强缓存，會让改版後的新内容迟迟不生效；設定過短，又會让每次訪問都回源，增加服務器压力。

重定向相關头里的 Location 要和狀態碼配合：301 表示永久搬家，302、307 表示临时跳轉。如果實际是永久換地址却返回了 302，搜尋引擎可能繼續保留舊地址，把抓取次數花在跳轉上。

四、自查步骤

1. 用 curl -I 或開發者工具查看目标頁面的最终响應头，確認狀態碼是 200。
2. 检查 Content-Type 是否包含正确的 charset。
3. 搜尋 X-Robots-Tag，確認没有意外的 noindex、nofollow、noarchive。
4. 看 Cache-Control 的 max-age、s-maxage，判断新内容多久能被訪客和蜘蛛看到。
5. 對首頁、栏目頁、詳情頁、附件、後台各抽一個样本，不要只看首頁。
6. 把响應头配置记錄在运营文档里，改模板、換 CDN 後复查一次。

五、几個容易踩的坑

• 只改頁面里的 meta robots，忽略服務器或 CDN 加的头。
• 把 404 頁面配成 200，或者把正常頁面配成 404，可以用狀態碼快速確認。
• HSTS、CSP 等安全头配置過嚴，導致部分资源加载失敗，影响頁面渲染。
• 多個中間层各自加了一组头，最终响應里出現重复字段。

响應头不是给訪客看的，但會直接影响浏览器和搜尋引擎怎么理解你的頁面。定期抽查，比出問题後再翻配置更省事。

站点运营里的很多問题，最後都能落到配置和頁面是否一致上。响應头自查不需要高深工具，一條 curl 命令加一張记錄表就够。把它放進上线检查清單，能减少很多看不见的麻烦。