Apache .htaccess rules can restrict access to selected WordPress files and disable directory listings. They supplement updates, sound access controls and backups, and need testing with your site’s web-server configuration.

Before editing

Back up the existing .htaccess file and test on a copy of the site where possible. These examples require Apache 2.4 and permission to use the relevant directives. NGINX does not read .htaccess files.

Place custom rules outside the BEGIN WordPress and END WordPress markers so WordPress does not overwrite them.

Restrict sensitive files

For the WordPress root directory:

<FilesMatch "^(wp-config\.php|\.htaccess)$">
    Require all denied
</FilesMatch>

This blocks HTTP access, not authorised filesystem editing. Do not replace working server protections or broaden this pattern to application files visitors need.

Disable directory listing

Where the server permits it:

Options -Indexes

This stops automatic folder listings. It does not prevent access to a known public file URL.

For a site whose allowed domain is example.com, with mod_rewrite available:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?example\.com(?:/|$) [NC]
RewriteRule \.(?:jpg|jpeg|png|gif)$ - [F,L,NC]

Change the domain and include other authorised sites or subdomains before use. This permits empty referrers and is not a private-file access control.

Test the site

Check pages, images, the editor and uploads after each change. Restore the backup if a rule causes errors. Do not block the entire wp-includes directory, because it contains public assets. Administrative IP restrictions need their own scoped design, including access recovery and any public admin-ajax requests.