Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Direct answer: add autoindex off; to the NGINX configuration serving your WordPress site, then test and reload NGINX. The directive is valid in http, server, and location contexts, and NGINX documents off as its default. Put it in the active NGINX configuration—not in WordPress and not in an Apache-style .htaccess file.
For a whole WordPress virtual host, place it in the relevant server {} block. If only one path, such as /wp-content/uploads/, should be covered, place it in that path’s location {} block. Afterward, request a directory that has no index file: a generated file list should disappear, while a 403, 404, or application response may be normal depending on the rest of your configuration.
What directory browsing means on a WordPress LEMP server
A LEMP deployment serves WordPress through Linux, NGINX, a MySQL-compatible database, and PHP-FPM. NGINX handles static files and forwards PHP requests to PHP-FPM. When a browser requests a URL ending in a slash, NGINX treats it as a directory request and checks the filenames listed by its index directive.
A typical WordPress server block uses index index.php index.html;. If one of those files exists in the requested directory, NGINX serves it or passes the PHP file to PHP-FPM. If no index file exists and directory indexing has been enabled with autoindex on;, NGINX creates an HTML listing of the directory contents. That list can reveal upload names, backup archives, generated assets, or other implementation details.
#1 Best Overall
With autoindex off;, NGINX does not generate that listing. It does not remove files, make files private, alter WordPress permissions, or prevent a visitor who already knows a file’s URL from requesting it. Those are separate controls.
Where the setting belongs
Standalone NGINX has no directory-level configuration file equivalent to Apache’s .htaccess or IIS’s web.config. WordPress cannot automatically change the NGINX configuration. An administrator with access to the NGINX service must edit the enabled site configuration or an included file that owns the affected block.
Recommended Free Tools
| Context | Effective scope | When to use it |
|---|---|---|
http |
All virtual hosts handled by that NGINX instance | Use only when every site should follow the same policy. |
server |
One virtual host, identified by its server_name |
The usual choice for a WordPress site whose directories should never produce listings. |
location |
One URL path or matching location | Use when the rule is limited to a path such as /wp-content/uploads/. |
NGINX applies the most specific applicable configuration. A server-level value can therefore be affected by a more-specific location or by another included file. Always inspect the effective configuration if the result does not match the file you edited.
Before editing the configuration
Confirm that NGINX is the component returning the listing
Open the affected URL and inspect the response and page styling. NGINX’s autoindex output is a plain generated directory page, while a WordPress plugin, a hosting control panel, a reverse proxy, or an object-storage service may generate a different response. If another layer owns the URL, changing the WordPress server block will not change that layer.
Find the active virtual-host file
Locate the enabled NGINX site file for the domain and check its root, server_name, and location blocks. Some distributions keep per-site files in an enabled-sites directory; others use a single configuration file and include directories. The filename is not important—the loaded configuration is.
Back up before making the change
Copy the active file, or otherwise create a versioned backup, before editing. A one-line directive is low risk, but a missing brace, semicolon, or include can prevent NGINX from reloading. Keep the backup available until normal WordPress pages and uploads have been tested.
Apply autoindex off; to the whole WordPress site
For a site-wide policy, add the directive inside the matching server {} block. This example shows the placement and the surrounding WordPress routing pattern; replace the domain, document root, include files, and PHP-FPM socket with the values used by your host.
server {
server_name example.com;
root /var/www/example.com/public;
index index.php index.html;
autoindex off;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}The important line is autoindex off;. The try_files rule preserves the normal WordPress permalink fallback, and the PHP block is shown so you can recognize the correct server block; neither is a substitute for the directory-listing setting.
Do not put the directive in the PHP location by accident
A PHP location handles requests matching PHP filenames. A directory URL such as /wp-content/uploads/ is normally processed by the prefix location or by the server-level configuration. Putting the directive only in a PHP location can leave directory requests unaffected.
Apply the rule only to a specific path
If you want a narrow policy, add a location block for the path that should never show an index. For example:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11location /wp-content/uploads/ {
autoindex off;
}Keep the trailing slash in the location and make sure the block is in the same virtual host that serves the files. A path-specific block is useful when another directory intentionally provides a listing, but it also requires more careful review of NGINX’s location matching and any existing rules for aliases, caching, authentication, or access denial.
If the server-level rule already says autoindex off;, adding the location-level line is usually unnecessary. Use the narrower block when you are deliberately documenting or enforcing a different scope, not merely because the setting appears in two places.
Validate and reload NGINX safely
- Save the edited file. Check that the directive ends with a semicolon and that the surrounding braces remain balanced.
- Run the platform’s NGINX configuration test. The commonly available command is
nginx -t, but use the command and configuration path required by your distribution or hosting panel. A successful test should report that the syntax is valid and the test is successful. - Fix every reported error before reloading. Do not reload a configuration that has an unknown directive, an invalid include, a bad certificate path, or an unmatched brace. Restore the backup if necessary.
- Reload through the normal service manager. Many Linux systems use a service-manager reload for NGINX; managed platforms may provide a control-panel action instead. Reloading applies the new configuration without intentionally stopping active worker processes.
- Record what changed. Note the file, context, and time of the change so a later administrator can identify the policy and roll it back if a separate location needs different behavior.
The exact test and reload command depends on the Linux distribution, service manager, container layout, and whether a hosting platform controls NGINX. Do not assume a command that works on one server is valid on another.
Verify that the listing is gone
Test a directory that genuinely has no configured index file. A directory containing index.html or index.php will serve that file and is not a useful test of autoindex behavior.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Choose a non-sensitive test directory under the site’s document root, or use an existing directory only if you understand its contents.
- Request its slash-terminated URL in a private browser window so a cached page does not mislead you. A command-line HTTP request can also show the status and response body.
- Confirm that the response contains no generated table or file-name list from NGINX. An application-generated page, a 403, or a 404 can all be expected outcomes depending on your other rules.
- Request a normal WordPress permalink and confirm that it still reaches WordPress rather than returning an unexpected 404.
- Request a representative upload URL and confirm that legitimate media still loads. The directory-listing change should not make ordinary static files unavailable.
- Repeat the test through the public hostname and scheme that visitors use if a reverse proxy or CDN sits in front of NGINX.
How NGINX decides what to return
An index file exists
For a slash-terminated directory request, NGINX checks the names configured by index. In a WordPress server block, index.php is commonly included. The request may therefore enter WordPress even though no directory list is generated.
No index file exists and autoindex is off
NGINX does not build a listing. Depending on the rest of the configuration, it can return an error such as 404, an access-control response such as 403, or pass the request to an application rule. The important security result is that the web server does not disclose a generated directory inventory.
Autoindex is explicitly enabled
autoindex on; intentionally enables generated directory output. If you still see a listing after adding off, another applicable configuration may be enabling it, the request may be reaching a different virtual host, or the page may be produced by a component other than NGINX.
Troubleshoot a listing that remains visible
The edited file is not loaded
It is common to edit a file that looks like a site configuration but is not included by the running NGINX instance. Inspect the full effective configuration with the administrative tooling available on your platform and search for the domain, the affected path, and every occurrence of autoindex. Check symbolic links or enabled-site mechanisms where applicable.
The request reaches a different server block
Verify the hostname, port, and protocol used for the test. A default server, an HTTP-to-HTTPS redirect target, an IPv6 listener, or a separate staging virtual host can have a different root and policy. Test the exact public URL and compare its response headers with the server block you changed.
A more-specific location changes the result
Review prefix and regular-expression locations for the path. An included location can set autoindex on;, use an alias, or route the request to an upstream service. Put the policy in the location that actually handles the request, or remove the conflicting setting when a listing is not intentional.
The page is generated by an application or proxy
Some file managers, development tools, reverse proxies, and storage services generate their own indexes. NGINX’s autoindex off; cannot suppress a page that another component creates after NGINX forwards the request. Identify the component from response headers, logs, and the request path, then apply its own access-control setting.
A browser or intermediary is serving cached content
Use a private window and make a fresh request. If a CDN or reverse proxy caches the directory response, purge or revalidate that cache according to its operating procedure after the NGINX reload. Do not treat a cached old listing as proof that the active server still has autoindex enabled.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →The configuration reload never succeeded
Check the service status and error log after the reload attempt. A syntax-test failure, a permission problem reading an include, or a service-manager error leaves the previous configuration running. Correct the underlying error, test again, and then reload.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Do not confuse directory-listing control with file protection
Turning off autoindex prevents one form of disclosure. It does not make the files in a directory inaccessible. Anyone who knows or guesses a public URL may still retrieve a readable file, and a writable web directory can still be abused if other protections are weak.
Review ownership and permissions
WordPress hardening guidance treats filesystem ownership, write permissions, and writable application paths as separate concerns. Ensure that only the processes that need to write uploads, cache files, or updates can do so, and that sensitive configuration and backup files are not publicly readable.
Protect hidden files and private artifacts
Review rules for hidden files, deployment metadata, logs, archives, and temporary files. A hidden filename is not a security boundary. If your deployment uses a general hidden-file denial rule, preserve deliberate exceptions required for validation services and test it against the site’s actual files.
Free tools Windows power users keep installed
One-click scans. No signup required.
Prevent PHP execution in uploads where appropriate
WordPress media uploads are normally static content. Many administrators add a dedicated NGINX rule that denies PHP execution under /wp-content/uploads/. The exact expression must match your server’s existing PHP locations and any application that legitimately needs scripts there; test it before deployment. A typical pattern to adapt is:
location ~* ^/wp-content/uploads/.*.php$ {
deny all;
}This example addresses execution, not browsing. Keep both controls if both risks apply, and review location precedence so the PHP handler cannot override the denial.
Choose the right scope for your deployment
| Decision | Server-level policy | Path-level policy |
|---|---|---|
| Coverage | All directories handled by one WordPress virtual host | Only the selected URL location |
| Maintenance | One setting to review when the site grows | More locations to audit as paths and includes change |
| Best fit | Sites that never need generated directory indexes | Deployments with a deliberate exception or a separately managed path |
| Main risk | Accidentally affecting a legacy path that relied on listings | Leaving another directory exposed or missing a more-specific location |
For an ordinary WordPress site, the server-level setting is the simpler default. Choose a location-level rule when the scope is genuinely limited and document the reason in the configuration or deployment notes.
What to do when you lack NGINX access
On managed WordPress hosting, shared hosting, or a platform where the web server is controlled by an administrator, you may not be able to edit the server block. WordPress cannot add autoindex off; through its dashboard. Ask the host or administrator to disable directory indexing for the relevant virtual host or path, identify the effective configuration they changed, and request a test of a directory with no index file.
If the provider offers only a control panel, use its documented NGINX or web-server settings rather than uploading an .htaccess file and expecting it to work. An Apache directive such as Options -Indexes does not configure standalone NGINX.
Production checklist
- Identify the component generating the directory page.
- Find the active NGINX virtual host and the location handling the path.
- Back up the configuration before editing.
- Add
autoindex off;at the server level or in the intentionally narrow location. - Inspect included files for a conflicting
autoindex on;. - Run the platform’s NGINX syntax test and resolve all errors.
- Reload NGINX through the platform’s supported service manager.
- Request a directory with no
index.htmlorindex.phpand confirm that no generated listing appears. - Test a normal permalink, an upload URL, and any reverse-proxy or CDN path used by visitors.
- Separately review permissions, sensitive-file exposure, hidden files, and PHP execution in uploads.
Key takeaway
autoindex off; is the NGINX control that stops automatically generated directory listings. Place it in the configuration that actually serves the WordPress request, validate the complete effective configuration, reload safely, and verify both the directory behavior and normal WordPress routing. Treat permissions and upload execution as additional hardening work rather than assuming the directive solves those problems.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
