How to Create User-Friendly URLs Using .htaccess

A user-friendly URL (sometimes called a clean, pretty, or search-engine-friendly URL) is a short, readable web address that hides a longer file path behind the scenes. Instead of sending visitors to example.com/files/folder/sitemap.html, you can let them use example.com/sitemap while the real file stays exactly where it is. Tidy URLs are easier to remember, easier to share, and generally read better to both people and search engines.

You achieve this with a small .htaccess file and Apache's mod_rewrite module. The .htaccess file is a per-directory configuration file that Apache reads on every request, so a rewrite rule takes effect the moment you save it, with no restart needed. This is a general Apache technique, so it works the same way whichever control panel your hosting uses.

Last reviewed: 27 July 2026, against Apache HTTP Server 2.4 (current stable series) and its mod_rewrite module. This guide is written for Noiz hosting and is kept current against Apache. It complements, and does not replace, the official Apache documentation linked below.

Official Documentation Reference

• Apache mod_rewrite Introduction (httpd.apache.org)
• The RewriteRule directive (httpd.apache.org)
• RewriteRule flags: L, R, QSA, NC and others (httpd.apache.org)
• Apache .htaccess how-to (httpd.apache.org)

Prerequisites

• A hosting account served by Apache with mod_rewrite available. This is the standard configuration on Noiz shared hosting, so no setup is needed on your side.
• Access to your website files, either through your control panel's File Manager or over SFTP.
• The exact real path of the file or page you want to reach, relative to your document root (for example /files/folder/sitemap.html).
• A copy of your current .htaccess file kept somewhere safe. A single malformed line takes the whole site offline until it is corrected, so having a known-good version to restore is worth the thirty seconds it costs.

Where the .htaccess file lives

An .htaccess file applies to the folder it sits in and every folder beneath it. For rules that should cover your whole site, put it in your document root, which is the top-level folder that holds your public web files (commonly named public_html, httpdocs, or public, depending on your panel). If a file called .htaccess already exists there, edit that one rather than replacing it, since your platform may rely on rules that are already present.

Note the leading dot in the name. It makes the file hidden by default, so if you cannot see it, enable Show hidden files (sometimes labelled dotfiles) in your File Manager or SFTP client.

Point a short URL at a longer path

1. Open or create the .htaccess file

In your document root, open the existing .htaccess file for editing, or create a new plain-text file named exactly .htaccess (no other extension). Watch out for text editors that helpfully append .txt on save, which is one of the most common reasons a perfectly good rule appears to do nothing.

2. Add the rewrite rule

Add the following two lines. Change the pattern and the target path to match your own site, then save the file:

RewriteEngine On
RewriteRule ^sitemap/?$ /files/folder/sitemap.html [L]

With this in place, a visitor who types example.com/sitemap is served the contents of example.com/files/folder/sitemap.html, while the tidy address stays in their browser bar.

3. Test it

Visit the friendly URL in a private or incognito window (browsers cache redirects aggressively, so a fresh window avoids confusing results). The page should load normally, complete with its images and styling. Then load two or three unrelated pages to confirm your new rule has not swallowed requests it should have ignored. If anything misbehaves, see the troubleshooting notes below.

Understanding the rule

Reading the rule left to right makes it easy to adapt:

• RewriteEngine On switches the rewrite engine on. You only need this line once per .htaccess file, before any rules.
• RewriteRule is followed by three parts: the pattern to match, the real file to serve, and a set of flags.
• ^sitemap/?$ is the pattern, written as a regular expression. The ^ anchors it to the start of the address and the $ anchors it to the end, so it matches the whole path and nothing longer. The /? makes a trailing slash optional, so both example.com/sitemap and example.com/sitemap/ work.
• /files/folder/sitemap.html is the real file that Apache serves when the pattern matches.
• [L] is the Last flag. It tells Apache to stop processing further rules once this one matches, which keeps behaviour predictable as you add more rules.

Because this is an internal rewrite rather than a redirect, the change happens on the server and the visitor never sees the underlying path.

Two details that catch almost everyone

Do not put a leading slash in the pattern. Inside an .htaccess file, Apache strips the leading slash from the path before matching, so the pattern is ^sitemap/?$ and never ^/sitemap/?$. A stray leading slash produces a rule that is syntactically valid, throws no error, and simply never matches anything.

Make the trailing slash optional. An older form of this snippet used ^sitemap/$, which only matches when the visitor types the trailing slash. Everyone who types example.com/sitemap gets a 404 instead. The /? in ^sitemap/?$ accepts both forms, which is nearly always what you want.

Rewrite quietly, or redirect visibly

The rule above is an internal rewrite: the short address stays in the browser bar and the real path is never exposed. If you instead want the browser to move to a different address, for example because a page has genuinely moved, add the Redirect flag:

