How to Find and Fix Broken Links: A Prioritized Approach

To fix broken links properly, first be clear about what counts as broken. A broken link no longer reliably leads to the content its anchor text and context promise. That can be an internal link to a deleted page, an external source returning an error, a redirect loop, a server error or a link that technically responds but ends up at the wrong destination.

A useful audit therefore does not only ask "Which URLs return 404?". It also asks: Where is the link? How important is the source page? Which destination was intended? Has the content been removed permanently, moved or is it only temporarily unavailable? Only then can you decide between correcting, redirecting, replacing, removing and monitoring. After reading, you can assess every finding this way and choose the right fix.

What counts as a broken link

The obvious case is a link to a URL returning 404 Not Found. In practice, other error patterns belong here too:

• 410 Gone, when content was deliberately removed for good
• 500, 502 or 503, when the target is unreachable because of a server problem
• redirect loops or overly long redirect chains
• internal links to an HTTP version when HTTPS is the correct target
• links to a domain that has expired or been taken over
• anchor links to a section ID that no longer exists
• JavaScript interactions that look like links but have no crawlable href
• soft 404 pages that return 200 OK although there is no meaningful content

A status code on its own therefore only describes part of the problem. Even a technically successful link can drop users in the wrong place.

Assess internal and external links separately

With internal links, your team controls both source and target. An error can disrupt navigation, crawling, internal signals and the path to an important action. The glossary entry on internal linking explains why internal links carry so much weight. These links can usually be corrected directly at the source.

With external links, the target belongs to another website. An outage can be temporary, the source may have moved or the content may be gone entirely. Different options apply here: find a new primary source, link to a current version, support the statement differently or remove the link.

External links should not be deleted just because they do not promise a direct ranking benefit. If a statement needs a source, the editorial question matters more: is there a better and more current reference?

Reading status codes correctly

The most common responses mean different things:

• 200 OK: The request succeeded. That does not yet prove that content and destination are right.
• 301 Moved Permanently: The target has moved for good. Internal links should usually point straight to the final URL. The glossary covers the 301 redirect in more detail.
• 302 or 307: Temporary redirect. Check whether the temporary state is still intended.
• 404 Not Found: Nothing was found at this URL. That can be correct for deliberately removed content.
• 410 Gone: The content was intentionally removed for good.
• 429 Too Many Requests: The checking client was rate limited. A single crawl can produce a false alarm here.
• 500, 502, 503: Server or service errors. Repeat the test and check timing and frequency.

Google does not treat 4xx responses as content for indexing and drops already indexed URLs over time. That does not mean every 404 URL causes "SEO damage". It becomes a problem mainly when important internal links or sitemaps still lead there, or when users can reasonably expect an existing replacement. The glossary entry on redirects and status codes explains which status code is right when.

Tools for a broken link check

A thorough check does not require an expensive specialist tool, but it does need the right combination. These tools cover the most important cases:

• Google Search Console. Free. The Page indexing report shows URLs Google found with a 404 or as a soft 404. It is not a complete link check, but it reveals which broken addresses Google itself knows about.
• Screaming Frog SEO Spider. A desktop crawler that follows every internal link and lists broken targets together with their source pages. The free version checks up to 500 URLs. Larger sites need a license.
• W3C Link Checker. A free online service from the W3C that checks the links on individual pages. Good for spot checks, too slow for whole websites.
• Browser extensions. Extensions such as Check My Links for Chrome highlight broken links on the page you have open. Handy when reworking individual articles.
• Server logs. They show which broken URLs are actually requested, including by visitors coming through old external links.
• A regular site crawl. For ongoing control you need a crawler that checks the whole site at fixed intervals and stores comparable results. The end of this article shows how that works in Crawl Foundry.

A reliable audit workflow

1. Use more than one data source

A site crawl shows links the crawler finds through internal paths. Server logs show actual requests. Search Console can provide indexing and crawl hints. Analytics or product data show which paths people use. No single source automatically contains the whole picture.

For a first check, these are usually enough:

• an internal crawl
• a comparison with the XML sitemap
• a check of important templates and navigation
• spot checks in a browser and an HTTP client
• Search Console and server data, where available

A crawler can see a different status than a normal visitor because of rate limits, authentication or bot protection. Suspicious targets should therefore be checked again, with the time documented.

2. Store source, target and context

A list of target URLs is not enough. For every occurrence you need at least:

• the source URL
• the link text, in other words the anchor text
• the target URL
• the HTTP status and final destination
• whether it is internal or external
• its position or page element
• the number of occurrences
• the page type and business importance

A broken footer link on 5,000 pages has a different reach than a single outdated source link in an old article. A link to the pricing page is more urgent than a link to optional background reading.

3. Choose the right action

For internal links, this usually applies:

• correct the wrong URL directly at the source
• link to the most suitable existing content
• only set up a redirect when a genuine replacement exists
• delete a deliberately removed link if no replacement makes sense
• shorten redirect chains to the final destination

Do not redirect every unknown URL to the homepage. It disappoints the user's expectation and can be treated like a soft 404. A 404 or 410 is correct when the content has been removed permanently and there is no equivalent replacement.

For external links, the options also include replacing the source, switching to official documentation, updating the statement or removing a paragraph that can no longer be supported.

4. Crawl again after the fix

A change in your CMS or repository does not prove that the public page responds correctly. After the release, check:

• the affected source page
• the final link target
• the status code and redirect chain
• the canonical and indexability of the replacement
• navigation and the mobile view
• the sitemap, if it was affected

With many occurrences, a targeted re-crawl of the affected directory is also worthwhile. After a relaunch, the link check belongs in your website migration checklist anyway.

Prioritize instead of just counting

The number of errors is rarely the best order. A practical priority model considers:

• Reach: how many pages or user journeys are affected?
• Importance: does the link lead to a purchase, sign-up, documentation or a central topic hub?
• Control: can the team change the source and target itself?
• Replacement: is there a clear, suitable destination?
• Risk: is it a server error, a taken-over external domain or just an outdated anchor?
• Effort: can the cause be fixed once in a template, or only one by one?

Template errors, broken main navigation and important internal targets usually belong at the top. External sources with temporary errors can be rechecked first. Our guide to the SEO audit shows how link errors fit into a complete audit.

Content review belongs to it

A link error can be a symptom of outdated content. If several sources no longer exist, product names have changed or a guide refers to interfaces that are gone, replacing individual URLs may not be enough.

Then the page needs an editorial review: is the statement still correct? Is there a current primary reference? Does the article still serve the same search task? That decision should come from the content, though, not from an automatic "refresh" status.

How Crawl Foundry helps

Crawl Foundry Site Audit crawls your website and shows links to targets with error status, redirect chains and empty anchor texts as findings with the affected URLs. The internal links view shows, for every link, which page it comes from, which anchor text it carries and where on the page it sits. That lets you quickly see whether many broken links come from the same template, such as the footer, and fix the cause once instead of on every page. With a saved view for broken targets, you check after the next crawl whether the errors are gone. The documentation on issues, pages and links shows how findings, Page Explorer and internal links work together.

No tool decides for you whether a 404 is intended or which redirect fits. That takes knowledge of the website and clear responsibility within the team.

How to check and fix broken links step by step

Checking broken links means more than counting 404 errors. Store source, target, anchor text and context for every finding, assess internal and external links separately and prioritize by reach and importance. Fix internal links at the source, only redirect when there is a matching destination and confirm every fix with a new crawl.

Start with one important page and record all of its links with source, target, anchor text and context.