Live Link Status Checker: How to Verify a Backlink Is Still Live

A backlink monitoring dashboard that only checks for a 200 status code will call a link "live" right up until the day it demonstrably stops doing anything for you. That's the gap a real live link status checker has to close: a linking page can return 200 every single day while the actual link inside it has been edited out, repointed to a different URL, tagged nofollow after the fact, or quietly dropped from Google's index — and a basic uptime check, the kind that only confirms a URL resolves, will never catch any of it. Ahrefs' analysis of the link profiles of just over two million domains puts a number on how often this happens: since January 2013, at least 66.5% of the backlinks in that sample had rotted, and once you count links lost to redirects, deindexing, and other SEO-specific issues, the real figure climbs to 74.5%.

This is a practical walkthrough of what actually verifying a specific backlink's live status involves — not "is the domain still online," but "is this specific link, exactly as originally placed, still doing what it was supposed to do." That distinction matters because most of the ways a link actually dies leave the linking page completely untouched and returning a clean 200 the entire time.

Why a Live Link Status Checker Has to Check More Than a Status Code

Most link monitoring starts and ends with an HTTP request: send it, read the status code back, mark the link "live" if it's a 2xx and "dead" if it's a 4xx or 5xx. That check is necessary, but it answers a much narrower question than "is my backlink still live" — it only answers "does this URL currently respond." A URL can respond perfectly well and still represent a link that's stopped functioning as a backlink in every way that matters for referral traffic or search visibility.

Treat live status as a spectrum, not a switch. In practice a backlink placed on someone else's page can fail in at least five distinct ways, and only one of them reliably shows up as an obvious HTTP error:

1. The linking page itself is gone or has moved. The URL 404s, 410s, or now redirects somewhere else entirely — a domain migration, a URL restructuring, or a content prune took the page with it. This is the one failure mode a basic status check actually catches.
2. The page is still live, but the link was removed. This is the case that catches the most people off guard, because every automated status check on that URL passes cleanly. The page loads fine, returns 200, and looks completely normal to any crawler — the specific link inside it is simply gone. Ahrefs' study of lost links found this is actually the second-largest cause in their sample: pages "still exist; they just no longer link to you," accounting for 34.2% of the links they classified as lost, not far behind the 47.7% lost to pages being dropped from their index entirely.
3. The link is still there, but the target changed. The anchor text and placement look identical, but the href now points somewhere else — often because the destination site restructured its own URLs and the publisher updated the link to follow along, or because an editor swapped it during a content refresh without noting the change anywhere.
4. The link picked up a different rel attribute. It's still technically present and still points to the right page, but it now carries nofollow, sponsored, or ugc, where it didn't originally. Google's own documentation on qualifying outbound links is explicit that this changes how the link is treated: links marked this way "will generally not be followed," even though the linked page itself "may be found through other means."
5. The page and the link are both untouched, but Google has deindexed the page. Nothing on the page changed. The link is exactly where it was, pointing exactly where it always pointed. But the linking page no longer counts toward the link graph the way it once did, because Google stopped including it in the index.

None of these are hypothetical edge cases. They map closely onto the actual categories Ahrefs' own crawl data breaks lost links into, and every one of them except the first is invisible to a monitoring setup that only checks whether a URL returns 200.

The Real States a Backlink Can Be In

"Live" and "dead" are the only two states a basic checker reports, but a backlink profile actually moves through more than that. This table breaks down the states that matter and what actually catches each one:

Building a Live Link Status Checker Process That Works

A process that actually verifies live status combines two layers: automated checks that cover volume, and manual spot checks that cover the failure modes automation structurally cannot see. Skipping either layer leaves a real gap — automation alone reliably catches only outright 404s and redirects, and manual review alone doesn't scale past a handful of links.

Step 1: Run a Bulk HTTP Status Check First

Start by resolving every backlink URL in bulk rather than one at a time. Tools built for this, like Screaming Frog's list mode, let you paste, upload, or manually enter a full list of linking URLs and get back the status code, the redirect destination if there is one, and whether the request failed outright. This step is cheap and fast, and it should always run first because it immediately sorts your list into "definitely needs a closer look" (anything non-2xx or redirected) and "passed the first filter" (everything else) — which is not the same thing as "confirmed live."

Step 2: Separate a Real 404 From a Soft 404

A clean 2xx from step one doesn't rule out a page that's functionally an error page. Google's own documentation defines a soft 404 as a URL that "returns a page telling the user that the page does not exist" while still sending back a 200 status — the kind of response a broken CMS template, an emptied-out page, or a failed database query produces. Google explicitly states that "such pages are excluded from Search," meaning a soft 404 on your linking page has the same practical effect as a hard 404 even though your bulk status check reported it as fine. Catching this requires actually looking at what the page renders, not just its header response.

Step 3: Resolve Every Redirect to Its Final Destination

A 301 or 302 on your bulk check isn't a verdict by itself — it's a pointer to somewhere you still need to check. Follow the chain all the way to where it actually lands, then check whether your link, or anything close to it, survived onto that final page. Google's own guidance on site moves recommends against long chains in the first place, noting that while "Googlebot can follow up to 10 hops" in a redirect chain, site owners should "keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5" — and separately warns that long chains "have a negative effect on crawling." A backlink sitting behind a five-hop chain is a real risk even before you check whether it survived the move, since it may not get crawled far enough to be recognized as still contributing to the destination page at all.

