Manual:Short URL

According to World Wide Web inventor Tim Berners-Lee, good page addresses should never change. Short URLs which hide complex programming code from the page address is good for webpage visitors. Please take a few minutes to devise a stable URL structure for your website before getting started, to reduce problems later. This page has been divided into separate "how to" mini-guides listed below to make things easier.

Defaults
MediaWiki's default installation path usually look like these examples:
 * (installed as root user)
 * (installed with a shared hosting provider)

MediaWiki's default page addresses look like these examples:
 * (MediaWiki version 1.11.0)

Using the methods below, short webpage addresses can be changed to addresses such as these:

Advantages and disadvantages
Before starting, we must first know what is wrong with long URLs. The answer is nothing much. Indeed, only long URLs work in all hosting environments— a good thing to know lest one day you move your wiki to a hosting environment where you can't keep using the same URLs everyone has bookmarked or linked to.

The advantages of short URLs are purely cosmetic ("pretty" versus "ugly" URLs).

Once you've decided that you really want short URLs and are willing to go through the effort, you're ready for the long trial and error configuration as detailed below.

Shared hosting
Most shared hosting systems do not allow changes to httpd.conf. If you are using a shared host, first try asking your hosting provider who may well solve your problem for you. If that doesn't work out, depending on your hosting provider, you may be able to edit .htaccess (detailed below).

If you have a choice, you should edit httpd.conf (which requires root access and is the preferred method because your wiki will perform better ). You only need to edit either .htaccess or httpd.conf, not both.

Recommended configuration (Used on Wikipedia)
The following setup is used on Wikipedia, and tends to be robust and easy to set up. This setup should be used unless you really dislike some aspects of it (it doesn't rewrite all URLs) or you simply can't use it (it requires root access).

Advantages

 * This method is reliable and guaranteed to work in all versions of MediaWiki for the indefinite future. Other schemes are not tested by MediaWiki developers and might break when changes are made to the software.
 * You should not rewrite articles to be in the document root. URLs like  http://wiki.example.com/Article_title  may look prettier to you than  http://www.example.com/wiki/Article_title , but the former causes a variety of problems (including issues with robots.txt, favicon.ico, and script paths).
 * Not all URLs are rewritten, but this is good. With a single simple rule, this allows you to easily block search engine spiders from viewing background pages (like the edit form or history pages), separate actual article views from other accesses in log analysis, et cetera. Although links to edit pages and background pages are slightly less memorable, this is no big deal: the important thing is the articles.
 * The method uses Alias instead of Rewrite. This is simpler and more reliable (but unfortunately requires root access).

Disadvantages
This method requires Apache and root access.

Guide
First of all, ensure that you are using Apache and root access (so you can modify httpd.conf; .htaccess</tt> is not enough!). If either of these is false, you cannot use this exact method; you need to modify it appropriately, or use some other method listed below, preferably Manual:Short URL/wiki/Page title -- no root access.

<ol> <li> Install your wiki to some directory. This guide will assume you install it in /w/</tt> relative to your web root, as Wikipedia does. If you choose another path, replace /w/</tt> with that path wherever you see it.</li> <li> Choose a directory that your articles should live in. This guide will assume that you choose /wiki/</tt>, as Wikipedia does. Articles will then be accessed like  http://www.example.com/wiki/Article_title </tt>. If you choose another path, replace /wiki/</tt> with that path wherever you see it. '''Do not create this directory. It should not contain any files and should not exist in the filesystem. The path also must not be the root directory, or the same as the virtual directory'''. The last point is important: do not try to ignore it to get prettier URLs, or else this method will not work.</li> <li> At the bottom of LocalSettings.php</tt>, add the following: Note that  should already be set to /w</tt>. If it is not (for example, if you're moving from a different URL scheme), make sure to set it to that.</li> <li> Edit httpd.conf</tt> to contain the rule. Note that the second path is relative to the filesystem root, not the web root! This might be, for instance,, if /var/www/</tt> is your web root.</li> <li> Make Apache reread its configuration file (gracefully restart). You might use, for instance,  or a similar command as root, or use features of WebHost Manager or similar software.</li> <li> In your web root, create a file called robots.txt</tt> if one does not already exist. Then add the following to the end of the file: User-agent: * Disallow: /w/ Disallow: /wiki/Special:Search Disallow: /wiki/Special:Random The first "Disallow" rule stops spiders from indexing histories, edit pages, and other background pages that are useless to users performing a search. This will also prevent duplicate content from being indexed. The second and third rules stop spiders from indexing two special pages that might confuse them, and generally be unhelpful.</li> </ol>

You're done; your wiki should be working perfectly. If not, go to irc://irc.freenode.org/mediawiki and report any problems.

Other techniques: how-to mini-guides
Anyone is welcome to create a how-to solution page and list it below. Please use a sensible name for the page, one that fits in with the below names. When each unique solution has its own page, readers can skip complexity they do not want. Keep it simple, readable, short, with a separate page per separate solution.

To help others find out which Short URL methods really work, after trying each method please edit the page and increase the "worked" or "didn't_work" numbers for that guide.

example.com/Page_title
How to create example.com/Page_title</tt> URLs:

(used this method: x2) (also works with 1.10, but not with 1.11., very similar to the above solution)

example.com/wiki/Page_title
How to create wiki/example.com/wiki/Page_title</tt> URLs: - recommended method if you don't have root access; should also work with PHP as CGI mode

Root access

These methods require that you have access to the server configuration. If you are on a shared host, you most likely don't; see the "no root access" examples instead.

(If the Alias method is not suitable [for example, you use PHP as a CGI], you can use Apache instead.)

wiki.example.com/Page_title
How to create wiki.example.com/Page_title</tt> URLs.

Ampersand (&) problem
The ampersand problem shows up when you have page titles with symbols in (such as &, ?, #, + and /) that, despite being correctly encoded in the link are not being passed correctly from mod_rewrite to the script. This manifests in 404 page-not-found errors, because the title gets cut off at the special character. For example, clicking on a link to "John & Maria's page" gets a 404, because MediaWiki is looking for a page named "John ".

This is because ampersands in long-form names are treated as query string separators, and would never reach the PHP runtime environment. This is caused by an old and problematic mod_rewrite bug. There are discussions of other possible solutions at lists.wikimedia.org and fgiasson.com.

Solutions:

Looping alias/rewrite errors
If you receive looping alias/rewrite errors such as "Cannot find page www.example.com/wiki/wiki/wiki/wiki/wiki/ [...] /index.php", try one of these fixes:

Revert to default
If you need to revert to the default values of your wiki but have accidentally deleted them, here are the defaults: