ECSHOP各类页面手机访问自动跳ECTouch：按UA判断加301

摘要：ECSHOP默认只把首页跳到手机版，商品详情、分类、团购、批发等页面都跳不过去。本文在lib_main.php新增一个pc_to_mobile函数，按UA和当前文件名拼装出ECTouch对应的路由参数，再在init.php里调用，实现PC端各类页面在手机访问时自动跳到ECTouch对应的手机版页面，并兼顾Googlebot的跳转决策和SEO的301处理。

ecshop其他页面(商品详情页、商品分类页、团购页、优惠活动页、积分商城) 如果是手机访问则自动跳转到ECTouch手机版对应页面的方法，首先在ecshop根目录下的includes/lib_main.php文件里添加一个函数function pc_to_mobile()

/**
* ecshop 实现其他页面(商品详情页、商品分类页、团购页、优惠活动页、积分商城)
* 判断如果是智能手机访问的话 跳转到ECTouch1.0手机版对应页面 方法
*
* @access public
*/
function pc_to_mobile()
{
//判断是否是手机访问
$is_mobile = false;
$ua = strtolower($_SERVER['HTTP_USER_AGENT']);
$uachar = "/(nokia|sony|ericsson|mot|samsung|sgh|lg|philips|panasonic|alcatel|lenovo|cldc|midp|mobile)/i";

if(($ua == '' || preg_match($uachar, $ua))&& !strpos(strtolower($_SERVER['REQUEST_URI']),'wap'))
{
$is_mobile = true;
}

/* 判断是否重写，取得文件名 */
$cur_url = basename(PHP_SELF);
if (intval($GLOBALS['_CFG']['rewrite'])){
$filename = strpos($cur_url,'-') ? substr($cur_url, 0, strpos($cur_url,'-')) : substr($cur_url, 0, -4);
}else{
$filename = substr($cur_url, 0, -4);
}

if($is_mobile){
/*
* 如果你绑定了手机版域名 http://www.abc.com/mobile 为 http://m.abc.com
* 那么 $mobile_url = http://m.abc.com
*/
$mobile_url = $GLOBALS['ecs']->url().'mobile';

/* 根据文件名分别处理中间的部分 */
if ($filename != 'index')
{
/* 处理有分类的 */
if (in_array($filename, array('category', 'goods', 'brand')))
{
/* 商品分类或商品 */
if ('category' == $filename || 'goods' == $filename || 'brand' == $filename)
{
$Loaction = $mobile_url .'/?c='.$filename.'&a=index&'.$_SERVER["QUERY_STRING"];
}
}
/* 处理无分类的 */
else
{
/* 团购 */
if ('group_buy' == $filename)
{
if(!empty($_GET['id'])){
$Loaction = $mobile_url .'/?c=groupbuy&a=info&id='.$_GET['id'];
}else{
$Loaction = $mobile_url .'/?c=groupbuy';
}
}
/* 拍卖 */
elseif ('auction' == $filename)
{
if(!empty($_GET['id'])){
$Loaction = $mobile_url .'/?c=auction&a=info&id='.$_GET['id'];
}else{
$Loaction = $mobile_url .'/?c=auction';
}
}
/* 夺宝 */
elseif ('snatch' == $filename)
{
if(!empty($_GET['id'])){
$Loaction = $mobile_url .'/?c=snatch&a=info&id='.$_GET['id'];
}else{
$Loaction = $mobile_url .'/?c=snatch';
}
}
/* 批发 */
elseif ('wholesale' == $filename)
{
if(!empty($_GET['id'])){
$Loaction = $mobile_url .'/?c=wholesale&a=info&id='.$_GET['id'];
}else{
$Loaction = $mobile_url .'/?c=wholesale';
}
}
/* 积分兑换 */
elseif ('exchange' == $filename)
{
if(!empty($_GET['id'])){
$Loaction = $mobile_url .'/?c=exchange&a=exchange_goods&gid='.$_GET['id'];
}else{
$Loaction = $mobile_url .'/?c=exchange';
}
}
/* 优惠活动 */
elseif ('activity' == $filename)
{
$Loaction = $mobile_url .'/?c=activity';
}

}
/* ecshop跳转到手机对应页面 */
if (!empty($Loaction)){
ecs_header("Location: $Loaction");
exit;
}
}

}

}

