Can Directory Indexing Be Turned Off on WordPress? Find Out!
Type a folder URL into your browser, something like yourdomain.com/wp-content/uploads/, and if you land on a plain list of every file in that folder instead of a “Forbidden” message, directory indexing is turned on. Most site owners never test this, which is exactly why it stays on for years on a lot of WordPress installs without anyone noticing.
This walks through what directory indexing actually is, why it’s worth the five minutes to disable it, and both ways to turn it off depending on whether your server runs Apache or Nginx.
What Directory Indexing Actually Is
Web servers normally look for a default file, index.php or index.html, when someone requests a folder URL rather than a specific file. If that file exists, the server shows the page it points to and the folder’s raw contents stay invisible. Directory indexing is what happens when that default file is missing and the server, instead of blocking the request, falls back to generating a plain listing of everything in the folder: filenames, subfolders, file sizes, and last-modified dates, all laid out for anyone who requests that URL.
WordPress installs an empty index.php in most core folders specifically to prevent this, which is why the problem usually shows up in folders that aren’t part of core: custom upload subfolders, a plugin’s cache directory, or a backup folder a developer created and forgot about.
The risk isn’t abstract. A visible uploads directory can expose unpublished draft images, private media meant only for logged-in members, or backup files with predictable names like backup-2025-01.zip that a bot can simply download. Plugin and theme folders can leak version numbers that tell an attacker exactly which known vulnerabilities to try first. None of this requires any real hacking skill; it’s just reading what the server was willing to show for free.
Why It’s Worth Fixing Even on a Small Site
- It closes an easy reconnaissance path. Attackers routinely scan for exposed directories before attempting anything else, because a browsable folder tells them what’s there without needing to guess.
- It protects files you forgot were public. Old backup exports, unused plugin remnants, and config file copies left behind by a migration are the most common things found this way, not because someone hacked in, but because the server handed the file list over on request.
- It reduces fingerprinting. Visible plugin folder names and version strings let automated scanners match your site against known vulnerability databases in seconds.
- It’s a five-minute fix with no downside. There’s no legitimate reason a folder listing needs to be public on a WordPress site, so disabling it costs nothing functionally.
What an Attacker Actually Does With an Open Directory
It helps to walk through this concretely rather than treating it as an abstract “security risk” checkbox. A bot scanning thousands of WordPress sites a day doesn’t need to find a login form vulnerability first; an open directory listing does much of the reconnaissance work for it automatically.
- Plugin and theme fingerprinting. A browsable /wp-content/plugins/ folder reveals every installed plugin by name, and often its version number sitting right in a readme.txt file inside that folder. Cross-referencing that against public vulnerability databases takes seconds and tells the attacker exactly which known exploit to try.
- Exposed backups. Developers and site owners routinely generate a quick .zip or .sql export while troubleshooting and forget to delete it. If it lands in a public, indexed folder, anyone who finds the listing can download a full copy of the database, including hashed passwords and any personal data stored in it.
- Leftover config and log files. A stray wp-config.php.bak, an error log with stack traces, or a debug file left on from development can hand over database credentials or reveal exactly how the site’s custom code is structured.
- Private or unpublished media. Draft post images, membership-only content, or files meant for a specific logged-in audience can sit in an uploads subfolder that was never meant to be crawled directly, but an open listing makes it just as accessible as anything published.
None of this requires the attacker to break anything. The server is simply configured to hand the information over on request, which is what makes this particular fix so disproportionately valuable relative to how little effort it takes.
How to Check Whether It’s Enabled
- Pick a folder on your site that’s unlikely to have its own index file, commonly a subfolder inside /wp-content/uploads/.
- Type the full folder URL directly into your browser’s address bar and load it.
- A raw file listing means indexing is on. A “403 Forbidden” response, a redirect, or a blank page means it’s already off.
Test a couple of different folders before concluding either way. Indexing can be disabled site-wide but still active on one folder with an unusual permission setting, especially after a migration or a plugin that creates its own upload directories.
A more thorough check worth running once a year, especially on sites with several plugins that create their own storage folders, is testing every top-level folder under wp-content individually: /wp-content/uploads/, /wp-content/plugins/, /wp-content/themes/, and /wp-content/cache/ if a caching plugin is active. Each of these can technically end up with different permission behavior depending on how a plugin was installed or whether a manual file transfer reset folder permissions along the way. A site that passes the test on its main uploads folder can still have a forgotten cache or backup subfolder wide open, so treating this as a single pass/fail check on one URL undersells how granular the actual risk can get.
Sites that changed hosting providers recently are worth re-testing specifically, since a fresh server configuration doesn’t automatically inherit the previous host’s directory-indexing settings. A migration is one of the more common, and more overlooked, moments where a previously secured site quietly reverts to an exposed default.
Method 1: Disable It Through .htaccess (Apache Servers)
Most shared and managed WordPress hosts run Apache, where the .htaccess file controls exactly this kind of server behavior.
Step-by-Step:
- Connect to your site’s files using an FTP client like FileZilla, or your host’s File Manager in cPanel.
- Locate the .htaccess file in your WordPress root directory. Make sure hidden files are visible in your FTP client’s settings, since dotfiles like this one are hidden by default on most systems.
- Open it in a plain text editor, never a word processor that might add formatting.
- Add this line, ideally near the top of the file:
Options -Indexes- Save the file and upload it back to the server, overwriting the original.
- Revisit the folder URL you tested earlier. You should now see a 403 error instead of a file list.
The Options -Indexes directive tells Apache to stop generating an automatic listing for any folder that’s missing an index file, without touching anything else about how the site functions.
Method 2: Disable It on Nginx
A meaningful share of managed WordPress hosts, including most cloud and high-performance platforms, run Nginx instead of Apache, and Nginx doesn’t use .htaccess files at all. If your host runs Nginx, directory listing is controlled by the autoindex directive in the server’s main configuration block, which typically needs to be set through your hosting provider’s control panel or support team rather than a file you can edit yourself:
autoindex off;Most managed Nginx hosts already ship with autoindex off by default, but it’s worth confirming directly with your host if you’re not certain which web server software is running underneath your account.
Method 3: Use a Security Plugin
For anyone who’d rather not edit server files directly, a security plugin can toggle this setting through the dashboard instead. Options worth considering include All In One WP Security & Firewall, Sucuri Security, and iThemes Security (now Solid Security).
Steps:
- From your WordPress dashboard, go to Plugins → Add New and install one of the plugins above.
- Open the plugin’s security settings. In All In One WP Security, for example, the option lives under WP Security → Filesystem Security → Directory Listing, and it’s a single toggle.
- Save your changes, then re-test the folder URLs to confirm the listing is gone.
A security plugin adds this fix on top of broader protection, firewall rules, malware scanning, and login hardening, so it’s a reasonable default for anyone who wants one tool covering multiple issues instead of a manual server-file edit.
The three plugins mentioned above take slightly different approaches worth knowing about before installing one. All In One WP Security & Firewall is free and specifically strong on granular filesystem and login-hardening settings, directory indexing included, which makes it a solid pick if this is the primary problem you’re solving for. Sucuri Security leans more toward monitoring and malware detection, with directory protection as one piece of a broader server-hardening checklist it walks you through. iThemes Security, now rebranded as Solid Security, bundles brute-force protection, two-factor authentication, and file change detection alongside the directory listing toggle, making it a reasonable single choice for someone who wants one plugin covering most of the basics rather than stacking three separate tools.
What If .htaccess Doesn’t Fix It?
Occasionally the Options -Indexes directive doesn’t take effect even after saving and re-uploading .htaccess, and there are a few specific reasons this happens:
- AllowOverride is restricted. If the server’s main Apache configuration has
AllowOverride Noneset for your site’s directory.htaccess directives are ignored entirely regardless of what’s in the file. This requires either a change to the server’s main config (which usually means contacting your host) or setting the directive directly in the virtual host configuration if you have that level of access. - A caching layer is serving a stale version of the folder listing. If a CDN or server-level cache is in front of the site, clear the cache after making the change and test again before assuming the fix didn’t work.
- The server is actually running Nginx behind an Apache-style dashboard. Some hosting panels present an Apache-like interface even when the underlying web server is Nginx or a mixed setup, in which case the .htaccess file is being read but partially ignored. Confirming with your host which web server software handles your account avoids a lot of wasted troubleshooting here.
If none of these explain it, a quick support ticket to your host asking them to confirm directory indexing is disabled at the server level resolves it faster than continuing to guess.
A Common Misconception Worth Clearing Up
Disabling directory indexing does not make individual files in that folder private. If someone already knows or guesses the exact filename, say, backup-2025-06-01.zip, they can still request that specific file directly and download it, because Options -Indexes only blocks the automatic file listing, not direct access to a known file path. True protection for sensitive files means not storing them in a publicly accessible web folder at all, or password-protecting the specific directory with an additional .htaccess authentication rule. Treat directory indexing as one layer, not a complete lock on the folder’s contents.
Other Security Basics Worth Pairing With This Fix
Disabling directory indexing closes one specific gap, but it’s not a complete security posture on its own. A few other habits matter more in practice:
- Keep everything updated. Outdated core, theme, and plugin versions remain the most common entry point for a compromised WordPress site, well ahead of exotic attack methods.
- Use strong, unique passwords on every account with publishing or admin access, and enable two-factor authentication wherever the login system supports it.
- Run a security plugin like Sucuri or Wordfence for firewall protection and malware scanning beyond just the directory listing fix.
- Limit login attempts to blunt automated brute-force attacks against wp-login.php.
- Keep automated, off-site backups running through a plugin like UpdraftPlus or BackupBuddy, so a compromised or corrupted site can actually be restored rather than rebuilt from nothing.
The roundup of the best WordPress security plugins goes deeper into choosing between the options mentioned above, and the guide to the best WordPress backup plugins covers what to look for in backup frequency and off-site storage specifically. If admin email exposure is also a concern on your site, the piece on how hackers mine WordPress sites for admin emails covers a related, commonly overlooked exposure path.
If You Manage Multiple WordPress Sites
Agencies and freelancers running several client sites on shared infrastructure face a slightly different version of this problem: fixing it once doesn’t fix it everywhere, and a new site added to the server months later can silently inherit whatever the server’s default happens to be rather than the hardened configuration applied to earlier sites. A network-level .htaccess rule at the server root, applied above the individual site level where the hosting setup allows it, closes this gap for every site under that account rather than relying on remembering to add the directive manually each time a new site goes live. Where that’s not an option, a shared staging checklist that includes a directory-indexing test as one of the standard pre-launch steps catches it before a new client site goes public with the default left open. This is a small operational habit, but it’s the kind of thing that’s easy to do once and then forget entirely on the next ten sites unless it’s written down somewhere the whole team actually follows.
Common Questions About Directory Indexing
Does disabling directory indexing slow down my site?
No. Options -Indexes and autoindex off are both configuration flags evaluated only when a request hits a folder without an index file, which is a rare case on a well-configured WordPress site to begin with. There’s no measurable performance cost either way.
Will this break any plugins or themes?
Legitimate plugins and themes don’t rely on directory listings to function; they reference specific files directly by path. If something breaks after making this change, it’s far more likely a coincidence or an unrelated issue than a direct result of disabling indexing.
Is this the same thing as blocking search engines from crawling my site?
No, these are unrelated. Search engine crawling is controlled by robots.txt and meta robots tags, and applies to actual pages and posts you want indexed for search. Directory indexing is a raw server-level file listing feature that has nothing to do with SEO, and disabling it has no effect on how Google or any other search engine treats your published content.
How do I know if my host already disabled this for me?
Many managed WordPress hosts, particularly Nginx-based ones, ship with autoindex off as a platform-wide default. The only reliable way to know for certain is to run the test described earlier: visit an indexless folder URL directly and see what comes back.
The Bottom Line
Directory indexing is one of the smallest, most overlooked settings in WordPress security, and also one of the easiest to fix once you know to check for it. Adding Options -Indexes to .htaccess on Apache, confirming autoindex off on Nginx, or flipping a toggle in a security plugin closes the gap in a few minutes with zero downside.
Treat it as one line item in a broader security routine rather than a fix-and-forget task: pair it with regular updates, strong passwords, and real off-site backups, and most of the common ways a WordPress site gets compromised stop being viable.
What Is WordPress? Start Your Website Journey Today