Home / Guide
The complete playbook

The Complete Guide to Broken Link Monitoring for Websites

Reviewed for 2026, updated September 8, 2026.

Everything a site owner, marketer, or developer needs to understand, find, fix, and prevent broken links, from the first crawl to a continuous monitoring routine.

In short

This guide explains what broken links are, why they damage search visibility and user trust, and how to detect them across sites of any size. You will learn how to classify and prioritize failures, choose the right fix for each one, protect a migration, and move from one-off audits to continuous monitoring with a clear team workflow.

Every website is a set of promises. A link says: click here and you will find something useful. When that promise breaks, the visitor lands on an error page, a search engine crawler wastes its budget on a dead end, and a small piece of the trust you have built erodes. Broken links are rarely dramatic on their own. What makes them dangerous is that they accumulate quietly, spread across pages nobody has looked at in months, and usually go unnoticed until a customer, a partner, or a ranking drop points them out. The web decays by default, and any site that publishes content over a period of years will collect dead links unless someone is deliberately looking for them.

This guide is our attempt to cover the whole subject in one place. We run a small company that builds broken link monitoring software, so we spend most of our working days looking at failed requests, redirect chains, and the reports that come out of them. We have tried to keep the product out of the way here. The goal is to give you a complete mental model: what a broken link actually is, why it matters for search and for people, how to find every one of them on a site of any size, how to fix each type correctly, how to survive the high-risk moments like migrations, and how to turn a one-time cleanup into a routine that keeps working after the initial enthusiasm fades. Each section links to a deeper article when you want the details.

Key facts, as of 2026
  1. A broken link, also called a dead link, is a hyperlink whose target can no longer be reached as intended: the server answers with an error status such as 404 Not Found or 410 Gone, the domain fails to resolve, the request times out, or the page loads but no longer holds the content the link was pointing to, which is often called a soft 404.
  2. HTTP status codes tell a link checker what happened: codes in the 200 range mean success, 301 and 308 are permanent redirects, 302 and 307 are temporary redirects, codes in the 400 range are client errors such as 404 Not Found and 403 Forbidden, and codes in the 500 range are server errors. A monitoring tool normally records the final status after following any redirects.
  3. Link rot is the gradual decay of links over time as pages are moved, sites are restructured, content is removed, or domains expire. External links rot on a schedule the linking site does not control, which is why a single audit falls out of date and a recurring check is needed to keep a site clean.
  4. A redirect chain is a sequence in which one URL redirects to a second URL that redirects again, and a redirect loop is a chain that eventually points back to itself. Each hop adds latency, crawlers give up after a limited number of hops, and the usual fix is to point every link and every redirect directly at the final destination.
  5. Continuous broken link monitoring means a service recrawls a site on a recurring schedule, compares each run with the previous one, and reports only new failures. Retrying a failed link before reporting it is standard practice because transient timeouts, rate limiting, and 403 responses to automated requests can produce false positives that look like broken links.

The most visible cost of a broken link is a frustrated visitor. Someone arrived with intent, clicked a link that promised an answer, and received an error instead. Most people will not try a second time. They will hit the back button, and if they came from a search result they will often pick a competitor from the same results page. That single moment carries a real cost for a store, a lead form, or a documentation site, because the link failed at exactly the point where the visitor had already decided to engage. Multiply that by every broken link on the site and by every day the problem goes unnoticed, and the quiet leak becomes something you can measure in lost sessions and abandoned journeys.

The search engine side is less visible but just as real. Crawlers follow links to discover and re-evaluate pages, and every request they spend on a URL that returns an error is a request not spent on content you actually want indexed. Internal links also pass authority and context between pages. When a link to an important page is broken, that page loses some of the signals that were helping it rank, and the pages that linked to it look slightly less well maintained. Search engines do not punish a site for a handful of 404s, but a site with hundreds of them, especially in navigation and key content, sends a consistent message that nobody is home. The article on why broken links quietly hurt SEO goes through each of these mechanisms in detail.

