The default error page is a bare server message with no navigation, no branding and no explanation. A visitor who reaches one has hit a dead end, and most leave rather than trying to find their way back.
A custom error page turns that into a recoverable moment. It takes a few minutes and it is one of the cheapest improvements available on a site.
Creating one
In cPanel, open Error Pages, choose the domain, and select the error code.
You get an editor with tags you can insert. The requested URL, the visitor's address, the referring page. Write plain HTML; there is no template system and nothing to learn.
Save, then visit a deliberately wrong address on your site to confirm it appears.
The codes worth customising
404 Not Found. The one that matters. Every site produces these, from old links, typos and removed pages.
403 Forbidden. Access denied. A protected directory, or permissions.
500 Internal Server Error. Something broke on the server.
The rest are rare enough to leave alone. If you only do one, do the 404.
What to put on it
Four things, and they are all about giving the visitor somewhere to go.
What happened, briefly and in plain language. "This page does not exist" beats "404 Not Found".
A link to the homepage. The minimum viable escape route.
A search box. The visitor was looking for something specific, and this is the fastest way to let them find it.
Links to your main sections. Two or three, not a full menu.
Keep it short. A visitor at a dead end wants a way forward, not paragraphs of apology.
What to leave off
Technical detail. File paths, server software versions, framework names. Error pages are read by people probing for weaknesses as well as by lost visitors, and the default pages give away more than they should.
Long apologies. One sentence is enough.
Anything that could itself fail. Which matters most on the 500 page.
The 500 page has a special constraint
A 500 means the application failed. So a 500 page that loads through the application cannot work: the thing that would render it is the thing that broke.
Write it as plain HTML with no PHP, no database queries and no dependency on the theme. Inline the styling rather than linking a stylesheet the server may also be failing to serve.
This is the difference between a 500 page that appears and one that produces a second error inside the first.
Fix the cause, not just the page
A custom 404 makes a broken link less costly. It does not make it less broken.
The access log shows which addresses are producing 404s and where the visitor came from. A 404 referred from your own site is a broken link on your site, fix it. A 404 for wp-login.php on a site without WordPress is background noise from bots and can be ignored entirely.
That distinction is the useful one, and viewing website statistics goes into finding it.
When a page moved rather than vanished, a redirect is better than any error page. The visitor arrives where they intended and inbound links keep their value. Redirecting a domain or page goes into it.
If your application already handles it
WordPress and similar systems have their own 404 template, and it usually takes precedence for addresses the application handles.
The cPanel error page still covers requests that never reach the application. A missing image, a direct request for a file that is not there. Both are worth having, and they are not the same page.
Test a wrong URL under a normal path, and also a wrong image path, to see which is being served in each case.
A good 404 page catches the ones you missed; finding them is a separate job. There is more in How to Find and Fix Broken Links on Your Site.
Check the status code, not the page
An error page that looks right and returns the wrong status is the fault worth testing for, because nothing about it is visible in a browser.
curl -sI https://example.com/no-such-page | head -1 curl -sI https://example.com/ | head -1
The first must report 404. A page that displays "not found" while answering 200 is telling every automated visitor that the address is valid, which means search engines index it and monitoring never alerts.
This happens most often when the error page is served by a redirect rather than as the response itself: the redirect answers 302, the destination answers 200, and the original status disappears. Serve the page in place instead of sending the visitor elsewhere.
The error page's own assets
An error page loads its stylesheet and images like any other page, and the paths behave differently because the page can be served from any address.
A page referencing css/error.css resolves that relative to the address requested. Asked for at /a/b/c, it looks for /a/b/css/error.css, finds nothing, and renders unstyled, which is why an error page tested at the root looks fine and looks broken in production.
curl -s https://example.com/deep/missing/page | grep -oE '(href|src)="[^"]*"' | head
Use absolute paths beginning with a slash, or inline the styling into the page. The second is worth doing for the 500 page specifically, since it removes one more thing that has to work.
Watch for the loop as well: a missing asset requested by the 404 page produces another 404, and a badly arranged setup can multiply one missing file into many requests.
Read the 404 log as a to-do list
The addresses producing errors are a record of what visitors and search engines expected to find, and most of it is actionable.
awk '$9 == 404 {print $7}' ~/logs/example.com | sort | uniq -c | sort -rn | head -20
awk '$9 == 404 {print $11}' ~/logs/example.com | sort | uniq -c | sort -rn | head -10
The first lists the missing addresses by frequency; the second lists which pages linked to them, which tells you whether the broken link is yours or somebody else's.
A repeatedly requested address that used to exist deserves a redirect in place of a nicer error page. One requested from your own site is a link to fix. The rest, probes for administrative paths on software you do not run, is background noise and can be ignored. For the first case, see redirecting a domain or page.
Do not let the page volunteer information
Default error pages state the server software and its version, and error output from an application can print file paths, database names and occasionally credentials.
curl -sI https://example.com/ | grep -iE '^server|^x-powered-by'
php -r 'echo ini_get("display_errors") ? "display_errors ON\n" : "display_errors off\n";'
Neither header needs to be detailed, and errors should be written to a log rather than to the page. That is not a strong protection on its own, and it removes the free reconnaissance that a default page offers.
The custom 500 page matters most here, because it is the one that appears when something has genuinely gone wrong and is therefore the one most likely to show a trace. For reading it where it belongs, see understanding cPanel error logs.