The problem
Every website we look after collects broken links over time. A supplier changes their site, a blog post points to a page that was renamed, a PDF gets deleted. Nobody notices until a visitor clicks and lands on an error, or a search tool reports a list of 404s.
Checking links sounds easy: request each address and see what comes back. In practice it's full of false alarms. Some servers refuse the quick “HEAD” request that checkers like to use. Some block anything that doesn't look like a person, LinkedIn being the famous one with its made-up status code 999. Some pages say “not found” while returning a perfectly healthy status. And a site that's down for two minutes shouldn't fill your inbox with alerts.
We also needed it in three different places. Developers and SEO people want to check any page in the browser. WordPress and OpenCart store owners want their own site watched, without having to remember.
What we built
One way of checking, everywhere
All three editions use the same approach. Try a light HEAD request first, and if the server refuses it or errors, try a normal GET before deciding anything. Follow redirects and record them. Treat a deep link that redirects to the home page as a likely “soft 404”, since that's what many sites do with deleted pages. Flag codes like 401, 403, 429 and 999 as “may block automated checks” rather than calling them broken.
The Chrome extension: any page, right now
Press the button or Alt+Shift+L and it checks every link on the page you're looking at, eight at a time by default. The checks run in the extension's background worker, which can reach other sites without the browser's cross-site restrictions, and it reads the real redirect codes from Chrome's network events, because the normal fetch function hides them. It finds links inside web components, same-site frames and even Google Docs and Sheets. “Re-check broken” tries again as you, with your own cookies, which clears up links that only fail for robots. It runs only when you ask, never in the background.
WordPress: the whole site, quietly
The plugin checks links from the server on a five-minute schedule, a few at a time per website so it never hammers anyone. A temporary error only counts as broken after three failures in a row, so a site that's down for a few minutes doesn't set off an alarm. Links to your own published posts are checked against the database without a web request at all. Working links are checked again on a schedule you choose, from daily to monthly, and broken ones every day.
Finding a broken link is half the job, so fixes are one click: change the address or remove the link, saved as a normal post revision you can undo. It also keeps a log of 404 errors on your own site with redirects to fix them, and that log never stores visitors' IP addresses.
OpenCart: a careful port
The OpenCart 4 version brings the same checker to product, category, information and blog descriptions, in every language the store uses. OpenCart had two quirks to work around. It keeps no revisions, so the extension saves each description before changing it, which is what makes undo possible. And descriptions are stored with their HTML escaped, so each fix decodes, edits and re-escapes the text. It also refuses to check private or internal network addresses, a basic protection for any tool that makes requests from a server. No OpenCart core files are changed.
Where it stands
The Chrome extension came first, built in October 2026 and published in the Chrome Web Store. The WordPress plugin followed and is free on WordPress.org. The OpenCart version went on the OpenCart Marketplace on 27 October 2026.
The Chrome edition has an end-to-end test with 66 checks, run against a small local test site that serves every awkward case on purpose: redirects, 404s, server errors, servers that refuse HEAD, slow pages, blocked requests and refused connections. That test site is what made the shared approach trustworthy enough to port twice.
The limits, plainly. The WordPress plugin checks post and page content; menus, widgets and some page builders need a developer hook. The OpenCart version checks descriptions, needs SEO URLs on for redirects and the 404 log, and has so far been tested on OpenCart 4.1. Building the same tool three times was slower than building it once, but it taught us which parts of a product are the idea and which are just the platform.
