Broken Link Checker for WordPress: Find and Fix Broken Internal Links

This guide is about finding and fixing broken internal links specifically: links from one of your posts to another. They’re the ones fully within your control, and the ones most worth keeping clean. We’ll cover why they break, why that costs you, three concrete ways to find them, the redirect-vs-edit decision that trips most people up, and a workflow so you stop fixing the same site twice.

Why internal links break

Internal links rarely break because of anything dramatic. They rot through ordinary editing:

• Slug changes. You rename a post, or tidy a permalink, and every older post that linked to the old URL now points at nothing — unless WordPress or a redirect catches it.
• Deletions. You unpublish or delete a thin post. Anything that linked to it is now a dead link, and WordPress gives you no warning that those links exist.
• Migrations and restructures. Moving to a new permalink structure, merging two posts, or changing your category base can invalidate large batches of internal links at once. These are the events that produce dozens of broken links in an afternoon.
• Typos and hand-edits. A pasted URL with a trailing character, a link to a staging domain that never got updated, an http link on a site that has since moved to https.

The common thread: the link was correct when you wrote it. It broke later, somewhere else, and nothing told you.

Why broken internal links hurt

Three concrete costs, in rough order of how much they matter:

• Wasted link equity. Internal links pass authority between your own pages. A link that resolves to a 404 passes none of it — the equity you intended for a real page evaporates. On a page you actually want to rank, that’s a self-inflicted handicap.
• Poor user experience. A 404 mid-article is a small breach of trust. Readers who hit one are more likely to leave, and they’re right to: it signals the content isn’t maintained.
• Crawl waste. Search engines have a finite appetite for crawling any given site. Internal links that lead to dead ends spend that budget on nothing, and on large sites that means real pages get crawled less often.

None of these is fatal. All of them are avoidable, and fixing them is some of the cheapest SEO hygiene available — no new content required.

How to find broken internal links

There’s no single right tool. Pick based on site size and how often you’ll repeat the check. All three methods below are legitimate; many people use a crawler quarterly and lean on Search Console between runs.

Method A — Crawl the site (most thorough)

A crawler walks your site link by link and reports the HTTP status of every URL it finds. Screaming Frog (free up to 500 URLs) is the standard tool; Sitebulb does the same job. The value here isn’t just the list of dead URLs — it’s that a crawler tells you which pages link to each one, which is the part you actually need to fix anything.

Concrete steps in Screaming Frog:

1. Crawl your site by entering your domain and letting it finish.
2. Open the Response Codes tab. In the filter dropdown, choose Client Error (4xx) — that’s your 404s, plus 403s, 410s, and the occasional 429. While you’re there, Redirection (3xx) is worth a glance for chains worth cleaning up.
3. Switch the side filter to Internal so you’re looking at your own domain, not every external link on the site. (External 404s matter too, but internal ones are the link-equity problem you control.)
4. Click any broken URL, then open the Inlinks tab in the lower pane. The From column lists every page on your site that links to that dead URL — your fix list. The To column confirms the broken target.
5. To work from a spreadsheet, use Bulk Export → Response Codes → Internal → Client Error (4xx) Inlinks. That hands you a row per broken link with its source page attached.

Prioritise by inlink count: a dead URL that 30 posts link to is a bigger leak than one with a single link. The trade-off with crawling is that it’s a manual, periodic job — you run it, fix what it finds, and remember to run it again next quarter.

Method B — Google Search Console (free, already watching)

Search Console won’t hand you a tidy “broken internal links” list, but it’s free, it’s already crawling you, and two reports are useful:

• Pages (Indexing) → the Not indexed section flags Not found (404) URLs Google tried to reach. If a 404 shows up here, something — often one of your own internal links — pointed Google at it. Open the example URLs and check the referring pages.
• Crawl stats (Settings → Crawl stats → “By response”) shows status-code trends over time. A rising Not found (404) count in the weeks after a migration is a clear signal to go crawl.

Search Console is reactive — it reflects what Google has already crawled, so it lags by days or weeks — but it’s the closest thing to a free, always-on monitor you already have running, and it catches links no on-site scan would (people linking to old URLs from off your site).

Method C — A WordPress plugin (on-demand, inside the dashboard)

If you’d rather stay in WordPress, a plugin can scan your content for broken links without exporting anything to a spreadsheet.

One performance caveat is worth understanding before you install the most popular option. The long-standing Broken Link Checker plugin, in its original local form, runs continuous background scanning — it re-checks your links on a schedule, server-side, indefinitely. On shared hosting that load can be heavy enough that some managed hosts (WP Engine and GoDaddy among them) restrict or disallow it outright. The newer cloud version of that plugin solves the load problem by moving the scanning to a third-party service: it sends your link URLs off-site to be checked from external servers, rather than checking them from your own. That’s a reasonable trade for speed, and to be precise about it — the cloud service is checking whether your link URLs respond, not reading or transmitting your post content. But it does mean the check now depends on an outside service and an account.

If neither always-on scanning nor an off-site dependency appeals, look for a plugin that scans on demand — you click “check,” it scans your current content once, it’s done — and runs on your own server. That keeps the work bounded (no background polling) and keeps your data in place.

