Backlink Checker API - Backlinks, Referring Domains & Anchors avatar

Backlink Checker API - Backlinks, Referring Domains & Anchors

Pricing

from $10.00 / 1,000 backlink rows

Go to Apify Store
Backlink Checker API - Backlinks, Referring Domains & Anchors

Backlink Checker API - Backlinks, Referring Domains & Anchors

Get the full backlink profile for any domain as structured JSON: domain score, referring-domain count, total-link count and one row per backlink with anchor text, follow/nofollow and the linking domain's authority. For SEO audits, competitor link gaps and bulk checks, no subscription, pay per row.

Pricing

from $10.00 / 1,000 backlink rows

Rating

0.0

(0)

Developer

SR

SR

Maintained by Community

Actor stats

2

Bookmarked

691

Total users

93

Monthly active users

5 days ago

Last modified

Features

Limited permissions

Share

The backlink checker API on this page returns the full link profile for any domain as structured JSON, without the captcha-solving and site-update maintenance you would otherwise own. Run it from the Apify Store with one click, or call it from your own service through the Apify API. Pay only for the lookup and the rows you get back: no monthly subscription, no per-seat pricing.

A backlinks checker answers one question that drives most of off-page SEO: who links to this domain, and how much authority do those links pass. This Actor takes a domain and returns its link profile as structured JSON, the referring domains count, the total link count, the share of dofollow links, a domain authority score, and a per-link breakdown with the anchor text and source. You get the same shape of data an SEO team pulls before a link-building campaign or a competitor audit, without a per-seat subscription.

The practical workflow is simple. Point the backlinks checker at your own domain to see where your authority comes from and which links are worth protecting, then point it at the domains ranking above you to find the referring domains they have and you do not. Those gaps are your outreach shortlist. Because the output is JSON and billed per result, you can run it across a whole list of competitors in one pass and load the link gaps straight into a spreadsheet.

What the source returns, and what it reports

This is the number to understand before you plan a run.

The source reports a total and hands over a capped list. zyte.com reports 25,440 backlinks and returns 462. On shoppingscraper.com a real run reported 288 and returned 168 rows from 89 distinct referring domains, so even a small profile comes back as a sample rather than the whole of it.

total_link_count is what the index says the profile holds. backlink_count on each row is how many first-index links the source handed over, counted before any maxBacklinks cut. backlinksReturned in the run summary is how many link rows this dataset actually contains after that cut, including any second- and third-index rows. Those last two are different figures on purpose: see the field table below. The gap against total_link_count is the source's own ceiling, not a parse failure, and no parameter widens it — limit and offset are ignored and everything else errors.

So for a large domain, treat this as a strong sample of the profile rather than the whole of it, and use total_link_count for the headline figure.

Maximum backlinks per domain (maxBacklinks) caps the rows, and therefore the cost.

Two indexes, and they disagree

Every backlink tool reports a single number and none of them tell you how much to trust it. This one runs the domain past two independent indexes and puts both answers in the row.

They will not agree. Measured on the same domain on the same day, one index reported 418 backlinks and the other 906, and their link lists barely overlapped: one had github.com and news.ycombinator.com, the other had saashub.com and linkorado.com. Neither is a superset of the other. They crawl different parts of the web and refresh on different schedules.

Nothing is merged. total_link_count is the first index and second_backlink_count is the second, and there is no averaged figure anywhere in the output, because an average of two numbers that differ by a factor of two is wrong for both. backlink_sources tells you how many answered.

The spread is itself the useful part. Two indexes that roughly agree mean the profile is well-established and evenly crawled. A large gap usually means the links are recent, or concentrated somewhere one crawler reaches and the other does not, and that is worth knowing before you quote any single number to a client.

One thing does hold steady across both, and it is the most useful number in the output for that reason. On a domain where the counts differed by 46 per cent (288 against 420), the dofollow share agreed to within a point: 74.0 and 72.9. Absolute link counts depend on how much of the web a crawler has seen; the ratio between followed and nofollowed links does not. So when the two indexes disagree on size, follow_percent and second_follow_percent are still the pair to trust.

