A static website can look complete when you navigate from its homepage and still return a 404 when someone opens a nested link directly. Start by comparing the requested URL with the finished files and the hosting route rules. A working browser navigation does not prove the server can deliver that same address on a fresh request.
Use the route test worksheet to record direct visits, refreshes, expected content and actual status. The example below is an original synthetic test case, not a report about your deployment. Run the static site preflight checker on your own exported folder before changing hosting rules.
Separate three kinds of failure
A missing file, an incorrect route mapping and a client-side application route require different repairs. First check whether the finished output contains the requested page. Source components alone are not deployed HTML. A folder containing a React project is not necessarily the output of its build.
Next ask what the host is supposed to serve. A page exported as about.html might use a different public address from about/index.html. Some hosts supply clean URLs automatically; others need explicit configuration. Check the active project's current behavior rather than assuming another host's convention applies.
Finally, determine whether the browser is rendering an application route after the homepage loads. If it is, direct navigation may require a fallback to the application's entry point. That fallback belongs to the application routing contract. It is not a universal fix for a genuinely missing article.
Work through an original route matrix
Consider a finished example folder containing index.html, about/index.html and images/logo.png. Its intended routes are the homepage and /about/. The following outcomes locate different problems:
- The homepage returns 200 and shows the intended product: the root document is available.
- /about/ returns 404 despite the exported file existing: inspect upload completeness, case and the route mapping.
- /About/ returns 404 while /about/ works: the link may have the wrong case; fix the link to the intended address.
- /missing-page/ returns the homepage with status 200: the missing page is being disguised as a successful response.
- The about page returns 200 but its logo fails: the page route works; inspect its asset path separately.
These outcomes are illustrative. Record the actual requested address, final address after redirects, response status and visible heading for your own site. Keep the deployment identifier with the record so a later release does not make the observation ambiguous.
Test without starting at the homepage
Open each important address in a fresh browser tab. Paste the full URL, then refresh it. Repeat for links you intend to share with clients or place in search results. A browser back button and an internal navigation click can reuse an already loaded application, so include an independent direct visit.
For a technical handoff, record the response status using the browser's network panel or a trusted HTTP client. A pretty error screen can still return 200, and an ordinary-looking page can be delivered with an error status. Write down both what the server returned and what the visitor saw.
Check the preferred hostname and the alternate hostname. A redirect should land on the equivalent nested page when that page exists. Sending every old or alternate address to the homepage makes a route problem harder to notice.
Repair the smallest confirmed defect
If a file is missing, rebuild or upload the correct finished output. If a link has the wrong case or extension, correct the link. If a known exported page needs a hosting mapping, add the narrow rule that delivers that page and verify its assets.
For a client-routed application, use the framework and provider's documented fallback behavior. Exclude paths that belong to real files, API endpoints or other services where required. Recheck an intentionally nonexistent address after the change; it should follow the application's explicit missing-page contract.
Avoid adding a catch-all rule just because it makes one 404 disappear. Confirm that your guide pages still return their own content, that images remain images, and that an unknown page does not impersonate a valid article. A routing change should have a before-and-after record.
Close the SEO and handoff loop
Once the route works, use the final preferred address in its canonical link and sitemap. Link to it from a relevant live page so visitors can discover it. Keep preview addresses out of public canonical metadata. Search discovery is a separate check from whether the server returns a page.
Read the custom domain launch checklist for host and HTTPS checks, and the broken image guide when the document works but its media does not. Return to GeminiLaunch with the verified finished files and use the worksheet in the client handoff.
Sources and maintenance
Prepared by GeminiLaunch as an original troubleshooting worksheet. The examples were checked for consistent file and route assumptions on October 6, 2026. Provider behavior can change; review the actual project's routing documentation before changing it. This worksheet does not modify files, hosting or DNS.
Prepared with AI assistance using the current public product and linked references. Practical checklists and illustrative examples are original planning aids. They do not establish product guarantees or replace a situation-specific review.