How to Find and Fix Broken Internal Links

A broken internal link is a link on your own site that points at a page that no longer returns a working response, usually a 404. It looks like a small cosmetic bug, a dead click a reader runs into once. It is worse than that. This guide is for the in-house SEO, solo marketer, or technical founder keeping a growing site in order, and it covers three things: how to find every broken internal link, how to tell a genuinely dead link from a false alarm, and how to pick the right fix for each one.

The short version

• A broken internal link does not just waste a click. It wastes crawl budget and cuts a path Google uses to discover and recrawl your pages.
• Find them two ways: crawl the whole site for bulk coverage, or check a single page in one click while you are editing it.
• Not every link a tool flags as broken is dead. Some servers refuse the automated check while serving a real browser fine.
• Fix by correcting the URL, redirecting, or removing the link, and the right choice depends on what happened to the target.

What does a broken internal link actually cost you?

Three things, and only one of them is the dead click readers notice. The first cost is crawl budget. When Googlebot follows an internal link to a 404, it spends a request learning the page is gone instead of learning something useful about a page that exists. On a large site, that adds up, which is why Google's own guidance on managing crawl budget treats wasted crawling of error pages as a real drain.

The second cost is reader trust. A link that lands on an error page tells a visitor the site is not maintained, right at the moment they were following your recommendation to somewhere else.

The third cost is the one most articles skip, and it is the one that matters most on a smaller site. A broken internal link is a severed discovery edge. On this site, internal links are the only discovery path I have measured that reliably works: new posts get found and recrawled through inbound links from pages Google already knows, not through the sitemap. When an internal link breaks, Google does not just hit a dead end for a reader. It loses a route it was using to reach the page on the other side. A link to a 404 is a wasted click. A broken link into a page you care about can quietly keep that page from being discovered at all. That reframing changes the priority. Fixing broken internal links is not tidying, it is protecting the way your site gets crawled.

Why do broken internal links keep appearing?

Because the thing a link points at keeps moving, and the link does not move with it. Broken internal links are generated by ordinary site maintenance, so they come back.

• A page gets renamed or its slug changes: every old link to the previous URL now points at nothing.
• A page is unpublished or deleted: drafts pulled back, outdated posts removed, products retired, each leaves inbound links hanging.
• A URL is mistyped at the source: a trailing slash, a wrong folder, a staging link that never got cleaned up.
• A section is restructured: moving /guides/ under /resources/ breaks every link that still uses the old path.

The pattern to take from this list: broken links appear whenever you move, rename, or remove a page. That is why a one-off cleanup never holds, and why the fix is a habit rather than a project.

How do you find broken internal links across your whole site?

Run a crawler that reports the HTTP status of every internal link on the site. A crawler starts at your homepage, follows links page by page, and records the status code each link returns. The links that come back 404 (not found) or 410 (gone) are your broken internal links. The ones returning 301 or 302 are redirects, which are not broken but are worth cleaning up so links point at the final URL directly.

The common tools for a full-site pass:

• Screaming Frog: crawls the site and lists every internal link by response code. Filter to client errors to see the 404s, then use the "inlinks" view to find which pages contain each broken link.
• Google Search Console: the Pages report under Indexing flags Not found (404) URLs Google has tried to crawl. This is Google's own view, so it is the most authoritative signal for what is actually being hit, though it lags and does not show you which page links to the dead URL.
• A dedicated internal link crawler: several tools focus only on the internal link graph. Our roundup of internal link checker tools compares what each one surfaces.

Reconcile the two signals. Search Console tells you which dead URLs Google has already met. A crawler tells you which live pages still link to them, which is what you actually need to fix the link. Status codes matter here, so it helps to know what each one means. Google's reference on HTTP status codes and how Search handles them is the primary source.

How do you check the links on one page in a single click?

Use a browser extension that reads the links on the page you are looking at, without crawling the whole site. A full crawl is the right tool when you want bulk coverage. It is the wrong tool when you have one page open in the editor and you just want to confirm its links resolve before you publish. For that, a per-page check is faster, and you can run it the moment you finish writing.

This is the check that belongs inside editing rather than in a separate audit. A page you just touched is the page most likely to carry a link you just broke, and it is already in front of you.

Is it a real 404, or a false positive?

Not every link a checker flags as broken is actually dead. Some servers return a 403 (forbidden) or 429 (too many requests) to an automated checker while serving the exact same page perfectly to a human browser. That is anti-bot behavior, not a broken link. The page works. The checker was simply refused.