The same idea applies to authority: domain_score and second_domain_score are each index's own trust score, and open_page_rank is a third opinion derived from the Common Crawl web graph when you supply a free key.

Turn Check against a second backlink index off for a slightly faster run with one source.

How good are those referring domains, and which way are they moving

A referring-domain count answers "how many" and stops there. Two domains with 11,000 referring domains each can be in completely different health, and the count cannot tell them apart. Two columns fix that.

referring_domain_authority_spread counts referring domains into ten authority bands, 0-10 through 90-100. On zapier.com, 57,557 of the 118,308 domains in that spread sit in the bottom 0-10 band. The headline number reads like an unassailable profile; the spread shows that about half of it is a long tail of near-worthless domains. That is the difference between a link profile you can quote to a client and one you cannot.

The bands come from the distribution of one source's view of your referring domains — the same source that supplies the new/lost series below — so they add up to neither referring_domains_count nor second_referring_domains_count. On zapier.com the spread totals 118,308 while referring_domains_count was 74,231; on the shoppingscraper.com run above it totals 157 against referring_domains_count 85 with second_referring_domains_count empty. Read the spread as that source's own distribution, not as a breakdown of either count.

referring_domains_new_lost_series gives referring domains gained and lost per day, with referring_domains_gained and referring_domains_lost as totals. A single snapshot cannot show direction. 1,003 gained against 392 lost is a profile compounding; the reverse is one decaying while the headline count still looks fine.

Neither figure is available from any other source in this Actor, and both answer on every domain, including ones the 100-link sample cannot reach because no crawl exists for them yet. They add no billed rows. Turn Add the referring-domain authority spread and trend (referring_domain_trends) off for a slightly faster run.

They do not raise backlink_sources. This is more detail about one index's view of your links, not another index's opinion, and counting it as one would be a claim the numbers do not support.

FieldTypeDefaultDescription
domainstringrequiredDomain to analyze (e.g. "coolblue.nl" or "example.com"). Scheme, www and any path are stripped before the lookup; one run covers one domain.
include_backlinksbooleanTrueIf false, returns only the domain-level summary (faster, smaller payload), one billed result instead of hundreds. The second_* metric columns still fill that one row; the third index is a row source only, so it is not queried and third_* stays null/0 without a third_index_miss.
timeoutinteger60How long to wait for the backlink lookup (1-60 seconds; the lookup is capped at 20 s on the endpoint).
second_indexbooleanTrueCheck the domain against a second, independent backlink index and return its counts, trust scores and dofollow split in their own columns.
second_index_linksbooleanTrueAlso return the second index's own backlinks as rows, marked link_source=second_index. Up to 100 more, and they barely overlap the first index. On by default; every row is billed, so use maxBacklinks for a cost ceiling or turn this off for the first index alone.
referring_domain_trendsbooleanTrueAdds the authority spread of the referring domains in ten bands plus a daily gained/lost series. Adds no billed rows.
maxBacklinksinteger0Stop after this many backlink rows (0-5000). Also the cost ceiling, since every row is billed. 0 means no cap beyond what the source returns.
max_backlinksinteger—Alias of maxBacklinks, for older integrations. When both are set, the smaller positive limit applies; 0 still means no cap.
include_thumbnailbooleanTrueAdds the thumbnail column (a preview image URL of the analysed site) to every row. Turn off to drop the column.
third_indexbooleanTrue (reports when not configured)Supplementary rows from a third index, when that index is configured on the endpoint. Needs Include per-link records on: this index only produces link rows, so a metrics-only run skips it and leaves third_* null/0 without reporting third_index_miss. Until it is configured, a run that still wants rows under maxBacklinks reports third_index_miss and the three third_* columns stay null/0: no extra rows appear. A run whose cap is already full from the first two indexes does not report it, because no third-index row could have been added. When it is configured, rows come only when no maxBacklinks is set or the first two indexes returned fewer rows than maxBacklinks. Free-plan runs always come from the first two indexes.
openpagerank_keystringoptionalAdds a third authority opinion from Open PageRank, derived from the Common Crawl web graph. Free for 30,000 domains a month. Without it the backlink data is unchanged and the run says the score is single-sourced.

