Prepare the missing-page file, choose explicit project destinations and test the deployed host separately. A heading that says “404” cannot configure route handling or establish the HTTP response status.
An original project recovery plan
The fictional Workshop Kit site uses https://example.org/workshop-kit/ as its proposed base. The example addresses are placeholders, not verified live destinations. A missing request such as /workshop-kit/guides/old-outline/ should offer this plain copy:
Page not found
The requested page is unavailable. Choose one of these Workshop Kit destinations to continue.
| Descriptive link label | Proposed destination path |
|---|---|
| Workshop Kit home | /workshop-kit/ |
| Browse Workshop Kit guides | /workshop-kit/guides/ |
| Read Workshop Kit notes | /workshop-kit/notes/ |
Confirm that the real destinations exist before using them. These are native navigation links, not a fake search form or a button that pretends to restore an unknown browsing history.
Preserve the project prefix at every depth
Assuming the normal document URL base with no overriding base element, the proposed path /workshop-kit/guides/ resolves from the origin root and retains the project prefix regardless of the missing path's depth.
At https://example.org/workshop-kit/guides/old-outline/, compare:
guides/resolves to/workshop-kit/guides/old-outline/guides/.../resolves to/workshop-kit/guides/, not the project home./resolves to the origin home, dropping/workshop-kit/./workshop-kit/resolves to the intended project home.
MDN's URL-resolution guide explains current-directory, parent-directory and root-relative resolution. Use the actual deployed base and any base-element configuration when checking your site; the example prefix is not a universal site setting.
The same concern applies to relative stylesheet or image paths on an error page. A self-contained design reduces those dependencies. Keep the important explanation and destinations readable if decorative assets fail.
Design a recovery page people can use
Use one visible “Page not found” heading, a short explanation and descriptive links. Keep the link labels readable, preserve visible keyboard focus and ensure navigation works as ordinary links. A minimal original layout needs no animated illustration to answer the visitor's immediate question.
Avoid an automatic redirect that removes the opportunity to choose a destination. Do not include a search field without a working search service. Do not echo a requested URL into generated markup or add error analytics simply to make the template appear complete. The example needs no visitor-data collection.
Keep the native file in the hosting workflow
GitHub's custom-404 guide directs GitHub Pages users to the site's publishing source and describes 404.html or 404.md. Its Markdown option uses front matter with a /404.html permalink. For the native HTML task here, keep the intended 404.html artifact in the chosen host's required publishing workflow.
Confirm the actual repository/source, build process and host behavior before integration. Another hosting platform may require a different configuration; the GitHub guide does not establish that merely naming a file works everywhere.
Test the response as well as the design
After an authorized implementation and deployment, check:
- A nonexistent shallow path, such as
/workshop-kit/missing/. - A nonexistent deep path, such as
/workshop-kit/guides/old-outline/. - The actual response status and displayed body for both requests.
- Each recovery link's resolved destination, including the project prefix and destination existence.
- An existing valid page, which should continue to work normally.
- Keyboard navigation, visible focus and narrow-screen readability.
Record results from the real host. Opening 404.html directly only checks the file's display in that context; it does not prove interception of missing routes or an HTTP 404 response. Mark each check complete only after observing its result.
Copy a project-safe 404 brief
Prepare a native 404.html design in US English for my chosen host.
Actual site origin/project base and publishing source: [enter]
Verified home/guides/notes destination paths and labels: [enter]
Host/build-specific missing-route requirements: [paste or TO CONFIRM]
Representative shallow/deep missing URLs and existing valid page: [enter]
Any configured base element or required assets: [enter]
Use a plain missing-page heading and explanation with descriptive native links.
Preserve the actual project prefix; do not infer destinations from missing-path
depth. Provide visible keyboard focus and readable narrow-screen layout.
Prefer self-contained markup/styles. No fake search, history-back control,
automatic redirect, requested-URL insertion or visitor-data collection.
Keep native host integration separate from a visual preview. State unresolved
configuration/destination checks. Do not claim deployment or HTTP status tested.
Return the proposed file content and real-host test checklist for owner review.
Check shallow/deep missing routes, response status/body, link destinations and
an existing valid page after authorized deployment. A rendered preview alone
must never be called a working site-wide error handler.
Maintain the native 404.html file and host configuration in the repository or publishing source. Verify real missing-route behavior there before marking recovery complete.
Optional visual review with NOS
NOS can save and display an HTML visual review copy of the proposed error-page design. Use that copy to inspect the explanation and link labels; it does not handle the site's missing routes or set its HTTP response codes.