uaredirect.js时代终结：百度SiteApp下线复盘、JS跳转的SEO灾难、DedeCMS响应式改造完整迁移路径

原文这段 uaredirect.js 是百度 SiteApp 平台 2012 年推出的脚本，用 JS 检测浏览器 UserAgent，识别移动设备就跳转到 m. 子域名。当年织梦 / DiscuzX / 帝国 CMS 几乎所有"PC + 手机分站"教程都引用这个文件。但有两件事让原文写法在 2026 年已经不能用：第一，百度 SiteApp 项目 2018 年下线，http://siteapp.baidu.com/static/webappservice/uaredirect.js 已经 404，远程引用直接挂掉；第二，Google Mobile-First Indexing 之后 m. 子域名 + UA 跳转的方案被搜索引擎视为反模式，对 SEO 是慢性毒药。这篇文章把 uaredirect.js 源码逐行拆开，标出隐藏 bug、UA 识别的边界场景、JS 跳转的 SEO 灾难、然后给出 2026 年的现代替代方案——响应式设计 + 服务端 301 + canonical/alternate 声明的完整迁移路径。

uaredirect.js 的历史与下线

百度 SiteApp（站长工具下的"百度移动建站"功能）2012 年上线，目标是给没钱做手机版的中小站长一键生成移动适配。生成的服务包括两块：

• 云端转码：百度服务器抓取 PC 版页面，自动转码成手机版（类似 Google Mobilizer）。
• JS 跳转：uaredirect.js + isSubdomain() 函数，让站长在 PC 版里嵌入一段 JS，检测移动端 UA 自动跳到 m. 子域名（自建的或百度托管的）。

2015 年百度宣布 SiteApp 转型，2017 年开始限制新接入，2018 年彻底下线。siteapp.baidu.com 域名仍解析（指向百度静态页"功能下线公告"），但子路径 /static/webappservice/uaredirect.js 已经 404。任何还在引用这个远程脚本的站点都会触发"等待 30 秒超时 → 报错 → 后续 JS 阻塞"的连锁反应——这是原文为什么强调"网站打开速度缓慢"的根因。

Web Archive（archive.org）还能找到 uaredirect.js 的多个历史版本，跨度 2013–2018。版本之间差异很小，主要是修了几个 IE 兼容 bug 和加了 fromapp hash 标记防循环。原文给的源码是 2015 年版本的精简化。

uaredirect.js 源码逐行拆解

主函数 uaredirect(f)

function uaredirect(f) {
    try {
        if (document.getElementById("bdmark") != null) {
            return
        }
        // ...
    } catch(d) {}
}

第一行 document.getElementById("bdmark") 检测页面里是否已经有 id="bdmark" 的元素。这是为什么？因为百度 SiteApp 转码服务器抓取 PC 页面后会自动注入一个隐藏 div <div id="bdmark" style="display:none"></div>，标记"这个页面已经被百度转码"。如果 uaredirect 在转码后的页面再次执行（被搜索引擎转码缓存），bdmark 存在直接 return，避免无限重定向循环。

2018 年 SiteApp 下线后，再也没有页面会被注入 bdmark——这段判断在现在等于死代码。但保留它没害处，因为遗留站点可能仍依赖。

外层 try-catch 静默吞掉所有异常。这是浏览器兼容代码常见做法——某些老 IE 不支持 location.replace 或 navigator.userAgent，与其报错不如沉默。但代价是调试很痛苦：脚本不工作时连 Console 都没有错误信息，只能逐行注释来定位。

子域名检测分支

if (arguments[1]) {
    var e = window.location.host;
    var a = window.location.href;
    if (isSubdomain(arguments[1], e) == 1) {
        f = f + "/#m/" + a;
        b = true
    } else {
        if (isSubdomain(arguments[1], e) == 2) {
            f = f + "/#m/" + a;
            b = true
        } else {
            f = a;
            b = false
        }
    }
} else {
    b = true
}