Output

Every run pushes results to the Apify dataset as JSON records. One record per backlink, not per referring domain: a site that links to you from three pages is three rows. The row count is therefore neither a referring-domain count nor simply backlink_count. On shoppingscraper.com the first index hands over 168 links from 89 referring domains; second_index_links can add up to 100 more rows on top of that, and maxBacklinks — 10 rows on the free plan — cuts the list to the cap. summary.backlinksReturned and billing.scraped count the rows in this dataset, and those are the ones you pay for.

Every row also repeats the target domain's own figures — domain_score, total_link_count, referring_domains_count, follow_percent — and both indexes side by side, so a CSV export stands on its own without a join. A row carrying only the link would force you to join it back against something else to know whose profile it belongs to.

Set Include per-link records (include_backlinks) off to get a single row with the metrics and no links, which is one billed result instead of hundreds. The second_* metric columns still fill that row; the third index only produces link rows, so it is skipped and third_* stays null/0.

One real row, from a run on shoppingscraper.com (abridged to the columns below; that run returns 52 fields per row, with the domain metrics repeated on each row and the three third_* columns always present — filled once the third index is queried, null/0 when it was not):

{
"url_from": "https://shoppingresult.com/company/",
"domain_from": "shoppingresult.com",
"url_to": "https://shoppingscraper.com/",
"anchor_text": "shoppingscraper",
"nofollow": false,
"link_type": "text",
"source_domain_score": 25,
"link_status": "active",
"link_source": "first_index",
"domain": "shoppingscraper.com",
"domain_score": 37,
"referring_domains_count": 85,
"total_link_count": 288,
"follow_percent": 74,
"backlink_count": 168,
"third_backlink_count": null,
"third_domain_score": null,
"third_index_link_rows": 0,
"position": 1
}
FieldFrom
url_from, domain_from, url_to, domain, anchor_text, nofollow, link_type, source_domain_score, link_status, outbound_links_on_pageThe backlink itself
link_sourceWhich index wrote this row: first_index, second_index or third_index
position1-based place in this run's rows (absent on the single metrics row of an empty profile)
backlink_countFirst-index link rows the source handed over, counted before any maxBacklinks cut. Not the same figure as summary.backlinksReturned, which is the link rows in this dataset after the cut (including second- and third-index rows), and not summary.backlinksReported, which is what the source says the profile holds
total_link_count, referring_domains_count, domain_score, follow_percentFirst index
second_index_link_rowsRows in this run with link_source = second_index, after any maxBacklinks cut
second_backlink_count, second_referring_domains_count, second_domain_score, second_page_score, second_follow_percent, second_backlinks_sampleSecond index
third_index_link_rows, third_backlink_count, third_domain_scoreThird index — the three columns are on every row; they fill once that index is queried (configured, third_index and include_backlinks on, and room under maxBacklinks), and stay null/0 when it was not
open_page_rank, open_page_rank_integer, open_page_rank_positionOpen PageRank, when a key is supplied
backlink_sources, authority_sourcesHow many sources answered

second_backlinks_sample is capped at ten links. That is the second index's own ceiling rather than a setting here, and its summary counts are complete. Turn on second_index_links to get up to 100 of that index's links as full rows instead, in the same columns as every other row and marked link_source=second_index.

The two indexes find largely different links. On one test domain, only 2 of the second index's 100 referring domains already appeared in the first index's 218 rows, and the other 98 skewed toward link networks. That is the point of asking both: a link audit that cannot see the spammy half is not an audit. spam_score and source_page_score are reported by the second index only and stay null on first_index rows.

