The site won't let you upload a theme because the file is too big. Search engines are indexing admin pages that shouldn't appear in results. Server logs show access attempts to wp-config.php from unknown IPs. Three problems, one solution: the .htaccess file already sitting in your WordPress site's root directory.

You've probably seen it when setting up pretty permalinks. But .htaccess capabilities go far beyond that: it controls access, security, redirects, and upload limits at the server level. And unlike security plugins, it adds no load to PHP.

Below are four practical scenarios every WordPress administrator faces. Each includes ready-to-use code, an explanation, and guidance on exactly where to insert it. The code is written for Apache 2.4 (the current version as of 2026), but every snippet includes a compatibility block for Apache 2.2 so you don't have to wonder whether it will work on your hosting.

💡 Quick overview:

• Increase file upload limits through .htaccess and .user.ini for PHP-FPM.
• Block search engine indexing at the server level.
• Disable directory browsing with a single line.
• Protect wp-config.php from direct access using modern Apache 2.4 syntax.

1. Increasing the maximum file upload size

You're trying to install a theme or plugin, and WordPress throws an error: "The uploaded file exceeds the upload_max_filesize directive in php.ini." The default limit on many hosts is 2 MB or 8 MB, and your theme archive doesn't fit.

You can't edit php.ini on shared hosting. But if Apache runs with the mod_php module, you can raise the limit directly from .htaccess. Open the file in your site's root (via FTP or your hosting file manager) and add this at the end:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

The first directive sets the maximum POST request size, the second sets the maximum size for a single uploaded file. Both values should match, or post_max_size should be slightly larger.

Check the result: go to the WordPress admin panel, Media → Add New. The current limit will display at the bottom.

Important: if your host uses PHP-FPM (which most do in 2026), the php_value directives in .htaccess won't work. To check: Tools → Site Health → Info → Server. Look for FPM in the "Server architecture" line. For such hosting, change the limit through a .user.ini file in the site root:

1
post_max_size = 100M
2
upload_max_filesize = 100M

The format is like php.ini, with equals signs instead of php_value. Changes apply instantly with no server restart needed. If there's no .user.ini file in the root, create one.

2. Blocking search engine indexing

The situation: a test site on a subdomain, a staging copy, or a landing page that shouldn't appear in Google or Yandex results. A simple robots.txt with Disallow: / can be ignored by search engines: it's a recommendation, not a prohibition.

The ironclad method is to block bots at the server level. The classic approach using SetEnvIfNoCase works in Apache 2.4 through the compatibility module mod_access_compat, but it's considered deprecated. The modern method redirects bots with an empty User-Agent through mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Here's what's happening: RewriteCond checks the User-Agent of each request. When it detects the keywords bot, spider, crawler, or scanner (case-insensitive due to the [NC] flag), the server returns 403 Forbidden (the [F] flag).

Four patterns are enough to block all major search engines: Googlebot, YandexBot, Bingbot, Yahoo Slurp, and dozens of lesser-known ones. Listing each bot individually is pointless: Google alone has several dozen User-Agent variations for different services (search, images, video, AdsBot).

Want to block only Yandex while leaving Google alone? Narrow the pattern:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

The ^ symbol means "start of string." Without it, the rule would also catch bots that have yandex somewhere in the middle of their User-Agent.

Important: if WordPress already uses mod_rewrite for pretty permalinks, the RewriteEngine On block already exists in .htaccess. Don't duplicate it; just add the new RewriteCond and RewriteRule after the existing WordPress rules but before the closing </IfModule> tag.

After making changes, check .htaccess for errors: a typo in the directives will bring down the site with a 500 error. You can verify the syntax with an online validator or the apachectl configtest command (not available on all hosts). Before editing, always download a backup of your current .htaccess.

3. Disabling directory browsing

Go to your site at /wp-content/uploads/. If instead of a 403 error you see a file listing, you have directory browsing enabled. This is a security hole: anyone can study your folder structure, find a vulnerable plugin, or read an uploaded PDF document.

It's disabled with a single line in .htaccess:

1
Options -Indexes

Add it at the beginning of the file, before the WordPress rules. Now when someone tries to open a directory without an index file, the server will return 403 Forbidden.

