Yes, directory indexing can be turned off on a WordPress site, and if you haven’t checked whether it already is, it’s worth five minutes to find out. Directory indexing is what happens when a visitor navigates to a folder on your server that has no index file in it, instead of a 404 or a redirect, the server hands back a plain listing of every file sitting in that directory. Anyone can browse it. Depending on what’s actually in that folder, that can mean exposing plugin source files, uploaded documents nobody meant to make public, backup archives, or configuration remnants a developer forgot to clean up.
Why This Matters More Than It Sounds Like It Should
Most WordPress folders have an index.php file specifically to prevent this. Open wp-content/plugins/index.php in any WordPress install and you’ll find a single line, <?php // Silence is golden., whose entire job is to give the server something to serve instead of a file listing. But not every folder gets one automatically, and a fair number of uploads directories, cache folders, and custom plugin subfolders end up without that protection, especially on older sites, sites migrated between hosts, or folders created by a plugin that didn’t follow the convention.
Test it yourself right now: try visiting yoursite.com/wp-content/uploads/ directly in a browser. If you see a bare list of folders and files rather than a 404 page or your homepage, directory indexing is currently on for that path, and probably for others across your install too.
How to Turn Off Directory Indexing
On the large majority of WordPress hosts running Apache, this is controlled through your .htaccess file, which lives in the root directory of your WordPress installation and controls a wide range of server-level behavior for your site.
Steps to Disable Directory Indexing
1. Access Your .htaccess File
You can reach it via FTP/SFTP, through your hosting control panel’s file manager (cPanel, Plesk, or your host’s custom dashboard), or through a WordPress plugin that exposes file editing, though editing it directly via FTP or your host’s file manager is generally the safer route since it avoids adding another moving part to a file that controls core server behavior.
2. Edit the .htaccess File
- Open the file in a plain text editor, not a word processor, which can introduce invisible formatting characters that break Apache’s parsing.
- Add this line, ideally near the top of the file, outside of the block WordPress itself manages between
# BEGIN WordPressand# END WordPress:
Options -Indexes3. Save and Upload
Save the file and, if you edited it locally, upload it back to the same location it came from, overwriting the original.
4. Verify the Change
Try accessing a directory on your site that has no index file. You should now see a 403 Forbidden error, or in some configurations get redirected to your homepage, rather than a file listing.
What Options -Indexes Actually Does
The Options -Indexes directive tells Apache to disable its automatic directory listing feature for that directory and everything below it (unless overridden by another .htaccess further down the folder tree). Without it, Apache’s default behavior when it can’t find an index file is to generate that listing on the fly, sorted by name, size, or date depending on query parameters a visitor can even manipulate directly in the URL. With it in place, a request for a directory with no index file gets denied instead.
It’s a single line, but it closes a real gap. Directory listings are a favorite target for automated scanners looking for exposed backup files (.sql, .zip), leftover installer scripts, or config files with predictable names. A bot doesn’t need to guess a filename if your server is happy to just list every filename in the folder for it.
What If You’re on Nginx Instead of Apache
.htaccess is an Apache-specific mechanism, it has no effect at all on an Nginx server, which a growing number of managed WordPress hosts use either exclusively or as a caching layer in front of Apache. If your host runs Nginx, directory listing is controlled instead by the autoindex directive in your server block configuration:
location / {
autoindex off;
}On Nginx, autoindex actually defaults to off already in most standard configurations, so this is less commonly an issue than on Apache, but it’s not guaranteed, some hosting configurations or custom server blocks do turn it on deliberately for specific paths, sometimes leftover from debugging a deployment issue. If you don’t have direct access to your Nginx configuration (common on shared or managed hosting), you’ll need to ask your host to confirm and adjust it, since you can’t fix this one yourself through WordPress or a plugin.
Confirming Your Host’s Setup Either Way
If you’re not sure whether your site runs Apache or Nginx, check your hosting control panel or ask your host directly, plenty of managed WordPress hosts run a hybrid stack where the answer isn’t obvious from the outside. Some hosting environments also lock down .htaccess editing entirely and manage server config centrally, in which case adding Options -Indexes yourself won’t do anything, and you’ll need to request the change through support instead.
A Plugin-Based Alternative
If you don’t have FTP or file manager access, or you’re not comfortable editing server config files directly, a general-purpose security plugin like Wordfence or All In One WP Security & Firewall includes a toggle for disabling directory browsing as part of its broader hardening checklist, without requiring you to touch .htaccess manually. Under the hood these plugins are typically still just writing the same Options -Indexes directive into your .htaccess file for you, so the end result is the same, but it’s a reasonable path if editing server files directly isn’t something you want to do yourself.
Other Things Worth Locking Down at the Same Time
Disabling directory indexing is one piece of a broader server-hardening pass, and if you’re already in your .htaccess file for this, it’s worth doing a few related checks in the same sitting:
- Block direct access to sensitive files.
wp-config.php,.htaccessitself, and anyreadme.txtorchangelog.txtfiles that reveal exact plugin/theme versions to an attacker scanning for known vulnerabilities. - Disable XML-RPC if you don’t use it. It’s a common brute-force and DDoS amplification target if left open and unused.
- Check file permissions. Directories generally shouldn’t be writable at 777, and PHP files shouldn’t be executable by processes that don’t need to run them.
- Remove any stray installer or backup files sitting in your web root, files like
install.php,backup.zip, ordatabase-export.sqlleft over from a migration are exactly what an open directory listing would have exposed in the first place.
Directory Indexing vs. Search Engine Indexing: Two Different Things
It’s worth clearing up a mix-up that comes from the two systems sharing the word “indexing.” Directory indexing (this article’s topic) is a server feature that lists files in a folder when no index file is present. Search engine indexing is Google, Bing, and other crawlers adding your pages to their search results. They’re completely unrelated. Disabling directory indexing does not affect whether your pages show up in Google. Controlling search engine indexing is instead handled through your robots.txt file, meta robots tags, and your XML sitemap, usually managed through an SEO plugin like Yoast or Rank Math. If you came to this topic worried about search visibility, that’s a separate setting entirely, don’t confuse the two when troubleshooting either one.
WordPress Folders Worth Specifically Checking
Once you’ve confirmed Options -Indexes is applied at the root, it’s worth spot-checking a handful of paths individually, since plugin-created folders don’t always inherit protection the way you’d expect, and nested .htaccess files can override the root setting:
/wp-content/uploads/and its yearly/monthly subfolders, this is where user-uploaded media lives and is one of the highest-value targets for a listing, since it can expose private documents customers or staff uploaded through a form./wp-content/plugins/and/wp-content/themes/, both should already carry the standard silence-is-goldenindex.php, but it’s worth a spot check, especially after installing a plugin from a less established developer.- Any custom upload directory a form plugin or membership plugin creates outside the standard
wp-content/uploadspath, some plugins create their own storage folders that don’t automatically inherit WordPress’s default protections. - Backup plugin storage folders, if your backup plugin stores archive files inside your web root rather than off-server, that folder is a prime target and should ideally not be publicly reachable at all, regardless of directory indexing status.
Testing With a Free Online Scanner
Beyond manually checking individual folder URLs, a handful of free security scanner tools (Sucuri SiteCheck and similar services) will flag exposed directory listings as part of a broader site scan, along with other common misconfigurations. Running one of these occasionally, not just once after making this fix, is a reasonable habit, since plugin updates and hosting changes can silently reintroduce a listing you’d already closed off.
CDN and Caching Layer Considerations
If your site sits behind a CDN or a caching proxy like Cloudflare, be aware that origin-server settings like Options -Indexes apply at your actual hosting server, not at the CDN edge. A cached version of a directory listing page, if one was ever generated and cached before you made this fix, could theoretically continue being served from cache for a short window even after the origin server is properly locked down. After making this change, it’s worth purging your CDN’s cache for the affected paths (or your full site cache, if that’s simpler) to make sure the fix is actually live everywhere a visitor might hit, not just at the origin.
Staging and Development Environments
Directory indexing gets forgotten most often on staging sites and local development environments, since those don’t feel like they carry the same stakes as production. That’s a mistake if your staging site is reachable on the open internet rather than behind a password wall or IP restriction, which is common with subdomain-based staging setups (staging.yoursite.com) that aren’t properly access-controlled. Apply the same Options -Indexes directive to staging environments, and ideally add HTTP basic auth or an IP allowlist on top, staging sites often contain the exact kind of half-finished, unreviewed content and test data that’s most awkward to have exposed in an open directory listing.
Why This Keeps Getting Rediscovered as a Problem
Directory listing exposure isn’t a new or obscure vulnerability, it’s been a known web server misconfiguration for decades, well before WordPress existed. It keeps showing up in WordPress-specific security audits because of how often sites get migrated between hosts, cloned for staging, or have plugins installed that create their own folder structures outside WordPress’s own protected defaults. Each of those events is a chance for the protection to quietly not carry over. Treat this less as a one-time fix and more as something worth re-checking after any hosting migration, major plugin installation, or infrastructure change.
Common Mistakes When Editing .htaccess
- Placing the directive inside the WordPress-managed block. WordPress can silently rewrite the section between
# BEGIN WordPressand# END WordPressunder certain conditions (like resaving permalink settings), so custom directives placed there can get wiped out unexpectedly. Keep custom rules outside that block. - Not backing up the original file first. A malformed .htaccess can produce a 500 error across your entire site. Always keep a copy of the working version before editing, so you can revert quickly if something goes wrong.
- Assuming the change applies everywhere. A subdirectory with its own
.htaccessfile containingOptions +Indexescan override the root-level setting for that specific folder. If you find one path still listing files after making the change at the root, check for a nested .htaccess overriding it locally. - Forgetting to test after a host migration. Server configuration changes, including this one, don’t always survive a move to new hosting, especially if the migration only copies WordPress files and database but not raw server-level Apache config. Re-verify after any hosting change.
What an Exposed Directory Listing Has Actually Cost Sites
This isn’t a theoretical risk raised for the sake of a security checklist. Open directory listings on WordPress sites have repeatedly been the entry point in real incidents: an exposed /wp-content/uploads/ folder revealing a full-resolution copy of a document a user thought they’d deleted, a forgotten backup-2023.zip sitting in the web root containing a full database export with hashed passwords and API keys, or an installer script left behind after a migration that let an attacker re-run WordPress’s setup wizard against an already-live database. None of these require any sophisticated exploit, they require nothing more than a bot finding an open folder and looking at what’s inside. That’s precisely why this fix punches so far above its weight for the effort involved, it removes an entire category of “the attacker didn’t even need to guess anything” risk.
Quick Answers
Does this affect my site’s SEO? No, disabling directory indexing has no bearing on search rankings. Search engines crawl your actual pages and posts through your sitemap and internal links, not by browsing raw server directories.
Will this break anything on my site? Almost never. Legitimate visitors and WordPress itself access files by their direct URL, not by browsing a folder listing, so disabling indexing doesn’t interfere with normal site function. The only edge case is if you were deliberately relying on directory browsing for something, like sharing a folder of downloadable files with visitors, in which case build a proper indexed download page instead rather than relying on the server’s raw file listing.
How do I know if it’s already off? Visit a folder path directly in your browser that you know has no index file, like yoursite.com/wp-content/uploads/2024/. A 403 error or redirect means it’s already disabled; a plain list of files and folders means it isn’t.
Does every host allow .htaccess edits? Most shared and VPS hosting environments do, but some fully managed WordPress hosts lock .htaccess editing entirely and manage equivalent server settings through their own dashboard or centrally on their end, in which case you’d request the change through their support team rather than editing the file directly yourself.
Is this the same as password-protecting a folder? No, those solve different problems. Disabling directory indexing stops the server from listing files when no index is present, but a direct link to a known filename inside that folder still works. Password-protecting a directory with HTTP basic auth blocks access to every file in it regardless of whether the exact filename is known, which is a stronger form of protection worth layering on top for anything genuinely sensitive.
The Bottom Line
Disabling directory indexing on your WordPress site is a straightforward yet essential step in enhancing your site’s security. By preventing unauthorized users from viewing the contents of your directories, you reduce the risk of exposing sensitive files or information that was never meant to be publicly browsable. Implementing this measure through a simple addition to your .htaccess file, or the equivalent Nginx directive if that’s your stack, helps safeguard your website against a category of low-effort, automated scanning that’s genuinely common on the open web. It takes a few minutes to check and fix, and there’s essentially no downside to having it in place. Add it to whatever post-launch or post-migration checklist you already run for a site, right alongside confirming SSL is active and backups are actually running, and it stops being something you have to remember to think about on its own.
Interesting Reads:
Best AI Tools for Market Research