There is also a trust and reputation dimension that is easy to underestimate. A partner who clicks a dead link in your press kit, a candidate who finds a broken careers page, or a journalist whose citation now leads to an error page all form an impression about how carefully the organization runs. Accessibility matters here too: screen reader users who rely on link text to navigate hit a wall when the destination is gone, and there is no visual cue to warn them beforehand. The article on what a 404 does to a visitor explores how people actually react and how a good error page can recover some of them. The short version is that broken links are a maintenance problem with customer-facing consequences, and they deserve the same attention as uptime.

A link is broken when following it does not lead to the resource it was meant to reach. In practice that covers more ground than a plain 404. The destination server may be gone entirely, so the DNS lookup fails or the connection times out. The server may respond with a 410 to say the page was intentionally removed, or with a 500-series error because something behind it is failing. The page may return a 200 status while displaying a generic not-found message, which is known as a soft 404 and is one of the hardest cases to catch automatically. A link can also be technically alive but practically broken: it redirects to the home page, points to a login wall, or lands on a page whose content has changed so much that the citation no longer makes sense.

Link rot is the name for the way these failures accumulate over time. Domains expire and get bought by unrelated parties. Companies restructure their sites and drop old URL patterns. Blog platforms shut down, PDFs get moved, and content management systems change how they build URLs after an upgrade. None of this is malicious, and none of it is under your control when the link points outward. The article on link rot explains why the web decays this way and what a realistic coping strategy looks like. The key insight is that outbound links have a shelf life, and a page that was perfect the day it was published is probably carrying some dead weight a few years later, no matter how carefully it was written.

It helps to split broken links into two families before deciding what to do about them. Internal broken links point to pages on your own site, which means you caused them and you can fix them completely, usually with a redirect or a corrected href. External broken links point to other people's sites, which means you did not cause them but you still own the visitor's experience and the choice of what to do next. The two families have different causes, different fix options, and different priorities. Our comparison of internal versus external broken links makes the case that internal failures almost always come first, because they are entirely within reach and they carry the most direct SEO consequences, while external ones are triaged by how much the reference still matters to the reader.

Detection starts with a crawl. A crawler begins at one or more seed URLs, fetches each page, extracts every link it finds, and follows the internal ones until it has visited everything reachable. Along the way it records the status code, the response time, the redirect target if any, and the page where each link was found. For a small site this takes minutes and a desktop tool is enough. The difficulty grows quickly with scale: a site with tens of thousands of pages, several subdomains, faceted navigation that generates near-infinite URL combinations, and content rendered by JavaScript needs a crawler that understands crawl budgets, canonical tags, robots directives, and how to render pages instead of just parsing raw HTML.

Crawling only finds links that are reachable from where the crawl starts. Orphan pages, links inside PDFs, links in email templates, links embedded in third-party widgets, and URLs that people share on social media or in printed materials will not show up. That is why a thorough detection strategy layers several sources. Server logs and analytics reveal which URLs real visitors and real crawlers are requesting and which of those return errors. Search engine webmaster tools report the broken URLs that their crawlers encountered on their own. Sitemaps tell you what you intended to publish, so comparing them to a crawl exposes pages that exist but are no longer linked. The article on how to find broken links at scale walks through combining these sources without drowning in duplicate data.

Scale also changes how you handle external links. Checking outbound links means making requests to thousands of other servers, some of which rate-limit or block automated clients, return different responses to bots than to browsers, or are simply slow. A good process retries transient failures before declaring a link dead, respects reasonable request rates, distinguishes between a server that refused your crawler and a page that is actually gone, and keeps a history so that a link failing once at three in the morning does not trigger a fire drill. How often you repeat all of this is its own question; the article on audit frequency ties the cadence to how fast the site changes and how much traffic depends on the links in question.

Once you have a list, every broken link falls into one of a few fix categories. If the destination still exists at a new address, the correct fix is to update the link itself so the visitor goes straight there, and, for internal URLs, to add a permanent redirect so that any other reference on the web also lands correctly. If the destination is gone and there is a close substitute, point the link and the redirect to the substitute, but only when it genuinely answers the same intent. If nothing equivalent exists, the honest options are to remove the link, to rewrite the surrounding sentence so it no longer depends on the reference, or for external citations to link to an archived copy so the reader can still see what you were referring to.

