WordPress .htaccess File: How to Find, Create, Edit, and Fix It

Sometimes the WordPress .htaccess file only becomes interesting after it breaks something. A post opens to a 404 page. A redirect goes somewhere strange. You paste one rule, refresh the site, and even wp-admin starts throwing a 500 error.

Before you touch it, back up your WordPress site with BlogVault or download a full copy of your site. This file is small, but Apache reads it before WordPress finishes loading, so one bad line can affect every URL.

TL;DR: The WordPress htaccess file is a hidden Apache configuration file that WordPress uses mainly for permalinks and request routing. Create a full WordPress backup first, because a broken rule can take down posts, pages, redirects, and wp-admin. If your .htaccess file is corrupted or missing, start with Settings > Permalinks > Save Changes. If that does not work, recreate it with the official default WordPress code below.

Use this quick route:

What the WordPress .htaccess file does

The .htaccess file is an Apache configuration file. For WordPress, the root file usually does one main job: it helps pretty permalinks work. A URL like example.com/contact/ may not be a real folder on the server. The WordPress rules tell Apache to pass that request to index.php, where WordPress can load the correct page.

For example, a plain query-style WordPress URL can still load the post while pretty permalink routing is not yet in place.

That is why .htaccess problems look bigger than the file itself. The visible issue might be a 404, redirect loop, 403, or 500 error. The hidden issue is often rule order, file permissions, server type, plugin-generated rules, or one copied character that Apache refuses to accept.

Plugins and hosts may also add rules for redirects, caching, compression, firewalls, or security. Malware can add rules too, usually to create spam redirects.

🔔 Important: Nginx does not use .htaccess. If your host runs Nginx, or a mixed Nginx and Apache stack, ask the host where rewrite and redirect rules are managed.

Where to find the .htaccess file

Most WordPress sites keep .htaccess in the WordPress root folder. This is the folder that also contains wp-config.php, wp-content, wp-admin, and wp-includes.

Your host may call that folder public_html, www, public, your domain folder, or an application folder.

To find it:

If it is still missing, do not assume the site is broken. The file may be hidden, not generated yet, blocked by permissions, or unnecessary because the server uses Nginx. Some sites also have .htaccess files in subfolders, but the root file is the usual WordPress target.

Make the edit recoverable first

The safest .htaccess edit is the one you can undo without wp-admin. A bad rule can block wp-admin along with the public site.

Before editing:

This is where BlogVault is useful: backup, staging, and restore turn .htaccess edits from a live-site gamble into something you can roll back. That matters most when the site earns money, takes bookings, or runs campaigns where a broken redirect is not just annoying.

If the site is already broken, avoid dashboard-based .htaccess editors. Use server file access so you can recover even if wp-admin stays unavailable.

How to create or restore the default WordPress .htaccess file

If wp-admin still works, start there.

On a WordPress 6.9.4 test site, the permalink screen behaved as expected: WordPress started with plain query-style URLs until permalink settings were changed. That is why saving permalinks is the right first fix for many missing or stale rewrite-rule problems.

If wp-admin is not available, recreate the file manually:

Restoring the default file can fix WordPress routing. It will not restore old redirects, cache rules, firewall rules, or custom access rules unless you saved them.

Default WordPress .htaccess code

Use this for a standard single-site WordPress install in the web root.

# BEGIN WordPress

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]

# END WordPress

In plain English, these rules turn on rewriting, preserve authorization headers, leave real files and folders alone, and send everything else to index.php so WordPress can load the right content.

If WordPress is installed in a subfolder, the paths may differ. A site under /blog/ may need paths that include /blog/.

Multisite .htaccess rules

Multisite uses different rules. Use the version that matches your network. For WordPress 3.5 or newer multisite subdirectory networks:

# BEGIN WordPress Multisite

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

# END WordPress Multisite

For WordPress 3.5 or newer multisite subdomain networks:

# BEGIN WordPress Multisite

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

# END WordPress Multisite

Be careful with older multisite networks, domain mapping, and custom upload paths. The default file is not the same as a backup of your old configuration.

How to edit .htaccess in WordPress

Choose the editor based on recovery, not convenience.

Method	Use it when	Watch out for
FTP or SFTP	You want controlled edits and rollback access	You need file credentials
Host file manager	You need a quick shared-hosting edit	Browser editors make accidental saves easy
WordPress plugin	wp-admin works and the edit is low risk	It cannot help if wp-admin breaks
SSH	A developer is handling the change	Fast command-line mistakes are easy

The workflow is simple: download the current file, save a dated copy, add one rule group, test, then keep the old copy until you know the change is stable.

For revenue-critical sites, test redirects and security rules on staging first. A rule that fixes one URL can quietly break checkout, login, images, or admin AJAX requests.

Where to put custom rules

Do not put custom rules inside the WordPress-managed block.

That block starts with # BEGIN WordPress and ends with # END WordPress. WordPress may rewrite it when you save permalink settings. Use this layout:

# Custom redirects or access rules
# Add one group at a time and explain why it exists.

