🔗 Website Backlink Checker & Audit

Website Backlink Checker & Audit lets you collect backlinks, referring domains, anchor-text distribution, backlink quality signals, and optional live link status for domains, subdomains, and URLs.

Build backlink reports, prioritize important links, inspect lost-link signals, research competitors, and export structured SEO data without manually checking referring pages one by one.

• 🔎 Discover backlinks: retrieve backlink data through a managed upstream Apify backlink provider
• 📊 Audit backlink quality: add deterministic priority scores, bands, recommended actions, and reason codes
• 🧭 Analyze referring domains: see which domains link to a target and normalize source authority to a stable 0–100 scale
• 🏷 Analyze anchor text: inspect which anchors appear most often and their observed share
• 🧪 Verify selected links live: optionally fetch referring pages and confirm whether a matching link is currently present
• 🧹 Get cleaner output: normalize targets, remove duplicate targets, deduplicate detailed rows, and enforce per-target output caps
• ⚡ Automate workflows: consume results through Apify Dataset, API, integrations, spreadsheets, databases, monitoring systems, or AI workflows

---

📦 What data does Website Backlink Checker & Audit return?

The exact fields depend on the selected report type.

🎯 Target input	🔗 Normalized target
🧭 Target scope	📄 Report type
🕒 Checked timestamp	🧩 Data source
🔎 Provider request ID	▶️ Actor run ID
🌐 Source domain	🔗 Source URL
📰 Source page title	🎯 Target URL
🏷 Anchor text	✅ Dofollow status
📈 Source domain rank	⚠️ Backlink spam score
🗓 First seen	🗓 Last seen
❌ Lost status	🧪 Live verification status
⭐ Priority score	🚦 Priority band
🧭 Recommended action	🧾 Reason codes

Unavailable provider fields are returned as null or an empty array. The Actor does not invent SEO metrics that the current upstream provider does not expose.

The public dataSource value for the current adapter is:

ApifyUpstream

---

🚀 Features

Website Backlink Checker & Audit is designed for SEO research, backlink monitoring, reclamation, and automation.

• Multiple targets: process up to 20 domains, subdomains, or absolute URLs in one run
• Five report types: summary, backlinks, audit, anchors, and referring_domains
• Up to 1,000 persisted detail rows per target
• Target normalization: equivalent domain inputs are normalized before processing
• Duplicate-target removal: duplicate normalized targets are not processed twice
• Stable public schema: provider-specific snake_case data is mapped into predictable camelCase records
• Authority normalization: upstream 0–1000 source-domain authority is converted to a public 0–100 scale
• Deterministic audit scoring: audit rows receive transparent priority fields instead of a black-box recommendation
• Optional live verification: selected referring pages can be checked at run time
• SSRF-safe verification: private, loopback, link-local, metadata-service, and unsafe redirect destinations are blocked
• Partial-failure protection: one failed target does not erase successful targets from the same run
• Named storage: summaries and errors are kept separately from normal result rows
• Spending guard: the Actor reserves billable capacity before starting provider work for a target
• No customer backlink-provider API key: users do not need to create or configure a separate backlink-data account
• No browser required for live verification: selected pages are fetched with bounded HTTP requests and HTML parsing

---

⬇️ Input

You can configure Website Backlink Checker & Audit directly from the Apify Console or send input programmatically through the Apify API.

🎯 Targets

Add one or more domains, subdomains, or URLs.

Examples:

example.com
blog.example.com
https://example.org/resources/

Current limits:

Minimum: 1 target
Maximum: 20 targets

Targets are normalized before processing.

Equivalent root-domain inputs can collapse into one normalized target, preventing duplicate work and duplicate billing.

---

📄 Report type

Supported report types:

summary
backlinks
audit
anchors
referring_domains

Default:

audit

summary

Returns a compact backlink-profile overview for each successful target.

backlinks

Returns flat backlink rows.

audit

Returns backlink rows, then adds scoring fields such as:

priorityScore
priorityBand
recommendedAction
reasonCodes

Optional live verification can also be enabled for this mode.

anchors

Returns anchor-text distribution rows.

referring_domains

Returns one flat row per observed referring domain.

---

🧭 Target scope

Supported values:

root_domain
subdomain
exact_url

Default:

root_domain

