Great for continuous link checking but false positives and other issues

Since November 2025, I’ve tested the Internet Archive Wayback Machine Link Fixer plugin against my custom command-line link checker.

Here are my comments.

Internet Archive Wayback Machine Link Fixer

Positives

1. Continuous link checking
2. Standard WP administrator interface

Negatives

1. A high false positive rate means you need to manually verify every flagged link. For example, recently, I saw amazon.com flagged as a 404. Deal breaker.
2. Automated replacements can unnecessarily replace links. To stop Link Fixer from redirecting to the Wayback Machine for amazon.com (and other good links), I needed to add a random query parameter (?t) to good links. Then I needed to exclude the original good link (that was flagged as a 404) and exclude the new ?t version on top of that (double work for every good link). Deal breaker.
3. Poor interpretation of HTTP status codes and no way to tweak that. Deal breaker.
4. Time sink from managing exclusions (no support for bulk action > exclude link) and doing workarounds for the false positives (see #2 above).
5. High risk of replacing current content with outdated (sometimes totally ancient) archives.
6. Poor visitor experience with unexpected link manipulation to Wayback Machine pages. At first, shocking and confusing, then annoying.
7. Content quality degradation from linking to super old information instead of intelligently finding fresh and relevant pages.
8. Real broken links (e.g., 404s) are not actually fixed in the HTML. So search bots will still see broken links (false sense of security). Dynamically replacing broken links does not help SEO. Google doesn’t guarantee crawling client-side rendering.
9. Not geared towards human content editors. Shows all broken links across the entire site in one long list. No grouping by document or page. No context about which document contains which broken links. It’s not easy for content writers like me to navigate and fix links.
10. The “Back to All Links” button is buggy. I expect to return to the main list of links. Instead, it acts like the browser back button. Example link for “Back to All Links”: admin.php?page=iawmlf-links&iawmlf_link_id=1401. On top of that, clicking “Back to All Links” submits the last HTTP request (which can undo any edits without you knowing—gnarly).
11. All Link Fixer admin pages show the same page title. That makes it difficult to navigate back to specific links using the browser history. In the screen capture attached, you cannot tell that the links are actually to different pages.
12. Phantom (orphaned) links: Links remain in the checking queue even when they’re no longer present in any post or page. This creates wasted processing cycles. cluttered interface, and confusion about which links need attention. I needed to manually exclude each orphaned link, so at least I know which ones I can ignore.

Custom code solution

More control

My custom solution is only semi-automated, but I define how to handle HTTP status codes and what my link replacements should be.  

Real link fixing

My broken links are “really” fixed when I edit my posts and pages (bonus: my edits update the “last modified” date). Search bots will see my real fixed links, and my “freshness” score gets a boost.

Document-centric workflow

My custom solution generates a report ordered by page. For each page with a 404 link, it lists the broken URL, the link text for that URL, and Claude Code suggestions for replacement candidates.

Screen captures

False positives: jumpshare dot com /share/VNPnKIoPF3khooUfnEO8

Same page title in browser history: jumpshare dot com /share/ADuvrhg7Xay2lzxv66QS

Parting thoughts

We’d definitely reconsider using this plugin if the major deal breakers are addressed. ☺️