Redirects deserve special care because they are the fix people reach for first and get wrong most often. A 301 tells browsers and search engines that a move is permanent and that they should treat the new URL as the canonical one. A 302 says the move is temporary, which is rarely what a site owner means. Chains happen when a URL redirects to another URL that itself redirects, often because each migration added a layer without cleaning up the last one. Loops happen when a chain circles back on itself. Both add latency for visitors and waste crawl budget, and a chain that runs past the number of hops a crawler will follow leaves the final page unreached, which defeats the purpose of the redirect. The article on redirects done right explains how to map old URLs to new ones directly, how to audit existing rules, and when a redirect is the wrong tool entirely.

Some URLs should not be redirected at all. A page that was removed on purpose, has no substitute, and was never important should return a clear 404 or 410 so that search engines drop it and visitors get an honest answer. That makes the quality of the error page part of the fix. A useful 404 page keeps the site's navigation, explains in plain language that the page is missing, offers a search box and links to the most likely destinations, and returns the correct status code rather than a 200. Our piece on what a 404 does to a visitor covers how to design that page so it softens the landing instead of confirming the visitor's worst assumption about the site and the people behind it.

Migrations, Redesigns, and Other High-Risk Moments

Most broken links are created gradually, but the largest batches appear in a single afternoon. A site migration, a platform change, a redesign that alters URL structure, a merger of two domains, or a move from HTTP to HTTPS can invalidate thousands of URLs at once. The links that break are not only the ones in your own navigation. Every backlink from another site, every bookmark, every link in an old email newsletter, and every search result that has not yet been recrawled still points to the old addresses. If those addresses stop responding correctly, the traffic and the authority they carried disappear together, and recovering them can take months of patient work.

The defense is preparation. Before anything moves, crawl the current site completely and export the full list of URLs, including the ones with traffic and backlinks that the crawl might miss. Build a redirect map that pairs every old URL with its best new destination, one to one wherever possible, and review the entries for important pages by hand rather than trusting a pattern rule to get them all right. Stage the new site, crawl it, and test the redirect map against the old URL list before the switch. On launch day, watch error rates in real time and keep the old environment available in case a rollback is needed. Our survival guide for broken links after a site migration turns this into a checklist you can follow under pressure.

After the launch, the work is not finished. Redirect rules written in a hurry often contain chains, wildcard patterns that send unrelated pages to the same destination, or gaps for URLs that nobody remembered. Search engines will keep requesting old URLs for a long time, so the redirects need to stay in place for years rather than weeks. Monitoring is what catches the leftovers: a recurring crawl compared against the pre-migration URL list surfaces anything that slipped through, and the redirect article's guidance on avoiding chains and loops becomes the standard for cleaning up the rules once the initial pressure is off. Treating the migration as a project with a monitoring phase, rather than a launch date, is what separates smooth transitions from lingering damage.

From One-Off Audit to Continuous Monitoring

A single cleanup feels satisfying, and it does help. The problem is that the conditions that created the broken links have not changed. Content keeps being published, external sites keep disappearing, editors keep pasting URLs with typos, and the next platform upgrade is always on the calendar. Within a few months the list starts filling again, usually without anyone noticing, because the person who ran the audit has moved on to other priorities. The realistic goal is not a site with zero broken links at a moment in time. It is a site where a new broken link is noticed within days rather than discovered by a customer a year later, and where fixing it is a routine task instead of a rescue operation.

The cadence question has a practical answer that depends on the site. A brochure site that changes twice a year can be checked monthly. A publication that posts daily and links out heavily benefits from weekly or continuous checks, because outbound links start failing from the day they are published. An e-commerce catalog with products going in and out of stock needs its internal links checked after every catalog change, since a product page that disappears leaves broken links in categories, recommendations, and campaigns. The article on how often to audit for broken links lays out a way to pick a schedule based on change rate, link volume, and how much revenue or reputation depends on the pages involved.

