Build Log
Error Pages Are Part of the Product
A site reveals its engineering culture when something goes wrong. The custom error-page pass treated failure states as product surfaces rather than hosting leftovers.
Three different failures, one calm response
The release added styled 403, 404, and 500 pages. Each uses the berries-and-cream chrome, a clear error code, a direct route back to the calculator, the normal footer, and a short countdown. Error pages are marked noindex because they are operational responses, not content destinations.
Root-relative assets make the pages reliable when the host invokes them from an arbitrary missing path. The navigation and countdown script were checked through a local HTTP server rather than by opening files directly, which better matches real routing behaviour.
Mobile failure is still mobile
Desktop and 390-pixel views were rendered for all three codes. The checks covered stylesheet loading, horizontal overflow, the large error-code type, countdown updates, and the final redirect. A broken mobile menu on an error page would be especially unhelpful because the visitor already needs a way out.
The pages also carry the normal identity and privacy-aware analytics configuration. This keeps operational telemetry consistent without pretending the failed URL is a successful content page.
What became standard
Error surfaces belong in the initial release checklist. They need the same brand, accessible navigation, responsive testing, and indexing intent as the rest of the product.
The recovery destination is the calculator; alternative paths include the Guide and Contact page.