A broken-link audit investigates where a website invites someone to go and whether that destination can still serve the intended purpose. It starts with the source page and its actual link, not just a list of failed targets. The same unavailable address may be linked from a header, a product description and an old article, with different editing owners. A repair plan needs to connect those instances to the place where the link can be changed.
Treat link failures as observations that require interpretation. An intentionally restricted destination, an automated-request challenge and a genuinely missing public article are not the same problem. Record enough context to distinguish them before deleting content or creating redirects. A visitor-oriented review asks whether the route is appropriate, reachable and understandable for the person likely to follow it.
Choose pages with meaningful link coverage
Start with navigation, important landing pages, commonly used help content and a sample of detail templates. Include recently changed pages and areas affected by a migration. If the website is large, define a crawl scope and document its limits. A crawl from the homepage reveals the graph it can discover; it does not automatically include every published document or every link inside authenticated screens.
The broken link checker inspects a bounded sample from the submitted page. Use the site crawler when you need broader page discovery, and compare the discovered inventory with a sitemap or publishing list if available. Keep a record of unchecked links rather than treating them as working. This matters when a report samples only a fraction of the URLs found on a very long page.
Save the source anchor with the destination
For each finding, record the source URL, link text, destination and observed result. Note whether the target is an ordinary page, an image, a document download or a fragment within the same page. A missing fragment heading requires a different fix from an unavailable hostname. If several pages contain the same incorrect navigation item, group them under the shared component while retaining representative source examples.
Consider a fictional help centre that changes /help/payment-options to /help/payments. A scanner may discover the old target from many tutorials. Editing each tutorial independently might be necessary for body links, but a repeated sidebar entry could require only one template change. The source-anchor record helps identify that difference and prevents a large duplicate issue list from obscuring a small number of underlying causes.
Classify results before choosing a repair
Inspect response statuses, redirects and network failures separately. A final error response is different from a redirected link that reaches a useful successor. A DNS failure happens before a normal HTTP response exists. A timeout establishes that the request did not finish within the test conditions; it does not identify the responsible server component by itself.
The HTTP status explanation provides a response-oriented interpretation. If an external site blocks automated requests, open the destination cautiously in a normal browser and record the difference. Do not label it confirmed dead solely because one probe was denied. Keep uncertain results in a follow-up queue with a reason, rather than silently removing them from the report or converting them into passes.
Restore, replace or retire the link intentionally
When the destination should still exist, investigate whether a path, filename, publication setting or hosting rule changed. Restoring the resource may be the correct repair. When content has moved, update the source link to the intended replacement and decide whether old public addresses also require an appropriate redirect. When information has genuinely been retired, remove or rewrite the surrounding reference so the page remains coherent.
Avoid redirecting every missing destination to the homepage. A person seeking specific setup instructions does not receive an equivalent experience by landing on a generic marketing page. If there is no suitable replacement, an honest explanation can be more useful than pretending the original information survives. The useful 404 page article addresses recovery paths for visitors who still arrive through older references.
Check link meaning as well as delivery
A destination can return a successful response while no longer matching the anchor text or surrounding claim. Review important references for relevance, ownership changes and outdated instructions. A product name may remain in an old comparison even after the target page switches to a different offer. Delivery checks cannot establish that the cited information still supports the sentence on the source page.
Use descriptive link labels that explain the next step. “Read the sitemap publishing checklist” gives readers more context than several identical “click here” links. Keep labels concise enough to scan, and avoid stuffing them with repeated promotional phrases. The internal-linking article discusses how navigation and contextual references work together to make important content discoverable.
Verify files, images and in-page targets separately
Document links deserve checks beyond an address opening successfully. Confirm that the download is the intended file and that its format and version match the surrounding description. For images, verify the actual resource and its use on the page rather than only the image element's presence. For in-page anchors, confirm the referenced identifier exists after the content renders.
If a documentation update renames a heading, old table-of-contents entries and links from other tutorials may still reference the previous fragment. Preserve a meaningful stable identifier where practical, or update the known references. This type of breakage can escape a simple server-status check because the document URL still loads. Add a small browser test for important guided journeys when fragment links are part of the instructions.
Close the loop after a repair
Retest each representative source page and follow the corrected link as a visitor would. Request a retired address directly if a redirect was part of the change. Check another page using the same template to ensure a global edit did not introduce a new destination error. Save the before-and-after source and target evidence so a reviewer can verify the actual repair instead of relying on a changed issue count.
Repeat the audit after migrations, navigation redesigns and large content cleanups. Assign ownership for shared menus and editorial references so link maintenance does not depend on someone noticing a broken route by chance. Use the website migration checklist when paths are changing at scale. A successful link audit leaves visitors with relevant next steps and gives maintainers a clear record of which references were checked, corrected or intentionally retired.
Compare link checking approaches
| Approach | Evidence | Useful for |
|---|---|---|
| Focused link checker | A bounded sample from one page | Inspecting source-page link evidence |
| Site crawler | Links across discovered pages | Finding repeated navigation failures |
| Manual browser check | Destination relevance and interaction | Resolving uncertain or context-sensitive results |
Using CrawlNFix for this task
Use the free broken-link checker without creating a CrawlNFix account or purchasing a plan. Its live requests require an internet connection, and the report should preserve what was actually sampled. Download the findings if you need an offline review with a colleague. Reading that export does not retest destinations; reconnect and run a new check when you need current link evidence.