TLDR: Mobile devices will receive the mobile version directly on the standard domain, instead of via a redirect to the mobile subdomain. The change is live in the Beta Cluster and on test wikis, and expected to follow a train-like rollout over the next few weeks.
Today, when you visit a link to a wiki (like en.wikipedia.org), the server responds in one of two ways: a desktop page, or a redirect to the equivalent mobile URL (like en.m.wikipedia.org). This mobile URL in turn serves the mobile version of the page from MediaWiki. Our CDN operates this way since 2011, when we enabled MobileFrontend by default.
Diagram: Unified mobile routing - before and after https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#/media/File:WMF_Unified_mobile_routing_2025.png
This redirect causes a number of problems, [2] such as: • User experience: Links shared by mobile users always display in mobile mode instead of the mode for your device, even after opt-out. • Site performance: Every Google Search result click is delayed by the redirect before displaying the article. • SEO: There is a conflict in our link graph because standard URLs redirect to mobile, and mobile sets a canonical pointer back to the standard URL. This de-indexes or mis-indexes pages in Google. T400022 https://phabricator.wikimedia.org/T400022 • Infrastructure cost: MediaWiki sends twice as many purges to our CDN infrastructure. • Technical debt and known issues (e.g. incompatibility with OAuth). [3] Over the next few weeks, the CDN will serve the mobile version directly, without first redirecting the browser to the mobile subdomain. What is not changing
• Backend code may detect mobile mode via `MobileContext->shouldDisplayMobile()`. • Frontend code may detect mobile mode via `mw.config.get('wgMFMode')`. [4] • Third-party MediaWiki sites. This is a WMF configuration change only. • Mobile requests to MediaWiki (identical HTTP host and headers). • Existing mobile URLs continue to work. • The "Desktop" opt-out footer link. • The speed of light. Backend requests unchanged
The mobile subdomain on WMF wikis is only recognised by Varnish (Wikimedia CDN). Varnish strips this "m" from the domain, activates MobileFrontend, and forwards the request to MediaWiki with the standard domain. [1]
This means MediaWiki core and extensions know how to handle mobile requests on the standard domain, because that's how it already works. It also means that the change is not observable (through supported means) by backend feature code in MediaWiki, because the mobile subdomains don't exist there. What should I test?
If your gadget or MediaWiki extension does not vary its behavior for mobile, or detects mobile mode using the supported mechanism listed above, then you're all set.
Note that Minerva-specific or mobile-specific code in a MediaWiki extension is naturally compatible with unified mobile routing, if it was tested locally or in CI. When you install Minerva (and optionally MobileFrontend) in your dev environment, they operate without a mobile subdomain by default. • There is (probably) no mobile domain in your local dev environment. • There is no mobile domain in Patch demo. • There is no mobile domain in CI. This infrastructure change aligns WMF production with how MediaWiki and MobileFrontend work by default. This decreases the potential for bugs we have today that can be exclusively found in production (via the mobile subdomain), and resolves a backlog of existing known issues. [3] Unsupported checks in frontend code
If a JavaScript-based feature contains a hardcoded `m.` hostname check, then this will no longer match in the future. The most likely place to find hardcoded `m.` checks is in a gadget or user script that changes its appearance or logic for mobile pages.
Detecting the mobile mode in this way is unsupported and should be replaced with a supported mechanism https://phabricator.wikimedia.org/T390923 instead. [4] An audit in April 2025 found there were 2 WMF-deployed extensions using this, which were confirmed to fallback gracefully or have since been adjusted. [5] Where can I test?
The new unified mobile routing is live on these wikis: • Beta Cluster at https://beta.wmcloud.org • test wikis at https://test.wikipedia.org and https://test.wikidata.org • https://wikitech.wikimedia.org • https://office.wikimedia.org • https://www.mediawiki.org For other production wikis, such as en.wikipedia.org, you can preview the change today by adding `?useformat=mobile` to a URL. This activates MobileFrontend on the standard domain, like it would in the future. For example: https://en.wikipedia.org/wiki/Banana?useformat=mobile.
The timeline https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting/2025_Announcement#Timeline spans several weeks and should not require dedicated testing. If you're unsure, you can test on the pilot wikis above, or in production via the `useformat=mobile` parameter. f you find a bug with mobile toggling or another regression, please report a bug to Phabricator. If you have questions or need help with a gadget or user script, please reach out on the talk page https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Mobile_domain_sunsetting.
-- Timo Tijhof
🔗 Read or share this post on the web via: https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting...
[1]: Diagram of mobile routing before and after https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#/media/File:WMF_Unified_mobile_routing_2025.png [2]: Problem statement and analysis on mediawiki.org https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#Context_and_Problem_Statement [3]: Known issues listed in the Phabricator task https://phabricator.wikimedia.org/T214998 [4]: Remember that mobile detection should be rare in frontend code, because most differences are between skins (Minerva vs another skin) and not MobileFrontend. [5]: Audit of unsupported m-dot checks in JavaScript https://phabricator.wikimedia.org/T390923
Just wanted to mention an anecdote that I told a volunteer two days ago that we are shuting down the .m. donains and saw in real time how his face lit up.
The appreciations might not be very visible but many (including yours truly) do appreciate it.
Keep up the great work.
Amir (he/him)
Krinkle krinkle@fastmail.com schrieb am Mo., 8. Sept. 2025, 21:46:
TLDR: Mobile devices will receive the mobile version directly on the standard domain, instead of via a redirect to the mobile subdomain. The change is live in the Beta Cluster and on test wikis, and expected to follow a train-like rollout over the next few weeks.
Today, when you visit a link to a wiki (like en.wikipedia.org), the server responds in one of two ways: a desktop page, or a redirect to the equivalent mobile URL (like en.m.wikipedia.org). This mobile URL in turn serves the mobile version of the page from MediaWiki. Our CDN operates this way since 2011, when we enabled MobileFrontend by default.
Diagram: Unified mobile routing - before and after https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#/media/File:WMF_Unified_mobile_routing_2025.png
This redirect causes a number of problems, [2] such as:
- User experience: Links shared by mobile users always display in
mobile mode instead of the mode for your device, even after opt-out.
- Site performance: Every Google Search result click is delayed by the
redirect before displaying the article.
- SEO: There is a conflict in our link graph because standard URLs
redirect to mobile, and mobile sets a canonical pointer back to the standard URL. This de-indexes or mis-indexes pages in Google. T400022 https://phabricator.wikimedia.org/T400022
- Infrastructure cost: MediaWiki sends twice as many purges to our CDN
infrastructure.
- Technical debt and known issues (e.g. incompatibility with OAuth).
[3]
Over the next few weeks, the CDN will serve the mobile version directly, without first redirecting the browser to the mobile subdomain. What is not changing
- Backend code may detect mobile mode via
MobileContext->shouldDisplayMobile().
- Frontend code may detect mobile mode via mw.config.get('wgMFMode').
[4]
- Third-party MediaWiki sites. This is a WMF configuration change only.
- Mobile requests to MediaWiki (identical HTTP host and headers).
- Existing mobile URLs continue to work.
- The "Desktop" opt-out footer link.
- The speed of light.
Backend requests unchanged The mobile subdomain on WMF wikis is only recognised by Varnish (Wikimedia CDN). Varnish strips this "m" from the domain, activates MobileFrontend, and forwards the request to MediaWiki with the standard domain. [1]
This means MediaWiki core and extensions know how to handle mobile requests on the standard domain, because that's how it already works. It also means that the change is not observable (through supported means) by backend feature code in MediaWiki, because the mobile subdomains don't exist there. What should I test? If your gadget or MediaWiki extension does not vary its behavior for mobile, or detects mobile mode using the supported mechanism listed above, then you're all set.
Note that Minerva-specific or mobile-specific code in a MediaWiki extension is naturally compatible with unified mobile routing, if it was tested locally or in CI. When you install Minerva (and optionally MobileFrontend) in your dev environment, they operate without a mobile subdomain by default.
- There is (probably) no mobile domain in your local dev environment.
- There is no mobile domain in Patch demo.
- There is no mobile domain in CI.
This infrastructure change aligns WMF production with how MediaWiki and MobileFrontend work by default. This decreases the potential for bugs we have today that can be exclusively found in production (via the mobile subdomain), and resolves a backlog of existing known issues. [3] Unsupported checks in frontend code If a JavaScript-based feature contains a hardcoded m. hostname check, then this will no longer match in the future. The most likely place to find hardcoded m. checks is in a gadget or user script that changes its appearance or logic for mobile pages.
Detecting the mobile mode in this way is unsupported and should be replaced with a supported mechanism https://phabricator.wikimedia.org/T390923 instead. [4] An audit in April 2025 found there were 2 WMF-deployed extensions using this, which were confirmed to fallback gracefully or have since been adjusted. [5] Where can I test? The new unified mobile routing is live on these wikis:
- Beta Cluster at https://beta.wmcloud.org
- test wikis at https://test.wikipedia.org and
For other production wikis, such as en.wikipedia.org, you can preview the change today by adding ?useformat=mobile to a URL. This activates MobileFrontend on the standard domain, like it would in the future. For example: https://en.wikipedia.org/wiki/Banana?useformat=mobile.
The timeline https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting/2025_Announcement#Timeline spans several weeks and should not require dedicated testing. If you're unsure, you can test on the pilot wikis above, or in production via the useformat=mobile parameter. f you find a bug with mobile toggling or another regression, please report a bug to Phabricator. If you have questions or need help with a gadget or user script, please reach out on the talk page https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Mobile_domain_sunsetting .
-- Timo Tijhof
🔗 Read or share this post on the web via:
https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting...
[1]: Diagram of mobile routing before and after https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#/media/File:WMF_Unified_mobile_routing_2025.png
[2]: Problem statement and analysis on mediawiki.org https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsetting#Context_and_Problem_Statement [3]: Known issues listed in the Phabricator task https://phabricator.wikimedia.org/T214998 [4]: Remember that mobile detection should be rare in frontend code, because most differences are between skins (Minerva vs another skin) and not MobileFrontend. [5]: Audit of unsupported m-dot checks in JavaScript https://phabricator.wikimedia.org/T390923
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
All wikis now serve mobile page views on the canonical domain, instead of via a redirect.
Over the past month we rolled unified mobile routing to all wikis. The rollout ended on Wednesday 8 October, after deploying to English Wikipedia.
The changed improved mobile response time by 20% worldwide, un-broke Commons SEO, reduced CDN purge load, and old mobile links now redirect to canonical which addresses a long-standing UX issue when opening shared links on desktop. Read more about this on the Wikimedia Techblog:
https://techblog.wikimedia.org/2025/11/21/unifying-mobile-and-desktop-domain...
-- Timo Tijhof
On Mon, 8 Sep 2025, Krinkle wrote:
TLDR: Mobile devices will receive the mobile version on the standard domain, instead of via a redirect to the mobile subdomain. The change is live in the Beta Cluster and on test wikis, and expected to follow a train-like rollout over the next few weeks.
wikitech-l@lists.wikimedia.org