Type a folder URL into your browser with nothing after it – no filename, just the directory path – and one of two things happens. Either you get a 403 error or a redirect to your homepage, which is what should happen, or you get a plain list of every file sitting in that folder, which is directory indexing doing exactly what it was designed to do decades ago and exactly what you don’t want it doing on a modern WordPress site.
What directory indexing actually is
Directory indexing is a web server behavior, not a WordPress feature. When a browser requests a folder and the server can’t find a default file to serve – typically index.php or index.html – it falls back to whatever it’s configured to do in that situation. On a server with indexing enabled, that fallback is generating an auto-listing of the folder’s contents: every filename, every subfolder, sometimes file sizes and modification dates too.
Visit yoursite.com/wp-content/uploads/ on a site with indexing enabled and you’ll see every media file you’ve ever uploaded, organized by year and month, sitting in plain view. No login required. No context about what the site is or why those files exist. Just a bare list, generated by the server, completely outside of anything WordPress itself controls.
Why this is actually a security problem
It’s tempting to shrug this off – so what if someone sees a list of image filenames? The risk isn’t usually in any single directory listing. It’s in what a browsable file structure tells an attacker about the rest of your site, and what it occasionally exposes directly.
Sensitive information exposure is the most direct risk. Plugin and theme directories reveal exactly which plugins and themes are installed, and often their exact versions, just by browsing to wp-content/plugins/ and looking at folder names and any readme files sitting inside them. That’s reconnaissance an attacker would otherwise have to work for, handed over for free.
Targeted attacks follow naturally from that reconnaissance. Once an attacker knows you’re running a specific plugin at a specific version, they can check that version against known vulnerabilities and go straight for an exploit that’s already documented, rather than blindly probing your site for weaknesses. Directory indexing turns a generic scan into a targeted one.
Unauthorized file access rounds out the risk. Backup files, configuration exports, or temporary files that a plugin or developer left sitting in a public directory – meant to be temporary, forgotten about, never intended to be found – become trivially discoverable the moment someone can browse to the folder they’re sitting in. A file doesn’t need to be linked from anywhere on your site to be found this way. It just needs to be sitting in a directory an attacker thought to check.
Checking whether directory indexing is enabled on your site
This takes about ten seconds. Open your browser and navigate to a folder on your site that doesn’t have an index file – wp-content/uploads/ is a reliable one to test, since it almost never has a custom index.php of its own.
If indexing is enabled, you’ll see a plain, unstyled list of files and folders. If it’s disabled, you’ll get a 403 Forbidden error, a blank page, or a redirect, depending on exactly how your server and any active security plugin are configured. Either of those second outcomes means you’re already protected. The plain file list means you have work to do.
Turning off directory indexing: three approaches
Method 1: The .htaccess file
This is the most direct fix on Apache servers, and it applies site-wide with a single line. The .htaccess file lives in your WordPress installation’s root directory and controls a range of server-level behaviors, indexing among them.
Connect to your site via FTP or your hosting file manager. Locate .htaccess in the root folder – if it’s not visible, your FTP client likely needs to be told to show hidden files, since files starting with a dot are hidden by default on most systems. Download a copy before touching anything, so you have something to restore from if a typo breaks the site.
Open the file in a plain text editor and add this line:
Options -Indexes
Save it, upload it back to the server overwriting the original, and revisit the test directory from earlier. You should now see a 403 error or blank page instead of a file listing. That single directive tells Apache to stop generating auto-indexes for any folder on the site that lacks its own index file.
Method 2: A security plugin
If editing server configuration files isn’t something you’re comfortable doing directly, a security plugin gets you the same result through a settings screen instead of raw code. Several well-known WordPress security plugins include this as a built-in hardening option:
- Wordfence Security – a broad security suite that includes site hardening options covering directory browsing among other server-level settings.
- iThemes Security – another comprehensive option with a dedicated hardening section that can disable directory browsing along with several other common attack surfaces.
- All In One WP Security & Firewall – built around an approachable interface specifically for site owners who want strong defaults without digging through raw configuration.
Install whichever fits your existing security setup through Plugins > Add New, activate it, and look for a hardening or file system security section in its settings. The exact wording varies by plugin, but “directory browsing,” “directory listing,” and “directory indexing” all refer to the same setting.
Method 3: Your hosting control panel
Some hosts expose this setting directly through cPanel or an equivalent control panel, which avoids touching any files at all. Log into your hosting account, look for an Index Manager or similarly named tool, select the folder you want to protect – usually the site’s root, which covers everything beneath it – and choose “No Indexing.” Apply the change and you’re done without ever opening a code editor.
Which method should you actually use
If you’re already comfortable with FTP and don’t mind editing a config file, the .htaccess method is the fastest and most direct. It’s also the one that survives most cleanly if you ever change security plugins later, since it’s not tied to any specific plugin’s settings.
If you’d rather not touch server files at all, and you’re already running a security plugin for other reasons, use the plugin’s hardening settings instead. There’s no meaningful downside to going this route as long as you actually check the box – a plugin sitting installed but unconfigured provides zero protection.
The hosting control panel route makes the most sense for site owners without FTP access or plugin management permissions, which does happen on certain managed hosting setups where the host handles server-level configuration directly.
None of these three approaches conflicts with the others. There’s no harm in setting the .htaccess directive and also enabling a plugin’s hardening option as a second layer, since the outcome – no browsable directory listings – is the same regardless of which mechanism actually enforces it.
Common mistakes worth avoiding
Assuming a managed host has already handled this. Some do, by default. Plenty don’t. The only way to know for certain is the ten-second browser check described above, not an assumption based on how premium or reputable your hosting plan sounds.
Editing .htaccess without a backup. This file controls more than just indexing – permalinks, redirects, caching rules, and security headers often live in the same file. A typo here can take the entire site down with a 500 error, and having the previous working version saved locally turns a stressful debugging session into a thirty-second fix.
Checking only the site’s root directory. Indexing needs to be off everywhere a sensitive folder might exist, not just at the top level. The .htaccess Options -Indexes directive covers the whole site in one shot, which is part of why it’s a reliable first choice – plugin-by-plugin or folder-by-folder fixes are easy to leave gaps in.
Forgetting to retest after changing hosts or migrating. Server configuration doesn’t always transfer cleanly during a migration, and a .htaccess directive that worked perfectly on your old host can silently stop applying on a new one with different server software or a different default configuration. Re-run the ten-second check after any hosting change.
Which folders actually matter most on a WordPress install
Not every directory carries the same risk if it’s left browsable, so it helps to know where to focus first if you’re auditing an existing site rather than setting one up fresh.
wp-content/uploads/ is the one most people think of first, and for good reason – it’s organized by year and month, making it trivially easy to browse chronologically through every file ever uploaded to the site, including images that were meant to stay unlisted, unpublished draft attachments, or documents uploaded for internal use that were never intended to be linked publicly anywhere.
wp-content/plugins/ and wp-content/themes/ matter for a different reason. Browsing these doesn’t expose user files, but it hands over an inventory of exactly what’s installed, often including version numbers visible in readme.txt files sitting in each plugin’s folder. That inventory is precisely what an attacker running an automated vulnerability scan needs to skip straight to checking known exploits for your specific setup instead of guessing.
wp-includes/ is less commonly a problem since it’s WordPress core rather than user-added content, but on an older, unpatched WordPress installation, an exposed listing here can occasionally reveal information about exactly which core version is running, based on file structure differences between versions.
Custom directories added by page builders, form plugins, or backup tools are the wildcard. A backup plugin that drops zip files into a folder under wp-content, a form plugin that stores file uploads outside the media library, a page builder caching generated CSS and JS into its own folder – all of these can end up as browsable directories nobody thought to check, simply because they weren’t part of the standard WordPress folder structure anyone was already thinking about.
What a real exposure actually looks like
The failure mode here rarely looks dramatic. Nobody gets an alert. Nothing crashes. What actually happens is quieter and slower: a security scanner, run by an attacker or a bot crawling thousands of sites automatically, requests a handful of common directory paths across your site. If one of them returns a file listing instead of a 403, that scanner now has a map of exactly what’s on your server without needing to guess at a single filename.
From there, the next steps are mechanical. Cross-reference plugin folder names and versions against a vulnerability database. Look for anything named backup, old, or test sitting in a public folder, since these names show up constantly in real scans precisely because site owners create files like these and forget about them. Check whether any configuration or environment file ended up somewhere it shouldn’t be. None of this requires sophisticated hacking skill. It requires an open directory listing and a few minutes of pattern matching against a known list of common mistakes.
What this doesn’t protect against
It’s worth being clear about the limits here. Disabling directory indexing stops someone from browsing a folder’s contents when they don’t already know a specific filename. It does nothing to stop someone who already has a direct link to a specific file – a backup file shared in a support ticket, a config export that got indexed by a search engine before you fixed this, a file linked from somewhere you forgot about. Directory indexing is one layer of a broader security posture, not a complete solution to file exposure on its own. Sensitive files that shouldn’t be publicly accessible at all need to live outside the web root, or be protected by additional access rules, regardless of whether indexing is on or off.
Frequently asked questions
Will disabling directory indexing break anything on my site?
For the overwhelming majority of WordPress sites, no. Legitimate visitors and search engines reach your content through actual URLs and links, never by browsing a raw folder listing. Turning off indexing removes something almost nobody was relying on in the first place.
The only scenario where this could matter is a site deliberately relying on directory browsing as a feature – a public file archive with no proper index page, for instance – which is uncommon and generally not how a WordPress site should be structured anyway.
Does WordPress disable directory indexing automatically?
WordPress core doesn’t control this setting directly since it’s a web server configuration rather than a WordPress application setting. Some hosting providers disable it by default at the server level, others leave the server’s default behavior in place, which is often indexing enabled unless someone explicitly turns it off.
What if I’m on Nginx instead of Apache?
The .htaccess method described above is Apache-specific. Nginx handles this through its own server block configuration using a directive like autoindex off, typically set by whoever manages the server configuration rather than something editable from within the WordPress file system the way .htaccess is. A security plugin’s hardening settings or your hosting control panel are usually the more accessible route on Nginx.
Can I check if a specific competitor or random site has this enabled?
Yes, using the exact same method – navigate to a likely folder path and see what loads. It’s a genuinely useful way to spot-check your own site’s security posture across every environment you manage, including staging sites that often get less security attention than production.
Is a 403 error the only correct outcome, or is a redirect just as good?
Either is fine from a security standpoint. What matters is that a visitor requesting a bare directory path never sees an actual file listing. Some hosts and security plugins redirect to the homepage instead of showing a 403, which achieves the same protective outcome even though the visible behavior differs slightly.
Run the check on every environment you’re responsible for, not just the main production site. Staging environments, development subdomains, and old sites still sitting on a server somewhere are exactly the places this setting tends to get forgotten, and they’re just as browsable as the site everyone actually pays attention to.
This is a fix that takes minutes and rarely gets revisited once it’s done. Put it on whatever checklist you use for a new site launch, and check it again any time you move hosts. It costs almost nothing to fix and quietly closes off one of the easier reconnaissance paths an automated scanner has into your server.
None of this requires a developer, a paid audit, or specialized tooling. It requires ten seconds to check and a few minutes to fix, and it’s one of those rare security tasks where the effort-to-payoff ratio is almost entirely in your favor. Most security hardening involves tradeoffs somewhere – more friction for admins, more moving parts to maintain, occasional compatibility headaches with a plugin update. This one has none of that. It’s a single setting that costs nothing and protects something real.
