WordPress .htaccess Guide: Safe Rules & Fixes

The WordPress .htaccess file is one of those small files that can quietly control a lot of important things on your website. It can help WordPress handle clean URLs, redirects, access rules, caching behavior, and some basic security restrictions. At the same time, one wrong line can cause a 500 Internal Server Error or make your site unreachable.

This guide explains what the WordPress .htaccess file does, where to find it, how to edit it safely, which rules are useful, and which changes beginners should avoid. The goal is not to turn every website owner into a server admin. The goal is to help you understand the file well enough to fix common problems without breaking your site.

What Is the WordPress .htaccess File?

The .htaccess file is a server configuration file used by Apache-compatible web servers. In WordPress, it is most commonly used to make pretty permalinks work. That means instead of URLs like example.com/?p=123, WordPress can serve cleaner URLs like example.com/sample-post/.

On many WordPress hosting setups, the .htaccess file sits in the root folder of your WordPress installation. This is usually the same folder where you see files like wp-config.php, wp-load.php, and folders like wp-content, wp-admin, and wp-includes.

WordPress can write rewrite rules to this file when you save your permalink settings. That is why many permalink issues are fixed simply by going to Settings > Permalinks and clicking Save Changes.

When Does WordPress Use .htaccess?

WordPress mainly uses .htaccess when your site runs on Apache or LiteSpeed. These servers understand Apache-style rewrite rules and directory-level configuration. If your site uses Nginx only, the .htaccess file will usually not control your server behavior because Nginx uses its own server block configuration instead.

This is important because many WordPress tutorials share .htaccess snippets without explaining the server requirement. If your website is on Nginx, those rules may do nothing. If your site is on Apache or LiteSpeed, those same rules may work immediately.

For a broader comparison, read the FyrePress guide on Nginx vs Apache for WordPress.

Default WordPress .htaccess Rules

A standard WordPress site often uses a default .htaccess block like this:

# BEGIN WordPress
<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>
# END WordPress

This block tells the server to send requests through WordPress when the requested file or folder does not exist physically. That is how WordPress can handle posts, pages, categories, tags, custom post types, and other dynamic URLs.

In most cases, you should not manually edit anything between # BEGIN WordPress and # END WordPress. WordPress or plugins may overwrite that section later. If you need to add custom rules, place them outside the WordPress-generated block.

Best Method by User Type

The safest way to work with the WordPress .htaccess file depends on your experience level and what you are trying to fix.

How to Find the .htaccess File in WordPress

You can usually find the WordPress .htaccess file through your hosting file manager, FTP, SFTP, or SSH.

1. Open your hosting file manager or connect through FTP/SFTP.
2. Go to your WordPress root folder, often named public_html, www, or your domain name.
3. Enable hidden files if you do not see .htaccess.
4. Download a backup copy before making changes.
5. Edit carefully and save only after checking the rule.

The dot at the beginning of .htaccess means the file may be hidden by default. Many file managers and FTP clients have an option like Show Hidden Files or Show Dotfiles.

How to Safely Edit WordPress .htaccess

Before editing .htaccess, follow a simple safety process. This file can break your site instantly if a rule has invalid syntax.

1. Download a backup of the current .htaccess file.
2. Copy the existing content into a text file on your computer.
3. Add only one rule at a time.
4. Test the site after each change.
5. If the site breaks, restore the backup immediately.

If you are not comfortable editing files directly, use staging first. A staging site lets you test changes before applying them to your live WordPress website.

Useful WordPress .htaccess Rules

Below are common .htaccess examples used on WordPress sites. Do not add every snippet blindly. Use only the rule that matches your actual need.

1. Force HTTPS

If your SSL certificate is installed correctly, you can force visitors to use the HTTPS version of your site:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Use this only after confirming SSL works. If the certificate is not active, forcing HTTPS can create browser warnings or redirect problems.

2. Redirect www to non-www

If your preferred domain is example.com instead of www.example.com, you can redirect www to non-www:

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

Replace example.com with your own domain. Use either www or non-www consistently so search engines do not see duplicate versions of the same pages.

3. Redirect non-www to www

If your preferred domain is www.example.com, use the opposite rule:

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

Do not use both www-to-non-www and non-www-to-www rules at the same time. That can create a redirect loop.

4. Protect wp-config.php

The wp-config.php file contains important configuration details. On Apache-compatible hosting, you can block direct browser access with:

<Files wp-config.php>
  Require all denied
</Files>

Many modern hosting environments already protect sensitive files, but this rule can add an extra layer on compatible servers.

5. Disable Directory Browsing

Directory browsing can expose file lists when no index file exists inside a folder. You can disable it with:

Options -Indexes

This is a simple hardening rule and is safe on many Apache-compatible WordPress hosting setups.

6. Block Access to .htaccess Itself

You can also block direct access to the .htaccess file:

<Files .htaccess>
  Require all denied
</Files>

This helps prevent visitors from reading the file through the browser if the server is misconfigured.

7. Increase Upload Size Using .htaccess

Some tutorials suggest increasing upload size with .htaccess like this:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

This may work on some Apache hosting setups, but it can also cause a 500 error on servers running PHP-FPM or restricted configurations. If this breaks your site, remove the lines and change PHP limits from your hosting panel instead.

WordPress .htaccess Rules You Should Avoid

Not every popular .htaccess snippet is safe for every site. Avoid copying large rule collections without understanding them.

• Avoid blocking all bots. You may accidentally block Googlebot, Bingbot, or useful SEO crawlers.
• Avoid aggressive hotlink rules. They can break image previews, social sharing cards, or CDN behavior.
• Avoid random speed snippets. Some caching and compression rules conflict with hosting-level caching.
• Avoid editing the WordPress-generated block. WordPress may overwrite it later.
• Avoid using both www and non-www redirects together. This can cause redirect loops.