然后在ecshop根目录下includes/init.php里大概129行的商店关闭判断代码之后添加

pc_to_mobile();

以上修改适用于ecshop2.7.3版本与ECTouch1.0版本且没有经过二次开发。

这套UA跳转方案，为什么在今天已经成了SEO反模式？

上面这段代码能跑，但要把话说在前头：按User-Agent嗅探、再把PC页面301到一套独立的手机URL，这种“分离式移动站”架构在2018年还算主流，到了今天已经是Google官方明确不推荐的做法。它不是不能用，而是维护成本高、出错点多、踩坑概率大。理解它为什么过时，比照抄代码更重要。

分离式移动站的本质，是同一份内容存在两套地址：PC端是www.abc.com/goods-123.html，手机端是m.abc.com/?c=goods&id=123。两套URL意味着两套需要同步维护的内容、两套需要互相声明的规范标签、两套都要被搜索引擎正确抓取和归并的页面。任何一个环节配错，权重就会分散，收录就会出问题。

反模式的三个核心代价

• 权重稀释：外部链接有的指向PC页、有的指向手机页，如果没有正确配置规范标签，Google会把它们当成两个独立页面，把本该集中的链接权重一分为二。
• 规范标签配置复杂：标准做法要求PC页用rel=alternate指向手机页，手机页用rel=canonical反向指回PC页，两边成对出现、一一对应。商品一多，靠模板批量生成极易错配，错配的结果就是收录混乱。
• UA判断本身就不可靠：原代码里那串nokia|sony|ericsson|mot|samsung的正则，是十几年前的设备名清单，今天的iPhone、主流Android机型在这串里一个都匹配不上。靠枚举设备名来判断“是不是手机”，注定是一场永远追不上新机型的猫鼠游戏。

换句话说，这段代码解决的是“ECShop默认只跳首页、其他页面跳不过去”这个具体问题，但它所依赖的整体架构，在移动优先索引时代已经站在了Google建议的反面。

移动优先索引是怎么一步步逼停分离式移动站的？

要理解分离式移动站为什么被淘汰，得顺着Google移动优先索引（Mobile-First Indexing，简称MFI）的演变史走一遍。这条时间线，基本就是“桌面版内容说了算”到“手机版内容说了算”的权力转移史。

这条线最关键的转折点是2021年前后：移动优先索引意味着Google主要看你的手机版内容来决定排名。对分离式移动站来说，这是个致命问题——很多站的m.版本为了“轻量”，砍掉了PC版才有的详细描述、评价、关联推荐、结构化数据。MFI之后，Google看到的是这个被砍过的手机版，于是排名按“内容单薄”来算，PC版上那些丰富内容相当于白做了。

ECShop配ECTouch恰恰是这种结构的典型：ECTouch手机版的页面信息密度、结构化数据完整度，普遍低于ECShop的PC详情页。在移动优先索引的规则下，这种“手机版偷工减料”会被如实反映到排名里。

跳转到底该用301还是302？状态码选错会怎样？

原代码用的是ecs_header("Location: ...")，这行底层默认发出的是302临时重定向。对“PC页跳手机页”这个长期固定的对应关系来说，302其实是个隐患。301和302的差别，搜索引擎看得很重。

301与302的本质区别

• 301永久重定向：告诉搜索引擎“这个地址永久搬到新位置了”，会传递绝大部分链接权重，且Google会逐渐用目标URL替换原URL进入索引。
• 302临时重定向：告诉搜索引擎“原地址还在，只是暂时去别处”，权重传递保守，索引里保留的仍是原URL。

