* Serve the main page of WMF wikis from a consistent URL, one that does not vary by wiki configuration, site language, or local interface message overrides.
* Let the domain root serve actual content instead of a redirect.
* Traffic team. (assert potential routing impact)
* Reading Web team. (about SEO, and reader user experience)
* Performance team. (believed to improve performance)
* Core Platform Team. (core behaviour being utilised that previously has only been used by low-traffic wikis and third-parties)
* Wikimedia communities via Tech News and Community Engagement team. (identify potential impact on technical workflows we may not be aware of, so that we may help accommodate those)
## Status quo
The URL to WMF wiki main page varies by wiki configuration (site language, or hooks), and interface message overrides locally to the wiki. For example:
* https://en.wikipedia.org/wiki/Main_Page //(default localised page name for EN)//
* https://nl.wikipedia.org/wiki/Hoofdpagina //(default localised page name for NL)//
* https://de.wiktionary.org/wiki/Wiktionary:Hauptseite //(overridden by community to a different namespace)//
* https://www.wikidata.org/wiki/Wikidata:Main_Page //(local override)//
* https://www.mediawiki.org/wiki/MediaWiki //(local override)//
* https://fixcopyright.wikimedia.org/ //(wmf-config hook)//
The following are HTTP 301 redirects to <https://en.wikipedia.org/wiki/Main_Page>:
The following are HTTP 301 redirects to <https://fixcopyright.wikimedia.org/>:
Examples of affected links:
* Portals, such as <https://www.wikipedia.org> and <https://www.wikimedia.org>.
* Language links in the sidebar of the main pages themselves.
* Interwiki links, such as `[[mw:]]`, or `[[wikitech:]]`.
* Browsing directly by entering the hostname of a wiki project.
* Browsing by changing homepage address of one project into another (usually leads to a 404 Not Found, as "Wikipedia:Hauptseite" would not exist on nl.wikipedia.org).
### Current issues
* Accessing wiki projects by domain results in a redirect. (Subpar performance)
* Address bars, urls and search results for our projects prominently expose the inconsistent naming conventions of each wiki. (Subpar user experience)
* SEO. "Avoid Landing Page Redirects", Google PageSpeed, <https://developers.google.com/speed/docs/insights/AvoidRedirects>.
* Difficulties with tooling. Performance tests are difficult to write in a way that targets a normal view of a main page without a redirect, due to the url not being deterministic or consistent. (Current workarounds: Using a `?whatever` query string, which will serve the Main Page as the default title without redirect).
* Monitoring such as "Is the Main Page for all projects up and responding content?" is not trivial, as simplistic tools do not follow redirects or consider a 301 it as success, even if the actual page with a random url is returning an error. In some places, Main_Page as a redirect is sometimes deleted, leading to false alarms.
### Performance data
From Navigation Timing, over February 2019:
-- sampled views to enwiki/Main_Page
SELECT COUNT(*),SUM(event.redirecting) FROM event.NavigationTiming WHERE year=2019 AND month=2 AND wiki="enwiki" AND event.revId=870437359 AND event.action="view" AND event.isOversample=false;
-- sampled views to enwiki/Main_Page that involved a redirect
SELECT COUNT(*),SUM(event.redirecting) FROM event.NavigationTiming WHERE year=2019 AND month=2 AND wiki="enwiki" AND event.revId=870437359 AND event.action="view" AND event.isOversample=false AND event.redirecting != 0;
| Sampled views | Sampled views (redirected) | Time spent redirecting
| 31,734 | 9,703 |840,039 ms
This is from a 1:1000 sampling. This means that in February 2019, the Main Page had an estimated 31 million views from [Grade A](https://www.mediawiki.org/wiki/Compatibility) web browsers that completed their page load. Of these, over 9.7 million page views (30.5%) experienced a redirect. They cumulatively spent 233,344 hours (or over 27 years) waiting for a redirect (about 0.1 s each, on average).
## Proposal 1:
I'd like us to consider changing the canonical URL to a the main page of Wikimedia wikis to be the domain root. This means <https://www.wikidata.org/> would serve what we currently see at <https://www.wikidata.org/wiki/Wikidata:Main_Page>, for example.
MediaWiki provides a hook that allows the canonical url for a given title to be customised. This has been in use at translatewiki.net since 2015 (written about on [Nixlas' blog](http://laxstrom.name/blag/2015/08/31/mediawiki-short-urls-with-nginx-and-main-page-without-redirect/), [source code](https://github.com/wikimedia/translatewiki/blob/18e05349e8b950c0c57a6aa9a83d521361a30efc/TranslatewikiSettings.php#L390-L398)), and also used at WMF for the Fix Copyright campaign in 2018.
* <https://translatewiki.net> uses `Special:TwnMainPage` as their home page.
* <https://fixcopyright.wikimedia.org> uses the `Main_Page` article as their home page.
Once configured, all canonical access to the main page is automatically reflected accordingly by MediaWiki.
* The link to the main page in the sidebar and on the logo will point to this.
* When browsing from the talk page, what links here, history page, contributions, search results, it points to the canonical url.
* When creating an internal link to it in wikitext like `[[Main_Page]]` this results in the correct HTML for an anchor link to the canonical url (e.g. `<a href="/" title="Main Page">Main Page</a>`).
* When editing the main page, the purges sent to the CDN layer will be for the canonical url, as expected.
* When manually browsing to `/wiki/Main_Page`, MediaWiki's router normalises this to the canonical url in the form of a HTTP 301 redirect.