Before approving a redirect for a reported 404, ask which address failed, where the link came from and what should be available there. The right response might be to correct a link, restore a missing page, redirect moved content or leave an address not found. A list of errors does not make those decisions for you.
For a business owner, the useful question is what a customer was trying to reach. Approve the response for each affected URL, rather than asking someone to make the report’s error count disappear. Keep the reason and the checks with that decision.
Capture the URL and Where It Was Found
Ask for the complete address, the report or source that identified it and the observation date. Include the page containing the link where known. A screenshot saying “broken links found” is not enough to locate the problem or decide who can correct it.
Distinguish a link on your own website from a reference on another website, an old email or a manually typed address. Your website editor can change an incorrect menu link. A link on somebody else’s site is a different dependency, and nobody should claim it was updated without checking that location.
Also distinguish the failing destination from the page that links to it. A working services overview can contain a link to a missing address. Reporting that the overview opens successfully does not show that its links work.
Google’s 404 help guidance says that not-found responses are generally not a search-performance problem when the URLs should not exist. It distinguishes deleted content, moved content and addresses that never existed. That is a reason to investigate the specific case, rather than treat every reported address as an urgent redirect job.
Ask what evidence makes this URL important: a current enquiry route, a useful page that should exist, an old address customers still use or a confirmed external reference. Keep unavailable traffic or link evidence marked unknown. A tool’s severity label is not a substitute for that explanation.
Check What the Address Returns Now
Have the responsible website or SEO person inspect the exact address. Record the current response, final destination if it redirects and what appears to the visitor. A historical report may describe an earlier version of the site, so keep its date separate from the new check.
A 404 is an HTTP response indicating that the requested resource was not found. A page can also display a friendly “not found” message while returning a success response. Google’s HTTP status documentation explains that error-like content returned with a success code can be treated as a soft 404.
The visible page and technical response therefore need to be checked together. A branded error page with useful navigation can still return the proper not-found status. Conversely, changing the wording on screen does not prove that the server response has changed.
If an important page is unexpectedly missing, ask the website owner to establish the cause and recovery scope. Avoid renaming another page, creating replacement content or adding a broad redirect before confirming what was supposed to be there. If several important addresses fail together, report the wider pattern for technical investigation.
Choose the Response That Fits the Problem
Use the evidence to agree a specific action. The examples below are planning choices for the responsible specialist to assess, not instructions to edit server settings yourself.
| Finding | Response to Discuss | Evidence Needed |
|---|---|---|
| A current link points to the wrong address | Correct that link to the intended working destination | The source page, wrong link and confirmed destination. |
| Useful content should still be at the missing address | Investigate restoration or another appropriate repair | The page’s intended purpose and the reason it disappeared. |
| Content has genuinely moved to a relevant replacement | Assess a redirect and update links under your control | The old address, replacement and reason it serves the same need. |
| The address should not exist and has no suitable replacement | Retain an appropriate not-found response with useful navigation | Confirmation that content is not required and no relevant destination exists. |
A corrected internal link and a redirect can sometimes both be useful. For example, an old published address may still be used elsewhere even after you update your navigation. Ask the specialist to explain that separate reason; do not assume that correcting one link settles every way someone reaches the old URL.
Google’s redirect guidance distinguishes permanent and temporary moves. The implementation should match the intended change. Agree the destination and its purpose before the developer chooses the method and checks the result.
Avoid sending all missing addresses to the homepage simply because it works. A visitor looking for a particular service or guide may not find an answer there. Google’s 404 guidance also cautions against homepage redirects for content that no longer exists. A redirect should have a useful reason beyond clearing an audit row.
Where the underlying issue is that your business has stopped offering a service, use the service-retirement guide to agree the customer message and continuing information needs. This article starts with a reported missing URL; a business change may require a wider content decision.
Before approving a redirect, ask for the named destination and the reason it answers the original customer need.
A Worked Example: A Typo in a Service Link
Illustrative example: an air-conditioning business has a working repair-service page. A link in its services overview points to a slightly different address with an extra word. Following that link produces a 404, although the intended repair page remains available.
The owner confirms that the service is still offered and identifies the correct page. The proposed fix is to correct the overview’s link and check the journey from the overview to the repair information and its enquiry option.
Before adding a redirect for the incorrect address, the reviewer asks whether it was previously a valid public URL or is a commonly used variation. That question may identify another reason to support the address. If no such evidence is available, the record says so rather than inventing a history of lost traffic.
The check then follows the corrected link on the public website. It confirms the destination’s content and asks the technical owner to record the relevant response. The old incorrect address is assessed separately under the agreed decision.
The repair makes the current link accurate. It does not establish a ranking increase, recovered customers or additional enquiries. Those outcomes would need their own evidence. The example is a planning illustration, not an AWE client result or a real URL change.
Ask for Technical and Customer Checks
For a link correction, request the exact source page and the delivered link destination. Follow it in context so the label, destination and available next step can be checked together. A correct address inside a document does not establish that the public menu contains it.
For a redirect, request the old address, response behaviour and final destination. Ask the developer to check for unintended intermediate redirects or loops and confirm that the final page contains the agreed information. A browser landing somewhere does not tell the owner the complete technical behaviour.
For retained not-found responses, check the actual status and the recovery options shown to a visitor. Keep the message clear and offer relevant navigation or contact routes. An elaborate error-page design cannot replace a working route back to useful information.
Include a phone view where the affected route matters to customers. Keep any form submission, call or booking test within an agreed scope. Opening an enquiry page is separate from proving a message was delivered or an appointment was created.
Record exactly what was tested and what was not. For wider questions about fetching, crawling and indexing, the indexing-evidence guide explains why a current browser or HTTP check does not prove Google’s recorded index state.
Keep the Report History Separate From the Live Fix
A dated live check can show that a link or redirect now behaves as agreed. It does not prove that an older crawl report has refreshed, that Google has processed the change or that the URL will appear for a particular search.
Keep the original report entry, approved action and later verification together. If the next report still lists the address, compare the dates and fetch details before commissioning the same fix again. Ask whether it is an old observation, a deliberately retained 404 or a new failure.
Use the SEO change-log guide to record the source, decision, delivery and next review. Preserve an intentional not-found decision as an explained state rather than repeatedly turning it back into an unfinished task.
Agree the Fix Scope Before Work Starts
Bring the exact failing addresses, known source links and intended customer destinations to the proposal discussion. Agree who checks the business purpose, who edits the website and what the completion evidence will show. Keep external references and unavailable evidence as explicit dependencies.
If you are discussing SEO services, ask for a scoped review of the reported issues rather than a blanket redirect rule. Contact Australian Web Experts with the report and affected routes so the actual investigation, implementation and verification work can be agreed.