问题在于：分离式移动站的“PC跳手机”是不是一种“永久搬迁”？答案是否定的。手机版和PC版是并存关系，不是替代关系——PC用户该看PC页，手机用户该看手机页，两者长期共存。如果对这种并存关系用了301，会误导搜索引擎以为PC页已经永久作废，反而可能把PC页从索引里清掉。

所以分离式架构里，更稳妥的不是纠结301还是302，而是配合“动态服务”思路：在同一个URL上根据设备返回不同内容，并在响应里加上Vary头声明内容随User-Agent变化，告诉Google这个地址对不同设备会给不同版本。这比硬跳转更不容易出错。当然，更彻底的解法是干脆不做跳转，下文会讲。

一句话决策

如果你坚持保留这套跳转：PC与手机是并存关系，就别用301把PC页判“死刑”；要么改用动态服务加Vary头，要么明确成对配好规范标签让两套URL各归各位。盲目把Location跳转当永久搬迁处理，是分离式移动站最常见的索引事故源头。

UA嗅探的可靠性陷阱：为什么这串正则迟早会失灵？

回到代码本身。判断“是不是手机”的核心是这一行正则：匹配nokia、sony、samsung、mobile等关键词。这种“关键词枚举法”有三个绕不过去的硬伤。

硬伤一：清单永远追不上新设备

设备型号、浏览器内核、操作系统每年都在变。靠手工维护一份设备名黑白名单，意味着每出一批新机型、新浏览器，你都得回来改这串正则。漏掉了，新手机就被当成PC不跳转；误判了，PC浏览器里某个含关键词的UA又被错跳到手机版。这是一笔永远还不完的维护债。

硬伤二：UA字符串本身正在被淘汰

现代浏览器为了保护隐私，正在主动“冻结”和精简User-Agent字符串，改用“客户端提示”（Client Hints）机制按需提供设备信息。也就是说，未来UA里能拿到的设备特征会越来越少、越来越模糊，靠UA做精确设备判断这条路本身就在收窄。

硬伤三：容易误伤搜索引擎爬虫

Googlebot抓取移动版时，用的是模拟移动设备的UA。如果你的正则逻辑写得粗糙，可能把爬虫错误地卷进跳转逻辑，或者反过来漏判，导致Google抓到的页面和真实用户看到的不一致——这在搜索引擎眼里属于“隐藏内容”嫌疑，风险很高。正确做法是确保爬虫无论从哪个UA进来，最终能拿到与对应设备用户一致的内容，且跳转链路干净、不绕圈。

把这三点合起来看：UA嗅探不是“能不能用”的问题，而是“用了就得持续填坑”的问题。它把一个本该由布局自适应解决的事，硬塞进了服务端的设备判断里。

现代做法：用响应式设计彻底取代分离式移动站

Google官方推荐的移动适配方案有三种，优先级很明确。理解这三种的取舍，才知道这套ECShop跳转代码在今天该被什么取代。

为什么响应式是首选？

• 一套URL，权重不分散：所有链接、分享、收录都集中到同一个地址，没有权重稀释问题。
• 无需UA嗅探：布局自适应交给CSS媒体查询，服务端不必判断设备，自然没有设备清单维护债。
• 无需规范标签互指：只有一个URL，不存在PC页和手机页谁是规范版本的纠结。
• 移动优先索引天然友好：Google抓到的内容和PC用户看到的完全一致，不会出现“手机版偷工减料被降权”的情况。

对独立站、新项目而言，几乎没有理由再选分离式移动站。响应式才是默认答案。这也是为什么本文开头的时效提示里建议：新项目直接上Shopify、Magento 2这类原生响应式的现代电商架构，从根上绕开UA跳转这一整套历史包袱。

给ECShop历史维护者的安全加固清单

