同一个页面通过两个域名都能打开,正文看起来一模一样,但响应头不同,最直接的影响是:你无法只凭“页面内容相同”判断哪个是首选域名,也不能据此判断重复内容已经处理干净。可核对的做法是,把两个响应头并排比对,重点看状态码、Location、Content-Location、Link和Vary这几项,再决定下一步是改跳转、改规范标签,还是先停手。
面对两个域名返回同一份正文,先把分歧拆开:第一层是正文是否一致,第二层是响应头是否一致,第三层是站内链接指向哪个域名。三层里只有第一层一致,说明不了后两层。不同角色说“页面是一样的”,往往是在说第一层;而技术侧看的是第二层和第三层。
把资料转成可执行清单,可以先做这三步:
只有这三步的结果放在一起,才能判断两个域名是“同一个站点的两个入口”,还是“两个各自独立、但内容碰巧相同”的站点。这个判断决定了后续动作完全不同。
假设你手上有A、B两个域名的同一路径响应头,可以按下面的顺序读,而不是先看正文。
如果A返回200、B也返回200,说明两个域名都在直接提供内容,没有在响应头层面做归一。如果B返回301且Location指向A,说明B在向A归并。这时要确认:301是永久还是临时,Location是否指向同一路径而非首页。指向首页的301会把所有路径压到一个地址,和逐路径归并是两种不同处理,后续判断规范标签是否还有意义,要先看这一点。
这两个头在某些实现里会被用来表达“这个内容的规范地址在哪”。如果A的响应头里Content-Location指向B,而正文里的规范链接指向A,两者互相矛盾。这种矛盾本身就是一条证据:它说明不同层(响应头层、正文层)对首选域名的表达不一致,此时不应直接判定“已设置好”,而应先统一表达口径。
如果响应头里有Vary,且值涉及Host或与域名相关的请求头,说明同一路径可能因请求头不同而返回不同结果。这种情况下,你抓到的两个响应头未必代表全部情况。下一步应固定请求头再抓一次,确认差异是域名造成的,还是请求头造成的。
假设某站有example.com和www.example.com两个域名,两条路径都返回200,正文完全一致,正文规范链接都写example.com,但www的响应头里带Content-Location指向example.com,而example.com的响应头里没有这一项。此时可以得到的判断是:正文层已表达首选为example.com,响应头层只有一侧表达。这个差异不会因为“正文一样”而消失。
对应的动作是:先确认站内链接和站点地图里用的是哪个域名,再决定是让www侧统一补上归并信号,还是直接改成301。动作做完后,重新抓一次两个响应头,看Status、Location、Content-Location是否已经指向同一方向。如果仍不一致,说明改动没有落到响应头层,下一步就不该继续改正文,而应回到服务器或CDN配置。
页面内容相同、响应头不同,不能推出“重复内容已经解决”,也不能推出“首选域名已经生效”。规范标签是提示,不是强制指令;301是响应头层的归并,但也不等于抓取和索引一定按你预期走。robots.txt的抓取限制不等于可靠的索引移除,站点地图不保证收录,HTTPS也不保证安全无漏洞或排名。这些都要分别核查,不能因为两个页面正文一样就跳过。
还需要注意:请求量、抓取量或某项统计归零,不能单独证明处理正确。它也可能是抓取预算变化、日志采样、CDN缓存或监控口径变化造成的。要判断归并是否生效,应把响应头比对、站内链接指向、规范标签三者放在一起看,而不是只看一个数字。
当多个角色对“哪个是首选域名”有不同理解时,最有效的做法不是继续争论,而是把这条判断写成一个可核对的验收项:同一路径在两个域名下的状态码、Location、Content-Location、正文规范链接、站内链接指向,是否全部指向同一域名。全部一致才算通过;有一项不一致,就记录为待处理项,并注明它属于响应头层还是正文层。
这样做的结果是:下一步动作有明确入口。响应头层不一致,改服务器或CDN;正文层不一致,改模板或内容;链接层不一致,改导航和站点地图。三层分开处理,才不会出现“正文改了但响应头没改,于是判断依旧矛盾”的情况。不同搜索引擎对响应头和规范信号的支持情况须分别核查,不能拿一个渠道的观察结果直接套到另一个渠道。