WordPress .htaccess vs server config

WordPress famously ships examples that edit .htaccess, so it is natural to assume every rewrite or security rule belongs there. On modern hosts the choice is not that simple. .htaccess is an Apache-only, per-directory override file that Apache reads on every request. Nginx does not read .htaccess at all. Where a rule lives changes how fast it runs, whether it works at all, and how much control the hosting layer keeps.

Why the location matters

When a request hits WordPress under Apache, Apache parses each .htaccess file in the path from the document root down to the requested file. That parsing happens on every single request, even cached or static ones. The core WordPress rewrite block in .htaccess is also what maps pretty permalinks to index.php, so many hosts special-case it. On Nginx, permalinks depend on a server block rule, usually a try_files line or an equivalent location snippet, and .htaccess is simply ignored.

Rules that fit .htaccess

Choose .htaccess when you have Apache-only hosting with no shell or config access, when you want a change you can revert without a server reload, or when you are applying a rule to a directory subtree such as a staging folder. Common .htaccess jobs include Redirect 301 lines, RewriteRule exclusions, ExpiresByType cache headers, ErrorDocument pages for 403 and 404, and SetEnvIf or Limit blocks that filter requests by header or IP.

Rules that belong in the server config

Put rules in the virtual host or server block when you control the server, when the rule should survive a WordPress core or plugin update, or when performance matters. The most common reason is bypassing .htaccess: on any host that sets AllowOverride None, .htaccess is ignored entirely, full stop. Nginx sites must use server block rules for permalinks, security headers, cache headers, and gzip. A server config also runs once at startup instead of being reparsed per request, which removes a small but measurable cost under load.

Configuring the layers in order

On Apache you can enable the override globally and then restrict it. For example, this permits .htaccess only in the document root, which keeps permalinks working while blocking override files in uploads and other subfolders:

<Directory /var/www/example.com>
    AllowOverride All
    <Directory /var/www/example.com/wp-content>
        AllowOverride None
    </Directory>
</Directory>

On Nginx, the equivalent is a server block that does not reference .htaccess. A minimal permalink rule for WordPress looks like:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Combine this with add_header lines for security headers, a gzip block, and expires blocks for static file locations. If you migrate a site with many .htaccess rules, translate each one into the corresponding Nginx directive rather than copying the file, because the directive names differ.

When to involve a professional

Server config changes can take a site down instantly, especially rewrite and location rules that shadow one another on Nginx. If you cannot test the change in a staging copy of the site, or you are not certain which module an Apache directive belongs to, keep the rule in .htaccess (or get server-level help) rather than editing the main config blind.

Prevention

Treat the server config as the longer-term home for rules and .htaccess as the quick-applied layer. Document every rule with a comment noting what it does and the date it was added. Test any .htaccess or config edit on a staging copy first, and keep a known-good copy of both files so a bad edit can be reverted in seconds.

Related architecture

WordPress keeps several other settings that can look confusingly similar: the wp-config.php constants act as application-level configuration, while .htaccess and server config both operate below the application. Read the wp-config.php constants reference to see the boundary between WordPress settings and host-level rules.