My site returns 404 at the 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.
warningsnames the problem in a sentence.
docit.generatedlists 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.htmlis 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.