Customize error pages

3 min read07 November 2026

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:

Text
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html

The 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

Bash
curl -I https://your-domain.tld/a-missing-page

Expected: 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

Was this article helpful?

Read next