That on-demand, on-your-server approach is the one I reach for, and it’s part of the same internal-link audit that catches orphan pages — broken internal links and orphans surface naturally in the same pass.

How to fix a broken internal link: redirect or edit?

Once you have the list of broken targets and the source pages linking to them, there are two correct fixes. The whole skill is knowing which one a given link needs.

Fix 1 — Update the link directly. Edit the source post and point the link at the correct URL. This is the cleanest fix: no redirect, no overhead, the link resolves in one hop. Reach for it when the move was a simple slug change and you know the new address, and when only a handful of posts are affected.

Example: You renamed /best-running-shoes-2023/ to /best-running-shoes/. Three old posts link to the dated URL. Open each, fix the three links, done. A redirect here would be solving a three-edit problem with permanent infrastructure.

Fix 2 — Add a 301 redirect. If the destination moved and you can’t easily edit every source, or if dozens of links point at one dead URL, set up a 301 (permanent) redirect from the old URL to the right replacement. One redirect repairs every link pointing at that URL at once — including external links and bookmarks you can’t edit.

Example: You merged five overlapping posts into one definitive guide and deleted the old five. Across the site, 40-plus internal links point at those dead URLs, plus inbound links from other sites. Editing 40 posts by hand is the wrong tool; five 301 redirects (old → the merged guide) fix all of them and preserve the external equity too.

Handling a deleted target. When the page is simply gone with no successor, you have two honest options: redirect to the closest real alternative (the new category page, a related guide, the parent topic), or remove the link and rework the sentence so it reads naturally without it. What you should not do is leave it 404ing or bounce it to the homepage.

A few principles keep every fix clean:

• Redirect to the closest real match, not the homepage. Mass-redirecting 404s to the homepage is a soft-404 pattern Google can treat as a not-found anyway, and it’s a poor experience. Send the link where the reader actually expected to go.
• Avoid redirect chains. A → B → C is slower for users and wastes crawl. Point A straight at C.
• Prefer editing the link when you reasonably can. A direct link always beats a redirect hop. Redirects are for when you can’t edit the source, or there are too many sources to edit by hand.

While you’re already in those source posts, it’s a natural moment to add the right internal links safely — fixing a broken link and adding a relevant working one are the same kind of edit, done in the same place.

A repeatable hygiene workflow

Broken-link checking isn’t a one-time cleanup; it’s maintenance. The aim is a light, repeatable pass — not a heroic annual purge.

1. Run it quarterly, and always right after a migration. Permalink changes, bulk deletions, and platform moves break links in batches. Check immediately afterward, while you still remember what changed.
2. Scan or crawl for internal 4xx links. Use whichever method above fits your site size.
3. Fix each one — edit the link, or 301 the target. Work from the source-page list, not just the dead URLs. A list of broken URLs without their sources is only half the job.
4. Recheck. Confirm the 404s are gone and you didn’t introduce a redirect chain in the process.
5. Log permalink changes as you make them. The cheapest broken link is the one you redirect the moment you rename a slug, before anything points at the old one.

If you’re already in your content doing this, fold in the rest of the audit while you’re there — find orphan pages too, since the same crawl that surfaces broken links also tells you which posts have no inbound links at all. One pass, two problems handled.

FAQ

Do broken internal links hurt SEO?

Yes, in two ways. A 404 target passes no link equity, so any internal links pointing at it are wasted — the page you meant to strengthen gets nothing. And on larger sites, dead internal links spend crawl budget on URLs that return nothing, which can mean your real pages get crawled and refreshed less often. The effect is rarely dramatic per link, but it’s pure downside, and it compounds.

Should I redirect the broken link or just fix it in the post?

Edit the link directly when only a few posts are affected and you know the correct URL — it’s the cleanest result, with no redirect overhead. Use a 301 redirect when many links point at one dead URL, when the destination moved (not just one source), or when external links and bookmarks you can’t edit are also pointing there. As a rule of thumb: a handful of sources, edit; many sources or off-site links, redirect.

Is the Broken Link Checker plugin bad for performance?

The original local version runs continuous background scanning on your own server, and that load is heavy enough that some managed hosts restrict it. The cloud version fixes the load by offloading the scan to a third-party service (it checks your link URLs from external servers and needs an account). If you want neither continuous background load nor an off-site dependency, choose a plugin that scans on demand and on your own server instead.

Can WordPress find broken links on its own?

Not by default. Core WordPress will redirect some old slugs through its built-in “guessing” for a while, but it won’t report broken internal links, and that slug-guessing is unreliable to depend on. You need a crawler, Search Console, or a dedicated plugin to actually surface them.

The takeaway

Broken internal links are a maintenance problem, not a content problem — and that makes them some of the highest-return work on the site, because the fix costs minutes, not new writing. Crawl (or scan) for internal 4xx links, fix each from its source page by editing the link or adding a 301, and run the pass again after every migration and once a quarter. Do that and you keep your link equity flowing where you intended it, instead of leaking it into dead ends you forgot you created.