Your Broken Link Report Is Hiding the One Failure That Costs Customers

A broken-link report can contain 5,000 dead URLs and still fail to identify the one broken path worth fixing first. The important failure may be a booking button, a product document, a pricing link or the only route to evidence a buyer needs. Its status code is no more broken than the other 4,999. Its consequence is completely different.

A correct 404 can still sit behind a broken promise

Not every missing URL is a defect. URLs are requested because old links survive, bots invent paths, people mistype addresses, products retire and websites change. A resource that never existed, or permanently disappeared without a suitable replacement, can correctly return 404 Not Found or 410 Gone. Google says ordinary 404 responses generally do not harm a site’s indexing or ranking, and that returning a missing response is appropriate when a page no longer exists and has no replacement. Google’s guidance on 404 errors is useful because it removes the superstition that every red row is an SEO emergency.

The source page changes the judgement. If a live service page still offers Book an assessment, the business has made a current promise. If the button goes to a missing URL, the 404 may be technically honest while the website design remains operationally false. The same applies to Download the specification, View prices, Check eligibility or See the evidence. The dead destination is only half the finding. The live promise creates the priority.

Error count is a terrible proxy for customer harm

Crawler exports are naturally organised around URLs and response codes. Businesses are organised around customers, products, services and responsibilities. Confusing those views makes volume look like importance. A template error repeated across 2,000 low-value archive links may deserve a systematic fix. One broken payment route may deserve an immediate intervention. A hundred requests for invented bot URLs may deserve no repair at all. I do not average these consequences into a generic site-health score.

This is where SEO, conversion rate optimisation and customer acquisition overlap. Search visibility can deliver a visitor to the page. The page can explain the right offer. One failed route can then prevent the person from completing the next meaningful action. Ranking reports will not necessarily expose that moment, and a final-form conversion audit may start too late. The priority question is: what was the person entitled to expect at this point in the journey? That expectation may be commercial, informational or procedural. The person might be trying to buy, book, compare, verify, log in, understand a restriction or reach support. Name that task before assigning urgency.

Verify the path before escalating it

Human consequence matters only after the failure is credible. A crawler row, analytics anomaly, customer report or screenshot can trigger investigation. None should automatically become a P0 ticket. Context changes results: authentication, location, device, cookie state, JavaScript, temporary outages and security controls can all affect what a checker sees. Before prioritising a broken path, create a compact verification receipt:

• controlled source page, component, campaign or document;
• visible link label or promised action;
• exact destination or expected result;
• observed response or failure behaviour;
• relevant browser, device, authentication or access context;
• whether the failure repeats;
• whether one source or a reusable component publishes the route;
• date and person or system that verified it;
• known uncertainty.

This receipt is deliberately smaller than a full diagnosis. It establishes that the path failed and preserves enough context for the right owner to act. It does not decide whether the cause is a deleted page, bad route, malformed fragment, blocked script, faulty template or misconfigured redirect. I want verification before priority because urgency has a habit of laundering weak evidence. One dramatic screenshot can mobilise five people around a failure nobody can reproduce.

Rank the consequence without pretending it is mathematics

I use a Broken Path Triage with seven questions. They are qualitative fields, not points to total.

The method resists a common failure in performance marketing: turning every judgement into a score because dashboards prefer arithmetic. A confirmed broken checkout cannot be averaged down because it appears once. Ten thousand unverified requests do not become important through multiplication. Use the fields to explain the decision. Do not let the score make it for you.

Give the repair queue consequences, not colours

A practical queue can use priority bands, provided each band has a bounded meaning and a first receiver.

Two further states sit outside the ladder. Valid absence applies when no legitimate live promise, owned destination, user need or suitable successor is established: no repair, but retain the decision basis. Hold applies when the failure, scope, action status or ownership remains unresolved, and it belongs to a named verification owner. These are operating judgements, not classifications supplied by Google. Their purpose is to stop a technically large list from concealing a commercially decisive failure.

