什么是二级域名，同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e59d00480e9f.html
📄
什么是二级域名，同一地址因设备或登录状态返回不同内容怎样对照
结论先行：同一二级域名地址出现设备差异或登录态差异时，先不要急着改配置，而要先判断差异是“同一份内容的不同呈现”，还是“服务端真的返回了不同文档”。前者通常只需保留一套可抓取的规范版本；后者则要按差异来源分别处理，否则你修好的可能只是自己浏览器里的那一版。判断条件只有一个：用不携带 Cookie、不执行脚本的原始请求，看返回的 HTML 主体是否一致。若一致，问题多半在客户端渲染或个性化注入；若不一致，服务端就存在按条件分流。
先分清两类差异，再决定改哪一层
设备差异和登录态差异经常被混在一起，但代价完全不同。设备差异如果只是响应式布局、图片尺寸或脚本加载不同，HTML 主体往往相同，此时改动应落在模板和资源加载上，而不是内容本身。登录态差异则更危险：未登录访客看到的是介绍页，登录用户看到的是个人面板，两者可能共用同一个二级域名地址。
可以用一个假设例子说明对照方法。假设 shop.example.com 在手机浏览器显示商品列表，在桌面浏览器显示同一列表但排版不同，而登录后显示“我的订单”。这时应分别取三份原始响应：手机未登录、桌面未登录、桌面已登录。如果前两份的 HTML 主体一致，只有第三份不同，那么真正需要处理的是登录态分流，而不是设备适配。
用原始请求做对照，而不是靠浏览器观感
浏览器会带上 Cookie、执行 JavaScript、应用缓存和扩展，这些都会掩盖服务端的真实返回。对照时应使用不发送 Cookie 的请求，并关闭脚本执行，只看服务器返回的初始 HTML。具体动作是：对同一地址分别发起两次请求，一次带登录 Cookie，一次不带，保存两份响应体；然后比较标题、正文主体和指向自身的主链接是否一致。
这个动作的结果会直接决定下一步。如果两份响应体一致，说明差异来自客户端，你应去检查脚本注入和缓存策略，而不是改服务端路由。如果两份响应体不一致，说明服务端按登录态返回了不同文档，接下来要确认哪一份才是希望被外部访问到的版本，并让另一份不再以同一地址对外呈现。这一步不做，后面的规范链接和站点地图都可能是错的。
一个会让上述结论失效的反例
上面的判断依赖一个前提：两次原始请求之间没有其他变量。如果二级域名前面还有 CDN 或缓存层，同一地址可能因为缓存键包含设备类型或 Cookie 而返回不同副本。此时你看到的“服务端分流”可能只是缓存命中差异，而不是应用逻辑真的按登录态输出。反例是：不带 Cookie 的请求命中了旧缓存，带 Cookie 的请求绕过了缓存，两者内容不同，但源站逻辑其实一致。
遇到这种情况，先固定缓存条件再对照：清掉该地址的缓存，或在请求中加入绕过缓存的头，重新取两份响应。如果差异消失，问题在缓存键设计；如果差异仍在，才回到服务端分流处理。把缓存差异误判为登录态分流，会导致你去改根本不存在的路由规则。
对照之后，把结论落到一个可执行动作上
确认服务端确实按条件返回不同内容后，选择取决于你的目标。若希望外部访问者看到公开版本，就让未登录请求返回完整可读的公开内容，并让登录态内容通过独立路径或独立二级域名承载；若登录态内容本身就是唯一有效内容，则应让未登录请求返回明确的登录引导，而不是空白或错误页。两种做法都成立，区别在于你希望哪一类访问者获得完整体验。
动作落地后要再验证一次：用同样的原始请求方法重取响应，确认公开版本不再随登录态变化。这个结果会影响下一步——只有在公开版本稳定后，再去检查站点地图和内部链接指向的是不是这个版本。站点地图不保证收录，robots.txt 的抓取限制也不等于可靠的索引移除，所以不要用它们替代对返回内容的直接对照。
把对照变成可复查的记录
为了避免下次改动后无法判断是否回归，建议每次对照都保留三样东西：请求是否携带 Cookie、请求是否执行脚本、响应体中标题与主链接的原文。用这些记录比较不同时间点的返回，而不是凭记忆判断。若某次请求量或抓取量突然归零，也不能单独证明处理正确，它可能是缓存、日志采样或访问路径变化造成的，需要结合响应体对照一起看。
当设备差异和登录态差异同时存在时，优先固定登录态这一变量，再比较设备。因为登录态改变的是文档本身，设备通常只改变呈现。先解决文档层面的不一致，再处理呈现层面的适配，顺序反了会反复返工。最终要留下的，是一个不依赖特定设备或登录状态、可被稳定取到的公开版本，以及一份能说明当时请求条件的对照记录。