The first index returns every link it will give for a domain in one call, which is fewer than total_link_count says the profile holds. That gap is the source's ceiling, not a truncation here, and the run summary reports backlinksReturned against backlinksReported so you can see it. The row field backlink_count is the first-index haul before any maxBacklinks cut; backlinksReturned counts the link rows that made it into this dataset.

You can:

  • Download the dataset as JSON, JSONL, CSV, or Excel from the Apify console
  • Stream results via the Apify API for use in your own application
  • Pipe results to webhooks, S3, BigQuery, or any of Apify's 30+ integrations
  • Diff today's run against yesterday's to detect changes (new entries, removed entries, modified fields)

When a source comes back empty, which empty is it

"No data" is several different facts, and they call for different reactions. Most of them are soft: the errors record names which one happened, warnings carries the same lines, and the run still succeeds with everything the other sources did return. Every finding also carries kind. partial is true when a requested phase did not fit or did not answer (budget, timeout, a skipped third index, not configured, or a failed call). Findings whose kind is answer report emptiness as the answer — the phase replied, and what it held for this domain is nothing — and sit in errors and warnings without setting partial. gap findings set it.

CodeWhat it meansWill a re-run help?
openpagerank_missOpen PageRank held no rank for this domain (answer), or was unavailable (gap). The backlink figures are unaffected; only the second authority opinion is missing.Maybe
second_index_no_crawlThe second index has never crawled this domain, so it has no links to add for it.No. The answer is stable
second_index_links_emptyIt has crawled the domain and holds no links for it. That is its answer, not a failure.No
second_index_links_missIts link list was unavailable, or that part of the run is not configured here.Yes (when unavailable)
second_index_missThe second index did not answer with a backlink profile for this domain, or is not configured here (gap); either way the counts are single-sourced rather than corroborated.Yes
referring_domain_trends_partialThe authority spread or the new/lost series was unavailable; the other half is in the row.Yes
referring_domain_trends_missThe authority spread and trend were unavailable, or are not configured here.Yes (when unavailable)
third_index_missThe third index added no link rows for this domain — it answered empty or every link was already present (answer), or it is not configured here, was unavailable, or the run ran out of time before asking (gap) (when third_index and include_backlinks are both on and maxBacklinks still has room; a metrics-only run asks for no rows and a run whose cap the first two indexes already filled could not have taken a third-index row, so neither reports this).Maybe

One code is not soft. upstream_quota_exhausted means the first index's allowance for this run is spent. That is a fatal first-index failure: the other enrichment sources are never asked, the run ends with an empty result (Apify reports it as succeeded with zero rows) and nothing is charged. A later run draws a new allowance.

The distinction that matters most among the soft codes is the second row against the fourth. A domain nobody has crawled and a source that was briefly unavailable look identical in an empty dataset, and only one of them changes if you run it again. The second row will read the same tomorrow; the fourth is worth another go.

The Actor already retries the recoverable ones for you before reporting anything, so an error in this list means it tried and the condition persisted.

Use cases

Competitive monitoring

Run the backlinks checker weekly across your top competitors. Spot meaningful changes before they show up anywhere else.

Lead enrichment

Pipe backlinks checker data into your CRM as part of a nightly enrichment job, every record gets the structured fields your team needs.

Market research

Aggregate backlinks checker data across a category to size demand, identify gaps, and find under-monetized niches.

Operational reporting

Schedule the backlinks checker as a recurring Apify task. Pipe results to your warehouse and surface in your existing dashboards.

How it compares

Ahrefs is a great tool, but it has trade-offs that this Apify Actor avoids:

  • No subscription lock-in. Ahrefs typically requires a monthly contract starting at $99-$449/month. This Actor charges per run, you can spend $5 on a one-off competitive audit and walk away.
  • Direct dataset access. Instead of clicking through a dashboard UI to copy data, you get a machine-readable JSON dataset on every run. Pipe it straight into BigQuery, Snowflake, or your warehouse.
  • Hosted scraping infrastructure. Apify handles the fetching, the retries and the captcha solving, so you get the same data Ahrefs returns, without paying for their reporting layer you may not need.
  • No per-seat pricing. Anyone on your team can call the Actor's API; pricing is based on usage, not seats.

