Why do anchor links and in-page jumps break silently without ever reporting a 404 error?

The part that breaks never reaches the server

When someone clicks a link to /pricing#enterprise-plan, the browser opens a connection and asks for /pricing. Everything from the hash onward stays on the client. The server has no idea which section was wanted, returns the whole page with a 200, and only then does the browser look through the rendered document for an element whose id matches the fragment. Two things happened: an HTTP request that succeeded, and a lookup inside the page that quietly failed. Ordinary link checkers report the first one, because the first one is all the network ever saw.

That split explains the silence. Server logs show nothing unusual. The 404 report is empty. Analytics records a normal pageview on a page that loaded fine. The visitor lands at the top of a long article instead of the section the link text promised, scrolls for a while or gives up, and the whole event looks like an ordinary bounce. This is why anchors rot for years on documentation sites, long guides, support hubs, and any page with a table of contents, which are exactly the pages where deep links carry the most traffic. Related: How do you handle broken external links on sites you do not control?

Keep reading: When to Run a Full Link Audit, How a Site Crawl Actually Works, Reading a Redirect Chain Map. See how DeadLinkr helps you on demand link and redirect audits for seo.

Five ways an id disappears without anyone noticing

First, and by far the most common: ids generated automatically from heading text. Change a heading from Refund policy to Refunds and returns and the id changes with it, so every link ever published to #refund-policy now lands at the top of the page and still returns 200. Second, a restructure moves a section to a different page. A redirect handles the path, but the id either travelled with the heading or got regenerated on arrival. Third, duplicate ids, which happen when two sections end up with the same title. The browser takes the first match, so the link works and goes to the wrong place, which is worse than doing nothing at all.

Fourth, case and encoding. Fragments are matched exactly, so #Section-Two does not find id="section-two", and ids containing accented characters, ampersands, or spaces get percent-encoded differently depending on where the link was authored. A link pasted from a browser bar and a link typed by hand can point at the same heading and behave differently. Fifth, timing. If the target sits inside a tab, an accordion, or a block that a script renders after load, the browser looks for the id before it exists, finds nothing, and never tries again. The same applies to sections behind lazy loading further down a long page.

How to test anchors properly

A real check has to do what a browser does, in two steps. During the crawl, keep the fragment instead of discarding it, and record which page the link came from. Then, for every target, fetch that document and confirm an element carries a matching id, or a legacy name attribute on an anchor tag. Same-page and cross-page anchors both need this. Cross-page ones deserve more attention, because they survive path redirects perfectly well and can end up pointing at a page whose entire heading structure was rewritten in a redesign nobody flagged as risky. Related: When to Run a Full Link Audit

Pages that assemble content with JavaScript need a rendered check. A raw HTML fetch returns the empty shell and reports every anchor on the site as broken, which is how teams learn to ignore the whole category. Run those pages through a renderer, wait for the network to settle, then query the resulting DOM. It is worth flagging two more states separately: duplicate ids in one document, and ids that exist but sit inside a collapsed or hidden element. Both pass a naive test and both still fail the reader, so we treat them as their own severity rather than a clean pass. Related: Auditing a Large Site Without Missing Pages

Fixing them, and keeping them fixed

You cannot redirect a fragment on the server, because the server never receives it, so the fix has to live inside the page. When a heading gets renamed, keep the old id alive. An empty span carrying the previous id, or a second id attribute alongside the new one, costs nothing and preserves every link that was ever published, including the ones in old newsletters, exported PDFs, support tickets, and on other people's websites. Where a section moved to another page entirely, leave a short stub heading with the old id and a sentence pointing readers to the new location.

Prevention is mostly a policy decision: stop letting headings generate their own ids for anything you link to. Set those by hand, then treat the id like a URL, meaning it is a published contract you do not edit casually. Add anchor checking to the same routine that checks links, typically quarterly for a stable site and immediately after any content restructure. One last thing that gets blamed on broken anchors and is not one: a sticky header covering the target after the jump. That is a CSS scroll margin problem and it takes a single line to fix. Related: How Broken Links Waste Crawl Budget