WordPress shows “Index of /”: remove the file listing and restore the homepage

Identify a directory listing in place of the homepage

Your domain displays “Index of /” or a page listing files and folders instead of WordPress. The server is producing a directory listing, often because it cannot find the intended index file or does not select it. This result does not automatically mean that posts have been deleted from the database.

The goal has two parts: stop exposing the listing, then recover the site’s correct entry file. Disabling the listing may produce a 403 page while the index is missing; this contains the symptom but does not yet repair the homepage. Next check the domain, its root, and the file that should start WordPress.

These operations require the domain panel, file access, or help from the server administrator. They do not begin by installing a WordPress plugin, because the server may produce the listing before running WordPress. On WordPress.com or fully managed hosting, give the provider the exact address. In multisite, identify the affected domain and directory before changing shared configuration.

Keep limited evidence and protect private files

Record the exact address, time, and directory names useful for diagnosis. Do not share a full screenshot if it shows archives, logs, or private identifiers. Do not open listed files to test their contents. The visible listing and domain settings are enough to begin checking.

If backups or private files are in this public directory, have the administrator contain access to them and preserve the originals in an appropriate private location. Removing automatic indexing does not necessarily prevent downloading a file whose address is known. This distinction matters when sensitive documents were stored in the wrong place.

Before changing the root or an entry file, keep a copy of the current configuration and affected files outside the public directory. Prepare access that allows rollback if the homepage remains inaccessible. Any temporary protection must apply to the correct scope, accounting for other services using the domain. Do not erase the displayed directories to make the listing disappear.

Check whether the listing affects the homepage or a secondary directory

Compare the requested address with the intended homepage address. A listing in /uploads/ or a file directory is not the same failure as a listing at the domain root. The first case mainly calls for managing publication of that directory; the second also requires finding the site’s entry point.

In the panel, record the document root associated with the domain. Then, in the file manager, check which directory actually corresponds to this root and which index files exist there. WordPress installed in another directory will not be found simply because its database is accessible.

1. Record the domain, protocol, and full path of the address listing files.
2. Compare it with the expected homepage without assuming that every subdomain shares its root.
3. Identify the served directory in the domain panel.
4. Examine its entry files without overwriting them.
5. Then choose between correcting the root, recovering a missing index, and configuring index selection.

Disable the directory listing in cPanel when the tool is available

This first approach contains automatic listing without installing a plugin. In cPanel, open Advanced, then Indexes. If the tool is absent, ask the host whether it is enabled: availability depends on the account configuration. Do not automatically choose the home directory as the scope of the change.

Keep the current option, then choose No Indexing for the affected directory. The tool may show an access-denied response instead of the listing if no index is available. That is the expected result for this protection step, but the homepage still needs repair if this is the site’s directory.

1. In Indexes, open Settings if necessary, choose Document Root for and the relevant domain, then Save Changes to begin browsing at its root.
2. Navigate to the exact directory producing the listing. Click Edit in its Actions column and record the initial option.
3. Choose No Indexing, then Save. Check that the Index Type column reflects this choice for the correct directory.
4. Reload the address in a new request and check that the listing is gone. A homepage now returning 403 still needs index repair.
5. If the setting does not apply, have the layer actually serving the domain checked without adding changes to other directories.

Check existing files without replacing them all

In the file manager or through SFTP, examine the confirmed document root. Check whether index.php exists, its size, date, and contents in a private copy. An empty, absent, or replacement file from another product is not handled like a simple index-priority issue.

WordPress may have an entry file adapted to a particular installation. The public root may call core located elsewhere. Therefore do not replace every file named index.php with the one from a downloaded archive. Small index files in some subdirectories do not all serve to launch the homepage.

If an administrator-proposed visit to index.php returns PHP code or triggers a download, stop public tests and have PHP execution addressed. Index selection is not enough in that case. If the file is correct and executes normally but the directory address still produces a listing, the server’s index priority or mechanism becomes the main lead. Keep these two results separate.

Correct the document root when the domain targets the wrong directory

