a row that drops out of a newer backlink index is not, on its own, a lost backlink. confirm a removal only by fetching the linking page, following its redirects, confirming the comparable article, and checking its html and rendered links for the target. an index comparison can point at the rows worth opening. it cannot describe what that live page still contains. settle the difference before you write the publisher or count the link as lost.
if you still need a starting list, begin with how to find backlinks for free. hold onto the original evidence after that: the page that linked, the target, the date, and which source made the observation. a report that only names domains cannot tell you which page to open. this guide covers named-release export comparisons; use the lost-backlink diagnosis guide for the wider page-level investigation.
a vendor's “lost” filter is the gap between two copies of that vendor's index. treat the flag as a lead to check. it is not proof that the publisher took the link off a live page.
what those lost-backlink reports usually count
a lost-backlink report sets an earlier record next to a later copy of the same index. an ahrefs-style lost filter is handy as a queue, because it brings forward the rows that changed. the label is still an index state. each change still needs its own evidence for the cause.
plenty of ordinary events can leave a similar gap. the publisher might redesign the site, send the page through a redirect, or switch between www and non-www, or between http and https. the crawler might drop the page from its frontier and simply fail to record it later. or the publisher might have deleted the href. a diff of two indexes does not sort those causes apart.
the next move depends on which cause you can actually show. a redirect can land on a page that still links to you. a link sitting on an unchanged page may be missing only from the later index. a deleted href can support a polite outreach note, and only after you have seen what the page serves now. looking up a “lost backlinks checker” does not skip that reading of the label. that checker query is a harder result set than “lost backlinks” itself, and the label still needs the same page check.
why a common crawl graph leaves the question open
common crawl publishes periodic hyperlink graphs of hosts it has seen linking. those graphs are separate from its crawl archives. crawlgraph names its releases from the common crawl web graphs. for the collection and the release calendar, read how the common crawl hyperlink graph works and when a new common crawl graph is published.
- a referring domain shows up in release A
- the same domain is missing from release B
- the domain was observed in A and absent from B
- a comparison someone else can repeat from the two release names
- that the linking page was inspected
- that the newer crawl fetched that linking page again
- when, or whether, a particular href changed
take a referring domain that shows up in release A and is missing from release B. the conclusion the data supports is narrow: the domain was observed in A and absent from B. the newer crawl may never have fetched that particular linking page again. a graph snapshot is not an inspection of the live page. crawlgraph is neither a live crawler nor a complete web index.
the release names are part of the evidence, because they name the two observations you compared. store both names with the result. an unlabeled pile of “lost” domains throws that context away. a later graph can list a different set of observed hosts without saying when a particular href changed, or whether it changed at all.
four checks for one suspected linking url
- keep the older evidence. write down the linking url, the anchor text, the observation date, the tool, and the release id when one was supplied. keep the target url as well. you then have a page to open and a record of what the earlier source actually showed.
- request the linking url yourself. follow redirects through to the final page and note where you land. when you read that destination, account for www and non-www hosts and for a change between http and https. a page that moved is a different finding from an href that was removed.
- search the final html for the target host. confirm this is the comparable article, rather than a login, consent screen or replacement homepage. inspect rendered links as well as html, and resolve relative destinations against the final page url. look at links to the target and to the relevant host variants. compare each href with the target you saved, and check the anchor when your audit cares about it. a domain named in ordinary prose is not, by itself, an href.
- record the result. call the link still live when the relevant href remains. call it redirected when the request ends somewhere else and that destination explains the result. call it removed only when the comparable article is accessible and neither its html nor rendered content contains the relevant link. otherwise leave the result unconfirmed. store the final url and the check date with the finding.
if you cannot fetch the final page, or you cannot read it, leave the result unconfirmed and come back later. do not invent an http status from the fact that a graph omitted the page. crawlgraph does not run this page fetch for you from the blog. the request, and the reading of the html, are yours.
when the link is still live, note where it points even if the anchor changed. when it is gone, keep the earlier evidence beside the check you just made before you decide whether outreach is worth the time. neither result, by itself, says what will happen to rankings.
compare two crawlgraph exports
for a domain-level comparison you can repeat, download paid csv or json exports from two named, queryable releases. csv has five columns, matching the fields of each row in the json results array: rank, domain, tld, hosts, and percentage. rows are ordered with the most hosts first. they are referring-domain rows. they are not a list of every linking url, anchor, or rel attribute. read a referring domain is not a backlink before you treat a change as a lost link.
save each file with the release name on it. then compare the domain column. a domain that appears only in the newer export was observed as added. a domain that appears only in the older export was observed as absent. keep those labels attached to the two releases. they describe the comparison. they do not date the moment a link showed up on a live page, or the moment it left.
the free check returns five referring-domain rows. that preview is the wrong input for a loss audit. a domain can fall outside a five-row sample without saying anything about its live links. paid accounts can download the referring-domain list. exports stop at the current retrieval limit of 100,000 referring hosts, and the product also reports the honest total count. keep that cap in view when you read a comparison. if either result is capped, a domain missing from the export may simply fall outside the retrieved rows. treat that difference as inconclusive until you have comparable coverage.
use the diff to decide which domains to open next. do not turn it into a list of confirmed removals. an observed-absent domain does not include the original linking url. when older evidence still has that url, run the four checks above. when it does not, leave the finding at domain level.
turn on the optional release monitor
on a paid account, the release monitor can be enabled for a saved site. it stays off until you turn it on. once it compares two named releases, it emails a digest of observed additions, observed absences, and authority moves. each group in that digest is sampled at a cap of 10 rows.
the digest has the same limit as an export comparison. a domain absent from the newer snapshot has not necessarily removed a live page link. the monitor compares graph releases. it does not watch the live web, and it does not alert you at the moment a link drops. use it when you want the next snapshot comparison sent to you, then open the specific linking pages on your own.
to start, check a domain free. the free result is a preview. the paid plan adds the export and the choice to enable monitoring on a saved site. the amount is shown at checkout for the selected plan and any applicable launch offer.
match the signal to the question
| signal | what it shows | what it does not show |
|---|---|---|
| vendor lost filter | a change inside that vendor's indexed evidence. | by itself, whether the live page removed the href. |
| common crawl snapshot diff | domains observed in one named graph and absent from another. | whether one linking page still contains a link. |
| manual page fetch | what the final fetched page's html contains after redirects. | what every page on the referring domain contains. |
| crawlgraph release-monitor digest | sampled additions, absences, and authority moves between named releases. | a live removal, or the moment a link dropped. |
when the job is a live lost-link audit, fetch the linking page and read it. when the job is a repeatable referring-domain diff against the open graph, use two paid exports or enable the monitor. a snapshot tool does not stand in for a live proprietary crawler. the tradeoff is spelled out in what a cheaper ahrefs alternative does and does not replace.
faq
What is a lost backlink?
A lost backlink is a link the linking page no longer shows. Some tools also mark a link lost when it drops out of their newest index. That second case still needs a look at the live page before the link is treated as removed.
How do I tell a removed link from an index gap?
Keep the original linking URL, follow redirects, and confirm you reached the comparable article rather than a login, consent or replacement page. Check the HTML and rendered links, including relative destinations. A link still present disproves removal; an inaccessible or different page leaves the result unconfirmed.
Does a missing referring domain in a new Common Crawl graph mean the link was deleted?
No. The older graph observed the domain and the newer graph did not. The later crawl may never have requested that linking page again, so the live link still needs its own check.
Can the free crawlgraph result show lost backlinks?
No. The free result is five referring-domain rows, too small a sample for a loss audit. Paid exports and the optional release monitor can compare named graph releases. Neither one proves that a live link was removed.
writes the queries we run internally. ships one tactical post a week.
plus one when a new common crawl release lands. that is all.