exact_url requires an absolute HTTP or HTTPS URL.

---

🔢 Maximum results per target

Controls the maximum number of persisted detail rows returned for each target.

Minimum: 1
Default: 100
Maximum: 1000

For example:

Targets:
example.com
example.org

Maximum results per target:
100

can persist up to:

100 detail rows for example.com
+
100 detail rows for example.org
=
200 detail rows

The requested number is a maximum, not a guarantee.

Some upstream analysis modes can perform or return more work before the local output cap is applied. The Actor still caps persisted detail rows to maxResultsPerTarget, but upstream cost may not be strictly proportional to the final row count.

---

🔴 Backlink status

Controls which backlink state is returned.

live
lost
all

Default:

live

• live excludes provider-reported lost backlinks.
• all includes available live and lost data.
• lost is supported only for backlinks and audit.

For lost-only backlink and audit reports, the Actor locally keeps rows where isLost = true before applying the final row limit.

lost is rejected for summary, anchors, and referring_domains because those report shapes do not expose enough per-row lost-state data to apply the filter truthfully.

---

🧹 Backlink grouping

Available values:

as_is
one_per_domain
one_per_anchor

Default:

one_per_domain

Grouping applies to detailed backlinks and audit output.

The Actor requests a larger candidate pool when necessary, applies the grouping locally, and then enforces maxResultsPerTarget.

• as_is keeps backlink rows as returned.
• one_per_domain keeps one backlink per source domain.
• one_per_anchor keeps one backlink per anchor text.

summary, anchors, and referring_domains are already aggregate report types, so this setting does not change their rows.

---

✅ Dofollow only

Default: false

When enabled, the current upstream adapter asks the provider to return dofollow backlinks only.

---

📈 Minimum source domain rank

Public scale:

Minimum: 0
Default: 0
Maximum: 100

The upstream provider uses a 0–1000 authority scale.

The Actor translates the public input before the provider call:

Public 80 -> Upstream 800

and normalizes returned authority back to the public scale:

Upstream 800 -> Public 80

This keeps your Dataset output on a predictable 0–100 scale.

---

⚠️ Maximum backlink spam score

Minimum: 0
Default: 100
Maximum: 100

Supported report types:

backlinks
audit
referring_domains

The Actor applies this filter locally using backlinkSpamScore before enforcing the final row limit.

It is rejected for summary and anchors, where an equivalent per-row spam-score filter cannot be applied truthfully.

---

🗓 First seen from

Optional format:

YYYY-MM-DD

Default:

null

Supported only for:

backlinks
audit

The Actor filters provider-reported first_seen values locally before applying the final row limit.

It is rejected for the other report types because their current upstream row shapes do not expose equivalent first-seen data.

---

🏷 Anchor contains

Optional case-insensitive text filter.

Default:

null

Supported report types:

backlinks
audit
anchors

The Actor applies the filter locally to anchorText before enforcing the final row limit.

It is rejected for summary and referring_domains.

---

🧪 Verify links live

Default: false

Live verification is available for:

backlinks
audit

When enabled, the Actor fetches selected referring pages and checks whether a matching destination is currently present.

Possible verification states include:

confirmed
missing
blocked
unreachable
unsupported_content
not_checked

A blocked or unreachable referring page is not automatically classified as a lost link.

Provider-reported state and live verification remain separate signals.

---

🔢 Maximum links to verify

Minimum: 0
Default: 25
Maximum: 100

The Actor never verifies more rows than it actually returns.

In audit mode, rows are pre-scored and the highest-priority candidates are selected for verification first.

---

🧹 Deduplicate results

Default: true

Detailed rows are deduplicated using stable keys appropriate to the report type.

For backlinks, identity is based on normalized link details such as source URL, target URL, anchor text, and link type when available.

---

⚙️ Provider concurrency

Minimum: 1
Default: 5
Maximum: 10

This controls how many target workflows may call the upstream provider concurrently.

---

⚙️ Verification concurrency

Minimum: 1
Default: 3
Maximum: 5

This controls concurrent live referring-page checks.

---

🌐 Proxy configuration

An optional Apify proxy can be used for live verification.

The discovery provider call itself runs as a separate Apify Actor call.

Use a verification proxy when selected referring pages block or restrict direct requests.

---

🧪 Example input — backlink audit

