.htaccess, Nginx & Caddy Rule Generator
Pick a preset or flip the switches — force HTTPS, fix www and trailing slashes, bulk 301s, security headers, AI crawler blocking, caching — and copy correctly-ordered code for Apache, LiteSpeed, Nginx or Caddy. No regex required.
Writing rewrite rules by hand is where most small mistakes happen — a missing flag, the wrong rule order, a redirect chain that costs you a hop on every visit, or a regex that works for Apache but does nothing on Nginx (which never reads a .htaccess file at all). This generator builds correct, ready-to-paste code for four servers, updates live as you toggle options, and gives you a link to the exact configuration so you can save it or share it.
Start from a preset, then fine-tune. The code below updates instantly.
Redirects
Redirect every plain HTTP request to HTTPS with a permanent (301) redirect.
Pick www or non-www so only one is indexed. Combined with HTTPS into a single redirect — no chains.
Enforce one URL format. Leave off for WordPress — it already follows your permalink setting.
Paste old and new URLs, one pair per line. Each goes straight to its final HTTPS address in one hop.
Security & bots
X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and HSTS.
Only if every subdomain serves HTTPS. Preloading is hard to undo — submit at hstspreload.org when ready.
Report-only mode logs violations in the browser console without blocking anything, so it can’t break your site.
GPTBot, ClaudeBot, CCBot, Bytespider, Meta and more — plus a matching robots.txt.
Blocking search fetchers also removes your pages from AI answers and their citations.
Return a 403 to aggressive SEO crawlers and common vulnerability scanners.
Deny .env, .git, other dotfiles, backups, SQL dumps and logs. Keeps .well-known open for SSL.
Stop the server showing a file list for folders without an index page.
Lock down the files and URLs attackers probe first on WordPress sites.
Performance
Gzip text, CSS, JS, JSON, SVG and fonts (zstd + gzip on Caddy). LiteSpeed does this automatically.
Cache images, CSS, JS and fonts for a year; never cache HTML. Assumes versioned asset URLs (WordPress adds ?ver=).
Serve photo.jpg.webp automatically when it exists next to photo.jpg and the browser supports WebP.
server_name for Nginx, the site address for Caddy, and redirect targets. Apache’s rules work for any domain automatically.If you’re writing about .htaccess, Nginx or Caddy config, or WordPress security, here’s a ready-to-paste link to this generator.
How to use the generated code
Each server reads its rules from a different place, and mixing them up is the single most common mistake with a tool like this.
On a WordPress site, your .htaccess file already has a # BEGIN WordPress / # END WordPress block that handles permalinks. Paste the generated code above that block, not inside or below it — WordPress will overwrite anything inside its own block the next time you resave permalinks, and rules placed after it may never run. LiteSpeed reads the same file, so the Apache output works there unchanged.
This is the single biggest misconception. Nginx has no .htaccess support, on any plan, on any host — the Nginx output needs to go into your actual config: the map blocks once inside http {}, the rest in your site’s server {} blocks (commonly /etc/nginx/sites-available/yoursite.conf), with the deny rules placed above your PHP location. Then run nginx -t and reload.
Caddy obtains certificates and redirects HTTP to HTTPS automatically, so its output is shorter. Merge the generated directives into the matching site block of your Caddyfile, keep your existing root, php_fastcgi and file_server lines, then run caddy validate and caddy reload.
A malformed rewrite rule can create a redirect loop or lock visitors out entirely — and because .htaccess takes effect immediately with no restart required, a mistake shows up in production right away. Download a copy of your existing config before editing it, so you can restore it in seconds if something goes wrong.
What each rule actually does
Checks whether the request arrived over plain HTTP or on the wrong host, and sends it to the one correct HTTPS address with a single 301 (permanent) redirect. Doing both in one rule matters: separate rules turn http://www.example.com into two redirect hops, which slows the first visit and dilutes link signals. If your site sits behind Cloudflare or another proxy, the Apache output includes a commented alternate line, because the standard check can misread the connection as insecure even when it reached your visitor over HTTPS.
Makes /page and /page/ resolve to one URL instead of two copies of the same content. Real directories and files with extensions are left alone, and only normal page requests are redirected. Leave it off on WordPress, which already redirects to match your permalink structure — adding a second rule can fight it.
For site migrations and URL clean-ups. Each old path matches with or without a trailing slash and goes straight to its final HTTPS address, so an old link never passes through a chain of redirects. Query strings on old URLs are ignored when matching, and any query string the visitor arrives with is carried over.
The core headers stop MIME sniffing, block your pages being framed by other sites, limit referrer leakage and switch off browser features you don’t use. HSTS tells browsers to use HTTPS only; the preload option qualifies you for the browser preload list, which is effectively permanent, so only enable it when every subdomain has a certificate. The Content-Security-Policy starter runs in report-only mode, so you can watch the browser console for violations before enforcing anything.
Returns a 403 to AI crawlers that identify themselves in their User-Agent, and adds a robots.txt tab for the ones that only respect robots.txt. Two of them, Google-Extended and Applebot-Extended, aren’t separate crawlers at all — they’re robots.txt tokens that tell Google and Apple not to use your content for AI training — so they appear only in the robots.txt output.
Automated scanners request /.env, /.git/config and backup.sql on millions of sites every day, because one exposed file can leak database passwords. These rules deny every dotfile except .well-known (which SSL certificate validation needs), plus backups, logs, SQL dumps and package manifests. Disabling directory listing stops folders without an index page from showing their contents.
Blocks xmlrpc.php, the most common target for password-guessing attacks; denies direct requests for wp-config.php; stops PHP from running inside the uploads folder, where a malicious upload would try to execute; and blocks ?author=1 scans that reveal usernames. Only block xmlrpc.php if you don’t use Jetpack or an app that publishes through it.
Compression typically shrinks HTML, CSS and JavaScript by 60–80% on the way to the browser. Browser caching tells returning visitors to reuse images, CSS, JavaScript and fonts for a year instead of downloading them again, while HTML is never cached so content updates appear immediately.
This rule does not create WebP images for you — it only serves one if it already exists next to the original (a plugin like ShortPixel, Imagify, or a build step typically creates the .webp file). Once that file exists, this rule detects that the visitor’s browser supports WebP and serves the smaller file automatically, without changing any image URLs in your content.
Frequently Asked Questions
The most common cause is pasting new rules inside or below WordPress’s own # BEGIN WordPress block, or a typo in a RewriteCond/RewriteRule pair that creates a redirect loop. Always add custom rules above that block, and keep a backup of the working file so you can restore it immediately if the site stops loading. If you see a 500 error right after adding the rules, your host may not allow the Options line — delete it and reload.
No, under any circumstances. Nginx was designed without per-directory config file support for performance reasons — every directive has to live in the main server configuration. If your host runs Nginx, use the Nginx output above and apply it through your host’s config editor or SSH access, not by uploading a .htaccess file.
Check your hosting control panel — cPanel almost always means Apache or LiteSpeed (both read .htaccess), while a custom VPS or cloud panel more often means Nginx. You can also check response headers: open your browser’s network tab and look for a Server header reading Apache, nginx, LiteSpeed or Caddy. When genuinely unsure, try the Apache output first — if .htaccess changes have no effect at all, you’re very likely on Nginx.
Yes. LiteSpeed Web Server reads .htaccess natively and understands the same rewrite, header and access rules, so use the Apache tab unchanged. OpenLiteSpeed is more limited: it reads only the rewrite rules from .htaccess (other directives are ignored) and must be restarted after changes, so set headers and access rules in its WebAdmin console instead.
Yes — this rule redirects every visitor to the HTTPS version of your site, so if no valid SSL certificate is installed, visitors will hit a browser security warning instead of your content. Confirm your SSL certificate is active first (most hosts now issue a free one automatically via Let’s Encrypt) before enabling this rule.
Blocking AI training crawlers has no effect on Google or Bing rankings, so it’s a low-risk choice if you don’t want your content used to train models. Blocking AI search and assistant fetchers is a bigger decision: it keeps your pages out of answers in ChatGPT search, Perplexity and similar tools, including the links they show back to sources. Many sites block training crawlers and allow search fetchers.
Because they aren’t crawlers. Google and Apple crawl with their normal search bots and check robots.txt for these two tokens to decide whether your content can be used for AI training. Blocking them at the server would mean blocking Googlebot or Applebot, which would remove you from search. They belong in robots.txt, which is why the generator adds them there.
Turn on Bulk 301 redirects and paste your list — one old and new URL per line, separated by a space, tab or comma (a two-column spreadsheet pastes in directly). For Nginx the generator uses a single map, which stays fast even with thousands of entries. On Apache, hundreds of rules are fine; for many thousands, a server-level RewriteMap or a redirect plugin is more efficient.
It breaks anything that still uses XML-RPC: Jetpack, some remote-publishing and backup services, and older mobile apps. Modern WordPress features use the REST API instead, so most sites lose nothing. If you rely on Jetpack, leave that one checkbox off and keep the other hardening rules.
Yes. Click Copy share link above the code. The link reopens this generator with every switch, your domain, your redirects and the selected server tab exactly as you left them — useful for saving a setup, sending it to a developer, or pointing to it in a forum answer.
No. Apache and LiteSpeed re-read .htaccess on every request, so changes take effect the instant you save the file. This is also why a mistake shows up immediately in production — there’s no restart step to catch a syntax error beforehand.
Yes. After saving changes to your Nginx config, run nginx -t to check the syntax, then reload with systemctl reload nginx (or your host’s equivalent). A reload is the safe option here — if the new config is invalid, Nginx keeps the old one running and your site stays up. A full restart is riskier, since a bad config there can leave no process running at all. Either way, always run nginx -t first.
No — these are third-party SEO tools, not Google, Bing, or any other search engine. Blocking them has zero effect on how your site is crawled or ranked. The only real trade-off is that you (and anyone else) will no longer be able to use those specific tools to analyze your site from the outside, including checking your own backlink profile through them unless you unblock temporarily or check it from a different network.
This rule is a traffic director, not an image converter — it checks whether a .webp file already sits next to the original and serves it only if so. Creating the actual .webp files is a separate step, usually handled by an image optimization plugin (ShortPixel, Imagify, EWWW) or a build process. Without that file existing, the rule silently falls through and serves your original image, so nothing breaks either way.
Correct server rules shouldn’t
require memorizing regex.
A single missing flag or misplaced rule in a server config can silently do nothing, or actively break your site — and the most common web servers don’t even share a syntax, let alone a config file. This generator exists so you can get the exact, correctly-ordered code for your actual server, without needing to become a regex expert to do it safely.
Pick a preset, copy it once, and paste it in the right place.