Difference between revisions of "Pretty URL"
(convert to new template) |
|||
| Line 1: | Line 1: | ||
{{Feature | {{Feature | ||
| − | |image= | + | |image=Pretty.jpg |
| − | |imgdesc= | + | |imgdesc=Pretty URLs |
| − | | | + | |title= |
}} | }} | ||
{{#set:feature description = clean and SEO friendly URLs }} | {{#set:feature description = clean and SEO friendly URLs }} | ||
Latest revision as of 17:45, 14 May 2020
Pretty URL 
| |
|---|---|
 | |
| Image shows: | Pretty URLs |
| Summary | |
| Description: | clean and SEO friendly URLs |
| More | |
| Example: | https://freephile.org/wiki/Pretty_URL |
A "Pretty URL" is one that is short, memorable, and easy to type. It's not the same as a Persistent URL (PURL), but ideally, your persistent URLs are also Pretty. Making a "Pretty URL" means transforming a system URL like wiki/index.php?title=Main_Page with /wiki/Main_Page.
For most Content Management Systems or other web application software the system creates a new URL for each new piece of content. Making the URL 'pretty' can be a straightforward task that usually involves URL rewriting features of your web server in addition to some configuration of the application.
Not only are Pretty URLs easy on the eyes and brain; but they are also better for SEO. (The unadorned keyword is also the article path) Pretty URLs are better for SPAM prevention. Many spam bots are programmed to look for default system URLs like ?action=edit. While the prettified application will still correctly process querystring parameters (the original way will still work), the visible links in the application (and thus in the search engine index) will not be those default links. That is an improvement for fighting SPAM. Basically, spammers won't recognize that your software is a wiki because you've disguised it.
MediaWiki[edit | edit source]
For MediaWiki, first you should get 'short URLs' working. Then, you can also add 'ActionPaths' so that even the edit, delete, unwatch, etc. actions are "clean" too. This results in a wiki that has article URLs present in a REST-like manner with the action "verb" at the end. The default 'view' action is assumed and left off.
