Treat automated results as investigation candidates. Verify the promised visitor journey, fix controlled sources and use relevant redirects only when content genuinely moved.
Audit broken links by recording where each link appears, what it should do and what actually happens for a visitor. Use an automated report to find candidates, then distinguish a missing page from a blocked checker, temporary outage, wrong destination or missing file. Repair the original link wherever you control it.
This guide uses official WordPress, Mozilla, Google and W3C documentation checked on 13 October 2026. It provides an investigation and repair workflow; it does not claim to have crawled your site or measured a search-ranking improvement.
Define what a working link means
A working link delivers the resource or action its wording promises. A successful HTTP response alone does not prove that. “Download the checklist” is still a poor route if it opens a general homepage, an obsolete document or a login page the intended audience cannot use.
Separate ordinary page links from images, document downloads, embedded resources and links to a section within a page. Each needs a slightly different check. An article can load correctly while its illustration is missing; a page can exist while its old heading anchor no longer does.
For a fictional community website, the first audit might cover the main menu, volunteer sign-up page, accessibility information, event articles and downloadable venue map. That boundary makes the first pass manageable without implying that the unreviewed archive has been verified.
Build a repair list with source locations
Use a spreadsheet or issue list with one record for each affected source location. Deduplicate repeated destinations for investigation, but retain every place that needs an edit.
| Record | Why it matters |
|---|---|
| Source page and exact location | Shows which paragraph, button, menu or reusable component needs repair |
| Destination and visible label | Preserves the promised journey, including query and fragment parts |
| Observed response and final address | Distinguishes an error from a redirect or unexpected destination |
| Visitor check, time and access context | Records whether the problem affects a logged-out reader, the checker or both |
| Decision, replacement and verification | Keeps uncertain cases separate from completed fixes |
Do not put login tokens, private document links or personal data into an external checker or shared report. Review what a scanning service receives before using it. Audit only resources you are authorized to access.
A small site can begin with a manual pass through its most useful journeys. For a larger archive, a crawler or maintained link-checking tool can expand coverage, but its report still needs interpretation. Record whether it scans published content, templates, rendered links or only stored article text.
Interpret the response rather than its warning colour
Mozilla’s HTTP status reference explains response classes. Use the exact code as evidence, alongside the response body and intended audience.
| Observation | Initial interpretation | Next check |
|---|---|---|
| 404 or 410 | The server reports the resource absent or gone | Confirm spelling, final URL and whether a relevant replacement exists |
| 301, 302, 307 or 308 | The request is redirected | Follow the chain and verify the final content and whether the move is permanent |
| 401 or 403 | Access is required or refused | Determine whether the intended public visitor can access it |
| 429 | The request rate has been limited | Reduce scanning and respect any retry instruction |
| 5xx, timeout, DNS or TLS failure | The request could not be completed normally | Investigate availability or configuration before declaring a permanent disappearance |
| 200 with the wrong content | The request succeeded but the journey may still fail | Read the returned page or file against the link’s promise |
A 403 response means the server refused the request. It does not establish that the target page has been deleted. A tool may be blocked while ordinary visitors can open the page; equally, a browser that works only after signing in does not prove public access.
Mozilla documents 429 rate limiting and 503 temporary unavailability separately. Repeatedly hammering a restricted or overloaded endpoint is not a useful verification method.
Confirm uncertain results in the visitor’s context
Open the source page through its normal public route and follow the actual link. Check the full destination rather than manually typing a shortened address. Compare the final page title, resource and access requirements with what readers were promised.
If an automated result differs, record both observations. A checker may use a different request method or network context. The HEAD method retrieves response metadata without the body, so a header-only result cannot prove that the correct document is present.
For the fictional venue map, a scanner’s 403 needs a public-browser check. If visitors obtain the correct map, mark the tool result as inconclusive or blocked with a review date. If they reach a staff-only page instead, the public link needs a different destination even though staff can open it.
Do not bypass a firewall, authentication requirement or paywall to make a report green. If it is your own site and a legitimate checker is blocked, ask the responsible administrator to investigate a narrow, supported configuration. Keep the protection in place while deciding what readers actually need.
Prioritize failures by their effect on readers
Repair essential journeys first: navigation, contact routes, forms, current instructions and documents readers need to complete a task. Then work through frequently reused references, important evergreen articles and the older archive.
A stale navigation link repeated on every page has a different impact from one obsolete citation deep in an archived event report. Both may need attention, but counting unique failed URLs alone hides that difference.
Also distinguish a site-wide pattern from isolated mistakes. If many unrelated WordPress posts suddenly return 404 while the homepage works, investigate routing and the recent change history before editing hundreds of article links. Our WordPress 404 and permalink troubleshooting guide covers that narrower problem.
Fix the source link and its description together
When a destination moved and a suitable current page exists, update links you control to that verified address. Repair reusable menus, templates or patterns at their source rather than patching only one visible instance.
Check the surrounding sentence. A replacement may explain a different process, offer a different resource or apply to another software version. Changing the URL without updating the claim can leave the article misleading.
For the fictional community site, a new venue map should keep a clear resource label and identify an edition if that matters. Replacing a defunct bus timetable with the operator’s homepage requires new wording; it no longer promises the same direct timetable.
W3C’s link-purpose guidance supports text whose purpose is understandable in context. Avoid replacing a descriptive link with several identical “here” labels merely to make editing quicker.
If no trustworthy equivalent exists, remove the link and revise the affected explanation, or clearly explain the historical context. Do not invent a substitute source or present an archived document as current advice.
Use redirects for real moves, not to hide every error
When you own an old URL and its content has genuinely moved, map it to the closest equivalent destination. Google’s redirect documentation distinguishes permanent and temporary moves. Choose the behavior that matches the actual change and implement it through the site’s supported controls.
Update internal links as well, so readers do not depend on unnecessary chains. Test the old address, the final destination and whether the route loops. A page that permanently moved should not travel through several forgotten intermediate addresses.
Do not redirect every removed article to the homepage. It rarely answers the original request and can make a missing resource harder to diagnose. When no replacement exists, a truthful missing-page response with useful navigation can be appropriate.
You cannot configure a redirect on someone else’s domain simply by editing your article. Replace the outgoing link you control or explain its removal. Plan broader URL changes with our permalink-change guide rather than treating an audit as permission to redesign all routes.
Check anchors, files and images explicitly
A section link includes a fragment such as #opening-hours. Confirm that following it reaches the intended section. The anchor-element reference describes fragment links; an ordinary page response does not verify that the referenced target still exists.
Open a download and inspect its actual title or edition. Confirm images return the intended asset, not a missing-file placeholder. Look at the rendered page as well as stored content, because templates or custom blocks can introduce references outside the article text.
When updating a shared file, list the pages that still point at the old address before deleting it. Our free PDF publishing guide explains stable introduction pages, versioned files and replacement limits.
Verify the repair and retain unresolved evidence
- Save the intended source change and inspect the public page.
- Follow the repaired link, including redirects and section targets.
- Confirm the final content matches its description and access expectations.
- Retest the affected group with the checker where appropriate.
- Keep temporary or blocked results with a reason and review date rather than silently marking them fixed.
Google’s crawler status-code guidance explains that error-like content can be problematic even with a successful response, and a 200 response does not guarantee indexing. A clean audit is not a promise of rankings; its immediate value is a more dependable reading journey.
Review navigation using our menu accessibility guide and the broader launch checklist. Repeat focused checks after migrations, URL changes and resource updates. Keep the scope and unresolved cases visible so a report represents evidence rather than a blanket claim that every link will always work.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- Mozilla: HTTP response status codesChecked Response classes and distinctions between success, redirects, missing resources, access errors and server errors.
Limits: A status does not alone establish a correct visitor journey, permanent disappearance or search indexing. Network failures need separate investigation. - Mozilla: 403 ForbiddenChecked Request refused is distinct from proof of resource deletion.
Limits: No universal cause for a checker/browser discrepancy inferred and no authentication or firewall bypass suggested. - Mozilla: 429 Too Many RequestsChecked Rate limiting and possible Retry-After instructions.
Limits: No request cadence or scan volume prescribed and no repeated probing to evade restrictions. - Mozilla: 503 Service UnavailableChecked Temporary unavailability requires investigation rather than automatic permanent removal.
Limits: No promise that every 503 resolves on a fixed timeline or that every 5xx has the same cause. - Mozilla: HEAD methodChecked Header-only responses omit the body and do not prove the expected document content was retrieved.
Limits: No claim that different HEAD/GET outcomes are always legitimate, or that any specific checker uses a particular method. - WAI: link purpose in contextChecked Maintain understandable link purpose and revise surrounding claims when substituting a destination.
Limits: Focused criterion, not whole-site accessibility certification or a requirement that every link text be unique out of context. - Google: redirects and SearchChecked Permanent versus temporary moves and selecting redirects to match the actual change.
Limits: No redirect configuration executed, traffic/ranking preservation guarantee or universal homepage fallback recommended. - Mozilla: anchor element and fragmentsChecked Links can target document fragments; checking page availability alone does not verify the intended section or resource.
Limits: No universal anchor checking ability attributed to crawlers; actual browser behavior needs focused verification. - Google: HTTP status and network errorsChecked Successful responses do not guarantee indexing and error-like successful pages can produce soft-404 treatment.
Limits: Google's crawler/indexing behavior is distinct from a human-access test; no Search Console property or indexing outcome checked.