The established backlink APIs all require you to register, manage an API key, and buy into a credit or subscription plan before the first call. This Actor runs on Apify with no key to manage and returns the link profile as JSON per run.

No API key to manageHosted for youJSON outputUsage-based, no monthly plan
This ActorYesYesYesYes
DataForSEO Backlinks APINo, key requiredYesYesCredit or subscription
SE Ranking Backlinks APINo, key requiredYesYesSubscription
vebapi Backlink Data APINo, key requiredYesYesCredit plans

FAQ

There is no monthly subscription and no minimum spend: you pay per run. On the free Apify plan every run is capped at 10 rows, which is enough to check one competitor; the $0.015 lookup fee still applies on a successful check. Paid plans deliver everything the sources return. For long-running daily jobs your monthly bill scales with the lookup and the rows you pull — see Pricing.

$0.015 per successful domain lookup plus $0.01 per backlink row delivered. A run whose lookup fails is not charged. The example run on shoppingscraper.com asks for maxBacklinks: 2, so it delivers and charges $0.015 + 2 × $0.01 = $0.035; the 168 first-index links that backlink_count reports on those rows would be $0.015 + 168 × $0.01 = $1.695 if you drop the cap and let the run deliver all of them. backlinksReturned and billing.scraped always count the rows in the dataset — those are the ones you pay per row for; billing.domain_checked is the single lookup fee.

Compared to Ahrefs, this Actor returns the same structured data without the monthly subscription or per-seat pricing. You pay per run, not per month, which is dramatically cheaper for most teams that need data in bulk but don't need a dashboard UI.

The full input schema is rendered as a form on the Apify Store page, you can run a job by filling out a few fields with no code. The schema also accepts raw JSON if you're calling the Actor via the Apify API from your own service. See the Input section above for the field list.

The Actor fetches the data directly from the source, so accuracy matches what a human user would see on the page. There's no third-party cache or middleware, every run returns the live state. If the upstream site throttles requests, the Actor retries. What remains is reported, not hidden: soft gaps land as structured errors in the dataset's errors field, while a spent first-index allowance ends the run with the fatal upstream_quota_exhausted and an empty result instead — see When a source comes back empty above.

Yes, Apify has built-in scheduling. You can set the Actor to run hourly, daily, or weekly, and pipe results to webhooks, S3, or your data warehouse via the Apify integrations. Most teams schedule the backlinks checker as a daily task and incrementally diff against the previous run to detect changes.

Pricing

From 9 October 2026 this Actor uses pay-per-event pricing with two events, so your bill scales linearly with usage. There is no monthly subscription and no minimum spend. Before that date only the per-row event exists (titled "Domain checked") and there is no lookup fee.

  • Domain checked — one domain lookup per successful run, charged once even when the domain turns out to have no backlinks, because the lookup costs the same either way. Not charged if the lookup fails.
  • Backlink row — one row in the dataset. A domain with no backlinks returns a single metrics row and is charged as one.
EventPriceWhen it is charged
Domain checked$0.015 per lookupOne per successful run, also when the domain has no backlinks. Not charged if the lookup fails.
Backlink row$0.01 per rowOne per row in the dataset. The maxBacklinks: 2 example on shoppingscraper.com is $0.015 + 2 × $0.01 = $0.035; without that cap the same domain delivers 168 rows at $0.015 + 168 × $0.01 = $1.695. A domain with no backlinks still returns one metrics row, charged as one.

There is no monthly subscription, no minimum spend and no per-seat fee. Runs on the free Apify plan are capped at 10 rows, and the $0.015 lookup fee still applies on a successful check; upgrade the plan or split the work across runs to get the full profile. Set maxBacklinks to the number of rows you are willing to pay for and the row part of the bill stops there.

⌂ 换网址