# BEGIN WordPress

# WordPress-generated rules live here.

# END WordPress

# Optional rules that must run after WordPress rules

Rules above the WordPress block usually run before WordPress handles the request. Rules below may run later, or may never run if an earlier rule has already ended the rewrite process.

Common uses for .htaccess

Use .htaccess when you truly need an Apache-level rule. Use WordPress settings, host controls, a CDN, or a plugin when those are easier to audit.

For security, do not build a personal firewall from copied snippets. Attackers change IPs, broad blocks can catch real visitors, and old rules become hard to explain. MalCare is a better fit when the job is ongoing scanning, firewall protection, and malware cleanup.

Troubleshooting WordPress .htaccess problems

When WordPress .htaccess breaks, fix the safest thing first. If a bad edit just happened, roll back before investigating.

Problem	Likely cause	Safe first action
File is missing	Hidden file, Nginx, not generated, or permissions	Show hidden files, check the WordPress root folder, then save permalinks
Posts or pages show 404 errors	Missing or stale rewrite rules	Save permalink settings and restore default WordPress rules
Whole site shows a 500 error	Bad syntax or a disallowed rule	Rename the file to .htaccess_old, reload, then restore a clean copy
403 Forbidden appears	Deny rule, file permissions, host security layer, or firewall rule	Roll back recent deny rules and ask the host to check permissions/security blocks
New rules do nothing	Wrong folder, Nginx, host restrictions, cache, or rule order	Ask the host whether root .htaccess overrides are enabled
File keeps changing or redirects return	Plugin rewrite, host automation, or malware	Restore a clean file and scan the site

If posts and pages return 404

The homepage may work while inner URLs fail. That usually points to missing or stale permalink rules.

Start with Settings > Permalinks > Save Changes. Then test a post, a page, and any custom post type URLs. If 404s continue, check whether the file is writable, whether the server uses Apache, and whether WordPress is installed in a subfolder.

The post and page can exist in WordPress while the public URL still fails because rewrite rules are missing or stale.

The same separation applies to pages: stored content and frontend routing are related, but they are not the same layer.

When the pretty URL is unavailable, the frontend symptom is often a normal-looking 404 page rather than an obvious server configuration message.

If the whole site shows a 500 error

A 500 error right after an edit usually means Apache found bad syntax or a rule your host does not allow. Use FTP, SFTP, SSH, or the host file manager. Rename .htaccess to .htaccess_old and reload the site. If the site comes back, restore the previous clean copy or regenerate the default WordPress rules.

Do not re-add every old rule at once. Add one group, test, then continue.

If changes are ignored

The server may not be reading the file. Common causes are Nginx hosting, the wrong folder, host restrictions, cache, CDN behavior, or another rule running earlier.

Ask your host this exact question: Does this site read root .htaccess overrides? That gets a better answer than a vague request to fix a redirect.

If the file keeps changing

Some changes are normal. WordPress can refresh its managed block. Caching, redirect, firewall, and security plugins may write their own sections.

Unknown redirects, encoded rules, or deleted rules that come back are different. Restore a known clean file and scan the site. If redirects return after cleanup, treat the site as compromised until proven otherwise.

MalCare is useful here because suspicious .htaccess changes are rarely only a file-format problem. You need to know what changed the file, whether the attacker still has access, and what else was touched.

What not to do with .htaccess

Most expensive WordPress .htaccess mistakes begin as a copied snippet that looked harmless. Avoid these:

The decision rule is simple: if the rule affects revenue, access, checkout, login, or admin behavior, treat it like production infrastructure. Back it up, test it, and keep a rollback path.

Should you edit .htaccess manually?

Conclusion

The WordPress .htaccess file is powerful because it handles requests early. That makes it useful for permalink routing and some server-level rules, but risky for casual experiments.

Start with the safest fix: save permalinks, restore the default file, or roll back the last edit. Before planned changes, use a backup plugin, keep a copy of the file, and test on staging when possible. If the file keeps changing or redirects look suspicious, stop treating it as a formatting issue and scan the site for malware.

FAQs

What is the WordPress .htaccess file?

It is a hidden Apache configuration file. WordPress mainly uses it to send pretty permalink requests to index.php, where WordPress loads the right post, page, or archive.

Where is the WordPress .htaccess file?

It is usually in the WordPress root folder, beside wp-config.php, wp-content, wp-admin, and wp-includes. Turn on hidden files if you do not see it.

Why is my .htaccess file missing?

It may be hidden, not generated yet, deleted, blocked by permissions, or unused because the site runs on Nginx. On Apache, save Settings > Permalinks to regenerate the basic file.

Can I delete the WordPress .htaccess file?

You can, but you may break permalinks, redirects, cache rules, or security rules. Download a copy first. If you delete it by mistake, save permalinks or upload the official default code.

Why did editing .htaccess cause a 500 error?

Apache likely found a bad rule or a rule your server does not allow. Rename the file, restore the previous copy, then re-add rules one group at a time.