Customize error pages
A default error page serves the server, not the visitor. Customizing it improves navigation and brand perception, provided you keep the correct HTTP code and reveal nothing about the infrastructure.
1. Tell the codes apart
| Code | Meaning | What the visitor sees |
|---|---|---|
404 |
resource does not exist | wrong URL, or content moved |
403 |
access denied | no permission, or a protected file |
500 |
server error | code failed, with no public detail |
Do not return 200 with a "page not found" message: that is a soft 404, which search engines and monitoring tools misread. Likewise, do not mask a 500 as a 404: you would lose both the alert and the diagnosis.
2. Configure Apache
At the site root, in .htaccess:
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.htmlThe path starts at the web root and begins with /. The file must exist and be readable. For a 500, use a static page (.html), never a PHP script: if PHP is the cause, the fallback page would fail too and create a loop.
3. Write a useful page
- A clear title: "Page not found".
- One sentence explaining what to do, without jargon.
- A link to the home page and the help centre (
/help). - Internal search if the site offers it.
- A contact address to report a broken link.
Never publish: stack traces, PHP or server version, absolute paths, SQL queries, user names or internal email addresses. That information helps an attacker map a target.
4. Work with KeyHelp
If KeyHelp provides a global error page setting, use it for the relevant domain. Avoid editing shared template files: your changes could affect other sites or be overwritten during an update.
Real errors must be logged server-side. The public page informs, the log diagnoses. Set PHP error display to off in production and read the domain logs.
5. Verify
curl -I https://your-domain.tld/a-missing-pageExpected: 404 and your custom page. Then test a 403 on a protected file, and trigger a 500 in a test folder with a deliberately broken script, deleting that script immediately.
Also check:
- no technical detail in the HTML;
- the page links work;
- the HTTP code is preserved (not
200); - the page still loads when the main application is unavailable.
A good error page does not fix an outage, but it keeps visitors from leaving without knowing where to click.
Advertisement