Deliver 404 and 500 error pages correctly from a technical perspective
An error page must retain the appropriate HTTP status: 404 for missing resources and 500 for internal errors, without publicly displaying technical details.
For PHP developers and website operators, "correctly delivering 404 and 500 pages" can be assessed primarily based on two points: "status before output" and "soft 404 response." This comparison makes the technical boundaries tangible.
Published: 3 min read · Author: Sebastian Geier
How does PHP deliver a formatted error page without incorrectly sending a 200 status?
Non-existent resources receive a 404 status, or, if they are intentionally and permanently removed, a 410 status. Unexpected application errors return a 500 error. The error view avoids fragile database and template dependencies, displays no internal information, and links a neutral message to protected logging.
Robust minimal view
Separate routing and exception paths and define explicit status responses for missing resources and internal errors.
Implement an independent minimal view without sensitive data and correlable protected logging.
End-to-end test direct, cached, and pre-routed responses with an intentionally missing route and a triggered exception.
Cross-check: "Soft 404 response"
An invalid product ID currently displays a nice message page with a 200 error, while a database failure renders the full stack trace. Routing returns a 404 error before the minimal view, and the central exception handler returns a 500 error with an event ID and protected log.
Secure Correlation
Percentage of verified error routes with expected HTTP status, neutral view, and discoverable internal event ID.
Number of successful 200 responses with error signatures, as well as public responses with stack traces or system details.
Status before output
Status before output HTTP code and necessary headers are set before PHP sends content or a buffer commits the response.
Robust minimal view – The error page functions even if the database, CMS, external services, or central layout components caused the incident.
Secure Correlation – Users see a neutral event ID; protected logs contain the time, route, and necessary technical context.
Soft 404 response
Soft 404 response – Missing content renders the normal layout with a 200 error, misleading monitoring, crawlers, and calling systems.
Error in the error page – The 500 view loads the same failed data source and generates a second exception without any useful guidance.
Public Stack Trace File paths, queries, access credentials, and library versions are, with one exception, included in the browser and search index.
What "Delivering 404 and 500 Pages Correctly" Means for Related Tasks
An in-depth question answered Centrally version shared headers, footers, and forms.How are common PHP components centrally modified without overriding page-specific settings?
Further Perspectives Identifying Soft 404 Pages That Technically Respond with a 200 Status.
If you want to practically implement "Delivering 404 and 500 Pages Correctly," you can refer to Robust Website Systems . This document focuses on "PHP Runtime, HTTP, and Diagnostics" and "Status Before Output."
Conclusion: Deliver 404 and 500 pages correctly
Error quality consists of correct HTTP semantics, robust orientation, and reliable diagnostics. Design alone cannot compensate for incorrect status or exposed internal information.
Sources and Further Information
The following official documentation and standards provide the technical classification.
PHP-FPM Configuration – PHP ManualThe PHP manual describes the process manager, worker limits, status path, timeouts, and logging for PHP-FPM.
RFC 9110: HTTP SemanticsThe Internet standard defines the semantics of methods, status codes, fields, and error responses.
Runtime Configuration for Error Handling – PHP ManualThe official PHP documentation defines `error_reporting`, `display_errors`, `log_errors`, and other runtime rules.
Key Thesis
Before output, the correct status is set, and a standalone, robust error view is loaded. Internal exceptions are logged; the public page provides orientation but no stack trace or system path.
What This Is Not About
A styled error message with status 200 is not a correct error response, and detailed exception output does not belong in the public user view.
What it's about
Before each output, the server sets the semantically appropriate status and renders a robust, standalone page with orientation and reliable incident identification.
PHP, forms & security
Disable error output in production without losing diagnostic capabilities.
The "Correctly Delivering 404 and 500 Pages" checklist includes the following question as a separate test step: How can PHP errors remain investigable if details are not allowed to appear in the browser?
PHP, forms & security
Building PHP forms so that errors remain traceable rather than invisible
The "Correctly Delivering 404 and 500 Pages" checklist is supplemented by a separate decision: How can a PHP form display errors clearly while simultaneously providing enough data for diagnosis?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Robust Minimal View: Implementation with Clear Testing
Two automated tests should trigger a missing resource and a controlled internal exception. The status, content, cache, and log correlation must be independent of each other.