这段是判断"目标移动版 URL 与当前 PC 域名的关系"。三种情况：

• isSubdomain == 1：完全相同域名（极少见，通常表示 m. 跳到 m.）。
• isSubdomain == 2：当前是目标的子域名（PC 是 www.xxx.com，目标是 xxx.com 的 m. 子域名）。
• isSubdomain == 0：完全不同域名（比如 PC 是 a.com，跳 m.b.com，跨站跳转）。

case 1 和 case 2 都拼接 "/#m/" + 当前 URL——这是百度 SiteApp 转码 URL 的格式：把当前页面 URL 当成 anchor 拼到目标 m. 域名后面，转码服务收到后从 anchor 解析出原页面再去抓取转码。

原文用法不传 arguments[1]：

uaredirect(window.location.href.replace("www.","m."));

只传一个参数 f，arguments[1] 是 undefined，进 else 分支 b = true——直接跳。这是简化版，跳过子域名判断，假设目标 m. 域名能正常处理 URL 映射。这种用法的隐患：如果当前 URL 不是以 www. 开头（比如直接访问 https://xxx.com/page），replace("www.","m.") 不替换任何东西，f 还是当前 URL，触发"跳到自己"。修复：

var target = window.location.host.indexOf('www.') === 0
    ? window.location.href.replace("www.", "m.")
    : window.location.protocol + "//m." + window.location.host + window.location.pathname + window.location.search;
uaredirect(target);

UA 检测部分

if (b) {
    var c = window.location.hash;
    if (!c.match("fromapp")) {
        if ((navigator.userAgent.match(/(iPhone|iPod|Android|ios)/i))) {
            location.replace(f)
        }
    }
}

核心是 navigator.userAgent.match(/(iPhone|iPod|Android|ios)/i) 这个正则。命中就 location.replace(f) 跳转。

fromapp hash 检测：移动端用户从 m. 站点点链接回到 PC 页面（比如分享给桌面端朋友）时，URL 里加 #fromapp 标记表示"我从 app 来，不要再跳回 m."。这是防止"PC ↔ 移动"无限循环的关键。

UA 正则的边界场景：

• iPad 不在列表里。iPad UA 含 iPad 但不含 iPhone/iPod，所以 iPad 用户不会被跳转——这通常是预期行为（iPad 屏幕大，PC 版能正常浏览）。但 iPad mini 7 寸可能更适合 m. 版，原文没区分。
• Android 平板被强跳。Android 平板的 UA 含 Android，会被强制跳到 m.——但平板屏幕够大，跳到 m. 后体验更差。修复：检测 Android.*Mobile（手机 Android 才有 Mobile 关键字，平板 Android 没有）。
• iPad iOS 13+ 默认伪装成 macOS。2019 年 iOS 13 起，iPad Safari 默认 UA 被改成 Macintosh——为了让网站把 iPad 当 PC 处理。如果想识别 iPad，要检测 navigator.maxTouchPoints > 1 && /Mac/.test(navigator.userAgent)。
• 微信浏览器：含 MicroMessenger，UA 里同时有 iPhone 或 Android，所以会被跳。但微信内打开的页面跳到外站需要"在浏览器打开"才能看，体验差。微信内通常希望保持当前域名，可以加 !/MicroMessenger/i.test(ua) 例外。
• QQ / 微博 / 钉钉浏览器：类似微信问题，UA 含 QQ、Weibo、DingTalk。各自有独立的 webview，跳转后场景割裂。
• Chrome DevTools 模拟模式：调试时切换到 iPhone 模拟，UA 真的会变成 iPhone。开发期间会被频繁误跳。
• 折叠屏手机展开：三星 Galaxy Z Fold / 华为 Mate X 展开后屏幕超 7 寸，但 UA 仍是 Android Mobile。会被跳到 m. 版浪费屏幕。

isSubdomain 函数

