Setting Up .htaccess for WordPress

By the HostStackPro Editorial Team

The .htaccess file is one of the most powerful — and most quietly dangerous — files in a WordPress install running on Apache. A single misplaced character can take an entire site offline with a 500 error, which is exactly why so many hosting support tickets start with “my site went white after I edited .htaccess.” Here’s how to work with it safely and what it actually does.

What .htaccess Actually Is

.htaccess (“hypertext access”) is a per-directory configuration file read by the Apache web server every time a request hits that directory. It lets you override server behavior — URL rewriting, redirects, access restrictions, caching headers — without needing access to the main server configuration, which is exactly why shared hosting relies on it so heavily: most shared hosting customers can’t touch the global Apache config, but they can edit .htaccess. Note this only applies to Apache and Apache-compatible setups (including LiteSpeed, which reads the same syntax); Nginx-based hosting uses a completely different configuration approach and ignores .htaccess entirely.

The Default WordPress .htaccess

A fresh WordPress install generates this block automatically, and it’s what makes your permalinks (like /blog/post-name/ instead of /?p=123) work:

<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>

If this block ever disappears (sometimes a plugin update or a bad edit wipes it), your permalinks will break and most pages will return a 404 — only the homepage will load. Go to Settings > Permalinks and click Save (without changing anything) to have WordPress regenerate this block automatically.

Before You Edit It: Back Up

This is the single most important step. Download a copy of your current .htaccess via FTP/SFTP or your host’s file manager before making any change, and keep it somewhere you can quickly re-upload. If a change breaks the site, restoring the backup file is a 30-second fix instead of a support ticket.

Common, Safe Additions

Force HTTPS

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Place this above the default WordPress block. Many hosts now offer a one-click “Force HTTPS” toggle in cPanel or their control panel instead, which is safer than a manual edit if it’s available.

Redirect www to non-www (or vice versa)

RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Replace example.com with your actual domain, and be consistent with whichever version (www or non-www) you’ve set as canonical in Settings > General.

Increase PHP Upload Limits (on some hosts)

php_value upload_max_filesize 64M
php_value post_max_size 64M

This only works if your host runs PHP as an Apache module; on PHP-FPM setups (increasingly common, including most managed WordPress hosts) this directive is ignored and will need to be set via a php.ini override or your host’s control panel instead.

Block Direct Access to wp-config.php

<files wp-config.php>
order allow,deny
deny from all
</files>

This adds a small extra layer of protection against direct requests to your site’s most sensitive file, though wp-config.php is already outside the web root’s directly-servable path on most properly configured hosts.

Mistakes That Cause 500 Errors

Mistake	Why It Breaks
Missing a closing tag (e.g. </IfModule>)	Apache can’t parse the file and refuses to serve the directory
Using a directive not supported on your host	Some hosts disable certain Apache modules; an unrecognized directive causes an Internal Server Error
Duplicate RewriteEngine On lines in conflicting blocks	Can cause unpredictable rewrite behavior or infinite redirect loops
Editing on a non-Apache host (Nginx/LiteSpeed in Nginx-compat mode)	.htaccess is ignored entirely, so the change silently does nothing

If You Break the Site

Connect via FTP/SFTP or your host’s file manager and either restore your backup copy, or simply rename .htaccess to .htaccess-broken and let WordPress regenerate a fresh default one from Settings > Permalinks. This immediately restores site access, and you can re-add your custom rules more carefully afterward, one at a time.

FAQ

Where is .htaccess located?
In your WordPress root directory (the same folder as wp-config.php), visible via FTP/SFTP or your host’s file manager — it’s a hidden file (starts with a dot), so make sure “show hidden files” is enabled in your FTP client.

Can a plugin edit .htaccess automatically?
Yes — caching plugins, security plugins, and redirect plugins commonly add their own rules to this file, which is another reason to keep periodic backups even if you never edit it manually.

My host uses Nginx — do I still need this?
No, Nginx doesn’t read .htaccess at all; equivalent changes are made in the server block configuration, usually by your host’s support team or control panel, since customers rarely have direct access to it.

Is it safe to just delete .htaccess?
It’s safe to delete and let WordPress regenerate the default block, but any custom rules (redirects, security rules) you’d added will be lost and need to be re-created.

Sources: WordPress.org Codex/Developer Resources on .htaccess (developer.wordpress.org), and Apache HTTP Server documentation on .htaccess files (httpd.apache.org).

HostStackPro is reader-supported. Some links to hosting providers are affiliate links, and we may earn a commission if you sign up through one — at no extra cost to you. This never changes which host we recommend; see our Affiliate Disclosure for the full policy.