.htaccess & Nginx Rule Generator
Flip the switches for what you need — force HTTPS, fix www, lock down headers, serve WebP, block bad bots — and copy pristine, correctly-ordered code for Apache or Nginx. No regex required.
Writing rewrite rules by hand is where most small mistakes happen — a missing flag, the wrong rule order, 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 both, updates live as you toggle options, and copies to your clipboard in one click.
Toggle what you need. The code below updates instantly — nothing to click or calculate.
Redirect every plain HTTP request to HTTPS with a permanent (301) redirect.
Redirect between the www and non-www versions of your domain so only one is indexed.
X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, and HSTS.
Serve a .webp version of an image automatically when one already exists next to the original.
Return a 403 to known aggressive crawlers and common vulnerability scanners.
server_name for you.If you’re writing about .htaccess, Nginx config, or WordPress security, here’s a ready-to-paste link to this generator.
How to use the generated code
The two formats work completely differently, 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.
This is the single biggest misconception. Nginx has no .htaccess support, on any plan, on any host — the Nginx output above needs to go into your actual site config file (commonly /etc/nginx/sites-available/yoursite.conf) and requires a config reload to take effect. If you’re not sure which server you’re on, check the FAQ below.
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 .htaccess before editing it, so you can restore it in seconds if something goes wrong.
What each rule actually does
Checks whether the current request arrived over plain HTTP and, if so, redirects to the same URL over HTTPS with a 301 (permanent) status — the status search engines are told to treat as a real, lasting move rather than a temporary detour. If your site sits behind Cloudflare or another proxy, the generated Apache code includes a commented alternate line, because the standard check can misread the connection as insecure even when it reached your visitor over HTTPS.
Search engines can treat www.example.com and example.com as two separate sites unless you pick one and redirect the other — splitting your backlinks and rankings between them. This rule makes that choice permanent and machine-enforced rather than relying on a setting in WordPress alone.
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.
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, or LiteSpeed. When genuinely unsure, try the Apache output first — if .htaccess changes have no effect at all, you’re very likely on Nginx.
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.
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 two most common server platforms 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.
Toggle what you need, copy it once, and paste it in the right place.