function isSubdomain(c, d) {
    this.getdomain = function(f) {
        var e = f.indexOf("://");
        if (e > 0) {
            var h = f.substr(e + 3)
        } else {
            var h = f
        }
        var g = /^www./;
        if (g.test(h)) {
            h = h.substr(4)
        }
        return h
    };
    // ...
}

this.getdomain 是函数内部赋值给 this 的方法——但 isSubdomain 不是用 new 调用的，this 在严格模式下是 undefined，在非严格模式下指向 window。也就是说每次 isSubdomain 调用都会污染 window.getdomain 全局——典型的 2010 年代 JS 反模式。

g = /^www./ 这个正则有 bug：点号在正则里是"任意字符"，不是字面量点。www.example.com 会被匹配（点匹配任何字符），wwwa.com 也会被错误匹配（"wwwa" 中的 "a" 被点号匹配）。正确写法是 /^www\./。

h.substr(4) 假定 "www." 总是 4 个字符——但如果原 URL 是 wwwa.com 被错误识别为 www.开头，substr(4) 会切掉 "wwwa"，剩下 ".com" —— 后续 isSubdomain 比较时一定不匹配。

这些 bug 在 2015 年那个年代百度内部测试可能也没发现——因为业务场景非常窄（就是 www / m / wap 三个子域名互转），bug 没暴露。

JS 跳转的 SEO 灾难

这是原文方案最致命的问题，2026 年的 SEO 已经不能再这么做。

Google Mobile-First Indexing 后的内容索引规则

2018 年 Google 完成 Mobile-First Indexing 切换，主要索引依据从 PC 版改为移动版页面内容。如果 PC 和移动版分两个域名（www / m），Google 期望看到：

• PC 版每个页面有 <link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.example.com/page" /> 声明对应移动版 URL。
• 移动版每个页面有 <link rel="canonical" href="https://www.example.com/page" /> 声明权威 URL 是 PC 版。
• 服务端响应 vary: User-Agent 头，告诉 CDN 不同 UA 缓存不同内容。

uaredirect.js 全是 JS 跳转，三个声明一个都没有。Google 看到的情况：PC 页面没有 alternate，移动版页面（如果 Googlebot 直接访问）没有 canonical。两套页面对 Google 是完全独立的——同样的内容被拆成两份，关键词排名互相 cannibalize（自相残杀）。最终结果通常是 PC 版排名下降、m. 版根本进不了前 10。

JS 跳转 vs 服务端 301

2026 年的最佳实践：用响应式设计单 URL 解决所有设备。如果实在要分站（比如功能差异大），用服务端 301 + alternate / canonical 三件套。

JS 跳转触发的 GSC 警告

Google Search Console 在 Coverage 报告里会显示 JS 跳转相关的几类警告：

• Page with redirect (但未跟随)：Googlebot 抓取 PC 页面，发现含 location.replace 但没跟踪到目标。页面被标记为"已发现但未编入索引"。
• Crawled - currently not indexed：Googlebot 抓取了 m. 版本，但因为没有 canonical 不知道权威 URL，索引悬挂。
• Duplicate without user-selected canonical：同样内容在 www 和 m 都出现，Google 自己挑一个作 canonical（通常挑得不对）。

这些警告累积到一定数量，整个站点的"质量信号"被拉低。

2026 年的现代替代方案

方案 1：响应式设计（最优）

单一 URL，CSS @media query 控制布局。DedeCMS 改造响应式步骤：

1. 给 PC 模板的 head 加 <meta name="viewport" content="width=device-width, initial-scale=1.0">。
2. 把 fixed 宽度（width:1200px）改成 max-width + percentage（max-width:1200px; width:100%）。
3. 给 nav / sidebar / table 加 @media (max-width: 768px) 的折叠规则。
4. 图片用 srcset / sizes 声明多分辨率版本。
5. 测试：Chrome DevTools 切换设备模拟，验证 320px / 768px / 1024px / 1920px 四档布局。