If your goal is performance, read the FyrePress guide on WordPress .htaccess speed rules before adding cache, compression, or browser header snippets.

Common WordPress .htaccess Errors and Fixes

How to Restore the Default WordPress .htaccess File

If your WordPress site breaks after editing .htaccess, you can restore the default file manually.

1. Connect to your site through FTP, SFTP, SSH, or file manager.
2. Rename the current file to .htaccess-old.
3. Create a new file named .htaccess.
4. Add the default WordPress rules.
5. Save the file.
6. Log in to WordPress and go to Settings > Permalinks.
7. Click Save Changes to refresh rewrite rules.

Use this default rule for a normal single-site WordPress installation:

# BEGIN WordPress
<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>
# END WordPress

If your WordPress site is installed in a subdirectory or uses Multisite, the rules may be different. In that case, do not blindly paste a generic rule without checking your setup.

.htaccess vs Redirect Plugin: Which Should You Use?

For small websites, a redirect plugin is often easier and safer. It gives you a dashboard interface, logs, and fewer chances of breaking the entire site with one typo.

For larger sites, server-level redirects can be cleaner and faster when handled correctly. This is especially true during migrations, URL structure changes, or large content cleanup projects.

Here is a simple rule:

• Use a plugin for a few simple redirects.
• Use .htaccess for sitewide Apache/LiteSpeed redirect rules.
• Use Nginx server config if your server is Nginx.
• Use your CDN if redirects are managed at the edge.

If you are comparing plugin options, read the FyrePress guide on best WordPress redirection plugins.

Does .htaccess Improve WordPress Speed?

The .htaccess file can support WordPress performance in some cases, especially for browser caching, compression, and redirect cleanup. But it is not a complete speed optimization solution by itself.

Most WordPress speed improvements still come from better hosting, lighter themes, optimized images, fewer unnecessary plugins, proper caching, database cleanup, and Core Web Vitals improvements.

For a broader optimization workflow, see the FyrePress guides on how to speed up a WordPress site without breaking it and Core Web Vitals for WordPress.

.htaccess Security Tips for WordPress

The .htaccess file can help with basic security hardening, but it should not be your only security layer. Keep WordPress core, plugins, and themes updated. Use strong passwords, trusted plugins, limited admin access, backups, malware scanning, and proper hosting-level security.

Good .htaccess security use cases include:

• Blocking direct access to sensitive files.
• Disabling directory browsing.
• Enforcing HTTPS after SSL is correctly installed.
• Adding simple access restrictions where appropriate.
• Reducing accidental exposure of configuration files.

Bad .htaccess security use cases include copying large firewall snippets from random blogs, blocking user agents without testing, or using outdated rules that conflict with modern hosting.

When Not to Use .htaccess

You should not use .htaccess for everything. In some situations, there is a better place to make the change.

• Use your hosting panel for PHP version and PHP limits when available.
• Use your CDN for edge redirects and cache rules.
• Use Nginx configuration if your server is Nginx.
• Use WordPress settings for permalink structure.
• Use a plugin when you need a safer interface for small redirect tasks.

The best WordPress .htaccess strategy is not to add more rules. It is to add only the rules your site actually needs.

Final Recommendation

The WordPress .htaccess file is useful, but it should be handled carefully. For beginners, the safest starting point is to back up the file, avoid editing the WordPress-generated block, and fix permalink issues from the WordPress dashboard first.

Use .htaccess for clear Apache/LiteSpeed tasks such as redirects, HTTPS enforcement, directory browsing protection, and basic file access restrictions. Avoid random snippets, test every change, and remember that Nginx servers do not use .htaccess the same way.

If you treat .htaccess as a precision tool instead of a place to paste every optimization trick, it can help your WordPress site stay cleaner, safer, and easier to troubleshoot.

Frequently Asked Questions

What is the WordPress .htaccess file used for?

The WordPress .htaccess file is mainly used for URL rewriting, pretty permalinks, redirects, access restrictions, and some server-level rules on Apache-compatible hosting.

Where is the .htaccess file in WordPress?

It is usually located in the root folder of your WordPress installation, often the same folder that contains wp-config.php and the wp-content folder.

Why can I not see the .htaccess file?

The file may be hidden because it starts with a dot. Enable hidden files or dotfiles in your hosting file manager or FTP client.

How do I fix WordPress permalinks with .htaccess?

First, go to Settings > Permalinks in WordPress and click Save Changes. This often regenerates the required rewrite rules automatically.

Can .htaccess break my WordPress site?

Yes. A wrong or unsupported rule can cause a 500 Internal Server Error, redirect loop, or broken URLs. Always back up the file before editing.

Does Nginx use .htaccess?

No. Nginx does not use .htaccess files like Apache. Nginx rules need to be added to the server block configuration instead.

Should I edit .htaccess manually?

You can edit it manually if you understand the rule and have a backup. Beginners should use WordPress settings or trusted plugins where possible.

Can I use .htaccess to improve WordPress speed?

In some cases, yes. It can help with caching headers, compression, and redirect cleanup on compatible servers. However, WordPress speed also depends on hosting, images, plugins, theme quality, caching, and database health.

What should I do if .htaccess causes a 500 error?

Restore your backup copy or rename the current file and create a fresh default WordPress .htaccess file. Then save permalinks again from the WordPress dashboard.

Is it safe to protect wp-config.php using .htaccess?

Yes, on compatible Apache/LiteSpeed servers, blocking direct browser access to wp-config.php can add an extra layer of protection. Some hosts already handle this at the server level.