THE SHORT ANSWER
Keep the missing-page message plain, offer a relevant route back into the site and have the developer check the actual response. Fix an old link at its source when you control it.
Start with a link a customer could really use
Choose an old service-page address from a bookmark, printed material or a business listing you control. Open it in a signed-out browser. Record whether it reaches the intended page, a relevant replacement or an error. Do not assume it works because the homepage loads.
You can also ask the developer for a safe nonexistent test address on your own domain. The purpose is to see how the website handles a missing page, not to probe private areas or guess administrative URLs.
Read the resulting page without explaining it to yourself. It should be clear that the requested page could not be found. A cheerful headline is fine, but a joke cannot do all the explaining. The visitor still needs to know what happened.
Separate the message from the technical response
MDN describes HTTP 404 as the server indicating that it cannot find the requested resource. Your visitor does not need that definition on the screen. The person maintaining the site does need to check that the response accurately represents what the server delivered.
A page can display an error message while returning a success response. Google's crawling documentation distinguishes these responses. Ask the developer to verify the status as well as the appearance rather than judging the repair from a screenshot alone.
Do not change server rules yourself from a generic snippet you found online. The right implementation depends on the platform. Give the developer the actual failing address and ask how they will check the result.
Offer a small number of useful next steps
Think about what someone reaching this site is likely to need. A link to services, the main contact page or a usable site search may help. Choose destinations that exist and work. Filling the error page with every navigation option just creates another sorting job.
Suppose an old flyer linked to a service that has been renamed. A relevant replacement page may answer the original question. If that service is no longer offered, the site should not quietly pretend a different service is the same thing. Keep that distinction visible in the explanation.
For a permanently moved page, ask whether an appropriate redirect is needed. For a genuinely removed page with no suitable replacement, ask how the missing-page response should behave. Sending everything to the homepage is not a thoughtful substitute for deciding where each important old address belongs.
Keep the normal branding and a clear way to contact the business. Avoid a form that asks for personal information merely to report a broken page. An ordinary contact route and the failing address can be enough to begin investigating.
Repair the trail, not only the destination
If you control the link on a menu, business profile or another page, update it there as well. A redirect can help visitors following an old address, but it does not make a printed URL disappear from material already distributed.
Keep a short record of the important addresses and their intended destinations. Note where each link is used and who can change it. This is particularly useful when a redesign replaces service pages or reorganizes the navigation.
Test the repaired link from the place the customer would click it. Check the destination on a phone, then follow the next action on that page. Reaching a page is only useful if it is the page that helps the visitor continue.
For each important old address, record the expected destination before the repair. That turns the final check into a comparison rather than a guess. An address that should reach a replacement service page should reach that page. An address with no replacement should produce the agreed missing-page response and offer the useful routes you selected, without pretending the original information is still available.
For a redesign discussion, bring the old addresses with the scope. That makes it possible to plan the move around actual customer routes instead of discovering them after launch. The missing-page screen should still work, but it should not be doing the job of an unplanned migration.