Fix broken links and plan page redirects carefully.

1. Record the page and the failing link

Save the page containing the link, the link text, its address, and what happened when you opened it. Note the date and whether the problem affected one link or many. Start with important routes such as navigation, featured listings, downloads, and contact information.

MDN defines a 404 response as a server being unable to find the requested resource. That response alone does not say whether the absence is temporary or permanent. A timeout, a sign-in requirement, and a missing page are different observations; record the one you actually encountered before deciding the destination is gone.

Sources: [1]

2. Match the repair to the cause

Use the following ATN decision aid after checking the destination and any available publishing records. For a page you do not control, look for an official replacement and confirm that it still supports the surrounding statement.

A homepage is rarely a helpful substitute for a specific document. Choose a destination that answers the expectation created by the link.

3. Map a real page move before implementing it

For each move, list the old address, replacement address, reason, and whether the change is permanent. Google documents 301 and 308 as permanent redirects, while temporary redirects have a different purpose. It recommends permanent server-side redirects for lasting URL changes when that method is available.

The implementation depends on your host, publishing system, or application. Give the map to the person managing that setup rather than pasting unrelated server instructions into a static page. Check that each target is the intended page and that rules will not redirect the replacement back to its old address.

Sources: [2]

4. Make the missing-page response useful

If there is no replacement, explain that the requested page cannot be found and offer a few relevant routes such as the category index or search. Keep the site’s navigation available. Avoid making the page look like a successful article when its content is missing.

The underlying response matters too. Google’s crawler documentation distinguishes successful responses, redirects, client errors such as 404, and server errors. Ask the builder to verify the actual status returned, not only the visible wording. A page saying “not found” is not enough evidence of its HTTP status.

Sources: [3]

5. Test the original route after the change

Open the original link from the page where a reader would use it. Check the final address and content, then try any important fragment or download attached to that route. Ask the builder to inspect the redirect sequence for loops or unnecessary intermediate stops.

Update internal links you control to use the intended current address. Keep the old-to-new map with your publishing records so a future edit does not accidentally remove a needed rule. When a source link changes, record a new source-check date only if you actually rechecked the factual material it supports.