{
  "targets": [
    "example.com",
    "example.org"
  ],
  "reportType": "audit",
  "scope": "root_domain",
  "maxResultsPerTarget": 100,
  "backlinkStatus": "live",
  "grouping": "one_per_domain",
  "dofollowOnly": false,
  "minDomainRank": 20,
  "maxSpamScore": 70,
  "verifyLive": true,
  "maxLinksToVerify": 25,
  "deduplicateResults": true,
  "apiConcurrency": 5,
  "verificationConcurrency": 3
}

Inputs that the current upstream adapter cannot faithfully forward are still parsed for compatibility but are documented above as adapter limitations.

---

⬆️ Output

The Actor uses structured Apify storage so each output type remains easy to consume.

📊 Default Dataset

The default Dataset contains the requested report records.

For:

summary

the summary record is available as the main result.

For detailed modes:

backlinks
audit
anchors
referring_domains

the detailed rows are written to the default Dataset.

---

📋 Summaries Dataset

A separate summaries Dataset stores the overview row for each successful target.

This is useful because detailed report modes still perform a summary step before collecting detail rows.

Typical summary fields:

recordType
targetInput
targetNormalized
scope
reportType
checkedAt
dataSource
providerRequestId
runId
domainRank
totalBacklinks
referringDomains
referringMainDomains
referringDomainsNofollow
referringIps
brokenBacklinks
backlinksSpamScore
firstSeen
returnedRows

Fields not exposed by the current upstream summary mode remain null.

---

⚠️ Errors Dataset

Target-specific failures are written separately.

Example shape:

{
  "recordType": "error",
  "targetInput": "invalid target",
  "targetNormalized": null,
  "errorCode": "INVALID_TARGET",
  "errorMessage": "Invalid target",
  "retryable": false,
  "attempts": 1,
  "failedAt": "2026-09-08T05:40:00.000Z"
}

Successful targets remain available even when another target fails.

If every target fails, the Actor fails instead of silently reporting a successful empty run.

---

🧾 OUTPUT summary

The Actor also writes a compact run summary containing fields such as:

runId
defaultDatasetId
summariesDatasetId
errorsDatasetId
processedTargets
failedTargets
returnedRows
verifiedPages
confirmedLinks
missingLinks
duplicateTargetsRemoved
providerCostUsd

This makes it easy for another workflow to inspect the run without reading every Dataset row.

---

📊 Example summary result

{
  "recordType": "summary",
  "targetInput": "example.com",
  "targetNormalized": "example.com",
  "scope": "root_domain",
  "reportType": "summary",
  "checkedAt": "2026-09-08T05:40:00.000Z",
  "dataSource": "ApifyUpstream",
  "providerRequestId": "upstream-run-id",
  "runId": "actor-run-id",
  "domainRank": null,
  "totalBacklinks": 100,
  "referringDomains": 100,
  "referringMainDomains": null,
  "referringDomainsNofollow": null,
  "referringIps": null,
  "brokenBacklinks": null,
  "backlinksSpamScore": 2.5,
  "firstSeen": null,
  "returnedRows": 0
}

domainRank is intentionally null here because the observed upstream summary exposes an average referring-domain rank, not a true target-domain rank. The Actor does not relabel that metric into something it is not.

---

🔗 Example backlink result

{
  "recordType": "backlink",
  "targetInput": "example.com",
  "targetNormalized": "example.com",
  "scope": "root_domain",
  "reportType": "backlinks",
  "checkedAt": "2026-09-08T05:40:00.000Z",
  "dataSource": "ApifyUpstream",
  "providerRequestId": "upstream-run-id",
  "runId": "actor-run-id",
  "sourceDomain": "api.druphelp.com",
  "sourceUrl": "https://api.druphelp.com/article",
  "sourceTitle": "Example page",
  "sourceStatusCode": null,
  "sourceCountry": null,
  "sourceLanguage": null,
  "sourcePlatformTypes": [],
  "targetDomain": "example.com",
  "targetUrl": "http://example.com/dir/file",
  "targetStatusCode": null,
  "finalTargetUrl": null,
  "anchorText": "Example",
  "textBefore": null,
  "textAfter": null,
  "dofollow": true,
  "attributes": [],
  "linkType": null,
  "semanticLocation": null,
  "imageUrl": null,
  "imageAlt": null,
  "backlinkRank": null,
  "sourcePageRank": null,
  "sourceDomainRank": 10,
  "backlinkSpamScore": 5,
  "firstSeen": "2024-02-29 07:08:28 +00:00",
  "previousSeen": null,
  "lastSeen": "2026-09-03 18:03:16 +00:00",
  "isNew": null,
  "isLost": false,
  "isBroken": null,
  "linksOnSourcePage": null,
  "linksFromSourceDomain": null,
  "verificationStatus": "not_checked",
  "linkPresentNow": null,
  "verifiedAt": null,
  "redirected": null,
  "priorityScore": null,
  "priorityBand": null,
  "recommendedAction": null,
  "reasonCodes": []
}

