How to Disable Directory Listing in WordPress (Apache and nginx)

If you visit a folder URL on your site, for example https://yourdomain.com/wp-content/uploads/2024/, one of three things happens. You see a clean white WordPress page (because index.php takes over), you see a "403 Forbidden" page, or you see something that looks like an FTP browser: a list of every file in that folder, with sizes and timestamps. The third one is the problem this guide is about.

Directory listing (also called "directory browsing" or "directory indexing") is a webserver feature that automatically renders an HTML index when no index.html or index.php is found in a folder. On a static site that is occasionally useful. On a WordPress site it is almost always a leak. This guide walks through what specifically leaks, why it matters, and how to disable the feature properly on Apache, nginx and the various managed WordPress hosts.

What actually leaks when directory listing is enabled?

Most WordPress folders contain at least one file that is interesting to an attacker, a competitor or just a curious visitor. The realistic worst cases:

• /wp-content/uploads/ contains every media file ever uploaded, organized by year and month. With listing enabled, anyone can see PDFs that were "unlinked" but never deleted, drafts of images, customer documents, and any private files that an editor uploaded thinking that "obscure URL" was good enough protection.
• /wp-content/plugins/ reveals the exact list of plugins installed on the site, including ones that were deactivated but not deleted. That is a precise vulnerability shopping list for any scanner.
• /wp-content/backup/, /backups/, /wp-content/uploads/backups/ and similar folders are typical destinations for backup plugins. If listing is on, full database dumps and zipped site backups become directly downloadable.
• Theme folders often contain old versions of style.css, leftover SCSS files, hidden test pages and developer notes that were never meant to be public.
• Site root folders can show wp-config.php.bak, editor swap files (.swp), .git/ directories from a botched deploy, and similar cleanup leftovers.

The sensitive files in those folders are typically there because someone uploaded them quickly, intended to delete them later, and forgot. As long as the folder does not list its contents, no one finds them. The moment listing is enabled, every URL in those folders is one click away from being indexed by a search engine or harvested by a scanner.

How to check if directory listing is enabled on your site

The fastest test takes ten seconds. Open these URLs in a private browser window:

• https://yourdomain.com/wp-content/
• https://yourdomain.com/wp-content/uploads/
• https://yourdomain.com/wp-content/plugins/
• https://yourdomain.com/wp-includes/

What you want to see is a 403 Forbidden page or, in the case of /wp-content/, a blank white page (that is WordPress's empty index.php doing its job). What you do not want to see is a list of files. If you see one, listing is on for that folder. InspectWP also runs this check during every scan and flags affected folders in the security section.

Option 1: Disable directory listing on Apache (and LiteSpeed)

The Apache directive that controls this behavior is called Options, with the value Indexes turning listing on and Options Indexes being negated by writing it without a leading plus, plus a minus sign in the directive itself. Add the following to the .htaccess file in your WordPress root directory, above the # BEGIN WordPress marker:

Options -Indexes

That single line disables listing for the entire WordPress install in one go. It applies to every folder under the document root, unless a more specific rule overrides it deeper in the tree.

If your host blocks Options in .htaccess entirely (some shared hosters do this for performance reasons), you have two fallbacks:

1. Drop an empty index.php or index.html into every folder you want to lock down. WordPress already does this for /wp-content/, /wp-content/plugins/ and a few others, but not for /wp-content/uploads/. The empty file makes Apache serve that file instead of listing the folder.
2. Ask your host to enable the Options directive for your account. Most managed hosts will do that on request.

The index.php trick is simple but easy to get wrong: you have to remember to add the file to every newly created folder, including the year/month folders that WordPress automatically creates for new uploads. A webserver rule does not have that problem.

Option 2: Disable directory listing on nginx

On nginx, directory listing is controlled by the autoindex directive. By default it is off on most installations, so on a default nginx setup the issue does not exist. The folders you visit fall through to a 403 when no index file is present.

If listing is on, someone explicitly turned it on at some point. Look for autoindex on; in your nginx.conf, in the site's server block, or in any included conf.d files. Either remove the line or change it to:

autoindex off;

Reload nginx with sudo nginx -t && sudo systemctl reload nginx. The next folder request will get a 403 instead of a file list.

If you cannot reload nginx (locked down managed hosting), the same index.php trick from the Apache section works on nginx too, because nginx will happily serve an existing index file before falling back to autoindex.

Option 3: Managed WordPress hosting

Managed hosts (Raidboxes, Kinsta, WP Engine, Cloudways, Pressable, etc.) typically disable directory listing by default at the server level. If you find that one of these hosts somehow has listing enabled on your account, the right move is a quick support ticket. They have access to the central nginx config and can fix it in minutes. Trying to work around it from inside WordPress on a managed host is rarely worth the effort.

Note that some hosts use a CDN layer (Cloudflare, KeyCDN, Bunny) that caches folder requests. If you change the server config and still see a file list, the CDN may be serving a cached version. Purge the cache for the affected paths and test again.

Common mistake: protecting wp-content/uploads with .htaccess

A pattern that shows up in older guides is putting a separate .htaccess directly into wp-content/uploads/ with a long list of rules. The intent is right, but the side effects are messy: depending on what the rules contain, image uploads can stop loading, lazy loading can break, or PDFs can become unreachable. If you only want to disable listing, the single Options -Indexes line in the root .htaccess is enough. It applies recursively. There is no need for separate per folder files unless you have a specific reason.

What about hiding files from search engines too?

Disabling directory listing prevents the folder index from being served, but it does not stop a search engine from indexing individual files inside the folder if they are linked from somewhere on the public web. If you have sensitive files in wp-content/uploads/ that you do not want appearing in Google, removing the file is the only reliable answer. noindex meta tags, X-Robots-Tag headers and robots.txt entries help with discovery, but only file deletion guarantees that the content is gone.

The general rule is the one that always applies to the uploads folder: do not upload anything there that you would not be comfortable seeing on the front page of your site. The folder is a public web directory by design.

How to verify your setup

1. Open https://yourdomain.com/wp-content/uploads/ in a private browser window. Expected result: a 403 Forbidden page or a blank page (depending on whether an empty index.html is present).
2. Repeat for any other folder you found earlier (/wp-content/plugins/, theme folders, custom upload folders).
3. If you see a file list, the change has not taken effect. Check that you edited the right .htaccess (the one in the WordPress root, not the one in the WordPress installation's parent directory) and clear any cache layers.
4. Run a fresh InspectWP scan. The "directory listing enabled" check in the security section should be green.

The whole change is a single line in .htaccess on Apache, or one config setting on nginx. Five seconds of work, and a whole class of accidental file disclosure goes away. Worth doing on every site, even if everything in your uploads folder is currently fine. The protection is for the next file someone uploads in a hurry, not just the ones already there.