A rewrite engine is a component of web server software that allows you to rewrite or redirect uniform resource locators (URLs). The most popular rewrite engine is the Apache HTTP server’s mod_rewrite. There are other web servers, such as nginx or lighttpd, that provide similar functions.

Some content man­age­ment systems generate cum­ber­some URLs. This software component is used to convert them into user-friendly URLs. The reasons for this are obvious: technical URLs such as

"http://example.com/a/index.php?title=pagetitle"

aren’t easy to remember; a rewrite engine enables the URL to be written in a much more intuitive way:

"http://example.com/article/pagetitle"

An internet user can also use this URL to access a cor­re­spond­ing web page. If a request like this is received by the web server, the rewrite engine au­to­mat­i­cal­ly converts the URL into the internal one used by the server

"http://example.com/a/index.php?title=pagetitle"

The rewrite engine creates an ab­strac­tion layer between the URLs used in­ter­nal­ly by the web project and the URLs pub­li­cal­ly displayed online. This makes it possible to provide a user-friendly, con­sis­tent address scheme, re­gard­less of internal technical re­quire­ments.

In­ter­nal­ly, the dynamic, pa­ra­me­ter­ized address can continue to be used while users from the internet access the web project via a seemingly static address. This function has the advantage that ex­ter­nal­ly-presented URLs remain valid even if internal changes are made to the file hierarchy.

In addition, website operators can use the rewrite engine to implement address redirects, which can be linked to specific con­di­tions. In effect, it is possible to set up redirects based on the user agent string or the IP address of the re­quest­ing client, in order to implement geo targeting or to have targeted, optimized websites appear on different devices. A 301 redirect is generally used, which ensures that only one version of the website is stored in the search engine’s index, despite the parallel operation of ad­di­tion­al mobile websites or different language versions.

Website operators should make sure they stay away from cloaking practices, which is where optimized sites are specif­i­cal­ly created and shown to search engine crawlers in order to improve rankings.

Examples of use

The rewrite engine provides various commands for ma­nip­u­lat­ing URLs, which can be iden­ti­fied as rules in different parts of the web server software. Mod_rewrite, the rewrite engine of the Apache web server, can be used in a directory container within httpd.conf, in a virtual host section or within an .htaccess file. With nginx, URL rewriting is recorded in the con­fig­u­ra­tion file /etc/nginx/nginx.conf. With lighttpd, the /etc/lighttpd.conf file is available in the vHost con­fig­u­ra­tion.

In order to rewrite the dynamic URL "http://example.com/a/index.php?title=pagetitle" via the rewrite engine into the static URL "http://example.com/article/pagetitle", different commands are used with Apache, nginx, and lighttpd web servers.

Apache’s rewrite engine

To use mod_rewrite with Apache, the rewrite engine needs to be activated with the RewriteEngine on directive. This is followed by the RewriteRule, which defines in­struc­tions for URL rewriting using regular ex­pres­sions (Regex):

RewriteEngine on
RewriteRule ^/article/(.*)$ /a/index.php?title=$1

If rewriting needs to be defined by a RewriteRule, then it can be broken down into two pa­ra­me­ters: the search pattern and the target pattern.

  • Search pattern: this pattern describes the URLs that are to be redi­rect­ed. A certain condition is defined in the form of a search pattern. If this condition is fulfilled, the URL can be rewritten according to the target pattern. In the current example, the search pattern would be the following section of the RewriteRule: ^/article/(.*)$.
  • Target pattern: this parameter describes the target URL. If the redi­rec­tion is con­fig­ured at server level, the complete URL is replaced. At directory level in the .htaccess file or within the httpd.conf, only the path from the current directory onwards is replaced. In this example, the target pattern includes this section of the RewriteRule: /a/index.php?title=$1.

An ex­pla­na­tion of the ex­pres­sions regularly used in the examples can be seen in this table:

Regular ex­pres­sion Ex­pla­na­tion
^ Beginning of string.
$ End of string.
(.*) A place holder for any string within a URL. The paren­the­ses store the string in a variable.
$1 A variable that allows access to cached values that are stored within paren­the­ses.

The RewriteRule ^/article/(.*)$ /a/index.php?title=$1 defines the rule that all URLs beginning with the string /article/ should be converted to the dynamic URL scheme /a/index.php?title=$1, where $1 is the string that cor­re­sponds to anything that comes after /article/, captured by the place holder (.*). If a user enters the static URL "http://example.com/article/pagetitle" into the web browser, the web server converts this in­ter­nal­ly to the dynamic URL "http://example.com/a/index.php?title=pagetitle", based on mod_rewrite. This is invisible to the user. In this case, the place holder (.*) and the variable $1 cor­re­spond to the 'pageti­tle' string. If URL rewriting is to be linked to certain options that control the behavior of the mod_rewrite, they are listed in square brackets after the RewriteRule, and separated by commas, if there are several. In this way, external redi­rect­ing via HTTP status code can also be im­ple­ment­ed. The following table shows a selection of options for the RewriteRule. A complete list can be found on the official website of the Apache Software Foun­da­tion.