响应式改造的工作量：纯 CSS 调整通常 2–5 天（看模板复杂度）。涉及 DOM 结构重写（比如 PC 是横向 tab，移动要纵向手风琴）的 5–10 天。一次投入终生受益，不需要再维护两套模板。

方案 2：服务端 UA 检测 + 301

如果一定要保留 m. 子域名（比如已积累 SEO 权重，迁移成本高），用 PHP 在服务端检测 UA 跳转：

// dedecms /include/common.inc.php 开头添加
$ua = $_SERVER['HTTP_USER_AGENT'] ?? '';
$isMobile = preg_match('/(iPhone|iPod|Android.*Mobile|Windows Phone)/i', $ua);
$isWeixin = preg_match('/MicroMessenger/i', $ua);
$isPCDomain = stripos($_SERVER['HTTP_HOST'], 'www.') === 0;

if ($isMobile && !$isWeixin && $isPCDomain) {
    $target = 'https://m.' . substr($_SERVER['HTTP_HOST'], 4) . $_SERVER['REQUEST_URI'];
    header("Vary: User-Agent");
    header("Location: $target", true, 301);
    exit;
}

关键点：

• Vary: User-Agent 头告诉 CDN / 浏览器缓存按 UA 区分缓存键。否则 CDN 第一次缓存了 PC 版，后续移动用户直接拿到 PC 版（或反之）。
• 301 而不是 302——301 传递 SEO 权重，302 不传。
• 排除微信浏览器（!isWeixin），避免微信内点 PC 链接被跳转后无法正常浏览。
• 用 Android.*Mobile 而非纯 Android，避免 Android 平板被误跳。

方案 3：rel="alternate" / rel="canonical" 双向声明（必加）

不管 JS 跳转还是服务端 301，都要给两版页面加双向声明。PC 版 head：

<link rel="alternate" media="only screen and (max-width: 640px)"
      href="https://m.example.com/path/to/page" />

m. 版 head：

<link rel="canonical" href="https://www.example.com/path/to/page" />

DedeCMS 模板里用 {dede:field name="aid"/} 或 {dede:field name="typelink"/} 拼出对应 URL。注意每个页面的 alternate / canonical 必须是 1:1 映射——首页对应首页、列表页对应列表页、详情页对应详情页，不能全站只指首页。

方案 4：sitemap 分别声明

给 sitemap 加移动声明：

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:mobile="http://www.google.com/schemas/sitemap-mobile/1.0">
    <url>
        <loc>https://m.example.com/page1.html</loc>
        <mobile:mobile/>
    </url>
</urlset>

提交两份 sitemap：www.example.com/sitemap.xml（PC 页面）+ m.example.com/sitemap-mobile.xml（移动页面）。Search Console 分别添加两个 property 监控。

DedeCMS 响应式模板改造的具体步骤

原文是 DedeCMS 教程，给出在 DedeCMS 上做响应式改造的步骤（替代 m. 子域名方案）：

模板路径规划

DedeCMS 模板在 /templets/yourtheme/。建议复制一份为 /templets/yourtheme-responsive/，在副本上改造，原模板保留作回滚。后台"系统 → 模板管理"切换。

viewport meta 与字体单位

在所有 head.htm（如果模板抽离了 head）加 viewport meta。把所有 px 字号改成 rem（基准 16px）：

html { font-size: 16px; }
@media (max-width: 768px) { html { font-size: 14px; } }
.article-title { font-size: 1.5rem; }  /* 而不是 24px */

栅格系统

DedeCMS 默认模板多用 table 或 float 布局。改成 flexbox 或 grid：

.layout {
    display: grid;
    grid-template-columns: 1fr 300px;
    gap: 30px;
}
@media (max-width: 768px) {
    .layout { grid-template-columns: 1fr; }
}

导航响应化

PC 横向菜单 → 移动汉堡菜单（前文 cid 114 的纯 CSS 折叠方案可直接用）。

