网站应该统一移动端与桌面端域名
我们如何实现移动端响应速度提升20%、优化搜索引擎优化(SEO)并降低基础设施负载。
此前访问维基站点(如en.wikipedia.org)时，服务器仅提供两种响应：桌面版页面或重定向至对应移动网址(如en.m.wikipedia.org)。该移动网址再从MediaWiki提供移动版页面。自2011年部署MobileFrontend以来，我们的服务器始终采用此模式运行。
过去两个月间，我们完成了所有维基站点移动端与桌面端域名的统一(时间线)。这意味着在页面加载过程中，移动用户将不再被重定向至独立域名。
10月8日周三完成英文维基百科部署后，我们正式完成此次变更。移动域名在24小时内进入休眠状态，这证实绝大多数移动流量此前均通过标准域名访问维基百科，因此始终处于重定向状态。[1][2]
为何如此？
为何我们曾采用独立移动域名？又为何认为变更此举将带来益处？
回溯2008年，当时各类规模的网站均设有移动子域名。BBC、IMDb、Facebook及全球各大报社都采用了标志性的m-dot域名。对维基百科而言，独立移动域名使移动实验得以低风险启动，并规避了技术限制。2011年通过重定向机制，该域名成为默认访问入口。
十七年后的今天，形势已然巨变。网站使用m-dot域名已不常见，维基百科沿用该域名令当代用户感到意外，甚至可能削弱域名品牌认知度。2008年的技术限制早已消除，维基媒体CDN现已能高效支持单一URL下的可变响应方案。更重要的是，我们有理由相信谷歌已停止支持独立移动域名——这正是当初启动该项目的动因。
详细历史沿革与技术分析详见移动域名终止RFC，相关周报更新可查阅mediawiki.org。
站点速度
谷歌曾直接从移动搜索结果跳转至我们的移动域名，但去年停止了该做法。这导致大量用户遭遇移动重定向，移动响应速度倒退10-20%。[2]
2008年谷歌曾支持移动域名，允许网站声明独立的移动网址。虽然谷歌仅对桌面版网站进行内容索引，但会存储该移动网址，并在移动设备搜索时跳转至此。[3] 该机制使谷歌引荐流量可跳过重定向环节。
谷歌于2016年推出新型爬虫程序，并逐步以此重新索引互联网内容。[4-7] 这款“移动优先”爬虫以移动设备而非桌面设备的方式运作，取消了区分移动端与桌面端链接的功能——如今所有用户仅通过单一链接访问！Wikipedia.org是谷歌最后一批完成切换的网站之一，2024年5月为其明确变更窗口期。[2] 这意味着谷歌带来的60%页面访问量，如今必须经历与2011年以来其余40%访问量相同的重定向流程。[8]
统一域名消除了重定向，使移动端响应时间提升了20%。[2] 这一改进既是恢复 也是净提升 ，因为它惠及所有用户！它既修复了去年谷歌引流流量出现的退化问题，也为其他所有流量带来了同等幅度的响应速度提升。
下图展示了该变更在全球范围内的影响。其中“全球p50”对应德国或意大利等靠近数据中心的高速网络体验，而“全球p80”则类似于伊朗用户浏览波斯语维基百科时的体验。
SEO
首个受影响的网站并非维基百科，而是维基共享资源。维基共享资源是维基百科及其姊妹项目使用的免费媒体库。蒂姆·斯塔林六月发现，Commons上1.4亿页面中仅半数被谷歌收录。[9] 而在已收录页面中，另有2000万因移动端重定向被移除索引。每月被移除的页面持续以百万计增长。[10] 经查，移除根源正是移动端重定向机制。新谷歌爬虫与普通浏览器相同，同样会执行移动端重定向。
爬虫遵循重定向后，会读取页面元数据，该数据将标准域名标记为首选域名。这导致循环问题，使页面无法更新或被谷歌搜索收录。从索引中移除与排名无关，而是关乎页面是否存在于搜索索引中。
6月23日，Tim与我通过紧急干预停用了“Commons上的Googlebot”移动端重定向。此后引荐流量开始回升，连续十一周持续增长，最终实现谷歌引荐流量100%的增幅——从每周300万页面浏览量攀升至600万。谷歌点击数据同样呈现显著增长，点击量从100万攀升至180万次。[9]
我们不仅扭转了去年的下滑趋势，更创下历史新高。我们认为Commons达成新高的原因有三：
- 重定向消耗了半数抓取预算，导致可抓取页面数量受限。[10][11]
- 谷歌比维基百科早数年将Commons切换至新爬虫系统。[12] 索引规模很可能已持续萎缩两年。
- Commons页面具有稀疏的链接图谱。维基百科条目间存在丰富的链接网络，而Commons页面仅包含图片及其描述，极少链接至其他文件。这种独特的页面结构使得在缺乏站点地图的情况下，难以通过递归爬取发现Commons页面。
统一域名体系让我们突破了未曾察觉的瓶颈！
MediaWiki软件内置站点地图生成器，但十多年前我们已在维基媒体站点禁用该功能。[13] 我们决定为维基共享资源启用该功能，并于8月6日提交给谷歌。[14][15] 此后谷歌已为Commons新增索引7000万个页面，较六月增长140%。[9]
我们还发现，谷歌仅将不到0.1%的Commons视频识别为视频观看页面(针对谷歌搜索的“视频”标签页)。我在与谷歌搜索的合作伙伴会议中提出此问题，这可能是谷歌端的问题。一周后，Commons开始出现在谷歌视频中。[16][17]
链接分享用户体验
此前在移动设备分享链接时，系统会强制使用移动域名。即使在桌面端接收链接，点击后仍会跳转至移动站点。移动站点页脚的“桌面版”链接指向标准域名，并禁用标准版至移动版的重定向功能——该设计基于用户通过重定向进入移动站点的假设。该“桌面版”链接不会在移动端本身记住您的选择，且当您通过移动端访问时，不存在从移动版跳转至标准版的等效机制。这意味着共享的移动链接始终显示移动版网站，即使您已在桌面端选择退出重定向。
现所有用户共享同一域名，系统将自动显示适配版本。
新闻文章、研究论文、博客、讨论页及邮件列表中存在大量指向移动域名的稳定引荐链接。我们将无限期支持这些引用。为简化运维，现通过全域名重定向处理此类请求。此方案具有修复历史用户体验问题的优势——旧版移动端链接现已重定向至标准域名。18
此举解决了长期存在的缺陷，此前需通过共享用户脚本[19]、浏览器扩展程序 [20]及个人脚本等临时解决方案。[24]
基础设施负载
编辑发布后，MediaWiki会指令维基媒体CDN清除受影响条目的缓存(“清除缓存”)。WMF系统可靠性工程团队长期担忧CDN清除率不可持续：每次MediaWiki核心清除操作，MobileFrontend扩展都会为移动域名新增一份副本。
在统一域名后，我们关闭了这些重复清除操作，并将MediaWiki清除率降低了50%。过去数周内，维基媒体CDN每日处理的清除请求减少约40亿次。MediaWiki原先以4万次/秒的基准速率发送清除请求，峰值可达30万次/秒，如今两项指标均已减半。综合其他服务因素，维基媒体CDN当前每秒接收的清除请求总量减少了20%至40%，具体取决于编辑活动量。[18]
脚注
- T403510: 主版本发布，维基媒体Phabricator。
- T405429: 详细流量统计与性能报告，维基媒体Phabricator。
- 运行桌面版与移动版网站 (2009年)，developers.google.com。
- 移动优先索引 (2016年)，developers.google.com。
- 谷歌将移动优先索引设为新域名的默认选项 (2019年)，TechCrunch。
- 移动优先索引正式上线 (2023年)，developers.google.com。
- 移动优先索引最终指南 (2024年6月)，developers.google.com。
- 移动域名日落RFC § 脚注：维基媒体页面浏览量 (2025年2月)，mediawiki.org。
- T400022: 共享资源SEO审查，维基媒体Phabricator。
- T54647：图片页面未被谷歌索引，维基媒体Phabricator。
- 大型网站的爬行预算管理，developers.google.com。
- 我无法估算谷歌何时将Commons切换至新爬虫。根据新重定向对页面加载时间的影响(即非零抓取延迟)，我将维基百科的切换日期锁定在2024年5月。而Commons的抓取延迟至少自2018年起就已非零。这表明谷歌旧爬虫将移动用户导向Commons规范域名，不同于维基百科——后者直至去年仍被导向移动域名。原始性能数据参见：P73601。
- 维基媒体站点地图发展史 作者：Tim Starling，wikitech.wikimedia.org。
- T396684：为MediaWiki开发站点地图API
- T400023：为共享资源部署站点地图API
- T396168：视频页面未被谷歌索引，维基媒体Phabricator。
- Google视频搜索结果中commons.wikimedia.org的显示问题.
- T405931: 清理与重定向，维基媒体Phabricator。
- 维基百科:用户脚本/列表(英文维基百科)。包含NeverUseMobileVersion、AutoMobileRedirect和unmobilePlus等脚本。
- Redirector (10,000名用户)，Chrome应用商店。
- 如何强制桌面浏览器永不使用移动版维基百科 (2018年)，StackOverflow。
- 跳过移动版维基百科 (726名用户)，Firefox附加组件。
- 搜索“移动版维基百科”，Firefox 附加组件。
- 移动域名2025年终止公告 § 个人脚本替代方案 (2025年9月)，mediawiki.org。
本文文字及图片出自 Unifying our mobile and desktop domains
en.wikipedia.org 在移动端会自动跳转到 en.m.wikipedia.org，但 en.m.wikipedia.org 在桌面端却不会跳转回 en.wikipedia.org，这确实有点烦人。所以当移动用户发链接给我时，我总得手动删除 ‘.m’ 才能正常浏览。不过想想也合理，毕竟桌面端开发者有时也需要查看移动站点。
我向来厌恶“m.”域名，原因正是如此。这类域名几乎只支持单向跳转——移动用户会被重定向至移动域名，而桌面用户永远无法返回。更糟的是，从桌面用户视角看，移动版网站往往客观劣质，且手动返回的链接要么难以寻觅，要么根本不存在。
维基百科堪称最恶劣的案例，但众多网站都犯过同样的错误。我认为这正是现代“移动优先”网页平台的先驱——它们要么将桌面用户视为二等公民，要么根本不欢迎桌面用户。
相比之下，m.域名总比当年(所幸短命)的.mobi域名风潮强得多——当时人人都抢购这类域名搭建移动站点。
明明子域名就在眼前。
我记得有个时期——大概2010到2020年间尤为明显——部分HN读者强烈偏好移动版维基百科，即便在桌面端也坚持使用。他们在评论区讨论维基百科条目时，总会使用“.m”前缀的链接。那十年间reddit讨论区似乎也出现过类似现象。
我隐约记得早期MediaWiki的桌面主题比移动版主题更难看，但当时这不足以让我尝试始终使用移动版。我至今仍强烈偏好old.reddit.com…只要这个门户继续存在。
没错，早年桌面版维基百科没有设置最大宽度，可读性确实很差。
我至今仍在使用旧版网站，个人更偏爱它
> 但想想也合理，毕竟桌面端开发者有时需要查看移动版界面。
我认为这理由站不住脚。开发者完全可以修改用户代理。
(我猜登录用户或许能设置“无重定向”选项，甚至只需在网址末尾添加特殊查询字符串即可。)
直接用浏览器开发工具调整尺寸即可，无需伪造用户代理
尺寸差异可能不是唯一区别？
网站或许需要为鼠标键盘用户和触屏用户提供不同界面？即便浏览器窗口的像素数完全相同。
维基百科似乎是根据用户代理重定向的，不过无所谓啦。关键是开发者可用浏览器开发工具模拟任何需求。
据我观察，在移动端点击分享按钮而非复制链接时，始终会使用非移动版地址。
我在桌面端使用移动版页面。更简洁的界面总是受欢迎的。
> 但我猜这有道理，毕竟桌面端开发者有时需要查看移动站点。
这根本不是原因；你读过那篇文章吗？
况且网页开发者完全可以使用开发工具模拟移动浏览器。
这个改进虽迟但到，值得欢迎。但更重要的是，他们应该解决移动端“无法链接到高亮内容”的问题。当所有板块默认折叠时，浏览器无法滚动到相关板块。
随机示例链接：https://en.wikipedia.org/wiki/Henry_I_of_Cyprus#:~:text=On%2…
若链接指向折叠内容区块内部，此类链接在移动端将失效。
这使得在移动端引导用户查看相关内容变得极其困难，最终我只能发送截图替代。
编辑：“链接到片段”功能曾存在相同问题，但显然已修复。对此也表示感谢！
折叠区域内的文本也无法搜索。
我在安卓Chrome浏览器中点击评论链接完全正常，且能高亮显示内容
这功能迟到十年了，除了维基百科，我实在想不出还有哪个网站还在用移动域名。
YouTube？Twitch？Facebook？GSMArena？还有很多呢。
m.youtube.com和m.facebook.com在桌面设备上会重定向到主域名。这曾是维基百科最大的问题——除非手动修改地址栏并刷新页面，否则桌面端用户被迫使用移动版布局。
m.wikipedia.org本就是设计特色而非缺陷。其桌面端界面相当出色。在维基百科重构桌面站点前，这曾是我长期使用的首选前端。
https://m.xkcd.com/ 是我觉得确实有用的一个例子。
(嗯，移动端视图挺实用。不确定把它拆分到独立域名是否合理。)
当前XKCD漫画相当感人。https://xkcd.com/3172。
想来这也说明我老了，毕竟还记得他搭档经历类似困境的早期漫画。这大概是我成为“周更读者”后读到的第一篇：https://xkcd.com/1141。
同意。据我所知，在桌面版网站上无法在移动端查看漫画的替代文本。(而且桌面版网站缩放比例实在太小。)
在桌面版xkcd长按图片可查看替代文本
追这部网漫15年了，我怎么之前都没注意到这个功能？？
迟到什么？
PC版网站从一开始就重定向移动用户
移动版网站却从未重定向PC用户
解决这个基础问题竟拖了十年
不过话说回来…迟到什么？又不是有人后来居上做得更好，现在维基百科成了日渐式微的过时产物
他们没立即跟上潮流变化，等到方向明确时才着手处理，而且以完全合理的方式实施…方向稳定反而可能让他们获益良多
> 以完全合理的方式实施…
…不合理？非常不合理？
单向PC/移动端重定向根本不合理
当前结果，而非先前状态
修复设计与用户体验分歧为时已晚
难以置信谷歌竟无人察觉这是他们端的退化问题，既未提供临时解决方案也未联系维基媒体。
干得漂亮。
我原本期待这是两种布局的统一方案，那才真正令人惊叹。移动版条目页面固然出色，但若能通过同一前端实现双版本呈现，将是个绝佳的案例研究。
移动版在编辑群体中相对不受欢迎，若真这么做恐怕会引发抗议。
不过移动皮肤其实有“桌面版”，在维基百科网址末尾添加?useskin=minerva即可调用。
我用这个技巧来获取向量布局。此后版本都不合我个人口味。
登录后可在偏好设置中固定该布局。
什么意思？
近两年流行的“新”PC设计不就是移动版吗？(因此丑得要命)
新版(名为vector-2022)更接近移动端风格，但并非完全相同。移动皮肤名为minerva。此外移动版还会简化内容结构并替换部分元素。
出色的工程设计，文档阐述清晰明了。我向来欣赏这类优化方案。
顺便发现维基百科CDN的说明文档：https://wikitech.wikimedia.org/wiki/CDN
为移动站点设置子域名的做法，简直和用www2、www3做负载均衡一样愚蠢。
终于！但是…
> 维基百科的这种做法对当代用户而言令人费解，可能削弱域名品牌的认知强度
真的吗？理由居然是这个，而不是 移动链接跳转到桌面浏览器时仍显示移动版界面 ？！
嘿，当你每年花上亿美元运营网站时，这种深思熟虑的分析才合乎预期。
这绝对比大多数非技术用户困惑“维基百科网址为何以'en'而非'www'开头”的问题要小得多。
除了最老派的非技术用户，我敢说没人知道“www”是什么，更不会在意它是否出现在网址开头。理解“en”代表语言根本不需要技术知识，而且这种情况很少见——毕竟用www或省略en，链接大多照样能用。
他们或许会疑惑(虽然我怀疑)，但这毫无实际意义。
过去使用m.时，用户看到的移动版布局在桌面屏幕上极其不适配，还得通过某个相对冷门的按钮手动切换。
> 但这不构成行动依据
当然构成，他们只需放弃英语非默认语言的伪装即可。
移动版在桌面端提供极佳的阅读体验。
不得不承认，在普通屏幕上确实能顺便锻炼颈部肌肉。
> 真的吗？这竟是理由？难道不是因为移动端链接跳转到桌面浏览器时会显示移动版界面？！
若您阅读更具技术性的内部说明而非仅限新闻稿，您所提及的内容已被列为变更原因之一
https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_d…
BUG：移动模式下显示目录(TOC)
用户在移动设备上可能尤其需要跳转至#标题的深度链接
现在轮到你了YouTube…