A website missing-page brief defines what visitors should see when an old bookmark, mistyped address or removed link no longer reaches the expected information. For a Kenyan business, this is a practical part of maintaining a usable site. The visitor still needs a clear explanation and a sensible next step, even when the original page is unavailable.
Discuss the behaviour with your website developer in Kenya before approving a decorative error illustration. A useful missing-page experience connects content decisions, navigation and technical responses. It also gives staff a repeatable way to investigate broken links without guessing where every old address should lead.
This guide covers missing-page recovery and its acceptance checks. It is separate from a complete redesign or search migration plan, and it does not promise preserved rankings or recovered sales.
Distinguish a missing page from a moved page
Start with the reason the address no longer works. A page may have moved to a genuine replacement, been removed without a replacement or never existed at all. Those situations need different decisions. A mistyped address should not automatically send someone to an unrelated service simply to avoid showing an error.
MDN's explanation of HTTP 404 describes it as a response indicating that the requested resource cannot be found. Ask the developer to explain how the website's visible missing-page message relates to its actual server response. A polished screen alone does not establish correct technical behaviour.
Create an address record with the original location, reason for review, current owner and proposed outcome. Where a replacement exists, have the content owner confirm that it answers the original visitor's need. Where none exists, document an honest recovery route instead of inventing an equivalent page.
Inventory links that people may still use
Review important addresses in the current navigation, articles, campaign materials and documents. Include links printed on brochures or shared through a QR code where the business knows they exist. These references can outlive the page they originally pointed to, so the website menu is only one part of the inventory.
Record the source of each link when available. A broken button on a current service page can usually be corrected at its source. A link inside an already distributed document may need a different decision about preserving a destination or explaining a replacement. Keep those cases distinct so the easiest fixes are not overlooked.
Prioritise by business relevance and available evidence rather than collecting an enormous list nobody reviews. An address repeatedly used for a current enquiry journey deserves attention. An unfamiliar address may require investigation before any change. Do not treat every recorded error as proof that a real customer lost a sale.
Write an explanation that helps the visitor recover
Use a short heading and explain that the requested page could not be found. Avoid blaming the visitor or displaying internal technical details. Someone arriving through an old link did not necessarily type anything incorrectly, and the message should allow for that possibility.
Offer a small number of useful routes. Depending on the site, these might be the main service directory, a working search feature or an appropriate contact page. Label them clearly. A screen filled with every menu item can make the recovery task harder than the original problem.
Keep the business identity and navigation recognisable. An error page that looks like a different website can make the visitor uncertain about where they have arrived. Review the message in the same mobile layout and visual language as the rest of the site while keeping its purpose immediately clear.
Choose destinations through a content decision
Where a page has moved, record the actual replacement address and why it is relevant. Do not use the homepage as a universal substitute for removed material. A visitor looking for detailed instructions may still have no answer after being sent to a broad introduction.
If several old pages have been consolidated, review their different purposes against the proposed new page. The new destination should provide a useful continuation rather than merely share a keyword. The person responsible for the content should approve that mapping before implementation.
For a wider rebuild, coordinate these decisions with the website redesign planning guide. Keep the focused missing-page register as evidence for individual decisions. The larger project plan should not obscure which old address was checked or which content owner approved its treatment.
Include downloads and external destinations
A missing document and a missing web page can affect the same customer journey. Review important download links from their actual page context. If a document has been replaced, the surrounding description should also match the current file rather than promising information it no longer contains.
Use the website download library brief to track document owners and versions. A renamed file may require updating multiple references. A working replacement link is only useful when visitors can understand what they will receive.
For external links, record the responsible supplier where known. Your team may be able to correct its own reference but not restore another organisation's service. Decide how to explain an unavailable dependency without silently substituting a destination that changes the meaning of the instruction.
Give staff a safe reporting route
Ask staff reporting a broken link to provide the address, where they found it and what they expected to open. This is usually more useful than a cropped screenshot saying the website is broken. Keep private customer information out of the issue record unless it is necessary and handled through an approved support process.
Assign an owner to review the report and record the outcome. The content team may need to correct a link, while a developer may need to investigate routing or a server response. Make that distinction visible so the issue is not repeatedly passed between teams without a decision.
Avoid asking staff to create live test enquiries merely to demonstrate a broken route. A link and page can often be checked without submitting a form. Where a complete journey needs testing, use the agreed review environment and acceptance arrangements instead of contaminating genuine business records.
Test the response and the recovery journey
Prepare several harmless review addresses: a known moved page, a deliberately nonexistent path and a removed resource with no replacement. Ask the developer to record the expected technical response and visible outcome for each. Keep expected behaviour separate from what was actually observed.
Open the addresses directly as well as through relevant links. Follow the offered recovery routes and confirm that they reach working pages. Review the narrow-screen layout, keyboard operation and the message's readability using the project's agreed evaluation methods. A successful redirect in one browser is not a full review of the error experience.
Recheck the source link after a correction. Fixing a destination does not always remove a stale button elsewhere. Record the final address and result in the register so later staff can distinguish a resolved issue from one that merely received an initial response.
Keep the register useful after launch
Include the register and reporting route in the website handover checklist. Name who reviews newly reported addresses and who approves content changes. Credentials belong in the appropriate secure account process, not in the link worksheet.
Review patterns alongside genuine customer feedback. Error requests, recovered page visits and qualified enquiries measure different things. Do not claim that a lower error count proves improved revenue, especially when monitoring coverage or traffic levels have also changed.
Before requesting development, prepare a representative list of addresses and the intended recovery routes. Request a website support quote that includes technical responses, content decisions and repeatable acceptance evidence. This makes the work more concrete than asking for a nicer error page alone.
Frequently asked questions
Should every missing address go to the homepage?
Review its purpose first. Use a genuinely relevant replacement where one exists, and provide an honest missing-page recovery experience where it does not.
Does a custom design prove the server response is correct?
No. Ask the developer to check both the visible result and the actual response for representative addresses.
Should we remove an old page immediately?
Assess its current use, useful content and replacement options before deciding. Record the decision and check affected links rather than deleting it solely because it looks old.
What evidence should a broken-link report contain?
Include the address, referring location, expected information and observed result. That gives the responsible person a clear starting point without requiring a customer to repeat an unrelated transaction.
