A broken link report often arrives as “this page is not working.” That description leaves several possible causes: the link may be wrong, the destination may have moved or the page may work only for a signed-in visitor. A short investigation log turns the complaint into a reproducible task.
Begin with one failing journey. Avoid changing every similar link before you know which address the visitor actually followed.
Capture the starting point and destination
Write the public page URL where the link appears, its visible text and the destination copied from the link. Note the date, device and whether you were signed in. Keep private session tokens and customer information out of shared reports.
Open the same starting page in an ordinary visitor session and follow the link. Record the final address and the visible message. A screenshot is useful evidence, but the source and destination URLs make the issue easier to reproduce.
Distinguish a missing page from a wrong journey
A page can load successfully while showing the wrong content. Compare its heading and purpose with the promise in the link text. A support link leading to a generic homepage is still a journey problem even if there is no error screen.
If you have developer tools available, record the response status and redirect sequence. A successful response alone does not establish that the content is useful or that search engines will index it.
Choose the smallest justified correction
If the navigation points to a typo, correct the source link. If a public page has intentionally moved, discuss a suitable redirect with the site owner. Do not send every missing address to the homepage as a blanket repair.
Check the affected header, footer, article and mobile menu separately. A repeated link may be managed by different components, so fixing one instance may not fix the others.
Put it into practice
Use a log with five fields: source page, link text, destination, observed result and owner. After the correction, repeat the original visitor journey and record the result.
Keep the log small enough to maintain. One verified repair is more useful than a long list of assumed failures.