This approach is appropriate if the panel shows a root different from the site’s intended public directory. In cPanel, open Domains and look at Document Root on the domain’s row. The link opens the directory in the file manager; Manage opens its settings. The main domain’s root and roots of domains sharing it cannot be changed through this procedure. A managed plan may also require the provider’s involvement.

Keep the initial path and have the new directory confirmed against the site architecture. Do not point the domain at a private directory containing configuration or backups. Changing the root is not equivalent to moving every file; an existing public directory may simply be incorrectly associated with the domain.

On the management screen, New Document Root expects a path relative to the account’s home directory. Check the resulting path shown by the panel and have it confirmed if the prefix seems ambiguous. Do not copy a web address or an absolute path taken from another server. You do not need to delete the domain or change its DNS or email services.

1. In Domains, identify the exact domain and its current root.
2. Use Manage if the account permits the corresponding change.
3. In New Document Root, enter the confirmed public directory in the expected format, then click Update. This changes the association; it does not move files.
4. Check the homepage, then an internal page and administration.
5. If an error occurs or the wrong site is affected, restore the initial path and have the association corrected with the administrator.

Restore the missing entry file from an appropriate source

If the root is correct but the entry file is missing, first look for a reliable copy matching this installation. A site backup may preserve its path adaptation. For a standard WordPress installation without adaptations, the official file from the same version is the reference to compare. Obtain that version from the maintenance inventory; if necessary, the administrator can read the version value in a private copy of wp-includes/version.php without running a public diagnostic file. Keep existing files before any replacement.

Obtain the archive from WordPress.org or the validated private backup, then extract it locally. Identify only the necessary file. Do not transfer the entire archive to production to solve a missing index, and do not replace wp-config.php or wp-content. Targeted recovery must preserve site content and configuration.

1. Confirm that the file is actually missing from the served root.
2. Choose a reliable source matching the installation’s version and architecture.
3. Compare the entry file with the expected adaptation before transfer.
4. Restore only this file through authorized access, with appropriate permissions.
5. Check the homepage and keep the initial copy so you can return to the previous state if the hypothesis was wrong.

Correct Apache index selection in the authorized context

With Apache confirmed, DirectoryIndex determines the files searched for at a directory address. The example is suitable if this line replaces the effective definition for the affected directory. Multiple DirectoryIndex directives at the same level append their names to the existing list: pasting a new line at the end therefore does not guarantee priority for index.php. Have the existing definition corrected instead of multiplying rules.

The .htaccess file is usable only if these directives are permitted there. DirectoryIndex depends in particular on the Indexes category; permission for Options must be checked separately. If all overrides are disabled, this file may be ignored. Do not request globally enabling all overrides for this single need; the administrator will choose a limited setting or server configuration.

Options -Indexes removes only the automatic listing option, retaining other applicable options. It does not protect each file from a direct address. The correct index must exist and PHP must already execute correctly. Preserve redirect and security rules unrelated to this fix.

1. Privately back up the relevant configuration or .htaccess file.
2. Have the directory, directive inheritance, and permissions confirmed; correct the single relevant definition.
3. For server configuration, use apachectl configtest in the service’s context before the operations team applies it.
4. For .htaccess, also check a new request to the directory and the private error log: this file is read at request time, and checking the main configuration is insufficient to validate it.
5. If an error appears, restore only the faulty definition. A .htaccess edit may take effect without reloading; retain listing protection when necessary.

DirectoryIndex index.php index.html
Options -Indexes

Correct the Nginx index without replacing PHP handling

With Nginx, the index directive selects files in the specified order. The fragment below belongs in the site’s effective context, in http, server, or location according to its configuration. Selecting an index may produce an internal redirect and select another location block. Rules forwarding PHP to the engine must therefore be preserved; adding index.php is not enough to execute it.

autoindex is disabled by default. A visible listing requires finding where it was enabled, or which other layer is producing the response. autoindex off prevents listing within its scope, subject to more specific effective configuration. Do not add this fragment to .htaccess, which Nginx does not process like Apache. Panel-generated configuration must be changed through its durable mechanism.