The first receiver also matters. Sending every issue to “the developer” treats a business decision as a coding task. A developer can repair a URL but should not have to decide whether an obsolete offer remains available, whether a specification has a legitimate replacement or whether an old guarantee should still be public.

A live page is not automatically a valid replacement

The fastest way to make a broken-link report quieter is to redirect dead URLs somewhere that returns 200 OK. The fastest way to damage the customer journey is to mistake “alive” for “equivalent.” A booking promise sent to the homepage still breaks the booking task. A discontinued product sent to a broad category may create false availability. A detailed proof reference sent to an About page can preserve traffic while destroying the evidence relationship.

Google’s crawling guidance distinguishes content with a clear replacement from content that is permanently gone. A permanent redirect can be appropriate when a resource genuinely moved or has an equivalent successor; a missing response can be correct when it does not. Google’s crawling-error guidance supports the technical boundary. The business still has to decide whether the proposed destination fulfils the same human job. Record successor status explicitly: equivalent successor confirmed; destination should still exist; business action retired; no equivalent confirmed; or owner decision required.

I would rather leave a valid 404 than redirect a precise promise into a vague page and call the problem solved.

Broken proof is different from broken navigation

Two links can fail identically in the browser while requiring different decisions. A broken navigation link usually interrupts movement. A broken evidence link can leave a claim standing after its support disappears. A broken price link may conceal current commercial conditions. A broken policy link can affect consent or customer rights. A broken download may be the only route to technical information needed for product fit. That means the repair owner should understand the semantic job of the destination.

For evidence, ask whether the public claim can remain while the source is unavailable. For pricing, ask which current version is authorised. For forms and bookings, verify the complete action rather than the destination page alone. For login or payment, treat security and transaction integrity as part of the repair, not obstacles to a quick redirect. This is also an AI-readiness issue in the least theatrical sense. A public explanation is harder to verify when its supporting routes fail. Fixing those routes can improve the website for people and make evidence easier for systems to retrieve. It does not guarantee an AI citation, recommendation or ranking improvement.

Fix the generator when the failure repeats

Repeated failures require a source-level decision. If one reusable card, menu, template, feed or publishing process emits the same broken route across many pages, editing each occurrence wastes effort and invites inconsistency. Preserve a few representative failures, identify the common generator and route the problem to its owner. Do not infer the generator from count alone. Thousands of crawler rows can reflect historic URLs from many sources. Conversely, a component used on only six high-value service pages may deserve prompt attention because every instance interrupts a primary journey. My standard is verified repeated production, not a large spreadsheet.

Once the source is known, define acceptance criteria before changing it. Which routes should be emitted? Which should disappear? What should happen where no successor exists? Which page families are in scope? How will the team confirm that the repair did not redirect unrelated URLs or alter current navigation? That last question turns link repair into a controlled website change rather than mass search-and-replace.

Make the handoff preserve the blocked person

The most useful broken-link ticket is not Fix 404 on /old-page/. It preserves why the route matters. Use a handoff like this: On (verified source), the link labelled (promise) repeatedly produces (observed failure) under (context). This interrupts (defined audience) while they are trying to (decision or action). Successor status is (state). The (business owner) must confirm the intended destination or retirement decision; the (technical or page owner) must implement and verify the authorised route.

That sentence keeps the customer inside the technical work. It also prevents an SEO agency, developer or content editor from silently making a commercial decision outside its competence. For customer acquisition routes, test the complete path after repair. A button returning 200 is not enough if the form fails, calendar has no availability, telephone link is malformed or confirmation never appears. The promise ends where the user’s task ends.

Start with the page whose promise still matters

Do not set the team a target of “zero broken links.” Set a target of no verified broken path obstructing an important current decision. Start with primary actions, payment, access, safety, price, eligibility and decisive proof. Then inspect high-exposure navigation and repeated components. Confirm replacements rather than redirecting everything somewhere alive. Leave valid absences alone.

The result may be a crawl report that still contains missing URLs. That is not failure. A healthy website can return honest 404 responses. The failure is leaving a live promise attached to a route that cannot fulfil it, or spending the week polishing an error count while a customer keeps finding the door locked.