RewriteRule ^old-page/?$ /new-page [R=301,L]

Use R=301 for a permanent move, which passes accumulated search ranking to the new address, and R=302 only for changes that really are temporary. Choose deliberately. Browsers cache 301 responses hard, so a permanent redirect pointed at the wrong place keeps sending returning visitors astray long after the rule itself is fixed. Testing with R=302 and promoting to R=301 once the behaviour is confirmed avoids that.

Handy variations

Pass part of the URL through as a parameter

To turn example.com/product.php?id=42 into example.com/products/42:

RewriteEngine On
RewriteRule ^products/([0-9]+)/?$ product.php?id=$1 [L,QSA]

The bracketed group captures one or more digits and hands them to the target as $1. The QSA flag (query string append) preserves anything the visitor added themselves, so /products/42?ref=email still passes ref=email along to the script.

Drop the .html extension across a whole site

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ $1.html [L]

The two RewriteCond lines act as guards: the request must not already be a real directory, and a matching .html file must actually exist on disk. Without those checks the rule fires on requests for images, stylesheets and fonts as well, which is the usual route into a rewrite loop.

Send everything to a single front controller

Most modern applications route every request through one entry file. The standard pattern is:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [L]

Real files and real directories are served normally, and everything else is handed to index.php to resolve. If your application already ships its own .htaccess block, leave it intact and add your rules above it rather than overwriting it.

Other useful notes

• Escape literal dots. In a regular expression a dot means "any character". If your pattern needs to match an actual dot, write it as \. so it is treated literally.
• Rules run top to bottom. Apache evaluates each rule in order, so place more specific rules above broader ones and use the [L] flag to stop once a match is found.
• Working inside a subfolder. If your .htaccess lives in a subdirectory rather than the document root, add a RewriteBase line (for example RewriteBase /shop/) so the paths resolve correctly.
• Comment your rules. Any line beginning with # is ignored. Six months on, the reason for an obscure pattern is rarely obvious from the pattern alone.

Watch out for relative asset paths

A page that used to live at /files/folder/sitemap.html and is now served at /sitemap appears to the browser to sit at a different depth in the site. Any asset referenced relatively, such as images/logo.png, will be requested from the wrong folder and the page will load unstyled or without images. Fix it by referencing assets from the site root instead, as /files/folder/images/logo.png, or by adding a <base> tag in the page head. This catches people out far more often than the rewrite rule itself does.

Troubleshooting

You get a 500 Internal Server Error after saving: this almost always points to a typo in the rule. Check that RewriteEngine On appears once, that the rule has exactly three parts, and that there are no stray characters. Comment out the new lines with # and reload to confirm the site recovers, then re-enable them one at a time. The error log in your control panel names the offending line number, which turns guesswork into a two-minute fix.

The friendly URL does nothing: make sure the file was saved as .htaccess with the leading dot and no hidden extension such as .txt, and that you edited the file in your document root. Check for a leading slash in the pattern and for a mandatory trailing slash, the two failure modes described above. On Noiz shared hosting mod_rewrite is enabled and .htaccess overrides are permitted by default, so you should not need to change any server settings.

The browser reports a redirect loop: a rule is rewriting a request into something that matches the same rule again. Add RewriteCond %{REQUEST_FILENAME} !-f and RewriteCond %{REQUEST_FILENAME} !-d above the rule so real files and folders are left alone, and confirm the rule's target cannot match its own pattern.

A rule catches more than it should: patterns without ^ and $ match anywhere in the path, so a bare RewriteRule sitemap also fires on /blog/sitemap-notes. Anchor every pattern unless you have a specific reason not to.

The old behaviour keeps appearing: your browser may have cached an earlier redirect. Test in a private window, or clear your browser cache, before deciding a rule is not working.

The same rules work on one site but are ignored on another: .htaccess is an Apache feature. A web server such as nginx never reads the file and needs equivalent rewrite rules defined in its own site configuration instead. If the site in question is served by a static host or sits behind a proxy layer that never reaches Apache, the file will have no effect.

Good practice worth following

• Keep short addresses lowercase and hyphen-separated. Apache paths are case-sensitive, so /Sitemap and /sitemap are two different requests.
• Pick one canonical form per page, either with or without the trailing slash, and redirect the other to it. Serving identical content at two addresses splits your search ranking between them.
• Keep the original long address working, or redirect it to the short one, so that existing links and bookmarks do not break.
• Save a dated copy of a working .htaccess file outside the document root before each round of edits.

Need a hand?

If a rewrite rule is not behaving as expected, or your site has returned a 500 error after an .htaccess edit, open a ticket from the Noiz client area with the domain name and the exact rules you added. The Noiz support team can read the server error log for your account, pinpoint the failing line, and confirm whether the rule is reaching Apache at all.