How to Find and Fix Broken Links on WordPress

A broken link is a small thing until it is not. One dead link in a five year old post is not going to sink your rankings. A site with hundreds of them, spread across your archive, is a different story. Broken links accumulate the same way clutter accumulates in a house: nobody puts them there on purpose, they just show up over time as other sites reorganize, pages get deleted, and your own content gets moved or renamed without anyone updating the links that pointed to it.

Why broken links quietly hurt both users and SEO signals

The user experience cost is the most direct one. A reader clicks a link expecting a source, a product page, or further reading, and lands on a 404 instead. That breaks trust in the specific article and, if it happens more than once, in the site as a whole. Readers do not distinguish between a broken link you control and one on someone else's site. They just notice that clicking things on your pages does not work reliably.

The SEO cost is less direct but still real. Search engine crawlers follow links to discover and understand your site's structure. A broken internal link is a dead end in that structure, a place where link equity you built through internal linking simply stops flowing. If an important page is only reachable through links that are now broken, it becomes harder for crawlers, and for the ranking signals tied to internal linking, to reach it at all. Broken external links do not carry the same structural weight, but they still signal a page that has not been maintained, which matters more on pages you want search engines and readers to treat as current and trustworthy.

None of this shows up as a single dramatic ranking drop. It shows up as a site that is slightly harder to crawl, slightly less trustworthy to readers, and slightly worse at converting the traffic it already earns. Fixing broken links is maintenance, not a growth hack, and it belongs in the same category as updating plugins or renewing a certificate: not exciting, but the cost of skipping it compounds.

Internal vs external broken links, and why they need different fixes

An internal broken link points to a URL on your own domain that no longer resolves. These are usually caused by a page being deleted, a slug being changed without a redirect, or a category or tag structure being reorganized. You have full control over the fix. You can update the link to point to the correct URL, restore the page, or set up a redirect so the old URL forwards to the right destination. Internal broken links are also the more urgent category, because they directly interrupt your own site's crawl path and your own readers' navigation.

An external broken link points to a page on someone else's site that has moved, been deleted, or gone offline entirely. You have no control over the destination, only over how you reference it. This is a different kind of decision. You cannot fix the other site, so your options are to remove the link, point it to an archived or updated version of the same resource, or replace it with a different, currently working source that still supports the point you were making.

Treating both categories the same way is the most common mistake in link cleanup. Internal links are a structural problem you solve with redirects, covered in detail in our guide to WordPress 301 redirects. External links are a content problem you solve by re-evaluating whether the citation still belongs on the page. A checker that just reports every broken URL without distinguishing the two leaves you to sort that out manually, which is exactly the kind of triage that a good broken link checker on WordPress should do for you automatically.

How a broken link checker actually works, and the SSRF problem most guides skip

At its core, a broken link checker does something conceptually simple. It scans your published content for links, both internal and external, and sends a request to each URL to see what comes back. A response in the 200 range means the link is fine. A 404, a connection timeout, a DNS failure, or certain redirect chains that never resolve are flagged as broken. The scanner then stores the result so you can review it, rather than checking links live every time a page loads.

The part most articles on this topic skip is what happens on the server side while that scanning is running, and it is worth understanding because it is a real security consideration, not a marketing talking point. When a broken link checker fetches an external URL, it is your WordPress server making that outbound request. If the checker is not careful about which addresses it is willing to fetch, someone could plant a link on your site, in a comment, a guest post submission, or anywhere else content reaches your server, that does not point to a normal external page at all. Instead it points to an internal address: something like a private IP range, a cloud metadata endpoint, or a service running on your own server that was never meant to be reachable from the outside.

This class of attack is called server-side request forgery, or SSRF. The trick is that the request is not coming from the attacker's machine, it is coming from your server, which usually has network access the attacker does not. If your broken link checker blindly fetches whatever URL it finds in your content, it can be turned into a tool that probes your own internal network, reads data from internal services, or reaches cloud infrastructure endpoints that expose credentials. This is a documented, well understood category of vulnerability in any system that fetches URLs on a user's behalf, and a link checker is exactly that kind of system.

A checker that takes this seriously validates the resolved IP address of every URL before fetching it, not just the hostname, since a hostname can be made to resolve to a private or reserved address after the fact. It blocks requests to loopback addresses, private IP ranges, link-local addresses, and known cloud metadata endpoints, and it re-checks after any redirect rather than trusting the first address it resolved. This is exactly the kind of protection built into Rankwyn's broken link checker, which runs SSRF protected scans so that a malicious or malformed link in your content cannot be used to probe your own infrastructure. If you are evaluating any broken link tool for WordPress, this is worth asking about directly. Not every tool implements it, and the ones that do not are exposing a real attack surface without telling you.

The manual fix workflow: unlink, redirect, or update the link

Once a broken link is flagged, you have three real options. Choosing between them depends on whether the link is internal or external and what the destination content is doing now.

• Unlink: remove the hyperlink but keep the surrounding text. This is the right choice when the linked resource no longer exists anywhere, and the anchor text still makes sense as plain text. It is common for external links to old news articles, discontinued products, or blog posts that were taken down entirely.
• Redirect: point the old URL to a new one, either because you moved the destination yourself (internal) or because you found an updated version of the same resource elsewhere (external, by editing the link directly rather than a server redirect, since you do not control the other domain). For internal links, a 301 redirect preserves the link equity that was flowing to the old URL and avoids editing every single post that referenced it.
• Update the link: replace the URL with a corrected one when the content moved but the link text is still accurate. This is common when a slug changed, a site restructured its URL paths, or an external source republished the same article at a new address.

A practical rule: for internal links, prefer redirects over manually editing every post, because redirects fix the problem site-wide in one place and protect any external sites that may have linked to your old URL. For external links, prefer updating or unlinking over redirecting, since you cannot create a server-side redirect for a domain you do not control, and the update needs to happen in the content itself.

How often to scan a site of different sizes

Scan frequency should scale with how often your content changes and how much of it you have, not with a fixed calendar rule. A small site that publishes occasionally can reasonably scan weekly, since link rot accumulates slowly when there is little new content and few external references being added. A larger site that publishes frequently, links out often, or has years of archive content is exposed to more link rot at once, both from its own restructuring and from the outside web changing under it, and benefits from a daily scan so problems get caught and queued for review before they pile up.

The other trigger for a scan, regardless of size, is a site restructuring: changing permalink structures, merging categories, deleting old posts, or migrating to a new domain. Any of these can silently break dozens or hundreds of internal links at once, and a scan immediately after the change catches the damage while it is still fresh and easy to trace back to a single cause.

Rankwyn's site maintenance tools run this on a daily schedule by default, so you are not relying on remembering to check manually, and pairs it with a 404 monitor that logs real visitor hits so you can see which broken links are actually costing you traffic versus which ones are low priority. Combined with the redirect manager and the SSRF protected scanner, that covers both the internal structural fixes and the external content review in one place, which is part of what is included across Rankwyn's plans.