In audit mode, the priority fields are populated by the Actor's audit layer.

---

🏷 Example anchor result

{
  "recordType": "anchor",
  "targetInput": "example.com",
  "targetNormalized": "example.com",
  "scope": "root_domain",
  "reportType": "anchors",
  "checkedAt": "2026-09-08T05:40:00.000Z",
  "dataSource": "ApifyUpstream",
  "providerRequestId": "upstream-run-id",
  "runId": "actor-run-id",
  "anchorText": "link",
  "backlinks": 6,
  "referringDomains": null,
  "dofollowBacklinks": null,
  "firstSeen": null,
  "lastSeen": null,
  "sharePercent": 6
}

---

🌐 Example referring-domain result

{
  "recordType": "referring_domain",
  "targetInput": "example.com",
  "targetNormalized": "example.com",
  "scope": "root_domain",
  "reportType": "referring_domains",
  "checkedAt": "2026-09-08T05:40:00.000Z",
  "dataSource": "ApifyUpstream",
  "providerRequestId": "upstream-run-id",
  "runId": "actor-run-id",
  "sourceDomain": "news.example",
  "sourceDomainRank": 10,
  "backlinks": 3,
  "dofollowBacklinks": 2,
  "backlinkSpamScore": 10,
  "firstSeen": null,
  "lastSeen": null,
  "isNew": null,
  "isLost": null
}

---

⭐ Audit priority fields

Audit mode adds:

priorityScore
priorityBand
recommendedAction
reasonCodes

Recommended actions can include:

reclaim
protect
investigate
monitor
ignore

The audit is deterministic: the same mapped backlink signals produce the same score and recommendation.

The Actor does not automatically recommend disavowing a domain.

---

🧪 Live verification

When enabled, selected referring pages are fetched at run time.

The verifier:

1. validates that the URL is public HTTP or HTTPS
2. blocks private and unsafe destination ranges
3. revalidates redirects
4. caps response size and request duration
5. parses link destinations from the returned HTML
6. compares normalized destinations against the selected target and scope
7. returns one visible verification status

Verification states:

confirmed
missing
blocked
unreachable
unsupported_content
not_checked

A provider-reported lost backlink and a currently missing backlink are not the same concept.

Use both:

isLost
verificationStatus

when investigating reclamation opportunities.

---

🧹 Deduplication

Targets are normalized before processing.

Detailed records are deduplicated when deduplicateResults is enabled.

The Actor also enforces the requested per-target output cap after mapping upstream rows.

This is especially important for upstream analysis modes that can return more rows than the requested public limit.

---

⚡ Performance

Backlink discovery is performed through a managed Apify Actor call, not by launching a browser inside this Actor.

Optional live verification uses bounded HTTP requests and HTML parsing.

This keeps browser overhead out of the normal workflow while still allowing selected links to be checked against the current referring page.

The Actor currently uses:

Node.js 22+
TypeScript
Apify SDK
Cheerio
undici

---

🛡 Reliability

The Actor is designed so one target does not destroy the results of another.

If you process:

example.com
example.org
bad-target

and one target fails, successful target results are still written.

The Actor records target-specific errors in the errors Dataset.

If all targets fail, the run fails instead of silently returning an empty success.

Before provider work begins for a target, the billing layer checks whether enough run spending capacity remains for the reserved events.

---

🔐 Security

Customers do not provide a separate backlink-provider username, password, or API key.

The current production runtime uses Apify's Actor-to-Actor call flow for backlink discovery.

Optional live verification includes SSRF protections:

