.htaccess Generator

Where .htaccess earns its place every day

The first scenario is a change of address. After a move to another domain the old links from search engines, from bookmarks and from articles stop working, and every one of them returns a 404. A RewriteRule with the 301 code sends the visitor to the new address and at the same time tells the search engine that the old address is no longer current. The second scenario is making addresses uniform: while a site opens under both example.com and www.example.com, a search engine sees two addresses for one document and splits the weight between them. A redirect towards one canonical form removes the problem.

The third scenario is technical and the most common around payments and internal services: keeping what should never reach the internet out of reach. A .git directory holding the full history of a repository, an .env file with database and mail passwords, database dumps and logs — none of that belongs in front of visitors, and one rule in the site root closes off such files at once. The fourth is a custom 404 page instead of the standard one: it keeps a visitor on the site and offers a link home. The same set of rules also serves during a move to a new CMS, when the old pages answer with a temporary placeholder.

• A domain change and redirects from the old addresses
• Reducing www and non-www to a single canonical address
• Forced HTTPS without editing the main server configuration
• Keeping .git, .env, dumps and logs away from strangers
• Switching off file listings in directories
• A custom 404 page and a folder kept out of search results

Where .htaccess files go wrong

The first mistake is losing a curly brace in RequireAll, FilesMatch or LimitExcept blocks. The closing brace sits on its own line and must end with a slash, otherwise Apache cannot tell where the block ends. The second mistake is writing two rules that contradict each other: a redirect from www and a redirect to www at the same time send the browser into a redirect loop and it reports an endless redirect. The third is forgetting that the Require directives only arrived with Apache 2.4, so the same idea on an older server is written differently.

Two further mistakes come from wrong expectations. The first is expecting an .htaccess file to protect a file stored higher up the tree: rules only apply downwards, so a file inside an uploads folder cannot block something in the site root. The second is assuming that an added X-Robots-Tag header keeps a folder out of search results while mod_headers is not loaded: the block is skipped silently and the folder stays open. Checking what ended up in the file is easier with a regular expression tester, and comparing two versions of a config is what the text comparison is for.

• A missing trailing slash on the closing brace of a block
• Redirects in both directions switched on at once
• Require all denied syntax on Apache 2.2
• Trying to protect a file above the directory holding the .htaccess
• Counting on mod_headers when the module is not loaded
• Forgetting to clear the browser cache when testing a redirect

A worked example: moving an old page

Take a concrete task: the address /old-page no longer works and the page has moved to /new-page. The rule is one line, a RewriteRule with a pattern, a substitution and flags. The pattern is compared against the request path without its leading slash, so it reads old-page, and the question mark at the end makes a trailing slash optional. The substitution is written the other way round, with a leading slash, because it is a finished address.

The R flag sets the response code and L stops processing: once the rule has fired, Apache does not look at the remaining lines of the file. Choose the code deliberately, with 301 for a permanent move and 302 for a temporary one. A pattern that starts with a caret is treated as a regular expression, and that is where escaping of dots starts to matter. The finished example is broken down in the table below, and the file itself can be taken from the code block and uploaded, provided the module check comes first.

After uploading, the browser may still show a cached response, so a redirect is best tested in a private window.

Apache, nginx and neighbouring tools

Before filling the file with rules, it is worth finding out which web server the hosting runs. Apache and LiteSpeed read .htaccess, nginx does not. Under nginx the same tasks are solved with the return, try_files and location directives in the server configuration, and without access to it the rules have to be handed over to the host. A separate check concerns the permissions of the file itself: a very common reason for the file being uploaded while nothing happens, and the permission calculator helps work out the mode.

When part of the job concerns the response code of the server rather than the configuration, the HTTP status code reference shows how a 301 differs from a 302 and what the server answers on an error. Blocking a folder from indexing in .htaccess duplicates a job that can be done at page level, where the noindex meta tag is put together by the meta tag generator. Breaking down the address that redirects point to is easier with a look at a URL broken into parts.

• Working out the permissions of the configuration file
• A reference of the codes a server can return
• Why a particular HTTP error code appears
• Assembling noindex meta tags for individual pages
• Taking a page address apart
• Testing the regular expressions used in the rules