如果你接手的是一个还在跑、暂时无法迁移的ECShop老站，那这套代码的价值在于“先让它别出大事”。以下是把风险压到最低的加固清单，本文保留这段legacy代码，正是为这类历史维护场景服务。

1. 确认跳转关系不要用301：PC与手机版并存，把ecs_header的默认临时跳转保留即可，切勿手痒改成301，否则可能把PC页踢出索引。
2. 成对配置规范标签：PC页加rel=alternate指向对应手机页，手机页加rel=canonical指回PC页，一一对应，别批量套错。
3. 收紧UA误判：原正则的老设备清单可适当补充主流机型关键词，但更稳的是只在确认是移动UA时才跳，拿不准时默认不跳、留在PC页，宁可不跳也别错跳。
4. 放行并核对搜索引擎爬虫：用日志确认Googlebot移动版能正常拿到手机内容、且拿到的内容与真实用户一致，避免被判定为隐藏内容。
5. 保留wap参数兜底：原代码已用REQUEST_URI里是否含wap来防止重复跳转，这个判断要保留，防止跳转死循环。
6. 把迁移排进日程：加固只是续命，不是终点。ECShop已多年无大版本更新，PHP 8.x兼容性、安全补丁都停滞，长期看仍应规划迁移到响应式的现代架构。

一句话总结这份清单的逻辑：能不动就先稳住，该补的规范标签和爬虫核对补齐，但心里要清楚这是过渡态，不是长久之计。

比UA跳转更稳的折中：动态服务方案怎么落地？

如果一时还做不到响应式重构，但又想摆脱分离式移动站的索引隐患，动态服务（Dynamic Serving）是一个折中选择。它和UA跳转最大的区别是：URL不变，仍是www.abc.com/goods-123.html，只是服务端根据访问设备返回不同的HTML。用户和搜索引擎看到的是同一个地址，权重不再被拆成两份。

动态服务的三个落地要点

• 同一URL返回两套HTML：服务端检测到移动设备时输出移动版模板，桌面设备时输出桌面版模板，地址栏地址始终一致，不发生跳转。
• 必须加Vary响应头：在响应里声明内容随User-Agent变化，这一步是动态服务的灵魂。它告诉搜索引擎和缓存服务器“同一个地址会因设备给不同版本”，否则Googlebot可能缓存到错误版本，CDN也会把PC版缓存返回给手机用户。
• 两套HTML内容必须等价：移动版可以布局更紧凑，但核心内容、商品描述、价格、结构化数据不能比桌面版少。移动优先索引看的是移动版，移动版偷工减料一样会掉排名。

对ECShop的改造思路

把现有的“嗅探UA加Location跳转”逻辑，改成“嗅探UA加加载不同模板、不跳转”。原来的pc_to_mobile函数里那段设备判断可以复用，只是把ecs_header跳转那一步，换成切换ECShop模板目录或引入ECTouch模板渲染，URL保持不变，并在输出前补一个Vary头。这样既留住了老站的移动适配，又避开了双URL的权重稀释。需要提醒的是，动态服务对设备判断的准确度要求更高，判断错了用户会直接看到不匹配的版本，所以它仍是过渡方案，终点还是响应式。

怎么判断你的移动跳转有没有偷偷拖累收录？

很多ECShop老站长不知道自己的移动跳转早就出了问题，因为前台看着一切正常。判断收录有没有被拖累，不能靠肉眼，得看搜索引擎的真实反馈。下面这套自查动作，定期跑一遍就能发现问题。

四步自查清单

1. 用Google Search Console的网址检查工具：输入一个商品页地址，看Google抓取到的是PC版还是手机版内容、规范网址判定成了哪个。如果抓到的内容残缺或规范网址指错，说明跳转或规范标签配置有问题。
2. 看覆盖率（页面索引）报告：重点查“重复，Google选择的规范网址与用户指定的不同”这类提示，这往往就是PC页和手机页规范标签互指出错的信号。
3. 对比抓取内容与真实页面：用URL检查里的“已抓取的网页”查看Google实际拿到的HTML，和真实手机访问到的页面比对，确认两者一致、没有出现“爬虫看到的和用户不一样”的隐藏内容嫌疑。
4. 翻服务器访问日志：筛Googlebot的UA记录，确认它访问商品页时拿到的是200而不是被绕进跳转链路反复302，也确认它最终能落到有完整内容的页面。