private IP ranges blocked
loopback blocked
link-local blocked
metadata-service ranges blocked
non-HTTP(S) schemes blocked
redirect destinations revalidated
response size capped
request time capped

Secrets and raw authorization values are not intended to appear in public Dataset records or the final OUTPUT object.

---

🔌 API & integrations

Website Backlink Checker & Audit can be started programmatically through the Apify API.

You can connect results to:

• Google Sheets
• Make
• Zapier
• Airtable
• CRMs
• SEO dashboards
• internal APIs
• data warehouses
• monitoring systems
• AI agents
• MCP workflows

Every run produces structured Dataset rows plus a compact OUTPUT summary.

---

🧪 CLI example

apify call YOUR_USERNAME/website-backlink-checker -i '{
  "targets": ["example.com"],
  "reportType": "audit",
  "maxResultsPerTarget": 100,
  "verifyLive": false
}'

When using Windows PowerShell, a JSON input file is often more reliable than large inline JSON strings.

Example:

$payload = @{
  targets = @("example.com")
  reportType = "audit"
  maxResultsPerTarget = 100
  verifyLive = $false
} | ConvertTo-Json -Compress

[System.IO.File]::WriteAllText(
  "$PWD\INPUT.json",
  $payload,
  (New-Object System.Text.UTF8Encoding($false))
)

apify call YOUR_USERNAME/website-backlink-checker -f INPUT.json -o

---

💡 Example use cases

♻️ Link reclamation

Run:

reportType = audit
verifyLive = true

Then focus on rows where the recommendation and verification signals indicate that a valuable link may deserve restoration work.

Useful fields:

sourceDomain
sourceUrl
sourceDomainRank
backlinkSpamScore
isLost
verificationStatus
priorityScore
recommendedAction
reasonCodes

---

🛡 Protect strong backlinks

Use audit output to find backlinks worth monitoring.

Useful signals:

high sourceDomainRank
dofollow = true
verificationStatus = confirmed
recommendedAction = protect

---

🔎 Backlink research

Use backlinks mode to export a flat list of referring pages and target destinations.

This works well for:

SEO audits
competitive research
link-profile reviews
content promotion research
PR research

---

🧭 Referring-domain analysis

Use:

reportType = referring_domains

to inspect which domains contribute backlinks.

Useful fields:

sourceDomain
sourceDomainRank
backlinks
dofollowBacklinks
backlinkSpamScore

---

🏷 Anchor-text analysis

Use:

reportType = anchors

to understand the observed anchor distribution.

Useful fields:

anchorText
backlinks
sharePercent

---

📊 Fast profile overview

Use:

reportType = summary

when you only need a compact backlink-profile overview.

This is a useful first pass before deciding which domains need a deeper audit.

---

⚠️ Current limitations

The Actor intentionally avoids claiming data that the current upstream provider does not expose.

Current limitations include:

No proprietary backlink index owned by this Actor
No Ahrefs, Semrush, or Moz parity claim
No proprietary DR / DA / Authority Score branding
No automatic Google disavow recommendation
No automatic outreach emails
No persistent cross-run history in the MVP
No competitor backlink-gap report in the MVP
No browser-rendered verification for JavaScript-only pages

Upstream coverage

Backlink discovery depends on the current managed upstream Apify provider.

Results therefore reflect that provider's:

index coverage
crawl recency
available row shape
mode behavior
provider availability

The Actor adds normalization, audit scoring, storage, billing controls, and optional live verification, but it does not claim that its raw discovery coverage is larger than the upstream source.

Upstream mode behavior

Observed upstream behavior can differ by mode.

For example, during migration probes:

• detail backlinks mode respected a one-row request
• summary mode used its own analysis limit
• anchors mode returned a full anchor distribution even when a one-row limit was requested

The adapter enforces the public output cap locally, but upstream work and cost can occur before that cap.

Current compatibility inputs

The public schema still contains several filters from the earlier provider contract.

The current upstream adapter directly maps:

target
reportType -> upstream outputMode
maxResultsPerTarget
dofollowOnly
minDomainRank
live status -> exclude lost

Other compatibility fields are not all forwarded upstream yet.

Those fields remain documented in the Input section so users can distinguish the stable public contract from current adapter capabilities.

---

💳 Cost & billing notes

