Broken Link Audit

The Broken filter combines destinations that returned unsuccessful responses. Use Client Errors (4xx) and Server Errors (5xx) to separate unavailable targets from server failures. Success (2xx) provides the healthy comparison set.

Diagnose the destination and the source

A 404 can represent an intentionally removed page, but a source page still linking to it gives visitors a failed path. A 403 can be intentional access control or an accidental firewall block. A 429 can indicate rate limiting. A 5xx response can be temporary or a repeated application failure.

1. Open the destination and confirm its current status.
2. Review every Source Page and identify how the link is generated.
3. Decide what the user expected from the link.
4. Check whether a close replacement exists and satisfies the same purpose.
5. Group repeated failures by source template and destination pattern.
6. Distinguish external ownership from URLs you can restore or redirect.

<!-- Broken -->
<a href="/old-pricing">Pricing</a>

<!-- Corrected at the source -->
<a href="/pricing">Pricing</a>

Choose the right fix

• Update the source link when the intended resource has a known current URL.
• Restore the destination when it should still exist.
• Add a redirect when an old public URL has a true replacement and legitimate inbound use.
• Remove the link when its purpose no longer exists.
• Replace an unreliable external source only with an authoritative equivalent.
• Investigate server or access controls for repeated 403, 429, and 5xx patterns.

Do not redirect unrelated missing URLs to the homepage, and do not remove a valuable citation solely because one request failed temporarily.

Example decision

A footer link returns 404 and appears on every page. The policy moved to a new URL with the same purpose. Update the shared footer link and keep a permanent redirect from the old public URL. One template change resolves every source while the redirect protects external traffic.

Verify the fix

Inspect representative source pages, confirm the link resolves to the intended final 2xx destination, and run a new crawl. Check both the Broken filter and the relevant status group. For external links, verify stability over time before making a broad replacement.

Diagnose the failure before replacing the link

A broken-link audit should identify why the destination failed. A 404 may be a genuinely deleted page, a mistyped path, or a temporary deployment mismatch. A 403 can indicate access controls or bot protection. A 429 points to rate limiting, while a 5xx response usually needs server-side investigation. Network and TLS failures can also produce a Broken result without a normal HTTP status.

Open a small sample, then group affected rows by destination and source template. If one target is linked from 600 product pages, repair the component once. If 20 unrelated URLs fail, investigate migration rules, URL generation, or content governance.

What should happen after a fix?

After replacing or removing links and running a new crawl:

• 4xx and 5xx counts should fall.
• Successful 2xx links may rise because repaired destinations now resolve normally.
• Redirect counts may rise temporarily if you use redirects during a migration.
• The total link count may fall when obsolete links are intentionally removed.

Do not judge success from the broken count alone. Confirm that important source pages still contain a useful path to the intended content.

Example decision

Suppose /pricing-old returns 404 from the header. If /pricing is the direct equivalent, update the header link to /pricing. A redirect can protect old bookmarks, but internal links should still point directly to the final URL. If no equivalent exists, remove the item or link to the closest useful category; do not send every deleted URL to the homepage.

HTTP status classes are defined in MDN's status-code reference. For search migrations, also review Google's redirect guidance.