How to fix an "Index of /" page

Instead of your homepage, the browser shows a plain, unstyled list: file names, folder names, sizes, dates, nothing else. This is called a directory listing, and it is what a web server falls back to showing when a visitor requests a folder and the server cannot find any of the files it's configured to treat as that folder's homepage — no index.html, no index.php, nothing matching.

It is a fallback behaviour, not an error as such. The server did exactly what it's told to do when there's genuinely nothing else to show.

The usual causes, in order

1. There is no index file in the folder

The single most common reason. Check the folder — usually public_html, or a subfolder if your site lives in one — for a file literally named index.php, index.html, or occasionally index.htm. If none of those exist, the server has nothing to load automatically and falls back to listing what is there instead.

This happens most often straight after an upload or a migration that didn't fully complete — the bulk of the site's files transferred, but the index file itself was missed, renamed, or is still sitting in the wrong folder.

2. The index file exists but has the wrong name or case

Servers are case-sensitive on Linux, which is what almost all web hosting runs. A file named Index.php or INDEX.HTML will not be recognised as the folder's index, even though it looks correct to the eye in a file manager. Check the exact spelling and capitalisation of the file against what the server expects — lowercase, exactly index.

3. The index file is in the wrong folder

If your site's files were uploaded into a subfolder inside public_html rather than directly into it — a common mistake when unzipping an archive that itself contains a folder — the index file exists, but not in the folder the domain actually points at. Check whether your site's files are sitting one level deeper than they should be, and move them up if so.

4. Directory listing was left switched on where it shouldn't be

Even with an index file missing, a well-configured server can be told to show a permission error instead of a file listing. Add this line to the .htaccess file in the affected folder to disable listings outright:

Options -Indexes

This doesn't fix the missing index file, but it does stop the folder's contents being exposed to visitors while you sort out the underlying cause — which matters, because a listing shows every file name in that folder, including ones that were never meant to be public.

5. A recent change to .htaccess removed the default document setting

Some setups rely on an explicit DirectoryIndex directive to define which file counts as the index for that folder:

DirectoryIndex index.php index.html

If a recent edit to .htaccess removed or altered this line, the server may no longer recognise a perfectly normal index file. Check for this directive if the index file is confirmed present, correctly named, and in the right folder, and the listing still appears.

Putting it right, step by step

1. Open the file manager in your control panel

   Navigate to the folder the domain points at — typically public_html for the main site, or a subfolder for an addon domain.

2. Confirm an index file is present, correctly named, and lowercase

   Look specifically for index.php or index.html sitting directly in that folder, not nested inside another folder.

3. If it's missing, restore or re-upload it

   From a backup if you have one, or by re-uploading the site's files, making sure the index file lands in the correct top-level folder rather than a subfolder created by an unzipped archive.

4. Add Options -Indexes to .htaccess as a safety net

   This stops the folder's contents being listed even if an index file goes missing again in future, replacing it with a permission error instead.

If the site is WordPress and this has just appeared

Confirm that WordPress's own index.php — the one that comes with every WordPress installation — hasn't been deleted or renamed, and that the site's files weren't accidentally uploaded one folder too deep. This is a common outcome of a migration or restore where an archive was extracted and its contents uploaded without checking the resulting folder structure first.

Still seeing it after all of that

Send support the exact URL showing the listing and, if you can, a note on what changed most recently — a migration, a restore, a manual upload. That narrows it down to one of the causes above almost immediately, usually without needing back-and-forth.