On most modern hosts, this option is enabled by default, but check anyway, especially if the site has moved between servers or you're working with a VPS where Apache was configured manually.

4. Protecting wp-config.php from direct access

wp-config.php is the most important WordPress file. It contains security keys, the table prefix, and database credentials: the database name, user, password, and host.

The file itself is written in PHP and returns a blank page when opened directly in a browser because the WordPress engine doesn't execute it. But if PHP processing is temporarily disabled on the server (configuration failure, module update), the contents of wp-config.php could be served as plain text. Along with the database password.

We block access through .htaccess. Most articles on the internet offer outdated Apache 2.2 syntax that doesn't work in Apache 2.4.6 and higher. Here's the modern version with backward compatibility:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

The IfModule block checks for the presence of the mod_authz_core module (introduced in Apache 2.4.6). If the module is absent, Apache 2.2 syntax applies. If present, the modern Require all denied directive is used. One code block works on both Apache versions.

After adding the rules, any browser request to wp-config.php will receive 403 Forbidden, even if the PHP handler isn't working. WordPress accesses the file directly through the file system, so the rule doesn't affect site operation.

The same approach applies to any confidential file: replace wp-config.php with the filename you need, such as phpinfo.php or .env.

⁉️🤔 Frequently asked questions

Can I get by without.htaccess** in WordPress at all?**

Yes, if your site runs on Nginx instead of Apache. Nginx doesn't support .htaccess; all rules are set in the server configuration (nginx.conf or a file in sites-available/). On shared hosting, it's almost always Apache, and .htaccess is available. On VPS with Nginx, rules are moved to the server {} section: the syntax is different, but the logic is the same. For example, the Nginx equivalent of Options -Indexes is autoindex off;.

What should I do if the site crashes with a 500 error after changing.htaccess?

Immediately restore the backup of .htaccess that you made before editing (you did make one, right?). Connect via FTP, delete the modified .htaccess, and upload the saved original. The site will come back instantly. A 500 error after editing .htaccess is almost always caused by a typo in a directive or a construct that your version of Apache doesn't support.

Why doesn't php_value in.htaccess work on my hosting?

Most likely, your host uses PHP-FPM instead of mod_php. Check: Tools → Site Health → Info → Server. If FPM appears in the "Server architecture" line, php_value in .htaccess is ignored. Use a .user.ini file in the site root (see section 1) or contact your hosting support. On VPS, limits are changed in the PHP-FPM pool (www.conf), but this requires server configuration access.

How do I verify that.htaccess is actually working?

The simplest test is the rule from section 3 (Options -Indexes). Visit /wp-content/uploads/ before and after adding it. Was there a file listing before, and now a 403 error? The file is working. Another method: add a line with a deliberate syntax error to .htaccess and open the site. A 500 error confirms that Apache is reading .htaccess. Remove the test line immediately after checking.

Is it safe to use the code from this article on a live site?

Yes, all the snippets provided have been tested on Apache 2.4 (the current version as of 2026) and include compatibility blocks for Apache 2.2. The only mandatory requirement: before any .htaccess edit, download the current version of the file to your computer. This five-second operation saves hours of recovery in case of a typo. And don't edit .htaccess through plugins; use only FTP or your hosting file manager: a plugin might add escaping that breaks the syntax.

How does the approach to protecting wp-config.php in this article differ from what other sites write?

Most articles copy Apache 2.2 syntax: Order allow,deny and Deny from all. These directives belong to the mod_access_compat module, which is deprecated in Apache 2.4 and may be disabled on modern servers. Our snippet uses Require all denied from the mod_authz_core module, which is the current standard for Apache 2.4.6 and higher. At the same time, the <IfModule> block maintains functionality on older servers.

What to add to your.htaccess configuration right now

The .htaccess file is compact but powerful. Of the four techniques described, two close vulnerabilities with minimal effort: disabling directory browsing and protecting wp-config.php. That's one line and one code block you can add right now, and they don't affect site operation.

Increasing the upload limit helps every time WordPress refuses to upload a theme or plugin. And blocking indexing at the server level is the last line of defense for private and test sites.

Keep a backup of .htaccess before every edit. A syntax error brings down the site instantly, and it's fixed just as instantly if you have a copy on hand. With this rule in mind, .htaccess transforms from a scary file into a working tool.