The Actor uses pay-per-event billing guards internally.

Configured event names include:

domain-report
result-row
verified-page

The final Store price should be based on measured upstream Actor cost plus Apify compute and optional verification/proxy cost.

Upstream charges are not purely per persisted row.

During migration testing, even very small one-target probes had non-zero minimum upstream charges.

For that reason, do not interpret maxResultsPerTarget = 1 as meaning the provider cost will be approximately one row's price.

The price shown in the Apify Store is the customer-facing source of truth after release pricing is finalized.

---

❓ FAQ

Where does the backlink data come from?

Backlink discovery is retrieved through a managed upstream Apify backlink provider.

The public Dataset identifies the source as:

ApifyUpstream

The Actor then maps the upstream data into its own stable output contract.

---

Do I need my own backlink-provider API key?

No.

Customers do not enter a separate backlink-provider username, password, or API key.

---

Is this the same as Ahrefs, Semrush, or Moz?

No.

The Actor does not claim equivalent crawl coverage or proprietary metrics.

It provides a commercial workflow around the current upstream backlink source:

bulk targets
normalized output
audit scoring
optional live verification
partial-failure handling
Apify storage
API automation

---

Why is domainRank sometimes null?

The current upstream summary response exposes an average source-domain rank, not a target-domain authority metric.

The Actor deliberately leaves domainRank as:

null

instead of relabeling an average referring-domain metric as the target's own rank.

---

Why are many backlink fields null?

The stable public schema is broader than the current upstream row shape.

If the provider does not expose a field such as:

sourceCountry
sourceLanguage
linkType
semanticLocation
imageUrl
previousSeen
sourceStatusCode

the Actor returns null or an empty array rather than fabricating data.

---

Why is source domain rank divided by 10?

The current upstream provider uses a 0–1000 authority scale.

The Actor's public contract uses 0–100.

Example:

Upstream rank: 800
Public sourceDomainRank: 80

---

Can I verify every backlink live?

You can request up to:

100 live verifications per target

but verification is intentionally limited because every referring-page fetch adds time, network work, and potential proxy cost.

For larger reports, use audit mode and verify only the highest-priority rows.

---

Does missing mean the backlink is definitely permanently lost?

No.

It means the verifier did not find the matching link in the fetched page at that time.

A page can change, block the request, serve different content, require JavaScript, or later restore the link.

Use verificationStatus together with the provider's isLost signal.

---

What happens if a referring page blocks the verifier?

The Actor reports a state such as:

blocked
unreachable
unsupported_content

instead of pretending the backlink is missing.

---

What happens if one target fails?

Other valid targets continue.

The failed target is written to the errors Dataset.

If every target fails, the Actor run fails.

---

Can I export the results?

Yes.

Apify Dataset results can be exported in formats supported by the platform, including common workflows such as:

JSON
CSV
Excel
XML

---

Can I use it through an API?

Yes.

The Actor is designed for both interactive Console runs and programmatic Apify API workflows.

---

🧭 Recommended workflow

For most backlink-audit jobs:

1. Start with summary for a quick profile overview.
2. Run audit only on targets that need deeper inspection.
3. Keep maxResultsPerTarget modest while validating the target.
4. Use minDomainRank to reduce low-authority discovery rows when useful.
5. Enable verifyLive only when current-page confirmation adds value.
6. Keep maxLinksToVerify focused on the most important candidates.
7. Review isLost and verificationStatus as separate signals.
8. Export the final Dataset into your SEO, CRM, reporting, or monitoring workflow.

For anchor research, use anchors directly.

For domain-level link-profile analysis, use referring_domains.

---

💬 Feedback & support

Found a bug or have a feature request?

Use the Actor's Issues tab on Apify.

Useful future additions may include:

Competitor backlink-gap reports
Persistent snapshots
Cross-run new/lost change detection
Scheduled monitoring
Alerts and webhooks
More adapter-side filters
Provider fallback support
Domain-level rollups
Additional link-opportunity enrichment

---

🚀 Backlink data without the manual checking

Enter your targets, choose a report type, run the Actor, and receive structured backlink data ready for SEO audits, link reclamation, competitor research, reporting, APIs, and automation.

Add live verification only where it creates real value, and use the Actor's audit fields to focus attention on the links that matter most.