This distinction is the reason we built it into Hasten LinkLens. Most broken-link tools collapse both cases into one "broken" label, and that creates false positives: you open a fix cycle for a page that was never broken, waste time confirming it loads, and learn to distrust the tool. LinkLens reports the two states separately. A genuinely dead link is one thing. A link where the destination refused the automated request is another, and it usually needs no fix at all beyond a manual check in your browser.

When I first started checking our links in bulk, several of the results flagged as "broken" were pages that opened without a hitch in a normal tab. They were external destinations throttling the checker. Treating a refused check as a confirmed 404 is how a cleanup pass ends up editing links that were fine. So before you change anything, separate the two:

• Genuinely dead: the URL returns 404 or 410, and it also fails when you open it yourself in a browser. This needs a fix.
• Refused check: the checker reports an error, but the page loads fine when you visit it. This is usually an anti-bot response on the destination, and the link is working.

The test is simple: open the flagged URL in a fresh browser tab. If it loads, the link is not your problem to fix.

How do you fix each broken internal link?

Pick the fix by what happened to the target page, not by habit. There are four clean outcomes, and choosing the wrong one creates new problems, such as a redirect chain where a direct link would have done. The decision table:

What happened to the target	The right fix	Why
The URL was mistyped or malformed	Correct the link at the source	The cleanest fix. The page exists, the link just pointed at the wrong string.
The page moved to a new URL	Update the link to the new URL, and 301-redirect the old one	Point the link directly at the live page so there is no redirect hop, and keep the redirect for any links you miss.
The page is gone, but an equivalent exists	Re-point the link to the closest relevant page	Preserves the reader's path and the internal link equity, sending both somewhere useful.
The page is gone with no replacement	Remove the link, keep the surrounding text	A link to nothing helps no one. Delete the anchor, not the sentence.

On redirect versus direct update: if a page moved, update the internal link to point at the new URL directly, and use a redirect to catch links elsewhere you have not fixed yet. A link that fires through a 301 still works, but it costs a hop and compounds into a chain if the target moves again. For the difference between a permanent and a temporary redirect, and when each is correct, see our guide to the 301 vs 302 redirect choice.

When not to redirect: do not 301 a deleted page to your homepage just to clear the 404. Google treats an irrelevant redirect as a soft 404, so you gain nothing and lose the signal that the page is genuinely gone. If there is no relevant destination, let the URL return a real 404 and remove the internal links pointing at it.

How do you keep broken internal links from coming back?

Build the check into the moments that create broken links, instead of running a cleanup every few months. Since broken links appear whenever a page moves, is renamed, or is removed, that is exactly when to check. A recurring cadence catches what slips through.

Check at the point of change: When you rename or move a page, search your own content for links to the old URL before you ship. When you unpublish a page, find what linked to it. When you publish a new post, confirm its outbound internal links resolve.

Run a full crawl on a schedule: Monthly for an active site, quarterly for a slower one. A crawl catches the links that changed without your noticing, including ones broken by a destination you do not control.

Watch Search Console: The Not found (404) list in the Pages report is a free, ongoing signal of dead URLs Google is still trying to crawl. Review it when you review coverage.

The same discipline keeps the rest of your link graph healthy. Broken links are one failure mode; orphan pages with no inbound links at all are another, and both come down to maintaining the connections between your pages. The broader structure is covered in our guide to internal linking.

How do you find and fix them across a whole site with GrowthHasten?

GrowthHasten crawls your pages and maps your internal link graph, so the broken connections sit alongside everything else that needs attention rather than in a separate tool. Sign up with your domain and it runs 130+ deterministic checks across your site, and the Links section shows your internal link graph and where a link would help. Site Audit scores every page and ranks what to fix first, so a broken link is weighed against the rest of your technical health instead of being treated in isolation.

It is a free plan: one website of up to 900 pages and three re-analyses, no card and no trial clock. Connect Search Console and it reads up to 16 months of your own query data alongside the crawl, and GA4 adds the engagement side. For the fast, per-page check while you edit, Hasten LinkLens stays the quicker tool. For the whole-site view of what to fix in what order, the product is where a broken link becomes one line on a prioritized list.

The single habit that keeps this from ever becoming a project again: check a page's links the moment you finish editing it, while it is still open. It costs seconds and catches the link you just broke before anyone else meets it. This week, pull the Not found (404) report in Search Console and crawl your five most-linked pages, then fix whatever points at a real 404. Start where your links concentrate, because that is where a severed discovery edge does the most damage.