Fix 'Index of /' Showing Instead of Your Website

A customer wrote in this week panicking because their homepage had turned into a plain list of filenames — no theme, no logo, just "Index of /" and a bunch of clickable file links. Nothing had been deleted, no hack, no DNS change. It's one of the most common "my site is broken" tickets we get, and the fix is usually a two-minute job once you know where to look.

What "Index of /" Actually Means

When a browser requests a folder (like https://example.com/) instead of a specific file, the web server looks for a default file to serve — usually index.html, index.php, or similar. If it can't find one, and directory listing is turned on, it falls back to showing you the raw contents of that folder instead. That's the ugly file list you're seeing. It's not a hack and it's not data loss; the server is just telling you "I have nothing to serve here automatically, so here's what's in the folder."

Common Causes

1. No index file in the directory

The most common cause by far. Your index.html or index.php got renamed, moved, or never uploaded to the right folder in the first place. This happens a lot right after a migration or a fresh cpanel" class="auto-link">WordPress install where the files landed one directory level off.

2. Wrong document root or addon domain path

If you just added an addon domain in cPanel, double-check where it actually points. It's easy to create the addon domain, then upload your site files to public_html instead of public_html/yourdomain.com (or vice versa), leaving the real document root empty.

3. DirectoryIndex directive missing or overridden

Apache decides which filenames count as an "index" via the DirectoryIndex directive. If a plugin, a bad deployment script, or a stray .htaccess edit wipes that out, Apache no longer knows to look for index.php first.

4. Directory listing (autoindex) is explicitly turned on

Sometimes this is intentional — a developer enabled it temporarily on a staging folder to browse files easily, then forgot to turn it back off before pointing the domain live.

5. Broken or overwritten .htaccess file

WordPress, and many frameworks, rely on .htaccess for routing. If it's deleted, corrupted, or replaced by a backup/restore tool with the wrong version, the fallback behavior can change and expose the raw folder in edge cases (especially with addon domains and multiple index candidates).

How to Fix It in cPanel (Apache / LiteSpeed)

1. Open File Manager and navigate to the actual document root for the domain (check Domains in cPanel to confirm the exact path if you're not sure — addon domains are easy to get wrong).
2. Confirm an index.php or index.html file exists directly inside that folder, not nested one level deeper in a subfolder.
3. If the file is missing, restore it from a backup, or re-upload it if you have a local copy.
4. Check for a .htaccess file in the same folder. If it's missing on a WordPress site, log in to wp-admin > Settings > Permalinks and click Save Changes — WordPress will regenerate it automatically.
5. If listing is still showing, add this to the top of your .htaccess file to explicitly disable it and set the index order:

Options -Indexes
DirectoryIndex index.php index.html

6. Save, then reload the site in a private/incognito window to rule out a cached page.

How to Fix It on an Nginx VPS

Nginx uses its own autoindex and index directives inside the server block, usually in /etc/nginx/sites-available/yourdomain.conf or a similar config file. Check for something like this:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public;
    index index.php index.html;
    autoindex off;
}

If autoindex on; is present, either remove the line entirely or set it to off. If the index line is missing, add it with the correct filenames for your app. After editing, always test the config before reloading:

sudo nginx -t
sudo systemctl reload nginx

Skipping the nginx -t test is how a small typo turns into a site-wide outage instead of a quick fix — it catches syntax errors before they hit production.

A Quick Sanity Check Before You Touch Config

Prevention

• After any migration or addon domain setup, load the live URL immediately — don't wait for a customer to tell you it's broken.
• Keep Options -Indexes in your base .htaccess template for new sites so a missing index file fails safely instead of exposing your folder structure.
• If you use a staging subfolder with directory listing on for convenience, password-protect it (cPanel > Directory Privacy) rather than leaving it open on a live domain.
• Back up .htaccess and your Nginx server blocks separately from your database backups — they're small, easy to version, and painful to lose.
• Run a quick file listing (ls -la over SSH, or File Manager's list view) after any restore to confirm the index file actually made it into the right folder.

Frequently Asked Questions

Is "Index of /" a sign my site was hacked?

Almost never. It's a server configuration state, not an intrusion symptom. If you also see unfamiliar files, altered permissions, or new admin accounts in that listing, treat it as a possible compromise and investigate further — but on its own, a plain directory listing is a missing-index-file issue, not malware.

Why does this only happen on my addon domain, not my main domain?

Addon domains get their own document root folder inside public_html. It's easy to upload files to the wrong level — either directly into public_html or one folder too deep inside the addon domain's directory. Check cPanel > Domains to see the exact path cPanel expects, then match your upload location to it.

I added Options -Indexes but I'm getting a 500 error instead now.

That usually means mod_rewrite or the Options directive isn't allowed to be overridden at the server level for your account, or there's a duplicate Options line further down the file conflicting with it. Remove any duplicate Options lines in the same .htaccess and keep only one, or ask your host to confirm AllowOverride is enabled for that directory.

Can I just leave directory listing on for a folder I use to share files?

You can, but it's a habit worth breaking. An open listing makes it trivial for anyone to browse every filename in that folder, including things you didn't mean to expose, like old backup archives or config files. Password-protect the folder instead, or disable listing and share direct links to the specific files people need.

Does this affect my SSL certificate or SEO?

Not directly, but an exposed directory listing sitting where your homepage should be will tank your rankings fast since Google sees a folder of filenames instead of actual content. Fix the index issue and your existing SSL setup and SEO signals are unaffected once the real page loads again.