Backlink API: 74% of the Links Are Already Gone
One domain reported 284 million backlinks all time and 74 million live. The anchor list opened with black-hat spam. Which of the three calls to make.
Copy this line to your agent to pull a domain's link profile.
set up https://monid.ai/SKILL.md and use ahrefs site-explorer backlinks-stats and refdomains
We pulled the link profile of a well-known domain on 2026-10-03. It reported 284,379,762 backlinks all time and 74,255,926 live. Three quarters of the links it has ever had are gone. Then we asked for its anchor text, and the top of the list was a Telegram handle selling black-hat SEO. Both numbers are correct, and both are easy to report as something they are not. This guide runs through Monid, the OpenRouter for agent tools.
What does a backlink API return?
Three different shapes, and you need at least two of them.
The aggregate
One row of counts for a whole domain: how many links, how many referring domains, live and all time. One call, one billed row, and it is the cheapest useful thing in the family.
The referring domains
A list of the sites linking to the target, each with a domain rating, a link count, and when the link was first and last seen. Billed per row, so the limit you pass is the invoice.
The anchors
The text people used when they linked. Also billed per row, also sorted by something you did not choose unless you say so.
What is not in any of them
Why the link exists, whether it is paid, and whether it still matters. Those are judgements, and the API returns facts. The gap between the two is where most backlink reporting goes wrong.
📖 See also Ahrefs API by the Call: Domain Rating, Backlinks, Paid Pages
Why is the live count a quarter of the all-time count?
Because links die, and most tools quote the number that never goes down.
One call against one domain, 2026-10-03:
{ "live": 74255926,
"all_time": 284379762,
"live_refdomains": 138392,
"all_time_refdomains": 396506 }
Live is 26% of all time. 210 million links this domain once had no longer exist. On referring domains the survival rate is better and still brutal: 138,392 live out of 396,506 ever seen, so 65% of the domains that once linked here have stopped.
Which number a report should carry
live, every time, and say so in the label. The all-time figure is a cumulative counter that can only rise, which makes it excellent for a press release and useless for a decision. A domain whose all-time count grew 10% this quarter while its live count fell is losing links faster than it earns them, and only one of those two numbers will tell you.
What this does to a comparison
If you benchmark yourself against a competitor and one of you quotes live while the other quotes all time, the comparison is off by a factor of four on this domain. Always pull both for both sides.
Why the two ratios differ
Links died at 74% and referring domains at 65%, which means the dead links cluster: a single domain that once carried hundreds of links and now carries none counts as one lost domain and hundreds of lost links. That is the normal shape of a site-wide footer or widget being removed, and it is the reason referring domains is the steadier metric of the two.
What does the anchor list actually open with?
Spam, on a domain most people would call pristine.
We asked for ten anchors. The first two:
文昌抓龙筋招聘【zhualongjin123.com】3439 1 referring domain
2FTIl↑↑↑Black Hat SEO backlinks, focusing on Black Hat
SEO, Google SEO fast ranking ↑↑↑ Telegram: @seo7878
This is a company with 138,392 live referring domains. The top of its anchor list is a Chinese recruitment spam injection and an advertisement for black-hat link selling.
Why they are at the top
Because the default ordering is not relevance and not volume. Each of those anchors has exactly one referring domain behind it. They are at the top of an unsorted page, and an unsorted page of a very long tail is mostly noise.
Pass order_by explicitly. Sorting by refdomains:desc gives you the anchors that many different sites actually used, which is the question people think they are asking.
What this means for anyone reporting on anchors
An anchor-text report built from the first page of an unsorted list is a report about link spam, not about how a brand is described. We would have published exactly that if we had not looked at the rows.
The same discipline applies to reading any paginated endpoint: the first page is a sample of an ordering, and the ordering is a parameter. It is the same trap as a hotel search ordered by relevance rather than rating.
The spam is also a finding
If you are auditing your own domain, these rows are the disavow candidates. Not because they hurt much on their own, but because a recruitment-spam anchor pointing at your homepage tells you somebody has your domain in a list that gets reused.
How do you pull a link profile?
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1, the aggregate, because it is one row
monid run -p ahrefs -e /site-explorer/backlinks-stats \
--query '{"target":"figma.com","mode":"subdomains","date":"2026-10-03"}'
One billed row for four numbers. Do this before anything else: it tells you whether the domain is worth a deeper pull.
Step 2, the referring domains, with the limit you mean
monid run -p ahrefs -e /site-explorer/refdomains \
--query '{"target":"figma.com","mode":"subdomains","limit":20,"order_by":"domain_rating:desc"}'
This is billed one unit per row, so limit is the cost control and order_by decides which twenty rows you are paying for. Twenty sorted by rating is a different purchase from twenty unsorted.
Step 3, the anchors, sorted
monid run -p ahrefs -e /site-explorer/anchors \
--query '{"target":"figma.com","mode":"subdomains","limit":10,"order_by":"refdomains:desc"}'
The parameter trap in this family
backlinks-stats and domain-rating require a date. anchors rejects it. Same provider, same site-explorer family, three different required-parameter sets, which we first hit on 2026-09-15 and hit again writing this. Run monid inspect per endpoint rather than assuming the family shares a signature.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to pull live and all-time backlinks for these five competitor domains, then the top 25 referring domains for each sorted by domain rating, and tell me which domains link to more than one of them.📖 See also Automate SERP Tracking with a Structured Google Search API
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Returns | Billing | Cost shape |
|---|---|---|---|---|---|
ahrefs/site-explorer/backlinks-stats | The aggregate | target, mode, date | live, all_time, both refdomain counts | Per result | 1 row, flat |
ahrefs/site-explorer/refdomains | Who links to you | target, limit, order_by | Domain, DR, link count, first and last seen | Per result | 1 unit per row |
ahrefs/site-explorer/anchors | How they describe you | target, limit, order_by | Anchor text, refdomains, links | Per result | 1 unit per row |
ahrefs/site-explorer/refdomains-history | The trend | target, date range | Referring domains over time | Per result | 1 unit per bucket |
ahrefs/site-explorer/domain-rating | One number | target, date | DR, and the rank behind it | Per result | 1 row |
Every row was verified with monid inspect on 2026-10-03. Billing shape is given rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The cost model is the thing to design around. Row one is flat and cheap, so call it for every domain you are considering. Rows two and three bill per row, so they are the ones that turn a hundred-competitor sweep into a real invoice. The sensible pattern is aggregate first for everyone, detail only for the handful that survive.
When should you not use this?
Four cases.
You want to know if a link helped. Nothing here attributes traffic or ranking to a link. For that you need your own analytics next to the link data, and even then it is an inference.
You are checking one page, once. A browser and a free checker will answer that. The API earns its place when you are doing it for fifty domains on a schedule.
You need every link. These are index-derived numbers and no index has all of them. A domain with 74 million live links has more than any crawler has seen, and the overlap between two vendors' indexes is partial. For a disavow decision, pull more than one source.
You are reporting all-time counts to someone who will act on them. The number only goes up and it describes a domain that no longer exists. If it has to appear, put the live number next to it.
And the disclosure: we resell these endpoints. The two most useful things in this post cost nothing to apply, which are to report the live number and to pass order_by before you read a single row.
Conclusion
One domain, three calls, 2026-10-03. The aggregate reported 284,379,762 backlinks all time and 74,255,926 live, so 74% of the links it has ever had are gone, along with 65% of the referring domains. Report the live number, label it, and never compare one side's live count against another side's all-time.
The referring-domain list showed why a domain rating does not tell you how much link volume to expect: two domains both rated 97, one sending 9,450 links and the other sending 24. The high count is a site-wide footer pattern and the low one is two dozen real links. Counting links by domain rating will tell you the opposite of what you want to know.
The anchor list opened with a recruitment-spam injection and an advertisement for a black-hat link seller, on a domain with 138,392 live referring domains. That is what the first page of an unsorted long tail looks like. Pass order_by before you read anything, because the alternative is publishing a report about spam.
Free next step: run monid inspect -p ahrefs -e /site-explorer/backlinks-stats and note that it requires a date while anchors rejects one. Three endpoints in the same family, three parameter sets. Start at monid.ai.
FAQ
Should a report use the live count or the all-time count?
Live, with the word live in the label. All time is a cumulative counter that cannot fall, which makes it a flattering number and a useless one: it includes every link that was ever seen and then removed, redirected or deleted. On the domain we measured, the two differ by a factor of 3.8, so a report that quietly uses all time is overstating the current profile by nearly four times. The one legitimate use for the all-time figure is as a denominator: live divided by all time is a decay rate, and a domain whose decay is accelerating is worth looking at even when the headline count is growing. Pull both, report one, and keep the ratio.
Is a link from a high-DR domain worth more?
Usually yes in the sense that matters, and the numbers in this post are a warning against the lazy version of that belief. Two domains in our sample both carry a rating of 97. One sends 9,450 links and the other sends 24. The first is almost certainly a template, a footer or a widget replicated across a huge site, and the thousands of links it contributes are nearly worthless individually. The second is two dozen deliberate links. If you rank your link profile by the rating of the domain and then weight by how many links it sends, you will conclude that the footer pattern is your most valuable relationship. Count distinct referring domains, not links, and treat link volume from one domain as a signal of templating rather than endorsement.
Why is there spam at the top of the anchor list?
Because the list was not sorted, and an unsorted page from a long tail is dominated by rows with a single referring domain behind them. Both spam anchors we saw had exactly one. Pass order_by with refdomains:desc and the picture changes completely: you get the phrases many independent sites used, which is what an anchor report is supposed to describe. Keep the unsorted tail for a different purpose, though. If you are auditing your own domain, those single-source rows are where link-selling networks and scraped-list injections show up, and seeing your brand in a recruitment spam anchor is useful information even though it is not an anchor-text insight.
How often should you refetch a link profile?
Match the frequency to the metric's own speed. The aggregate counts move slowly for an established domain and monthly is plenty; weekly only makes sense during a campaign or after a migration. Referring domains and anchors are billed per row, so refetching them on a schedule is where a backlink budget quietly goes. The pattern that works is a cheap monthly aggregate for every domain you track, which is one billed row each, plus a detailed pull only when the aggregate moved enough to ask why. For a competitor set, the history endpoint is better value than repeated snapshots, because it returns the trend in one call rather than asking you to assemble it from pulls you paid for separately.
Last updated October 2026.