Option Flag Function
Redirect R The [R] flag causes an HTTP redirect to be issued to the browser with the 302 status code. To use another status code, append it with an equal sign to the flag, e.g. [R=301].
Forbidden F This instructs the webserver to send the web browser a 403 (forbidden) HTTP status code.
Gone G The webserver sends the browser the HTTP status code 410 (gone) and shows that a resource that used to be available is no longer available.
Last L This flag causes mod_rewrite to stop pro­cess­ing the rule set.
Nocase NC When verifying whether a URL meets the rewriting con­di­tions, upper and lower case do not matter.
Chain C The next RewriteRule is only con­sid­ered if the current condition is met.

Based on such an option, an external for­ward­ing via HTTP status code could be im­ple­ment­ed as follows:

RewriteEngine On
RewriteRule ^oldpage.html$ /newpage.html [R=301]

In addition to RewriteRules, mod_rewrite can also be used to define Rewrite­Conds which can be used by website operators to set ad­di­tion­al con­di­tions that must be met for URL rewriting.

The syntax of a Rewrite­Cond cor­re­sponds to the following structure and is noted before the RewriteRule:

RewriteCond TESTSTRING CONDITION

The test string typically contains server variables which are defined by percent signs and curly brackets such as %{HTTP_HOST}. The following table shows a selection of server variables.

Server variable Ex­pla­na­tion
HTTP_USER_AGENT Refers to the client used for server access. The variable is generally used to provide an optimized website to various web browsers.
HTTP_HOST Refers to the hostname. This can include values such as domain.com, subdomain.domain.com, or the IP address.
SERVER_PORT Refers to the addressed port (e.g. 80 for HTTP or 443 for HTTPS). The variable allows website operators to redirect visitors to a secure con­nec­tion.
REMOTE_ADDR Refers to the IP address of the user accessing the web server. This variable is sometimes used to block spam attacks.

The following example shows a Rewrite­Cond that binds a sub­se­quent RewriteRule to the user’s IP address:

RewriteCond %{REMOTE_ADDR} 173.45.68.79

URL rewriting with nginx

The webserver, nginx, also supports URL rewriting natively. This can be im­ple­ment­ed by using regular ex­pres­sions. In order to convert URLs, the rewriting command is simply inserted into the web server con­fig­u­ra­tion file /etc/nginx/nginx.conf according to the nginx syntax in a { [...] } block:

location /article {
 rewrite ^/article/(.*)$ /index.php?title=$1 last;
}

The location /article part tells website operators that URL rewriting is ref­er­enc­ing the sub­di­rec­to­ry article. The regular ex­pres­sions for rewriting cor­re­spond to those that are also used with the Apache web server and are initiated with the rewrite command. The last flag indicates that the rewriting should be done in­ter­nal­ly and therefore without being redi­rect­ed. The following flags are available for temporary or permanent redirects:

Flag Ex­pla­na­tion
last URLs are rewritten in­ter­nal­ly. There is no redi­rect­ing.
redirect The user is tem­porar­i­ly redi­rect­ed to the new URL by a 302 redirect.
permanent The user is per­ma­nent­ly redi­rect­ed to the new URL by a 301 redirect.

If no flag is set, then nginx au­to­mat­i­cal­ly assigns the HTTP error code 500.

Rewrite with lighttpd

With lighttpd, URL rewriting is im­ple­ment­ed on the basis of the url.rewrite-TYPE function. The place holder TYPE stands for various rewriting con­fig­u­ra­tion options:

Rewriting con­fig­u­ra­tion options Ex­pla­na­tion
url.rewrite-once One-time URL rewriting. If the search pattern is found and the cor­re­spond­ing URL is rewritten to the target pattern, no more rewriting needs to take place.
url.rewrite-repeat In contrast to url.rewrite-once, url.rewrite-repeat can be followed by further rewriting.

The syntax basically follows the same pattern as with Apache when rewriting with lighttpd since the same regular ex­pres­sions are used:

url.rewrite-once = (
 "^/article/(.*)$" => "/index.php?title=$1"
)

If an external redi­rec­tion is to take place instead of an internal one in lighttpd, the rewriting module isn’t used, but rather a redirect module where URLs pass through the rewrite, then the redirect module.

Rewrite with Microsoft IIS

The platform Microsoft Internet In­for­ma­tion Services (IIS) doesn’t natively have a rewrite engine. However, this can be added later on to the webserver with the Modul IIS URL Rewrite 2.0. This also allows Microsoft users to make URLs available to their website visitors, without having to interfere with the internal file man­age­ment. After down­load­ing, the URL rewriting extension is in­te­grat­ed directly into the IIS Manager interface where Rewrit­in­gRules are entered via a graphical user interface. IIS URL Rewrite 2.0 uses regular ex­pres­sions to define URL search and target patterns.

URL rewriting and search engine op­ti­miza­tion

Through rewriting, pa­ra­me­ter­ized URLs can be converted into mean­ing­ful URLs, which makes them more user-friendly. Because of this, the functions of mod_rewrite and cor­re­spond­ing im­ple­men­ta­tions in other web server systems are often discussed when talking about search engine op­ti­miza­tion. It’s been a topic of dis­cus­sion for a while as to whether user-friendly URLs count as ranking factors since there is no clear evidence for a direct relation. However, website operators are likely to benefit from indirect efforts. In contract to cryptic pa­ra­me­ters, rewritten URLs allow internet users to un­der­stand where a link leads. Rewriting can therefore be used to build trust and possibly increase click-through numbers. In addition, search terms in URLs are displayed in bold on the search results page, which can provide an ad­di­tion­al incentive for clicks.

Go to Main Menu