.htaccess Generator — redirects, WordPress fixes and hardening
Build Apache rules for HTTPS, www canonicalisation, WordPress permalinks, security and caching — with the traps flagged before you deploy.
Free and instant — results appear in seconds. No sign-up, no limits, and nothing you type is stored.
.htaccess is a per-directory configuration file Apache reads on every request. It is the standard way to change server behaviour on shared hosting, where you have no access to the main configuration.
It is also unusually easy to break a site with. Apache does not validate the file on save — it reads it on the next request, and if a directive references a module that is not loaded, the response is a 500 error on every page at once. There is no staged rollout and no warning.
The generator below wraps every block in <IfModule>, which is the single most effective precaution: a missing module causes the block to be skipped rather than the server to fault. It also refuses combinations that conflict, and flags the options whose consequences are not obvious.
Tick what you need, enter your domain, and read the notes under the output before you paste anything.
The WordPress 404 problem, and why this file fixes it
The most common .htaccess emergency: the homepage loads fine, every other page returns 404, and nothing in WordPress appears broken.
The cause is almost always a missing or overwritten WordPress rule block. WordPress does not create real files for its pages — example.com/about-us/ is not a directory on disk. Apache looks for it, finds nothing, and returns 404. The rewrite block is what tells Apache to hand unmatched requests to index.php so WordPress can resolve them internally:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressLine by line:
RewriteCond %{REQUEST_FILENAME} !-f— only if no real file matches.RewriteCond %{REQUEST_FILENAME} !-d— and no real directory matches.RewriteRule . /index.php [L]— then send it to WordPress and stop processing.
The two conditions are what stop the rule swallowing your images and stylesheets. Without them, every request including static assets goes to PHP.
The file typically disappears during a migration that copied the site without hidden files — .htaccess starts with a dot and standard FTP clients hide it by default. It also gets clobbered by security plugins that rewrite the block and by manual edits that delete the markers.
Ordering matters. If you add a Force HTTPS block, it must sit above the WordPress block. Rules run top to bottom, and the WordPress rule ends with [L], which stops further processing for anything it matches — which is nearly everything. A redirect placed below it will never execute.
If you are already logged out and locked out, rename the file to .htaccess.bak over FTP, load the site to confirm it recovers, then go to Settings → Permalinks in WordPress and press Save. That regenerates the block from scratch.
Getting canonicalisation right
A site reachable at four addresses — with and without www, over HTTP and HTTPS — is one site as far as you are concerned and up to four as far as a crawler is concerned. Pick one canonical form and redirect the rest with a 301.
The order of the rules matters more than which form you choose. Force HTTPS first, then canonicalise the hostname. Reversing them produces two redirects for some entry points where one would do.
Never enable both www→non-www and non-www→www. The generator blocks this, but it is worth knowing why: each rule sends the request straight back to the other, and the browser gives up with ERR_TOO_MANY_REDIRECTS.
Rules that will lock you out
Three options here can leave you unable to reach your own site:
IP-restricted wp-login. If you enter the wrong address, or you are on a dynamic residential IP that changes overnight, you lose admin access. Recovery means editing .htaccess over FTP. Confirm your current IP first, and prefer this on a static connection.
HSTS. Once a browser caches the policy it refuses plain HTTP for your domain until max-age expires — a year, by default. There is no early retraction. Only enable it when HTTPS works on every hostname, and only add includeSubDomains when every subdomain has a valid certificate.
Blocking PHP in uploads, placed in the wrong directory. This rule belongs in wp-content/uploads/.htaccess. In the site root it blocks PHP execution everywhere, and the site goes down completely.
Ordering, briefly
Apache reads top to bottom. Two consequences:
1. Redirects go above the WordPress block, because that block ends in [L] and stops processing for almost every request.
2. <Files> and <FilesMatch> blocks are evaluated separately from rewrite rules and can go anywhere.
Caching with unversioned filenames
Setting a year-long expiry on CSS and JavaScript is standard advice and is wrong unless your filenames change when the content changes. style.css cached for a year means returning visitors keep the old file for a year after you edit it — and hard-refreshing your own browser will not reveal the problem, because you are not the one holding the stale copy.
Either version the filenames (style.a1b2c3.css), append a query string that changes on deploy, or use a one-month expiry instead.
If you are on nginx or LiteSpeed
nginx does not read .htaccess at all. The rules must be translated into the server block and the configuration reloaded, which requires root.
LiteSpeed and OpenLiteSpeed do read .htaccess and support most Apache directives, which is why cPanel hosts running LiteSpeed behave as expected. A small number of directives differ; if a rule silently does nothing, that is the likely reason.
Before you deploy
Back up the existing file first. Not "copy the contents into a text editor" — download it, so you can restore by upload if the site 500s. If you have SSH access, apachectl configtest catches syntax errors before they reach visitors.
Frequently asked questions
My WordPress site returns 404 on every page except the homepage. What fixes it?
The WordPress rewrite block is missing from .htaccess. Generate it with the WordPress default option ticked and place it in the site root, or simply open Settings then Permalinks in WordPress and press Save — that regenerates the block automatically, provided the file is writable.
Should I use www or non-www?
Either works; consistency is what matters. Pick one, redirect the other with a 301, and make sure internal links and your sitemap use the chosen form. The only technical consideration is that a bare domain cannot take a CNAME record, which occasionally matters for certain CDN configurations.
My site returns a 500 error after adding these rules. What do I do?
Rename .htaccess to .htaccess.bak over FTP or through your file manager, and the site will recover immediately. The usual cause is a directive belonging to an Apache module that is not loaded. Wrapping blocks in IfModule prevents this, which is why the generator does so by default.
Where exactly does the file go?
The site root, alongside index.php or index.html — usually public_html or www. Rules apply to that directory and everything below it. The exception is the uploads PHP-blocking rule, which belongs in wp-content/uploads/.htaccess; placing it in the root takes the whole site down.
Does .htaccess work on nginx?
No. nginx ignores the file entirely. The equivalent rules must be written into the nginx server block and the configuration reloaded, which needs root access. LiteSpeed and OpenLiteSpeed do read .htaccess and support most Apache directives, so cPanel hosts running LiteSpeed work as expected.
Will these rules slow my site down?
Marginally. Apache checks .htaccess in every directory along the request path on every request, which is why AllowOverride None with rules in the main config is faster. On shared hosting the difference is not measurable against network latency and database queries. Keeping the file short and avoiding deeply nested copies is enough.
Can I use 302 instead of 301 for redirects?
Only for genuinely temporary moves such as maintenance pages or A/B tests. A 301 is permanent and passes ranking signals to the destination; a 302 tells search engines to keep indexing the original URL. Using 302 for a permanent change is a common and quietly expensive mistake.
Reviews
No reviews yet. If this tool solved something for you, yours would be the first — and it helps other people decide whether it is worth their time.