图片响应

DedeCMS 上传的图通常单尺寸。改造：用 dede 的 thumb 函数生成多尺寸，配合 srcset：

<img src="{dede:field name='picname' function='thumb(@me, 800)'/}"
     srcset="{dede:field name='picname' function='thumb(@me, 400)'/} 400w,
             {dede:field name='picname' function='thumb(@me, 800)'/} 800w,
             {dede:field name='picname' function='thumb(@me, 1600)'/} 1600w"
     sizes="(max-width: 768px) 100vw, 800px">

301 m. 子域名到 www（关键步骤）

响应式改造完成后，旧 m. 子域名的所有 URL 必须 301 到 www 对应 URL。nginx 配置：

server {
    listen 80;
    server_name m.example.com;
    return 301 https://www.example.com$request_uri;
}

这一步保留了之前 m. 子域名积累的 SEO 权重——301 会把权重传递给目标 URL。

客户端 UA 检测的现代替代库

如果某些功能必须在客户端检测设备类型（比如 PWA 安装提示、APP 下载链接），不要再用 uaredirect.js 这种 2015 年的脚本。现代选择：

• UAParser.js：体积 17KB（min+gzip），支持 200+ 设备 / 浏览器 / OS 识别。维护活跃，npm 月下载 800 万。
• Bowser：体积 12KB，API 链式调用清晰。const browser = Bowser.getParser(window.navigator.userAgent); browser.getOSName()。
• navigator.userAgentData（Client Hints）：Chrome 90+ 内置 API，navigator.userAgentData.mobile 直接返回 boolean。最现代但 Safari 还不支持。
• CSS @media (pointer: coarse)：不靠 UA，靠输入设备能力检测。手机 / 平板触屏 = coarse，PC 鼠标 = fine。最语义化，但只能在 CSS 用，不能 JS 检测。

建议组合：CSS @media + navigator.userAgentData，老浏览器 fallback 到 UAParser.js。

百度 SiteApp 之外的同类项目历史

2012–2016 年有几个类似 SiteApp 的产品：

• 百度 SiteApp：2012 上线，2018 下线。
• 360 智能建站：类似产品，2019 关停。
• Google Mobilizer：2014 推出，2014 年底关闭。
• Bing Mobile Friendly：从未推出独立服务，整合到 Bing Webmaster Tools。

这些项目的共同问题：UA-based 自动适配在响应式设计普及后失去意义，且 SEO 副作用越来越明显。"两套域名 + UA 跳转"的时代已经结束。

常见问题解答

uaredirect.js 远程引用为什么失效？

百度 SiteApp 平台 2018 年正式下线，远程脚本 URL http://siteapp.baidu.com/static/webappservice/uaredirect.js 已经返回 404。如果还在引用这个远程地址，浏览器会等待响应直到超时（通常 30 秒），期间后续 JS 阻塞执行——表现为页面加载慢、白屏。修复方法：把脚本本地化到自己服务器（参考原文做法），或者更彻底——直接放弃 JS 跳转方案改用响应式设计。本地化只是把"加载慢"问题修了，没解决 SEO 灾难，建议彻底重构。

UA 检测正则 /(iPhone|iPod|Android|ios)/i 漏掉了什么？

主要漏掉：iPad（不在列表）、Windows Phone（虽然死了）、KaiOS / Tizen 等小众系统。误识别：iPad iOS 13+ 默认 UA 伪装成 Macintosh 不会被识别为移动；Android 平板（不带 Mobile 关键字的 Android）会被错误识别为手机；Chrome DevTools 模拟模式时开发者 PC 也会被识别为移动。修复：用 navigator.maxTouchPoints + window.innerWidth 配合判断，比纯 UA 可靠。或者直接放弃 JS 检测改用 CSS @media (pointer: coarse)。

Google Mobile-First Indexing 后还能用 m. 子域名吗？

