📍 WDQWDWQD987AAAAA:216.73.217.105
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a39fba510f2a.html
📄

主域名选择：同址因设备或登录态返回不同内容怎样对照

先给结论：同一地址在不同设备或登录状态下返回不同内容，通常不是“主域名选错了”，而是主域名在服务端被做了条件分发。对照时不要只比较页面截图，要先固定对照维度：同一路径、同一请求头、同一登录态，再分别记录状态码、重定向链、响应正文和关键资源。只有把差异落到可复现的请求上，才能判断该保留哪个版本、该让哪个版本退出。

下面用一个明确标注为假设的情境串联决策过程，方便你套用到旧内容、旧系统或旧合作关系需要退出的场景。

假设情境：旧活动页在新设备上变成登录引导

假设某主域名下有一个旧活动路径 /campaign/legacy，桌面端未登录访问时返回完整活动页，移动端未登录访问时却返回登录引导；同一账号登录后，桌面端和移动端又都返回完整活动页。此时不能直接说“移动端坏了”，因为差异可能来自设备识别、登录态判断、缓存分片或边缘规则，而不是内容本身被删除。

这个情境的关键是：旧内容仍有价值的部分可能只是活动说明和条款，而参与入口已经下线。主域名选择在这里不是换域名，而是决定这个路径继续由谁响应、响应什么。

第一步：固定请求变量，建立可对照的请求组

不要同时改设备、账号和网络。先选一个路径，建立至少四组请求：桌面未登录、移动未登录、桌面已登录、移动已登录。每组记录以下字段：

• 请求的完整 URL 与查询参数；
• User-Agent 与是否携带登录 Cookie；
• 响应状态码与重定向链；
• 响应正文中是否出现活动主体内容；
• 关键 CSS、JS、图片是否返回同一版本。

如果只有移动未登录返回登录引导，而移动已登录返回活动页，那么差异更可能来自登录态判断，而不是设备本身。反过来，如果四组都返回登录引导，只是桌面未登录偶尔返回活动页，则要怀疑缓存分片或边缘节点不一致。

实际动作：把四组请求各重复三次，间隔一段时间。结果如何影响下一步：若同一组三次结果不稳定，先查缓存与边缘规则，不要急着改主域名解析；若同一组三次稳定但组间不同，进入下一步查服务端分发逻辑。

第二步：区分设备差异、登录态差异与缓存差异

设备差异的典型证据是：请求头里的 User-Agent 变化后，响应正文主体随之变化，且变化可重复。登录态差异的典型证据是：只切换 Cookie 或会话标识，响应正文主体就切换。缓存差异的典型证据是：同一请求头下，不同时间或不同节点返回不同版本，且响应头里出现缓存命中或分片标识。

假设你发现移动未登录请求命中了旧缓存，而移动已登录请求绕过缓存。此时问题不在主域名选择，而在缓存键没有把登录态纳入区分。你需要决定：是让未登录也返回活动页，还是让未登录统一返回登录引导。这个决定取决于旧内容中仍然有价值的部分是否必须对未登录用户可见。

如果活动条款必须公开可见，那么让未登录返回登录引导就是错误的退出方式；如果参与入口已经关闭，只保留说明页，那么让未登录返回说明页比返回登录引导更合理。

第三步：用对照结果决定保留、重定向还是移除

对照完成后，通常只有三种处理方向：

1. 保留并统一：所有设备与登录态都返回同一版本。适用于旧内容仍有公开价值，且不需要登录才能阅读。
2. 重定向到新位置：把旧路径 301 到主域名下新的有效路径。适用于旧内容已被新页面完整替代，且新页面可公开访问。
3. 移除并返回合适状态：对已无保留价值的内容返回 410 或 404。适用于旧系统退出、旧合作关系结束，且没有可替代页面。

这里要特别注意：robots.txt 的抓取限制不等于可靠的索引移除。即使你在 robots.txt 里禁止抓取该路径，搜索引擎仍可能因为外部链接而保留旧 URL 的索引摘要。站点地图也不保证收录，它只是提示，不是移除工具。HTTPS 同样不保证内容安全无漏洞或排名，它只解决传输层加密。

实际动作：如果决定重定向，先确认目标页面与旧路径主题一致，再检查重定向链是否只有一跳。结果如何影响下一步：若重定向链超过一跳，先修链再提交，否则对照结果会被中间跳转掩盖。

第四步：退出旧系统时，保留仍然有价值的部分

旧系统退出往往不是整站关停，而是部分路径继续服务。假设旧活动页里的条款和常见问题仍有价值，但报名表单已经失效。此时可以保留条款和常见问题，把报名入口替换为说明文字或指向新流程的链接，而不是整页返回登录引导。

判断“仍然有价值”的依据不是页面是否还有流量，而是：内容是否仍准确、是否仍对用户有参考意义、是否有外部链接指向它、是否能用更低成本维护。如果内容已过时且无人维护，移除比保留更合理。

对于登录态差异，还要考虑：未登录用户是否应该看到同一内容。如果内容本身不敏感，强制登录只会让对照结果更复杂，也会让旧内容的价值无法被未登录用户获取。

对照时容易误判的几种情况

请求量、抓取量或某项统计归零，不能单独证明你的处理正确。归零还可能来自：统计工具未加载、路径被重定向后统计未跟随、缓存导致请求未到达源站、或外部链接自然减少。需要结合状态码、重定向链和正文对照一起判断。

另外，不同搜索引擎对登录态、重定向和移除请求的支持情况须分别核查，不能用一个平台的表现推断另一个平台。主域名选择在这里的落点是：同一主域名下，不同路径可以有不同的退出策略，但对照方法必须一致。

如果你已经完成四组请求对照，下一步不是立刻改 DNS 或换主域名，而是先修服务端分发逻辑，让同一路径在不同设备与登录态下返回可预期的结果。只有预期结果稳定后，保留、重定向或移除的决定才有可靠依据。