如何布局您的PC站和移动站，并表达两者之间内容的对应关系目前较流量的PC站与移动站配置方式有三种，百度站在搜索引擎角度将这三种分别称为跳转适配、代码适配和自适应，以下为这三种配置方式的名词解释及异同对比。
1，跳转适配：该方法会利用单独的网址向每种设备提供不同的代码。这种配置会尝试检测用户所使用的设备或ua，然后使用 HTTP 重定向和 Vary HTTP 标头重定向到相应的页面。
2，代码适配：该方法使用相同的网址（不考虑用户所使用的设备），但会根据服务器对用户所用浏览器的了解（ua），针对不同设备类型生成不同版本的 HTML。
3，自适应：通过同一网址提供相同 HTML 代码的网站设计方法。该方法不考虑用户所使用的设备（pc、平板电脑、移动设备），但可以根据屏幕尺寸以不同方式呈现（即适应）显示屏。
| PC、移动网址是否一致 | PC、移动网页代码是否一致 | |
| 跳转适配 | 否 | 否 |
| 代码适配 | 是 | 否 |
| 自适应 | 是 | 是 |
三种配置方式的分析百度仅站在搜索引擎角度对跳转适配、代码适配、自适应这三种配置方式做了一些对比和分析，希望能够帮助站点选择更适合自己、性价比最优的方式来进行移动化。
| 跳转适配 | 代码适配 | 自适应 | |
| 复杂程度 | 简单到中等。开发独立网站的速度可以非常快。 小型企业可选用多种自动方案，以近乎实时的速度生成移动网站。 |
中到高，取决于网站的复杂程度和您需要创建的代码库数量。 代码适配所需的开发时间可能较长，且要求服务器端编程 |
中。需要使用能随屏幕尺寸而变的流体网格从头开始创建。 如果网站需求较简单，有许多开源模板可供选择。 如要构建包含额外编程的复杂的自适应网站，所需的时间会比较长。 |
| 性能 | 中。图片和其他网站内容可轻松针对小屏幕优化，但网站重定向经常会导致延迟问题。 | 高。可以简化为只包含为相应设备优化的内容，以实现最佳性能。 | 高。无任何重定向，但需要有周全的计划才能实现最优的效果。数据量膨胀是最常见的错误。 |
| 维护需求 | 中到高。更新主网站后，还必须单独在移动网站上进行更新。 | 如果人工维护，将需要大量的资源。许多网站使用内容管理系统来避免这一问题，并自动在所有模板上发布内容。 | 低。创建后，更新内容会流向所有设备，维护工作量极低。 |
| 设备 | 可专门针对移动用户优化网站。 | 单独的文件和服务器端代码（会在向用户传递网页前在您的服务器上运行）可以提供依设备而定的体验。 | 所有设备上的用户体验保持一致（一些设备专属的选项可通过服务器端程序添加）。 |
| 是否支持扩展至新平台 | 不支持。这是智能手机专用的独立移动网站。新平台无法轻松集成到现有架构中。 | 支持。可轻松针对具体的设备（例如智能电视）创建模板，并通过同一个网址投放。 | 支持。使用指定的断点和流体网格，可轻松扩展到新平台和新设备。 |
一、域名&服务器&前端语言
1.域名
最初的时候，我以为移动站（俗称手机站，简称M站或者wap站）的域名和PC站一样，随便挑一个就可以了。后来才发现，“理想是美好的，现实是残酷的”：百度搜索引擎原来有自己的偏好！如下所示：
推荐： m.baidu.com sports.sina.cn a.m.hao123.net www.m168.info
不推荐：www.baidu.com/m
可以看出来，百度搜索引擎喜欢独立的、短小的二级域名（简洁的三级域名也可）。但却不喜欢用子目录做的M站，理由也很简单，如果说PC站用 www.baidu.com，M站用www.baidu.com/m/ ，那搜索引擎对 /m/ 这个目录会感到疑惑：到底是PC站的一个子目录，还是PC站相对应的M站呢？真是剪不断，理还乱啊。
以上举例的域名，我们来做个PC站与M站对应的关系：
PC站 M站
www.baidu.com m.baidu.com
sports.sina.com sports.sina.cn
a.hao123.net a.m.hao123.net
www.m168.cc www.m168.info
可能大家会发现，最后一个例子中，PC站和M站都是使用的www作为前缀，其实我是不怎么赞同的，使用 m 或者 wap 才较为合适。因为说不定什么时候老板想把www.m168.cc 作为他用，而 www.m168.info 作为PC站了。
OK，我们现在知道M站用二级域名或者三级域名了，那么有同学又提到了一个问题，在百度搜索引擎的策略里，PC站和M站的主域是不是必须用一个呢？答案是“否”，但又必须相关，如下：
可行——PC站：www.hao123.com 移动站：m.hao123.net
不推荐——PC站：www.hao123.com 移动站：m.123.com
可以看到，百度搜索引擎（以下内容简称百度）认同 用 hao123 做为主干，使用不同后缀的域名分别用作PC站和M站的域名，但不推荐使用没有关系的域名。
不管做什么站，首先网站有个非常重要的前提：服务器的稳定性。百度官方透露：目前百度对可访问性有问题的网站打压是非常厉害的。如果被检测到网站404、502等各种影响用户浏览网站的状况发生，是会影响到网站自身在移动百度搜索结果里的排名。同时，移动百度搜索对网页加载速度上的要求也很苛刻：“网页加载超过3秒以上不考虑排名”。当然，一般情况下会排除统计工具代码的加载时间，但广告加载会计算在3秒之内！大家还是先回家测试一下手机站的加载速度吧。温馨提示：利用站长平台工具“页面优化建议”可以粗略的查出影响页面加载的因素有哪些。
3.前端开发语言移动互联网发展至今，前端开发语言经过历次的更迭，目前主流仍在使用的用xml、xhtml、html5。
历年来，移动web主要技术标准有：
WML——古典的移动web标准，使用WML
i-mode——小日本的标准，使用iHTML，我们可以忽略
OMA领导的xHTML mobile profile，使用xHTML
W3C领导的xHTML Basic，使用xHTML
以及所谓的Full Web，也就是普通的HTML——从iPhone开始流行起来近年来比较流行HTML5，是html标准的最新版（在2014年10月正式发布），目前世界上主流浏览器最新版均以支持，同时，也是各站长平台、浏览器厂商推荐的移动站点的前端语言标准。附送一张进化图，用以各位看官了解：
二、applicable-device标注
1.意义
用来向百度蜘蛛说明此url页面适合在PC端还是M端展现。说白了，就是帮助百度提交校验识别结果的正确性，减少百度蜘蛛把PC站当成M站，或者把M站当成PC站进行抓取。
2.代码位置
代码放在<head></head>中间，规则和对应关系见下：
如果是PC站，代码：<meta name=”applicable-device”content=”pc”>
如果是M站，代码：<meta name=”applicable-device”content=”mobile”>
如果是自适应或代码适配，代码：<meta name=”applicable-device”content=”pc,mobile”>
三、站点结构
1.树状or扁平？
其实大家没有必要再纠结所谓的树状还是扁平，只要能让Baiduspider把整个网站跑一遍就可以，但今天要提醒大家注意两点：
a 不要所有内容放在同一个目录下（包括根目录），这种不符合上面所说的“树状结构”，同时无法让蜘蛛明白这些文章的分类。错误例子：http://www.xxx.com/article-7750-1.html
b 不要过度细分目录（就是一级目录下面有二级目录，然后还有三级、四级。。。等目录），按需生成目录，不要无下限的生成多级目录：
http://www.xxx.com/news/ 推荐
http://www.xxx.com/news/yyxw/ 若内容过少，不推荐
2.面包屑导航
对于移动网页来说，面包屑导航也非常重要，在此不再多言。
3.anchor质量
超链接分两种，一种是纯文本链接（只有url，没有说明描述），在移动网页上百度并不推荐使用；另一种就是锚文本链接，代码如下：
<a title=”标题描述” href=”http://www.xxx.com/article-7750-1.html”>标题描述</a>
上述标题描述即为anchor，这个anchor必须准确地描述相对应的链接内容，虚假的anchor内容还会受到百度的惩罚。
四、url结构和外链
1.url结构
虽然百度已经支持动态化url链接，但静态化url链接依然是优先推荐使用（纯静态化，或者伪静态化）。在使用静态化url链接时，url的结构也是需要注意的地方：
尽量简单短小，少用特殊符号；
尽量不用中文url，因为在移动端没有太大意义，目前平台的改版工具和移动适版工具支持得也不够，别给自己找麻烦了；
结构层次尽量不要太多，越少越好，但不要把所有的内容页放在同一个目录里面
2.外链
有句内行话是这么说的：“内容为王，外链为皇”。如今，外链的作用依然很强大，不管是导量方面也好，SEO优化方面也罢。各个站长依然为了“外链”而头疼，特别是被不明身份者恶意刷外链的站长们，更是吃不下睡不着。关于外链生效的问题方面，PC端、移动端外链均有效（PC链向移动站点同样有效），但需要注意几点：
整体而言，减弱信任度；
高质量的外链，一直有效；
低质量的外链，具有负面影响，而作弊外链，则会受到惩罚。
针对恶意外链事件屡次发生，站长平台发布了“外链分析”的工具，让各位站长可以明确的知晓到底有哪些站放了我们网站的外链。各位可以在站长平台查看：
五、移动类型提交
百度站在平台的设置里，把网站分为了五类：PC站；有对应PC站的移动站；独立移动站；自适应的站点；代码适配的站点。根据站点实际情况进行设置，有利于百度蜘蛛在抓取页面，以及搜索结果的排名（PC站和M站的搜索结果展现机制不一样）。设置方法如下：
当用户用百度搜索某个关键词时，百度会优先展现用户体验最佳的页面，就算你做了移动站，可因为百度并没有发现你原PC页面对应的移动页面，也会失去上述优先机会。那么，如何让百度快速发现PC–移动页面的对应关系？我们常做的有自主适配、meta标注、站长工具提交适配关系，但由于自主适配和meta标注只有在百度蜘蛛抓取原PC页面的时候才能发现对应的移动页面，那么发现全部移动页面会需要很长的时间，而在百度站长工具中提交移动适配关系将大大缩短了这个时间。
下图中这个移动站上线半年，之前一直做了自主适配和meta标注，在8月10日的时候提交了移动适配，通过下面曲线图就可以看出6天之后适配效果就达到比较理想状态（红线和蓝线间距越小适配效果越好）。
6天时间就校验成功并生效，可能会让一些校验不成功或一直校验中的同学愤愤不平，但在吐槽的时候，是不是也应该在自己身上找下原因呢？下面我们主要阐述下移动适配中的几个要点。
一、内容一致是移动适配成功的关键
1、PC页面和对应的移动页面主体内容必须完全对等
尽量保持原PC页面信息量不变，但为了移动页面美观和访问速度，可以删减不太重要的模块和细分导航，但页面主体内容必须保持不变，比如文章正文或目录页面的链接数和链接指向要完全一致。
2、PC和移动的适配关系必须是一对一，不能多对一
若某些PC页面没有对应的移动页，那这些PC页可以不提交适配关系，但不能将多个PC页面同时指向一个移动页面，比如某文章页面在PC上有分页，到了移动站上分页取消，原PC文章所有分页都指向了同一个移动页面，这也会导致校验识别。PS：允许出现一个PC页面对应两个移动页的情况：一个是给高端机看的，一个是给低端机看的。
3、需要适配的页面不能内容过少、为空或者无法访问
百度需要将PC页面内容和移动页面内容进行对比参照，若内容过少或空，以及需要登录才能查看的页面，百度都无法识别相似度。
二、建议移动站和PC同主域或同主干，不建议使用目录
1、移动站和PC主域相同，或主干相同
例若PC站是www.123.com，移动站强烈建议选用m.123.com，移动站URL尽量简洁短小，建议使用m.123.com而非yidongzhan.123.com。www.123.net因为主干相同也可以。
2、不建议使用二级目录作为移动站
例若PC站是www.123.com，移动站选用www.123.com/m/，这样，百度、GOOGLE等搜索引擎都是不喜欢的。但如果真的这样做了，百度站长工具也可以提交适配规则，具体方法可查看站长学院中《目录级移动适配如何使用工具提交适配关系》这篇文章。
三、更多注意事项
1、允许Baiduspider访问，不要robots封禁
虽然听起来有些无厘头，但这种情况是真实存在的，要注意你的移动站点对百度是不是开放的。
2、UA判断后尽量使用301或302进行跳转
现在比较常见的是PC站点只适配一个移动站点，那么使用301就可以，如果需要同时适配高端域名和低端域名，推荐使用302
3、尽量为页面添加applicable-device标签
applicable-device标签用于帮助百度校验识别页面类型的准确度，虽然不是硬性要求，但对站点来说没有任何弊端
如果是PC页，在<head></head>中标注<meta name=”applicable-device”content=”pc”>
如果是移动页，在<head></head>中标注<meta name=”applicable-device”content=”mobile”>
4、移动适配工具、META标签、自主适配——三种方式逻辑关系保持一致
很多朋友都是这三种方式全用的，百度也支持这样，但这里有一个问题是：逻辑关系要保持不致，不能在自主适配时PC页对应的是移动页是A，而提交时却变成了B。这样最终百度自主选择的适配移动页面可能和你预期的不一样。
四、通过百度站长工具提交适配关系的注意事项
前面两个要点要确保都没问题了，那接下来就是向百度提交适配关系了。
1、强烈推荐使用规则适配
使用规则适配的好处主要有百度校验快，生效时间短，最主要的是后期不需要站长去维护，而URL适配需要不断地更新近期增加的页面。建议只有当PC对应的移动页面URL没有规则可言时再考虑URL适配。
2、在规则适配中推荐使用提交多条规则
除非你的站点简单，页面类型单一可以选用单条规则，使用多条规则的好处是可以针对不同类型的URL页面写出对应规则，比如目录页、目录分页、文章页、专题页、产品页等等，这样能照顾到每一种页面类型，一旦某个规则填写错误负面影响可以缩到最小，整体提高校验速度和缩短生效时间。
3、规则适配中正则粒度越细越好
提交多条规则就涉及到正则式的问题，正则匹配符号(\d+)表述数字，([a-zA-Z]+) 表示字母，([a-zA-Z0-9]+)表示字母混合，(\w+)表示字母数字下划线混合，上述四种匹配符号中，前两者属于粒度最细的、推荐使用，第三种第四种粒度较粗，在正则式中若用大粒度匹配符将会增加校验时间。
案例：若有两个PC页面www.123.com/a/abc-1.html和www.123.com/a/def-1.html，有些站长会直接用 www.123.com/a/(\w+).html 对应 m.123.com/a/${1}.html 一个正则表达。但建议写成两个正则：
www.123.com/a/abc-(\d+).html对应 m.123.com/a/abc-${1}.html
www.123.com/a/def-(\d+).html对应 m.123.com/a/def-${1}.html
五、最后强调
不管使用哪种方式，适配成功后都要持续保持PC页和移动页的适配关系，因为百度会继续检查适配关系是否正常是否生效，如果发现适配关系不正确，之前生效的数据也会转为失效，影响移动流量。
1，PC结构发生变化，检查移动站点是否快速跟着变了
2，PC页面主体内容发生变化，检查移动页面是否一致
3，如果使用平台工具提交的适配关系，定期检查数据状态，如果之前显示“适配成功”的数据改成了“校验失败”要赶紧查看PC页与移动页的对应关系。
一、什么样的网站适合做自适应
自适应网页设计(Responsive Web Design)是指可以自动识别终端设备屏幕的大小从而做出相应调整的网页设计方法。这种网页设计方法完美解决了如何在不同大小的网络设备上呈现同样的网页效果。大家公认自适应至少有4个好处:提升用户体验；PC端和移动端SEO保持一致；避免重复内容和出错内容；链接统一。
而自适应比较明显的缺陷是，开发成本比较高，尤其是要构建包含额外编程的复杂的自适应网站，所需的时间会比较长。如果网站需求较简单，有许多开源模板可供选择。
对于已经比较成熟PC网站来说，如果要实现全站的自适应，有可能需要推掉原来所有的代码进行重构，时间和技术成本都比较大，而且如果一个网站有多个portal（入口），会大大增加架构设计的复杂度，所以现在有很多网站只在移动端实现了响应式布局设计。
二、自适应网页代码上需要做出哪些调整
1、 阻止移动浏览器自动调整页面大小
iOS和Android浏览器都基于webkit核心，这两种浏览器以及其他的很多浏览器都支持viewport meta元素覆盖默认的画布缩放设置，只需在HTML的<head>标签中插入一个<meta>标签，<meta>标签中可以设置具体的宽度(如像素值)或者缩放比例2.0(设备实际尺寸的两倍)，下面是将一个页面放大到设备实际尺寸两倍显示的meta标签示例:
<meta name=”viewport” content=”initial-scale=2.0,width=device-width”/>
2、将网页修改为百分比布局
当某个浏览窗口处于媒体查询固定的范围之外，网页就需要水平滚动才能完整浏览，而通过百分比布局可以页面元素根据窗口大小在一个又一个媒体查询之间灵活修正样式，具体来讲，就是css代码不会指定具体像素宽度：width:xxx px;而是会指定一个百分比宽度：width:xx%;或者直接就是width:auto;这里大家可以根据一个简易的公式将固定像素宽度转换成对应的百分比宽度：目标元素宽度 ÷ 上下文元素宽度 = 百分比宽度
例如：
<div id =”wraper”>
<divid = “header”></div>
</div>
#wrapper {
margin-right: auto;
margin-left: auto;
width: 960px;
}
#header {
margin-right: 10px;
margin-left:10px;
width: 940px;
}
转换为百分比的header区块的css为：
#header {
margin-right: 10px;
margin-left: 10px;
width: 97.916667% /* 940 ÷ 960 */
}
3、用em替换px
同样，目标元素宽度 ÷ 上下文元素宽度 = 百分比宽度这个公式也适用于将文字的像素单位转换为相对单位，值得注意的是，现代浏览器的默认文字都是16像素，因此一开始给body标签应用下列任何一条规则所产生的效果都一样:
font-size: 100%;
font-size:16px;
font-size: 1em;
例如某网站网站标题相应的样式:
#logo {
display: block;
padding-top: 75px;
color: #0d0c0c;
font-family: Arial;
font-size: 48px;
}
修改后的样式如下:
#logo{
display: block;
padding-top: 75px;
color: #0d0c0c;
font-family:Arial;
font-size:3em /* 48 ÷ 16 */
}
4、流动布局（fluid grid）的使用
“流动布局”指的是各个区块的位置都浮动，不是固定不变的。
.main {float: right;width: 70%;}
.leftBar {float: left;width: 25%;}
这么做的好处是，如果宽度太小，放不下两个元素，后面的元素会自动滚动到前面元素的下方，不会在水平方向溢出，避免了水平滚动条的出现，大大提升了用户的阅读体验。另外，绝对定位（position:absolute）的使用，也要非常小心。
5、Media Query技术的使用
在自适应设计的技术中，css3支持css2.1定义的媒体类型，同时添加了很多涉及媒体类型的功能属性，包括max-width(最大宽度)，device-width(设备宽度，orientation(屏幕定向:横屏或竖屏)，因此可以通过Media Query加载相应的CSS文件. 例如，下面代码定义了如果页面通过屏幕呈现，并且屏幕宽度不超过480px,则加载shetland.css
<link rel=”stylesheet” type=”text/css” media=”screen and (max-device-width: 480px)” href=”shetland.css” />
同样可以创建多个样式表，以适应不同设备或者不同分辨率的宽度范围，当然更有效的做法是将多个Media Query整合在一个样式表文件中:
@media only screen and (min-devece-width: 320px) and (max-device-width: 480px) {
/* Styles */
}
@media screen and (min-width: 600px) {
.hereIsMyClass {
width: 30%;
float: right;
}
上面的代码中定义的样式类只有在浏览器屏幕宽度超过600px时才会有效。
因此，使用min-width和max-width可以同时判断屏幕尺寸与浏览器实际宽度，如果希望通过Media Query作用于某种特定设备，但忽略在其上运行的浏览器是否由于没有最大化尺寸与设备屏幕尺寸不一致，则可以使用max-device-width和max-device-width属性来判断设备本身屏幕尺寸。
Media Query不是唯一的解决方案，同样可以通过Javascript来实现自适应设计，特别是某些旧浏览器无法完美支持CSS3的Media Query时，它可以作为备选方案。当然，我们仍然能借助专业的Javascript库来帮助旧浏览器(IE5+,Firefox 1+,Safari 2等)支持CSS3的Media Queries.使用方法:下载css3-mediaqueries.js,然后在页面中调用它即可，例如:
<!–[if lt IE 9]>
<script src=http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js></script>
<![endif]–>
6、 设计响应式图片
有很多同比缩放图片的技术，其中有不少是简单易行的，比较流行的方法是使用CSS的max-width属性：
img { max-width: 100%;}
老版本的IE不支持max-width，所以只好写成：
img { width: 100%; }此外，windows平台缩放图片时，可能出现图像失真现象。这时，可以尝试使用IE的专有命令：
img { -ms-interpolation-mode: bicubic; }
或者，Ethan Marcotte的imgSizer.js。
addLoadEvent(function() {
var imgs =
ocument.getElementById(“content”).getElementsByTagName(“img”);
imgSizer.collate(imgs);
});
如果有条件的话，最好能根据屏幕的不同大小，加载不同分辨率的图片。
三、 自适应站点对百度友好的关键
1，applicable-device标注应该怎么写
有了自适应设计的网页，还要照顾到对百度友好的设计，即告诉百度“我是自适应页面”方便百度进行识别校验。方法也很简单，只要在上面viewport标签下面再添加一个applicable-device标签就行：
<meta name=”applicable-device” content=”pc,mobile”>
表示页面同时适合在移动设备和PC上进行浏览。
2， 在使用百度站长平台链接提交工具的sitemp进行提交时，要做mobile type标记，具体取值：
<mobile:mobile type=”pc,mobile”/>
其他网页取值如下：
<mobile:mobile/> ：移动网页
<mobile:mobile type=”mobile”/> ：移动网页
<mobile:mobile type=”htmladapt”/>：代码适配
无该上述标签表示为PC网页
百度的移动适配目前分为三种情况：跳转适配，代码适配和自适应。跳转适配目前百度的站长平台里有完整的适配工具，可以在平台里提交适配规则即可。但是代码适配则需要我们在网站里做一些配置，才能让百度准确识别我们的网页适配关系。下面就详细介绍下我们做代码适配的过程。
流量潜力
如果不做移动适配的话，可能我们本来有的移动网页和移动端排名因百度无法确认是移动页面，因此这部分流量都给指向了百度的转码页。可以看自己网站在站长工具里面，移动端有多少流量是指向了转码页。这部分流量在做完适配后，即可指向我们的移动页面，避免了自己的流量被百度截流。
开发
代码适配的开发，百度官方也有详细的说明，可分为两部分： Vary HTTP标头 和 Meta applicable-device 标签。
【Vary HTTP 标头】
其作用在百度的文档里解释得很清楚：1、它会向百度传递一个信号，表示说这是个代码适配的站点，百度就会尽快把网站抓取一遍进行适配；2、它可以防止用户接收到错误的网页缓存。这部分是在网站的服务器上进行的，有可能是 Nginx,Apache, IIS 等， 需要在服务器的配置里，设置 Varyheader 为 Vary:Accept-Encoding, User-Agent
比如Nginx 下， 可以在配置文件中加上：more_set_headers-s 200 “Vary: ” “Accept-Encoding, User-Agent”
注意：打开这个设置需要nginx同时安装有ngx_headers_more模块
在Apache下，可以在配置文件里写上：Headerappend Vary User-Agent
【Meta applicable-device 标签】
Vary header 加上之后，为了让百度更好地识别我们的页面是 PC 还是 Mobile，就需要使用百度自定义的这个 Meta applicable-device 标签了。注意以下来自百度的消息: Meta applicable-device 标签，并非是站点必须标注的，现在很多站点没有标记这个标签情况也很好。但这个标签可以帮助百度校验自己的判断，并及时进行修正。做这个事情又不麻烦，所以我们建议代码适配站点为了保证效果，还是加这个标签。
因此可能有些网站之前的移动流量已经很好了, 不会出现被百度转码的情况. 这说明百度已经能很好地识别你的移动页面了. 但是依然建议加上这个标签, 一来加这个标签很容易, 二来可以确保百度能更准确地识别页面类型. 如果没有加这个标签的话, 万一突然技术做改版, 一些代码的修改导致百度无法继续准确识别页面类型了呢?
这部分是在网站的模板里添加的。自适应的网站肯定已经有了判断用户设备是 PC 还是 Mobile 的逻辑。利用这个逻辑，在整站的 <head></head> 部分添加一行代码即可：
如果用户是PC设备(注意需要包括Baiduspider PC UA)，则添加<metaname=”applicable-device” content=”pc”>
如果用户是移动设备(包括 Baiduspider Mobile UA)，则添加<metaname=”applicable-device” content=”mobile”>
注：关于BAIDUSPIDER，移动和PC其实都是Baiduspider，并没有区分，只是UA进行了区分。最新移动UA请见百度官方文档。
验收上线
开发完成后，需要先在测试机上验收。可以用 Google 浏览器来模拟 Baiduspider 来检查是否添加正确, 如图所示, 是检查 Baiduspider Mobile UA 的效果的
在测试机上验收完成后就可以上线了。上线后，尽量再用站长平台的抓取诊断工具测试几个页面，以免到线上后出现与测试机不一致的情况。比如下面是抓取 PC 页面来检查的线上结果。
跟踪
上线后就可以持续跟踪百度移动的SEO流量数据了。要追踪的主要是网站自己的统计工具统计的流量数据和百度站长平台的移动端转码页流量数据。上线后一到两周，移动端的流量应该就会有明显的增长，而百度转码页的流量则会下降。这个此消彼长的过程会持续一段时间。直到转码页的流量基本为0，都转为移动页的流量。
本文内容来源于：百度资源搜索平台
微信扫一扫 
支付宝扫一扫 
