站点运营

站点运营:主机名与 www 规范化自查,别让同一站在两个入口各自为政

同一套内容如果同时能从 example.com、www.example.com、http 版本甚至 IP 访问,抓取、权重和日志统计都会被摊薄。本文给出一份可落地的自查清单,从 301 跳转、canonical、内链写法、Cookie 作用域到 CDN 回源,帮你把入口收敛到唯一主机名。

站点运营

站点运营:主机名与 www 规范化自查,别让同一站在两个入口各自为政

先想清楚:你希望蜘蛛从哪个入口进来

一个站点通常能通过多种写法访问:带 www 和不带 www、http 与 https、主域名与别名域名,甚至直接用 IP。省事的做法是全都留着能打开,代价是同一份内容被当成多份资源:抓取量被分摊,外链权重被拆开,服务器日志里同一个页面出现好几条来源,统计时很难判断哪条数据是真的。

规范化要做的就是选定一个首选主机名,把其他写法用 301 一次性归拢过去。下面这份清单可以按顺序过一遍。

跳转层自查

首选主机名与 301

  • 明确选定 https 加 www 或 https 加非 www 其中之一,写进团队文档,不要今天一个样明天一个样。
  • 其余变体全部 301 到首选,避免用 302、307 长期顶着,这类跳转不传递规范化信号。
  • 尽量让 http 版本一步跳到最终的 https 首选地址,而不是先到 https 再去 www,链式跳转会让每次抓取多花一轮往返。
  • 跳转要覆盖到具体路径,而不是一律回首页,否则内页的外链和收录信号会被丢掉。

服务器默认站与 IP 访问

  • 检查 Nginx 的 server_name 或 Apache 的 VirtualHost 是否有兜底配置,未匹配的主机名会不会返回正常页面。
  • 用 IP 直接访问时,建议返回 403 或 301 到首选域名,不要让 IP 也能渲染完整站点。
  • 如果站点挂在 CDN 后面,确认回源时发送的 Host 头以及缓存键是否包含主机名。

页面层自查

canonical 与内链一致性

  • canonical 使用绝对地址,并且指向首选主机名,不要写成当前访问的变体,否则等于自我否定。
  • 模板里生成 canonical 时留意变量有没有被替换,批量出现的错误往往比单个页面更难排查。
  • 站内导航、面包屑、正文链接、Sitemap、RSS 统一使用首选域名,避免同一页在不同位置出现两种写法。
  • 抽查一批内页,看有没有硬编码的老域名残留,尤其是历史文章和专题页。

Cookie 与安全设置

  • Cookie 的 Domain 不要随手写成 .example.com 这种带点的形式,这样 www 与各子域会共享,容易把测试态带进正式访问。
  • 提交 HSTS 前确认所有子域都已全量 HTTPS,否则会把还在用 http 的子域直接挡在门外。
  • 证书要覆盖实际在用的所有主机名,包括 www 与别名域名,别让某个入口先弹安全告警。

验证时看什么

  1. 用 curl 带上 -I 分别请求 http、https、www、非 www 和 IP,逐个记录状态码与 Location,确认最终都指向同一个地址。
  2. 看一段时间的访问日志,按 Host 字段分组统计,正常情况下非首选主机的请求量应该趋近于零。
  3. 在搜索资源平台只验证首选主机名即可,验证一堆变体只会让自己更乱。
  4. 随机抽 20 个内页,检查标题、canonical 与内链是否都落在首选域名上。
常见坑:只给首页做了跳转,内页仍能通过旧主机名打开;canonical 模板批量生成时出错;子域被 301 到主域,但子域本身还有独立业务;测试域名与正式域名共用一张证书。

主机名规范化不是一次性任务,它更像一条底线:改服务器配置、换 CDN、新增子域时,都顺手回归检查一遍跳转和 canonical。入口收敛之后,日志看得清,抓取也不会再被同一份内容重复消耗。