能用，但必须做完全的双向声明。每个 PC 页面 head 加 link rel=alternate media=only screen and (max-width:640px) href=m. 对应URL；每个 m. 页面 head 加 link rel=canonical href=www. 权威 URL。响应头加 Vary: User-Agent。提交两份 sitemap（一份 PC 一份 mobile，mobile sitemap 用 mobile namespace 标记）。Search Console 添加两个 property 分别监控。任何一处缺失 Google 都可能误判内容重复。整个 setup 比响应式设计复杂得多——除非已经积累了大量 m. 域名的 SEO 权重不舍得放弃，否则推荐迁移到响应式。

uaredirect 跳转后能保留 query string 和 anchor 吗？

原文调用 uaredirect(window.location.href.replace(www., m.))——location.href 包含完整 URL（含 query string 和 hash），replace 只动域名部分，所以 query string 会保留。但 hash（#xxx）不会发到服务器（hash 是浏览器本地状态），如果目标 m. 站点的 SPA 路由依赖 hash，跳转后路由可能丢失。修复：在跳转 URL 拼接时显式带上 hash，let target = window.location.href.replace(www., m.) + window.location.hash;。但更稳妥的还是用响应式或服务端跳转。

uaredirect 与 SEO 蜘蛛识别有冲突吗？

有冲突。uaredirect.js 用 navigator.userAgent 检测移动设备——但 Googlebot Mobile 的 UA 含 Android 关键字（Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/...）。意思是 Googlebot Mobile 抓 PC 页面时会被 uaredirect 跳到 m. 域名，然后又抓 m. 页面——重复抓取浪费 crawl budget。如果 m. 页面没有 canonical 指 PC，Googlebot 会困惑。修复：在 UA 检测正则里排除 Googlebot：if (!/Googlebot|Bingbot|Baiduspider/i.test(navigator.userAgent) && /Mobile/i.test(navigator.userAgent))。但即使排除了爬虫，普通用户的跳转仍然影响 SEO（Google 用真实用户行为评估，跳转过多影响 dwell time）。

DedeCMS 怎么改造成响应式（不用 m. 子域名）？

六步：复制模板目录创建 -responsive 副本；所有 head 加 viewport meta，px 字号改 rem；PC 的 table/float 布局改 flexbox/grid；导航改汉堡菜单（CSS input checkbox 折叠）；图片用 dede thumb 函数生成多尺寸配 srcset；老 m. 子域名 nginx 加 301 到 www. 对应 URL（保留 SEO 权重）。完整改造工作量纯 CSS 调整 2-5 天，涉及 DOM 重写 5-10 天。改完后所有设备共用一份代码，维护成本远低于双站方案。

百度 siteapp 关闭后还有同类一键移动适配工具吗？

没有同类的一键转码工具。百度、Google、Bing 都关闭了云端转码服务，因为响应式设计普及让这种服务失去意义。现在的"移动适配"路径都是在源站做响应式或独立 m. 站点。如果实在要做云端转码（比如老旧 ASP 站点改造成本太高），可以考虑：用 Cloudflare Workers / Vercel Edge Functions 写一个简单的 HTML 改写代理，把 PC 版抓取后插入 viewport meta + 简单 CSS 覆盖。但这是临时方案，长期还是要做响应式。

JS 跳转 vs 服务端 301 性能对比？

服务端 301 单次额外耗时 80-150ms（一次 HTTP RTT + 重定向头解析）。JS 跳转更慢：浏览器先下载 PC 页面（200ms+）、解析 HTML、执行 JS（30-100ms）、再 location.replace 触发新请求（200ms+）——总耗时 400-700ms，而且白屏闪烁。SEO 上服务端 301 远胜 JS 跳转——301 是 HTTP 标准重定向，所有爬虫都正确处理；JS 跳转在 Googlebot 简单抓取模式下不执行，留在 PC 版。任何场景下，能用服务端 301 就不要用 JS 跳转。最优方案是响应式设计完全无跳转。