Can Directory Indexing Be Turned Off on WordPress?
Type a directory URL into a WordPress site with no index file present, something like yoursite.com/wp-content/uploads/2023/06/, and one of two things happens. Either the server returns a 403 Forbidden page, or it hands back a plain list of every file sitting in that folder: filenames, sizes, modification dates, all of it browsable and clickable. The second behavior is directory indexing, and on a WordPress install it is almost always something you want turned off.
This is a server-level setting, not a WordPress setting, which is why it gets missed. WordPress has no admin screen for it. You will not find it in Settings or in any core menu. It lives in your web server’s configuration, and depending on your host, the default can go either way.
A common way this gets discovered: a developer runs a database backup manually before a migration, saves it into /wp-content/uploads/backup-temp/ for convenience while they finish the job, and forgets to delete it afterward. Six months later a routine security scan flags an open folder listing, and sitting inside it is a full .sql export with every customer record the store has ever processed. Nobody hacked anything. The folder was simply browsable the entire time.
What Directory Indexing Actually Exposes
The risk is not that someone sees a folder name. It is what accumulates inside folders over the life of a WordPress site that nobody expected to become public. A few concrete examples, all of which show up regularly in security audits of real sites:
Backup files left by a plugin or a manual export. A .sql or .zip database backup dropped into /wp-content/uploads/backups/ for convenience, then forgotten, contains your entire database including hashed passwords, order data if you run WooCommerce, and API keys stored in options tables. With directory indexing on, that file is one click away from anyone who finds the folder.
Uploaded documents that were never meant to be public. Invoices, resumes submitted through a job application form, ID scans from a verification process, anything a plugin wrote to the uploads directory without a corresponding access-control check. The files themselves might not be linked from anywhere on the site, but directory indexing makes them discoverable without a link at all.
Plugin and theme version fingerprints. Browsing /wp-content/plugins/some-plugin/ and seeing a readme.txt with a version number tells an attacker exactly which known vulnerabilities to try. This is a smaller risk on its own since version numbers often leak through other means too, but it removes a layer of friction that would otherwise slow down automated vulnerability scanners.
Staging or development leftovers. A folder like /old-site/ or /test/ created during a migration and never deleted becomes fully browsable, sometimes exposing an entirely separate, outdated WordPress install with its own set of unpatched vulnerabilities.
None of these require any special skill to find. Automated scanners, the same bots that constantly probe WordPress sites for known plugin vulnerabilities, also request common upload paths and check whether the response is a listing or a blocked request. A site with indexing left on is not targeted specifically; it is simply caught by the same broad sweep that hits every WordPress install on the internet, and it gets flagged as an easier target the moment a scanner sees a file listing instead of a 403.
How to Check If Directory Indexing Is On Right Now
Before changing anything, confirm whether this actually affects your site. Navigate to a folder inside /wp-content/uploads/ that you know does not have an index.php file, most uploads subfolders do not by default. Try a URL pattern like yoursite.com/wp-content/uploads/2024/01/, adjusting the year and month to match when you last uploaded media.
If you see a plain, unstyled list of files and folders, directory indexing is on. If you see a 403 Forbidden page, or your site’s normal 404 page, it is already off, and someone configured this correctly at some point. If you see a WordPress-styled error or your homepage instead, the server may be redirecting missing index requests rather than genuinely blocking the listing, worth digging into further with a command-line check rather than relying on the browser alone.
For a more reliable test that bypasses caching and browser redirects, run a curl request from a terminal:
curl -I https://yoursite.com/wp-content/uploads/2024/01/A 403 or 301 status in the response headers confirms indexing is blocked. A 200 status followed by HTML containing <title>Index of confirms it is open.
Disabling Directory Indexing on Apache
Most WordPress hosting still runs Apache, and the fix is a single directive in your .htaccess file.
Step 1: Locate .htaccess
It lives in your WordPress root directory, the same folder as wp-config.php. Access it through your host’s File Manager or an FTP client like FileZilla. It is a hidden file by default (the leading dot marks it as hidden on Unix-style systems), so enable “show hidden files” in your file manager or FTP client if you do not see it.
Step 2: Add the Directive
Options -IndexesAdd this line near the top of the file, before the WordPress block that begins with # BEGIN WordPress. Placing custom directives inside that block is technically fine but risky, since some plugins regenerate that section and can wipe out anything you added inside it.
Step 3: Verify
Save the file, clear any server-side or CDN caching in front of your site, and repeat the browser or curl test from above. A 403 response confirms the change took effect.
If nothing changes after saving, the most likely cause is that your host’s Apache configuration has AllowOverride None set for your account, which means .htaccess directives are ignored entirely regardless of what you put in the file. In that case, contact your hosting provider directly and ask them to disable directory indexing at the server configuration level, since you cannot override it from .htaccess alone.
Disabling Directory Indexing on Nginx
Nginx does not read .htaccess files at all, so this fix happens in the server block configuration, which typically requires SSH or root access rather than a file manager.
Step 1: Locate the Configuration
The main config is usually at /etc/nginx/nginx.conf, but the actual server block for your site is more often in /etc/nginx/sites-available/yoursite.conf or a similarly named file under conf.d/. Managed hosts (Kinsta, WP Engine, Cloudways) typically handle this server-side and directory indexing is disabled by default; if you are on one of those, check with support before assuming you need to edit anything yourself.
Step 2: Add or Confirm the Directive
autoindex off;Place this inside the relevant server or location block. Nginx defaults to autoindex off out of the box in most standard installs, so if you find indexing enabled on an Nginx server, someone (a previous developer, an old tutorial someone followed) explicitly turned it on at some point, which is worth investigating since it suggests other non-default settings might be present too.
Step 3: Test and Restart
sudo nginx -tRun this first to check the configuration file for syntax errors before restarting; a bad edit here can take the entire server offline for every site it hosts, not just yours. Once the test passes:
sudo systemctl restart nginxDisabling Directory Indexing on LiteSpeed
LiteSpeed and OpenLiteSpeed, common on shared hosting stacks marketed as high-performance, generally support the same Options -Indexes directive through .htaccess since LiteSpeed maintains Apache compatibility for this feature. If that does not take effect, check the LiteSpeed admin panel under the virtual host’s configuration, there is usually an explicit “Auto Index” setting under Context configuration that can override .htaccess behavior regardless of what the file says.
Quick Reference by Server Type
| Server | Configuration File | Directive | Access Needed |
|---|---|---|---|
| Apache | .htaccess (site root) | Options -Indexes | File Manager or FTP |
| Nginx | Server block config | autoindex off; | SSH or root access |
| LiteSpeed / OpenLiteSpeed | .htaccess or admin panel | Options -Indexes or Auto Index toggle | File Manager, or LiteSpeed panel |
| Managed hosting (Kinsta, WP Engine, etc.) | Handled by host | Usually disabled by default | Support ticket if not |
Alternative Methods If You Cannot Edit Server Configuration
Not everyone has file manager or SSH access, particularly on tightly managed hosting plans or agency-managed sites where the client only has WordPress admin access.
Security plugin toggle. Wordfence, Sucuri Security, and Solid Security all include a directory listing protection option, usually under a hardening or firewall settings tab, that writes the appropriate .htaccess rule for you without manual file editing.
Ask your host. Most managed WordPress hosts will disable this on request through a support ticket, and many already have it disabled platform-wide, meaning the issue you are seeing might actually be a caching artifact rather than genuine indexing. Confirm with a fresh curl request before assuming the fix did not work.
Blank index file per folder. Dropping an empty index.html or index.php file into a specific folder prevents that one folder from listing its contents, since the server serves the blank file instead of generating a listing. This does not fix the setting globally and needs repeating for every folder you want protected, so treat it as a stopgap for one sensitive folder rather than a real solution.
Common Mistakes
Fixing it and stopping there. Directory indexing being off does not mean sensitive files inside those folders are actually protected, it only means they cannot be discovered by browsing. A backup file with a guessable or previously-shared URL is still directly downloadable even with indexing disabled. If backups have ever lived in a web-accessible folder, move them outside the web root or delete them, do not rely on indexing being off as the only safeguard.
Editing .htaccess without a backup. Before adding any directive, copy the existing file’s contents somewhere safe. A syntax mistake in .htaccess, particularly a stray character inside the WordPress rewrite block, can produce a 500 error across the entire site until it is fixed.
Assuming a CDN or caching layer reflects the change immediately. Cloudflare, a page cache plugin, or your host’s own edge cache can all serve a stale, previously-indexed version of a folder listing for minutes to hours after the server-side fix is live. Purge cache at every layer before concluding the fix did not work.
Confusing this with file permission hardening. Disabling directory indexing stops casual browsing of folder contents. It does nothing to stop a script that already knows the exact file path from requesting it directly. These are two different layers of protection, and a full security posture needs both: indexing off, and sensitive files (backups, config exports, log files) kept out of any web-accessible directory entirely.
Confirming the Fix Across Your Whole Site
A single test on one folder is not proof the setting applies everywhere. Check a handful of different locations: an uploads subfolder, a plugin directory, a theme directory, and if you have one, any custom uploads path a form plugin or backup tool writes to. Some server configurations apply Options -Indexes only to the directory the .htaccess file lives in without inheriting it into subdirectories properly, depending on server version and configuration inheritance rules, so a spot check across a few different paths is worth the extra five minutes.
Where a Security Scan Fits Into This
If you run periodic security scans through Wordfence, Sucuri’s SiteCheck, or an external tool like Qualys or Detectify, directory listing is one of the standard checks most of them run automatically, usually reported as an informational or low-severity finding rather than a critical one. Do not let the low severity rating lead you to deprioritize it. Scanners rate it low because the presence of an open directory alone is not a breach; what matters is what happens to be sitting inside the folder at the time someone finds it, and that is impossible for an automated scanner to know in advance. Treat any directory-listing finding as worth fixing immediately regardless of the severity label attached to it, and use the scan as a prompt to also audit what files currently live in your uploads and backup folders, since the scan will not tell you that part.
It is worth building this into a recurring habit rather than a one-time fix. Add a quarterly check to whatever maintenance routine you already run for updates and backups: pick three or four folder paths, run the curl test against each, and glance through your uploads directory for anything that should not still be sitting there. A backup file created for a one-off migration two years ago rarely gets remembered unless something prompts you to look.
Frequently Asked Questions
Is disabling directory indexing absolutely necessary?
It is not mandatory for a site to function, but it is a low-effort, zero-downside change that closes off a real information-disclosure risk. There is essentially no legitimate reason for visitors to browse raw folder contents on a production WordPress site, so there is no tradeoff to weigh here.
Does disabling directory indexing affect SEO?
No. Search engines index your published pages and posts through your sitemap and internal links, not by crawling raw folder listings. Disabling indexing has no measurable effect on rankings either way.
Can disabling directory indexing break anything on my site?
Very rarely, and only if something on your site intentionally relies on a folder listing being visible, which is unusual for a standard WordPress install. If a specific feature stops working after the change, check whether it was silently depending on a browsable directory (some very old gallery plugins did this), and if so, that plugin needs a proper fix rather than continuing to rely on an insecure server behavior.
How do I know if my host already disabled this for me?
Run the curl test described earlier against a folder you know lacks an index file. A 403 or 301 response means it is already handled. Many managed WordPress hosts disable indexing platform-wide, which is why some site owners never encounter this issue at all.
Will a security plugin alone fix this without touching .htaccess?
Most security plugin toggles for this feature work by writing the same .htaccess directive on your behalf, so functionally it is the same fix delivered through a UI instead of manual file editing. If your host runs Nginx, though, a plugin’s .htaccess-based toggle will do nothing, since Nginx ignores .htaccess entirely; you will need the server-block edit described above or a request to your host.
Should I check for open directories on subdomains too?
Yes, and this is easy to overlook. A staging subdomain, an API subdomain, or a secondary microsite hosted on the same account can each have their own server configuration and their own .htaccess file, meaning fixing the main site does not automatically fix a subdomain running as a separate vhost. Run the same curl check against every subdomain you control.
Closing the Gap Quietly
This is a fifteen-minute fix on most hosting setups, and unlike a lot of WordPress hardening advice, it carries no downside to weigh against the benefit. Confirm your current state with a direct request rather than guessing, apply the directive that matches your server software, purge every cache layer in front of the site, and check a few different folders rather than just the one you tested first. Then move sensitive files, backups especially, out of the web root entirely so a browsable folder was never the only thing standing between them and the public internet.