1. Keep the active configuration and identify the homepage context.
2. Correct the index definition without deleting existing PHP rules.
3. Check with nginx -t using the relevant service’s binary, permissions, and configuration file. This check also verifies that referenced files can be opened; fix its errors before applying anything.
4. After success, apply through the operational procedure; a standard installation may use nginx -s reload.
5. If the result is incorrect, restore the previous definition, check it, then apply the rollback.

index index.php index.html;
autoindex off;

Apply changes to the correct server and retain a rollback

A panel, proxy, and several servers may serve the same domain. Check that the change affects the one responding to the observed address. An old cached copy may also show a listing after the origin has already been fixed. The comparison must rely on configuration and logs from the same request.

For a server-configuration edit, a successful syntax check does not automatically load the new setting. The administrator then applies the method intended for the service. On a standard Apache installation, a successful check may be followed by apachectl graceful with the same permissions and context. A panel may control another procedure that should be retained.

Keep separate ways to restore the initial root, index, or configuration. Do not restore a public listing merely to reproduce evidence if private exposure was identified. Rolling back a diagnostic setting must not undo a necessary protective measure. Record what was fixed and what remains temporary so the next person does not confuse them.

Avoid a plugin that would act too late in the request path

A directory listing may be generated without WordPress starting. Installing a security plugin in administration therefore does not guarantee that it will change this server response. It does not automatically choose the domain’s document root or recreate a missing entry file. The panel or server configuration remains the appropriate route for this symptom.

If an existing tool manages an index rule, identify its mechanism and owner before editing the file it produces. A manual change may be overwritten the next time its settings are saved. Conversely, deleting the entire rules file to test the index may remove useful redirects or protections.

Do not add an empty index.php at the root and consider the site repaired either. It may hide the listing while leaving a blank homepage. Protective index files in some subdirectories are not WordPress’s front controller. The expected result remains the correct site rendering, with automatic indexing removed wherever it should not be public.

Check the homepage, internal pages, and affected directories

After the fix, open the homepage in a new request and confirm its contents, not just HTTP status 200. Test an internal page and administration to verify that the root and entry file correspond to the same installation. Check the domain with and without the expected subdomain if those addresses are part of normal use.

Then revisit the exact address that displayed the listing. A directory without an index that is intended to remain unlistable may legitimately return 403. The homepage directory must serve the intended site. If private files were misplaced, check their protection with the administrator; a hidden listing alone does not establish that they are inaccessible by direct address.

Keep a record of useful changes and remove test settings that brought no benefit. If the homepage is restored but internal pages fail, handle navigation rules separately. Do not change the working entry file again without evidence related to this new symptom. The repair is validated when responses match each address’s intended use.

Prevent automatic indexing from returning after deployment

Document the domain’s public directory, entry file, and configuration selecting that index. During a transfer or deployment, check these three elements before opening the site. An archive copied at the wrong directory level may leave the root without an index even though all files appear present in the account.

Keep private backups and logs outside the published directory, with their independent access procedure. Do not use disabled listing as the sole protection for a sensitive document. Also check inherited settings when a new subdirectory is intended to serve files or host a test copy.

For technical help, provide the address, time, recorded document root, and names of existing index files, with private data masked. Specify what the homepage returns after disabling the listing and which change was applied. This record distinguishes a wrong directory, missing file, and incorrect selection rule without erasing all content or repeating an unnecessary installation.

Interpret the three successive repair results correctly

On a private test domain, an exercise can distinguish three states. Do not deliberately reproduce a public listing in production to obtain a screenshot.

To document each state, keep the redacted address, time, status, and a short description of the contents. Do not photograph real backup or account names. Rollback concerns the incorrect root or index change, not restoring file exposure. No plugin is required for this procedure: the server must be corrected at the level producing its response.

1. File listing: the directory address returns an inventory. Note the directory actually served and whether the index exists. This observation does not tell you whether PHP works.
2. 403 after removing the listing: the server no longer lists the directory, but it does not yet serve the homepage. For a file directory with no intended index, this may be correct; for the site root, repair must continue.
3. WordPress homepage after fixing the entry point: verify the expected contents, an internal page, and administration. An empty index.php could produce a 200 without a site; status alone is not enough.