Open a link incident with the exact broken transition
Write the failing transition as source, visible label, expected destination job, observed result, and date. Examples include an article that cannot be reached from navigation, an anchor that predicts the wrong answer, a redirect chain ending on a generic hub, or a control that works with a mouse but exposes no usable destination. Attach rendered HTML or DOM evidence, response chain, canonical target, and a short task observation. The incident artifact is a link-failure tree whose branches test exposure, transport, destination state, semantic match, and human use. Do not begin with ‘needs more internal links.’ Google’s link guidance and W3C’s link-purpose criterion show why technical and semantic failures need separate checks. A count alone cannot identify the broken layer.
Evidence: Google Search Central; World Wide Web Consortium
Stabilize the production path for diagnosis
Freeze template changes affecting the path until the cheapest branch checks are complete; otherwise the incident state will change while it is being diagnosed.
Evidence: Google Search Central; Google Search Central
Branch one: the edge is not exposed
Inspect the rendered source for an anchor and meaningful href. If the interface relies on an onclick handler, button, hover-only menu, or delayed component, determine whether crawlers and keyboard users can reach the same destination. Compare source templates with production output because build and hydration failures can remove an intended edge. This branch is supported when the destination is valuable and healthy but the source exposes no navigable relationship. It is weakened when a normal anchor exists and can be activated, which sends the investigation to transport or meaning. Do not add a second workaround link before understanding why the intended component failed. Google documents crawlable anchor patterns; W3C and direct keyboard checks cover user access that a source-code grep may miss.
The tree records browser state, viewport or menu condition, and reproduction steps so the repair owner can verify the same failure after deployment.
Evidence: Google Search Central; GOV.UK Service Manual
Branch two: transport changes the destination
Follow the href without assuming the label’s URL is final. Record each status code, redirect location, protocol or hostname change, and the eventual canonical declaration. Look for loops, long chains, soft-error pages, tracking parameters that create variants, and links ending on a replacement whose job differs. A transport cause is plausible when the original edge is clear but the request never reaches the intended stable answer. It is weakened when the final URL returns the expected content directly. Update templates to the preferred destination when possible, repair server rules at their owner, and preserve necessary redirects for external references. Repeatedly resubmitting or adding links does not correct a broken chain. Google’s starter and link documentation ground discovery mechanics, but search-engine reports may lag the deployed repair.
Confirm behavior through both an HTTP inspection and the browser path because scripts, consent layers, or client routing can produce different results.
Evidence: Google Search Central; GOV.UK Service Manual
Branch three: label and answer disagree
When the edge transports correctly, compare the prediction created by its text with the destination’s opening promise and usable answer. ‘Check merchant claims’ should not land on a sales page or a broad list of programs. Run a first-choice task and ask participants what they expect before activation, then what job the destination actually supports. W3C’s link-purpose guidance provides the accessibility standard; GOV.UK’s realistic-task practice supports observable comparison. This branch gains support when several readers make the same reasonable but incorrect prediction. It weakens when the label is understood and the destination fulfils it, even if analytics shows low use. Repair the source wording, the destination scope, or the relationship itself. Do not force the anchor to mimic a target keyword at the cost of an accurate expectation.
The incident tree must preserve examples of both correct and incorrect predictions; one surprised participant is a clue, not a population estimate.
Evidence: Google Search Central; World Wide Web Consortium
Branch four: the graph creates loops or dead ends
A set of individually valid edges can still produce a poor route. Map the representative task through its prerequisite and continuation transitions. Identify cycles that return readers to definitions they have completed, hubs that require repeated backtracking, and destination pages with no sensible onward or recovery action. A dead end is not automatically a problem—some jobs legitimately finish—but the page should make completion clear rather than abandoning the reader. This branch is supported when people repeatedly retrace steps or cannot identify how to continue despite correct labels. It is weakened when the route closes the task and no further action is needed. Compare the route with the content ownership map before adding another edge; the loop may reveal duplicated answers or an invented hierarchy.
The repair can remove an edge, expose a direct continuation, or clarify completion. Increasing every page’s outlink count would obscure the graph failure.
Evidence: Google Search Central; World Wide Web Consortium; GOV.UK Service Manual
Choose a cause that the retest can disprove
Complete one branch at a time and write the observation that would contradict the chosen cause. The next action is to populate the link-failure tree for a single important transition and assign the relevant technical, editorial, or accessibility owner. After one reversible repair, repeat the same rendered, HTTP, keyboard, and task checks. Limits remain: a crawler’s route is not a person’s understanding, analytics cannot explain nonuse, and search reports may not reflect a recent deployment. A destination can be technically healthy yet unworthy of a link if it has no distinct answer. Keep the incident unresolved when two branches remain plausible rather than changing all layers at once. Close it when another reviewer can reproduce the former failure, observe the repair, and see why competing explanations were rejected. No ranking outcome is implied by closure.
Sources and further reading
These references informed this article. A source supports a claim; it does not imply endorsement of TenMultigure or any future product reference.
- Link Best Practices for GoogleGoogle Search Central · Accessed August 10, 2026
Google’s crawlable-link guidance supports the incident branches that inspect rendered anchors and distinguish absent exposure from later transport failures.
- SEO Starter Guide: The BasicsGoogle Search Central · Accessed August 10, 2026
Google’s starter documentation informs discovery and final-destination checks without treating a successful crawl as evidence that the route makes sense to people.
- Understanding Link Purpose in ContextWorld Wide Web Consortium · Accessed August 10, 2026
W3C’s link-purpose guidance grounds the label-answer branch, where expected purpose is recorded before the destination is revealed.
- Usability Benchmarking a Website or Whole ServiceGOV.UK Service Manual · Accessed August 10, 2026
GOV.UK’s realistic-task practice supports testing path loops, dead ends, and wrong turns with reproducible prompts rather than relying on click counts alone.
Reviewed by TenMultigure SEO Standards Review. See an error or a source that has changed? Tell the editorial team.
Review method: AI-assisted desk research with editorial checks. Reviewed ; next scheduled review . Converted the diagnostic into a five-layer link incident tree with contradiction tests for exposure, HTTP transport, destination meaning, graph loops, and human task completion.