---
title: "My site returns 404 at the root"
description: "Pages work but the site's own address 404s. Three causes, and the deploy reply almost certainly named yours already."
canonical: "https://help.sitesmojo.com/kb/troubleshooting/site-404-at-root/"
---

Your pages load, but the site's own address returns a 404. Three causes, in
order of likelihood.

## 1. The bundle has no root `index.html`

A static site serves what you shipped. Nothing generates a home page for a site
with no mounted books, so `/` has nothing to answer with.

The deploy reply told you this — it carries a warning reading roughly *no
index.html at the bundle root — the site will 404 at /*. Deploy again with an
`index.html` at the root of the bundle, not inside a subfolder.

## 2. The site is suspended

A suspended site does not serve, and deploying to it does not change that. The
revision is stored and queued and waits.

The deploy reply says so plainly: *site is suspended — this revision will not
serve until it is resumed*. **A queued deploy on a suspended site is not a live
site.** Resume it, and the live revision starts serving within one worker sweep.

## 3. The mounts are there but the front door is not

A mount is never at the site root. If your bundle ships no root `index.html`,
one is **generated** for you: a zero-second redirect to the first mount, in
mount-path order.

If you are getting a 404 instead of that redirect, either the bundle *does*
contain a root `index.html` that is broken or empty — yours always wins over the
generated one — or the mounts were removed, in which case the generated front
door disappears on the next deploy and `/` falls to the styled 404.

## Diagnosing it properly

- **Re-read the deploy reply.** `warnings` names the problem in a sentence.
  `docit.generated` lists exactly which files were added for you.
- **Check the paths you sent.** They must be relative and plain: no leading
  slash, no `..`, no backslashes. `/index.html` is not a valid bundle path.
- **Load the URL yourself** rather than trusting the reply. A deploy reply
  reports bytes, not pixels — it cannot tell you whether the page renders.

## Not this

A file that was dropped at the bundle caps is disclosed by name in the deploy
reply's `skipped` record. If your root `index.html` is not listed there, the caps
are not your problem.