A placed link isn't done: what we found when we re-checked 34 pages

One-line summary: Links break after they go live. This is what a full re-check of 34 placed pages looked like on 7 October 2026, plus how we handled a client deleting two pages, a link exchange partner removing our link, a partner's site rebuild that lost our link, and 21 links that needed a new address.

The situation

The first four case studies are about getting links placed. This one is about what comes after, because that's where a lot of link building quietly fails.

The records we're drawing on cover a global medical education platform, a B2B sales consultancy and an industrial cable manufacturer, plus a cleanup sheet from another account. A tracker row that says "Live" was true on the day someone looked. The question is whether it's true now.

The play: check, categorise, decide

The rule. The handover notes for the programme say a link counts only once it's checked live, with the right anchor, and indexed. An email saying "your article is live" doesn't count.

The check. On 7 October 2026 we opened each placed article on the roster and recorded the HTTP status and every outbound link to the client, with its anchor and destination. Then we put each page into one of five buckets: live with the link, live without the link, behind a bot wall, a site problem (certificate, server error, down), or gone.

The decision. The records show what happened to each kind of problem:

• Page live, link gone: a person decides whether to ask the publisher to restore it or to drop the question.
• Bot wall: the tracker note says the page needs a manual view in a real browser from a different network.
• Publisher's own fault (an expired security certificate): the row stays marked live with a note, and the publisher needs to renew.
• Page gone or down: the publisher goes on a hold list, with no new work until they're checked.

The results of the 7 October check

34 placed pages checked.

• 21 pages returned a live page and showed the client link. That's 12 for the medical education platform, 6 for the consultancy and 3 for the cable manufacturer. The check recorded 22 client links on those 21 pages.
• 13 did not confirm. 4 loaded fine but the client link wasn't there in the check. One of those is confirmed gone. 3 returned 403, a bot wall. 2 couldn't connect. One each returned a 526 error, a 500 error, an SSL error and a 410 ("gone").

Behind the numbers, the specific problems were: a customer-acquisition article returning "gone", a publisher with a server error, a publisher whose security certificate had broken (the tracker notes it expired on 25 June 2026 and that the link is still on the page), two publishers that were down (one of them accounts for both connection errors), and one article where the client link had been removed. The three sites that returned 403 (a health information site, a business-data site and a news site) block automated checks and need a person with a browser.

In the medical education tracker for 2026, 79 link rows: 76 live, 1 unverified (a bot wall that persisted even from a real browser on 6 August), 1 "live (site issue)" (the expired certificate) and 1 removed.

Four fixes, in the records

1. A client deleted two pages. The cleanup sheet is headed: "Currently, these anchor texts are linking to broken destination URLs as the client removed the 2 related pages." It lists 7 live articles, each with its anchor, its current dead destination and one suggested replacement, the client's parent page. Seven links, two dead pages, one new target.

2. 21 links changed address. The 2024 medical education tracker has a single line recording a batch of 21 existing links whose destination was changed from one section of the client's site to another.

3. An exchange partner removed our link. In a 2026 swap, a partner linked to us on 14 September, then took the link down on 18 September until we'd linked back. On 24 September they proposed a different page of ours to link from. At the time of the files the answer was still with the client's content lead, and a second holding reply to the partner went out on 2 October, promising an answer by 9 October.

4. A partner's site rebuild lost our link. One exchange showed "both links live" on 1 April. On 24 September a rendered-browser check found zero links to the client after the partner's site rebuild. The tracker status flipped to "removed" and the decision, "nudge them to restore, or remove our outbound link", sat with the client.

Two real emails

Both are from earlier campaigns, names removed. They're about the part of maintenance that takes patience: getting the live link from the other side, and the slow publisher.

1. Asking for the live link (August 2024)

We'd agreed an exchange with a study-tools company's blog. Our message:

Thanks for the positive response! We like your idea on the anchor text, but I couldn't load the screenshot you attached in the previous email. Can you share us again in text where you will add our link?

For our side, I'd add a sentence similar to "[a sentence about the topic]" and link to your post on "[a phrase from their post]". Do let us know if this works!

Their reply:

I've gone ahead and added the sentence into the blog so you can see it live at the bottom of the post: [live link]

Your suggestion sounds good to me. Can you send us the live link once you've edited your blog as well? Thanks!

Each side asked for the other's live link.

2. The chase sequence (November 2021)

After sending an article for publication on 13 November, we wrote the same short line three times:

Hi, any update? Is this published yet? Awaiting your reply!

That was 23, 25 and 27 November. The owner answered on 28 November: "I just saw your other email. I have no idea how I missed this! I'm so sorry. I'm working on it right now for you." A little later the same day: "The post is now live."

Three chases, two days apart, isn't elegant, but it worked and the owner didn't mind. The point is that the editor is human and the inbox is chaos.

What editors said

• A live URL, volunteered. Editors in these threads often sent the live address before we asked: "The post is now live", "here is your article live link".
• A quick apology and a fast fix when a request had been missed (above).
• A condition. The partner who removed our link wanted theirs placed before ours returned. It's a fair condition; we hold the same line on our side.

What we'd do again

1. Check on a schedule, not when someone remembers. The 7 October check found 13 pages that didn't confirm the link.
2. Keep five buckets, not two. "Live" and "dead" hide the difference between a bot wall, a certificate problem and a removed link. They need different actions.
3. Record the destination and the anchor every time. A live link on the wrong page isn't a verified link.
4. Keep a hold list. The handover names six publishers we hold new work for until they're re-checked.

Receipt box

Four rows from the 2026 medical education tracker and the live check. Category, DA as recorded, live status, anchor type. No URLs.

Site category	DA	Live status	Anchor type
General news blog	47	Live	Exact-match keyword
News and education blog	52	Live (site issue): certificate expired 25 Jun 2026, link still in the page, checked 3 Aug	Exact-match keyword
Business news site	51	Unverified: bot wall, retried from a real browser 6 Aug	Keyword phrase
Pre-med admissions guide site (exchange)	not recorded	Removed: no client link after the site rebuild, rendered check 24 Sep	Not recorded

How we vetted these sites

This case study is about vetting after the fact, so the line is simple: every claim above comes from a dated check or a tracker status, not from an assumption. The check covers status and every outbound link to the client, with its anchor and destination. It does not cover indexation, because the files hold no index check, so we aren't claiming one.