Dead links: the check that stops links going nowhere

Why generated pages are full of them

When a model or a template lays out a page before the real content exists, every link needs a target, and href="#" is the easiest one to write. The result looks finished in a screenshot: a navigation bar, “Learn more” under every card, social icons in the footer. Then a visitor clicks “Read the case study” and the page jumps to the top. It's a small failure, but a telling one, because it's exactly the kind of thing a person who checked the page would have noticed. Dead links also waste a search engine's crawl and confuse people using screen readers, who hear “link” and then reach nothing.

Two checks, two jobs

The Critic's version runs in the builder after each build and edit and reports a count, such as “2 dead link(s)”, in the Report tab. It's the stricter of the two for in-page anchors: it follows every # link and looks for an element with that id. The gate's version is the one that stops publishing. If a page fails it, publishing stops with a message saying every design check must pass and naming “every link goes somewhere” as the one that failed. The gate applies to pages; it doesn't read links inside model-written apps, which handle their own navigation.

Fixing a failing link

The gate's own advice is the right list of options: point each link at a page, a section on this page, an email address or a phone number. In practice:

1. Decide whether the link should exist. Many placeholder links were never needed. A “Learn more” under a card that already says everything can simply go.
2. If it should, give it a real target. Another page of the site, a section further down, mailto: for an email address, tel: for a phone number, or the full https address of an outside page.
3. For a missing section, check the id. A link to #menu needs an element with id="menu". If you removed or renamed that section, the link was left behind.
4. Or ask in words, and test it. Describe the change, such as “remove the Learn more links”, then check the Report tab to confirm the count has gone.

How Anticode's own links are built

Pages from the design engine link to sections that exist: the navigation is generated from the sections the page actually has. On a site with separate pages, links are written as in-page anchors first and then rewritten to point at the page each section lives on, so “Contact” in the header of the About page leads to the contact page rather than to a missing anchor. So a fresh design-engine page normally passes. If the check does fail, look first for a link to a section that's no longer on the page. Read more about structure in multi-page sites.

Limits

• No link crawling. Neither check requests outside URLs, so a link to a page that has since moved or closed isn't caught. Click through the outside links yourself before launch; the website launch checklist has a step for it.
• Spelling isn't checked. A link to https://instagarm.com/… is a real-looking URL and passes.
• Missing anchors only warn. A #section with no target is reported by the Critic but doesn't stop publishing.
• Apps aren't covered by the gate's link rule. App builds are checked by their own code gate instead.

Questions people ask

Why is href="#" treated as dead?

Because it goes nowhere: clicking it only jumps to the top of the page. It's almost always a link that was meant to be filled in later.

Does the dead links on website check test outside URLs?

No. It reads the page's own markup. It doesn't fetch other sites, so a broken outside link isn't detected.

Can I publish with a link to a missing section?

Yes. The Critic reports it, but the design gate only refuses empty, # and javascript: links. Fixing it is still worth the minute it takes.

Do mailto and tel links pass?

Yes. They lead somewhere, which is all the check asks.