Find Broken Anchor Links on Your Website

A broken anchor link is the most polite failure mode on the web. The page loads. No error is shown. The browser just... scrolls to the top instead of the section the user expected. Or nothing happens at all. The user assumes they misclicked, tries again, gives up, and leaves. You never find out.

Anchor links - also called fragment links or hash links - are the #section-name part at the end of a URL. They're supposed to scroll the page to a specific element with a matching id. When the element doesn't exist, the browser silently fails.

Why anchor links break

Anchor links are more fragile than regular links because they depend on something inside the page, not just the page existing.

• -Heading text changes - most CMSes and static site generators auto-generate heading IDs from the heading text. Change "Getting Started" to "Quick Start" and the ID changes from #getting-started to #quick-start. Every existing link to that anchor is now broken.
• -Content is moved or deleted - a section gets reorganized into a different page, or removed entirely. The anchor target is gone.
• -Framework rendering differences - some JavaScript frameworks generate heading IDs differently in SSR vs CSR, or add prefixes. What worked in development doesn't match what's in production.
• -Localization - multilingual sites sometimes generate localized heading IDs. A link in English works; the equivalent anchor in another language may not.
• -Manual typos - someone hand-wrote the anchor link and got the ID slightly wrong. #installation-steps vs #install-steps. Both look plausible; only one exists.

Where broken anchors hurt most

Documentation sites

Documentation is the worst place for broken anchors because it's the context where users most rely on them. Long documentation pages use anchor links in their table of contents, in cross-references between sections, and in external links from blog posts, Stack Overflow answers, and tutorials. A documentation site that keeps renaming headings to improve clarity is constantly breaking external references to those sections.

Long-form content with tables of contents

Any long article or guide with a "Jump to section" table of contents depends entirely on anchor links working. If the ToC was generated when the content was first written and hasn't been regenerated since, it's a bet that none of the headings have changed. That's not a safe bet.

Cross-page references

Internal links between pages that include fragments are particularly fragile: /docs/api#authentication requires both the page and the specific section to exist. Regular link checkers catch broken pages. Anchor-aware checkers catch broken sections.

How to find them

Manual checking is nearly impossible at scale - you'd need to visit every page, note every anchor link, then verify each one. A crawler handles this by fetching each page, extracting all fragment links, then checking whether the target element exists in the destination page's HTML. 4F does this as part of every scan - broken anchors are reported alongside broken links and missing assets, so you catch them in a single pass.