Step 4: Manually Confirm the Link Still Exists on the Rendered Page

This is the step a purely automated process skips, and it's the one that catches the largest single failure mode in Ahrefs' own data — a linking page that's completely healthy by every automated measure while the specific link is simply gone. Open the actual page, render it the way a browser would, not just the raw HTTP response, since plenty of links are injected or removed via client-side JavaScript. Then confirm your link is still there, pointing where it should. The baseline to check against is whatever was agreed at the time of placement — on a backlink marketplace like bklink, that's the URL and anchor recorded at time of purchase; for an earned or outreach-based link, it's whatever your own placement records show.

Step 5: Check the Rel Attribute on the Live Anchor

Presence isn't the same as full value. Once you've confirmed the link is still on the page, check what it's actually tagged with. A link that shipped as a normal followed link can pick up nofollow, sponsored, or ugc months later, through a CMS plugin update, a site-wide policy change, or a manual edit, without the link disappearing or the page's status code changing at all. Since Google's documentation treats these attributes as signals that a link will "generally not be followed" for ranking purposes, this single attribute change can quietly convert a link that used to count into one that mostly doesn't, while every other check you run says everything is fine.

Step 6: Confirm the Href Still Points Where It Originally Did

Separately from the rel attribute, check the actual destination URL in the href. Anchor text and placement can look completely untouched while the link now points somewhere else — a different page on the same domain after a restructuring, a redirected shortcut URL, or in rarer cases a different domain entirely after a content swap. This is easy to miss because it doesn't fail any automated check: the link still exists, it's still in the right spot on the page, and it still resolves to something. It's just not resolving to what you think it is.

Step 7: Check Indexation, Not Just Reachability

The last check covers the failure mode that leaves absolutely nothing visibly different: the page loads normally, the link is exactly where it was, the attributes are unchanged, and the href is correct — but Google has deindexed the page. Google's own Search Console documentation distinguishes between what it calls the "Google Index" view, which reflects data from "the most recently indexed version of a page, not the live version on the web," and a "Live Test," which fetches and examines the current version in real time. A page can pass the live test while showing as not indexed in the index view, which is exactly the deindexing scenario a link status check needs to catch — the page is genuinely fine for a human visitor, but it's no longer part of the index Google uses to evaluate links at all.

Automated Checks vs. Manual Spot Checks: What Each One Actually Catches

Neither layer covers everything on its own, which is why a real process runs both rather than treating one as a substitute for the other.

How Often to Recheck a Backlink's Live Status

A single check at the time a link goes live tells you almost nothing about whether it's still live six months later — every one of the five failure modes above can happen well after the initial placement, often without any notification to whoever built or bought the link. Treating a live-status check as a recurring pass rather than a one-time confirmation is really the specific, checkable core of the broader practice covered in Backlink Monitoring: Link Status, Link Rot, and Lost-Value Recovery, which also covers tracking authority changes, watching for new toxic neighbors on a linking domain, and catching link rot before it compounds across a whole profile. A reasonable cadence in practice: bulk status checks monthly across the full backlink list, since they're cheap to run at scale, with manual spot checks reserved for your highest-value placements — the ones where a quietly removed link or an added nofollow tag would actually change a decision you'd otherwise make about that vendor or that page.

Where Live-Status Verification Fits Inside a Full Audit

Live-status checking isn't a separate discipline from a full backlink audit — it's one specific, technical piece of it. The Backlink Audit Checklist: 27 Checks Before You Trust a Link Profile groups exactly this kind of check, confirming a link's live status, its redirect chain, and its rel attributes, inside its technical verification checks, alongside the inventory, authority, spam-signal, and competitive checks that make up the rest of a complete profile review. If you're running a full audit rather than checking a handful of specific placements, that's where this kind of live-status verification actually plugs in, rather than being repeated from scratch as a standalone process.

Common Mistakes When Checking Live Link Status

Trusting a 2xx status as confirmation the link is unchanged. A status code confirms the page responds. It confirms nothing about what's actually on that page, which is exactly the gap steps 4 through 7 above exist to close.

Checking the raw HTML response instead of the rendered page. Plenty of modern sites inject or remove content, including links, via client-side JavaScript after the initial page load. A raw HTTP response can show a link that a rendered browser view doesn't, or vice versa.

Treating a redirect as automatically bad, or automatically fine. A redirect isn't a verdict either way — it's a signal that you need to check the destination specifically, since your link may or may not have survived the move.

Assuming a link's attributes are fixed once it goes live. Nofollow, sponsored, and ugc tags get added after the fact more often than most monitoring processes assume, whether through a deliberate policy change or an unrelated CMS update.

Only checking reachability, never indexation. A page can be perfectly reachable and still be functionally invisible to how Google counts links, if it's been dropped from the index. Reachability and indexation are two different questions that need two different checks.

Related Reading

• Backlink Monitoring: Link Status, Link Rot, and Lost-Value Recovery — the broader monitoring practice this specific live-status check fits inside.
• Backlink Audit Checklist: 27 Checks Before You Trust a Link Profile — where live-status and other technical verification fits inside a complete profile audit.
• 404 Backlink Finder: Recovering Links Pointing to Dead URLs — what to do once a status check like this one turns up a dead link worth recovering.