出问题的典型信号

如果自查中发现这几种情况，基本可以确定移动跳转在拖累收录：手机版页面大面积未被收录、商品页的规范网址在GSC里被Google改判到了别的地址、搜索结果里点进来落地到空白或报错的m.页、或者排名长期上不去但内容质量明明不差。遇到这些信号，优先排查规范标签是否成对配齐、跳转状态码是否用错、移动版内容是否比桌面版单薄，三个方向逐一对照前文的加固清单修正。修不动、积重难返的，就是该认真考虑迁移到响应式架构的时候了。

常见问题解答

ECShop按User-Agent跳转ECTouch会影响SEO吗？

会有影响，且多数是负面的。核心风险有三点：一是分离式移动站把内容拆成PC和手机两套URL，若不成对配置rel=alternate和rel=canonical规范标签，链接权重会被稀释；二是移动优先索引时代Google主要看手机版内容排名，而ECTouch手机版的信息密度通常低于ECShop的PC详情页，容易被按“内容单薄”降权；三是UA嗅探的设备清单会过时，可能错跳或漏跳，甚至误伤搜索引擎爬虫。如果不是历史维护的不得已，新项目应当直接用响应式设计，从根本上避开这些问题。

这段跳转代码用的是301还是302？哪个对？

代码里的ecs_header("Location: ...")默认发出的是302临时重定向。对分离式移动站这种“PC版和手机版长期并存”的关系来说，302反而比301更合适，因为301会被理解为“原地址永久作废”，可能导致PC页被搜索引擎从索引里清除。更稳妥的方向不是在301和302之间二选一，而是改用动态服务：在同一URL上按设备返回不同内容，并在响应里加Vary头声明内容随User-Agent变化。

为什么原代码里的UA正则匹配不到iPhone和新Android手机？

因为那串正则用的是nokia、sony、ericsson、samsung等十几年前的设备名关键词，是个老旧清单。iPhone的UA里是iPhone、现代Android常见Android等标识，都不在原清单内，所以匹配不到。这正暴露了UA枚举法的根本缺陷：永远追不上新机型。如果必须沿用，需要补充iphone、android、ipad等现代关键词；但更彻底的解法是放弃UA嗅探，改用响应式布局。

ECShop老站现在还值得继续做移动适配吗？

分两种情况。如果是已经在运营、短期无法迁移的老站，值得按本文的加固清单把跳转逻辑做稳，确保不出索引事故，同时把迁移排进中长期计划。如果是新项目，完全不建议在ECShop上做分离式移动站——ECShop多年无大版本更新，PHP 8.x兼容性差、安全补丁停滞，应直接选择Shopify、Magento 2等原生支持响应式的现代电商方案，一套URL自适应所有设备，省掉UA跳转的全部维护负担。

从分离式移动站迁到响应式，成本到底有多大？

成本主要在前端模板重构，而不是数据层。响应式改造的核心是把PC和移动两套模板合并成一套带CSS媒体查询的自适应模板，商品数据、分类结构、订单逻辑这些后端部分基本不动。对ECShop这种PC和ECTouch模板分家的架构来说，工作量集中在重写主题模板和样式，再加一轮跨设备测试。迁移完成后能一次性消除UA嗅探维护、规范标签互指、双URL权重稀释这三类长期隐患，对移动优先索引也彻底友好。所以这笔账要算长期：响应式是一次性投入换长期省心，而维护分离式移动站是每年都要还的技术债。预算允许时，迁移到响应式或干脆换现代电商平台，长期回报更高。

权威参考资料