Continuous monitoring is the logical end point of that reasoning. Instead of a person remembering to run a crawl, a service checks the site on a schedule, compares each run with the previous one, and only reports what changed. That turns the output from a long list into a short stream of new failures, which is far easier to act on. The important design choices are the same whether you build this in-house with scripts or use a dedicated tool: check the links that matter most often, retry before alerting, group failures by cause, and route each alert to the person who can actually fix it. Our article on turning a broken link report into a fix plan covers how to keep that stream from becoming another ignored notification channel.

Building a Fix Plan and a Team Workflow

A raw broken link report is not a plan. It is a list of symptoms, often thousands of lines long, in which one missing image file referenced from a shared footer can appear as many failures as there are pages. The first step in turning it into something actionable is to group by root cause. Failures with the same destination URL are one fix. Failures that share a pattern, like every URL under an old directory, are one redirect rule. Failures that come from a single template or component are one code change. After grouping, a report of several thousand entries frequently collapses into a few dozen real problems, which is a number a team can actually look at in a single meeting.

Prioritization comes next, and it should be driven by impact rather than by count. A broken link in the main navigation, in a checkout flow, or on a page that receives most of the site's search traffic matters more than a dead citation in a five-year-old blog post. Internal links generally rank above external ones because they are fully within your control and carry direct ranking consequences. Links on pages with strong backlinks matter because the authority they pass is being lost. Our guide to turning a broken link report into a fix plan proposes a simple scoring approach that combines page importance, link placement, and fix effort, and the comparison of internal versus external breaks helps decide how deep to go on outbound references.

Finally, the work needs an owner and a home. Broken links cross team boundaries: developers own redirect rules and templates, content editors own the body copy, marketing owns campaign landing pages, and nobody owns the external web. A workable process assigns each category of fix to a role, sets a target for how quickly critical failures get resolved, and reviews the backlog on a regular rhythm alongside other maintenance. Recording the fix that was applied, not just closing the ticket, prevents the same URL from being redirected three different ways by three different people over the years. Small teams can run this from a shared spreadsheet; larger ones usually route alerts into their existing issue tracker so that broken links are handled with the same discipline as bugs.

Further reading from the LinkRotly blog, each answering one specific question in depth.

Broken links are not a crisis, which is precisely why they are neglected. They rarely take a site down, and no single one of them changes a business. What they do is compound: each dead link costs a little trust, a little crawl budget, a little authority, and a few visitors, and over the life of a site those small losses add up to something that shows in rankings and in revenue. The good news is that the whole problem is tractable. Understand the types of failure, detect them with a layered approach that goes beyond a single crawl, fix each one with the right tool instead of reflexively redirecting everything, guard the high-risk moments like migrations with a real plan, and replace the annual cleanup with monitoring that notices new breaks while they are still cheap to fix. The articles linked throughout this guide take each of those steps further. Whatever tooling you choose, the habit of looking is what matters most.

Frequently asked questions

What counts as a broken link?

Any link whose destination cannot be reached or no longer serves what the link promised. That includes hard failures such as 404 and 410 responses, server errors, DNS failures and timeouts, and softer cases such as pages that return a 200 status but display a not-found message, redirects that dump the visitor on the home page, and citations whose content has changed beyond recognition.

Do broken links directly lower search rankings?

There is no single penalty for having broken links, but they do harm rankings indirectly. They waste crawl budget, interrupt the flow of link authority between pages, and increase the chance that visitors bounce back to the results page. A few stray 404s on old content are normal; broken links in navigation, in key content, or across a large share of the site are the ones that show up in performance.

How often should a site be checked for broken links?

It depends on how fast the site changes and how many outbound links it carries. Small, static sites can be checked monthly. Active publications, stores with changing catalogs, and sites that link out heavily benefit from weekly or continuous monitoring, and every site should be checked immediately before and after a migration, redesign, or platform change.

Find broken links before your visitors do

Continuous broken link monitoring for websites.

Scan my site