When a backlink shows up in one report and not in another, the reports are not necessarily disagreeing. Search Console, a third-party link tool and the page's own HTML are three separate witnesses, and each was asked a different question. Treat them as one ladder of evidence: the page source settles whether the link exists and how it is written, Search Console shows what Google reports knowing, and a tool shows what its own crawler archived. Buyers, publishers and agencies who write backlink reports can use that ladder to stop arguing about numbers and start recording what each source actually proves.
The practical rule is short. Never write "the link is live" on the strength of a dashboard alone, and never write "the link is missing" because one dashboard is silent.
Why one link produces three different answers
Before comparing any rows, separate what each source can know.
Search Console knows what Google chose to report
The Links report in Search Console covers links pointing to your verified property and links inside it. In the external section it offers tables for top linked pages, top linking sites and top linking text, plus drill-downs that show which sites link to a given page and which pages on a given site link to it. The Search Console Help page for the report (Opens in a new tab) states plainly that it is not a comprehensive list of every link, and that some URLs, such as non-indexed pages or deduplicated URLs, may be left out.
A link tool knows what its crawler archived
Commercial backlink tools run their own crawlers and keep their own indexes. How often they revisit a page, when they mark a link as lost and how they merge duplicates differ by vendor. Google's documentation says nothing about how those tools work, so each vendor's own methodology page is the place to check definitions. If tool A lists a link and tool B does not, the likeliest reading is different coverage, not a fake link.
The page source knows only the present
Opening the publisher's URL and inspecting the HTML tells you whether an anchor element exists, where its href points, what text it carries and which rel values it has. It cannot tell you whether Google has processed the link, and it says nothing about last month.
| Source | Question it can answer | What it cannot answer |
|---|---|---|
| Search Console | Does Google report this link for my property? | Whether the link is live today, whether it is nofollow, whether the list is complete |
| Link tool | Did this vendor's crawler see the link, and when? | Whether Google knows about it, whether it is still there |
| Page source | Is the link written correctly right now? | Whether Google has seen it, how long it has been there |
Reading the Search Console side without over-reading it
For a walkthrough of the report itself, see how to check backlinks with the Search Console links report. Here the focus is how its quirks affect reconciliation.
Where the rows come from
The help page says tables are limited to 1,000 rows, so large or heavily linked sites may see truncated tables, and exports can reach up to 100,000 rows with the Export button. Single-table pages export up to 1,000 rows. Values shown as a tilde or a dash are exported as zeros, which matters if you plan to sum an export.
How rows are merged
Data is grouped by root domain, with protocol, subdomains such as m. and www, and subdirectories stripped. A link from a publisher's blog subfolder and one from its mobile subdomain collapse into one linking site. Pages are grouped by canonical URL, and duplicate links, meaning the same source URL pointing to the same target URL after parameters are normalized, are combined. In the anchor text table, duplicates are case-insensitive exact matches of the text, and links without text appear as "(empty)".
A buyer who ordered two links from one publisher and sees one row has probably met this merge, not a missing delivery. The detail view for that linking site is the next place to look.
Old rows and redirected targets
The report keeps links Google found over time, so a row may describe a link that has since been removed or a page that no longer exists. A row is therefore history, not proof of a live link. The "Target URL (if different)" column in the top linking pages table is filled when the link URL differs from the target page, which the help page attributes to a redirect or a canonical choice. If you ordered a link to a campaign URL and the report shows another target, start there. Menu and column names may look different if you use the interface in another language.
Interpreting link-tool data
A link tool is the widest lens and the least standardized one. Two habits keep it useful.
Never compare totals across tools
A tool total is a count inside that tool's index. Comparing it to Search Console totals compares two different populations. A better comparison is row level: take one publisher page and one target URL and ask each source whether it lists that pair.
Questions to ask about each tool row
- When did the tool first and last see the link?
- Does it show the rel attribute, and does it show it per link or only as a summary?
- Does the anchor text and target match the order?
- Is the row about a page or an entire domain?
- What does the vendor mean by "lost" or "removed"?
Write "unknown" for any question the tool cannot answer. An honest unknown is worth more in a report than a guess.
What a tool screenshot is worth
Practical suggestion: attach tool output as supporting evidence, not as the headline. If a dispute starts, a dated capture of the publisher's HTML will carry more weight than a vendor dashboard. The tool is most valuable when it adds timing, such as when the link first appeared.
Verifying the link in the page source
This is the step that turns "probably" into "confirmed" and the one that is easy to skip.
What to inspect
Google's link best practices page (Opens in a new tab) says Google can only crawl a link reliably when it is an anchor element with an href attribute, and that links built from elements without an href are not recommended. So check four things in the source: the anchor element exists, the href matches the ordered target exactly, the visible anchor text matches the order, and the rel attribute matches the agreement. The same page recommends marking paid links with sponsored or nofollow, so a sold link with no qualification is worth a note in your log.
Links added by JavaScript
The documentation says links inserted dynamically are still crawlable when they use standard anchor markup, while addresses that depend on javascript: calls are not recommended. When a link does not appear in raw HTML but shows in the browser, view the rendered DOM. For text added by script, the documentation points to the URL Inspection tool's rendered HTML, which works for properties you have verified. For a publisher's site you cannot verify, the browser's developer tools show the live DOM and are a practical stand-in.
Image links
For an image link, the documentation says Google uses the image's alt text as the anchor. An empty alt on a linked image therefore behaves like an empty anchor, and a missing text row in Search Console's text table may appear as "(empty)". Record the alt value alongside the href.
A decision rule for conflicting sources
Practical suggestion: apply the ladder in this order.
- Page source correct (address, text, rel): label the delivery "confirmed." Missing dashboard rows are timing, not failure.
- Page source has no link: label it "not delivered or removed," whatever a dashboard says.
- Page source has a link but one detail is wrong: label it "delivered with errors" and ask for a fix.
- Page does not load: log the HTTP status and treat the link's fate as tied to the page's fate.
Building the reconciliation table and writing the report
Columns and allowed values
One row per publisher page and link. Columns: publisher URL, ordered target and anchor, source check result with date, Search Console status, tool status, final label, next check date. Allow only four values in the source columns: present, absent, unknown, not checked. Absent from a sample is unknown, not absent.
| Page source | Search Console | Tool | Final label | Next step |
|---|---|---|---|---|
| Correct | Listed | Listed | Confirmed | Schedule a recheck |
| Correct | Not listed | Listed | Confirmed, Google visibility pending | Look again later |
| Correct | Not listed | Not listed | Confirmed, no outside visibility | Keep the dated source capture |
| Missing | Listed | Listed | Not delivered or removed | Send source evidence to the seller |
| Wrong URL or text | Any | Any | Delivered with errors | Request a correction |
Example scenario: a B2B invoicing app
Example scenario: A small invoicing software company buys a link in an accounting-industry newsletter archive. The seller sends the URL. The buyer opens it, finds the anchor pointing at the pricing page with rel sponsored, and logs the date. The tool lists the page two days later; Search Console shows nothing for the pricing page yet. The row reads "Confirmed, Google visibility pending," and a recheck is scheduled. When the seller asks for payment confirmation, the buyer sends the dated source capture rather than a dashboard screenshot.
Wording that survives scrutiny
Practical suggestion: tie each sentence to its source. "Link present in the page source on the check date" is a verified statement. "Not yet listed in the Search Console links report, which is not a comprehensive list" cites the documented limit. "Listed by the tool, first seen on this date" is supporting evidence. Statements such as "Google counted this link" or "it improved rankings" are not supported by any of the three sources and do not belong in a delivery report.
Reconciliation checklist
- Was the publisher URL opened directly, with its HTTP status noted?
- Were anchor element, href, text and rel compared to the order one by one?
- For script-added links, was the rendered DOM checked?
- Did you search the target page's linking sites in Search Console and account for root domain grouping?
- Are first-seen and last-seen dates recorded for tool rows?
- Does every source cell contain one of the four allowed values?
- Are the check date and the person who checked written down?
Three conflict patterns and how to read them
The tool says present, the source says absent
First confirm you are looking at the right page: syndicated copies, paginated archives and moved posts can mislead. Then check whether the link moved to another section. If the live source truly lacks the link, the tool row is an older record. The last-seen date helps: an old date supports removal.
The source is correct and Search Console is empty
This pattern is not an error. The documentation describes the report as incomplete and data builds up over time. The documentation gives no time frame for a new link to appear, so avoid inventing one. Keep the source capture and set a recheck date. Telling a seller that the delivery does not count because Google has not listed it contradicts the help page.
The target looks different
When the report shows a different target than the one ordered, read the "Target URL (if different)" column, then compare the href in the source. If the href differs from the order, it is a delivery error. If the href matches and the target differs, a redirect or canonical choice on your own site explains the gap, and the fix is on your side.
Packaging the evidence
What goes in the pack
- A dated capture of the anchor element with its href and rel values.
- The HTTP status and any redirect chain of the publisher URL.
- Search Console status, naming the table and the search used.
- Tool name and first and last seen dates.
- The final label and the next check date.
Keeping history
Practical suggestion: add a new row for every check rather than overwriting old ones. A sequence of dated rows shows when a link appeared or vanished, which a single snapshot cannot. For tracking after delivery, the record-keeping approach in backlink package delivery tracking fits this table well.
Who needs which level of detail
An executive needs the final label. A seller needs the source capture and the comparison with the order. The in-house SEO needs all three sources, because the gap between "pending visibility" and "removed" decides the monitoring plan. For the broader picture of reading a profile and comparing tools, see how to read a backlink profile and use link checkers.
From order form to monthly report
Before ordering
Write the target URL without parameters and with the correct protocol and subdomain, because Search Console groups by canonical URL and small address differences can appear as separate rows. Note one main anchor and acceptable variants, and the rel value you expect.
On delivery day
Open the URL and check the source and live DOM. Note the status code, whether the link sits in visible body text, whether the anchor is visible, and the alt value for image links. Dashboards are not needed yet.
In the weeks after
Search for the publisher domain in your tool and record first-seen. Look at the linking sites for the target page in Search Console. If nothing shows, record "not checked" or the date of your check and look again later rather than escalating.
At report time
Reopen each page source. That reopening is the only direct proof the link was alive on the reporting date. Then refresh the other two columns and set the final label to one of five values: confirmed, visibility pending, delivered with errors, not delivered or removed, unreachable. A short vocabulary lets different people read the report the same way.
Monitoring your own inbound links
The same three sources apply when you are not buying anything. You pull new linking sites from Search Console, new and lost links from a tool, and confirm important ones in the source. Without an order form, the labels become "unexpected link" and "expected link that never arrived," and a link whose anchor or context looks over-optimized deserves a closer look.
Mistakes that weaken a link report
Treating a dashboard as a witness statement
A dashboard is a summary produced by software you did not run. It can be useful, but it is not a record of what you saw on a given date. If the report will be used to release payment, request a refund or answer a client, the thing that carries weight is a record you made yourself: the date, the URL, the anchor element and its attributes. Without that, every later disagreement turns into a contest between screenshots.
Mixing property-level and page-level questions
Search Console answers for your verified property, and its rows are grouped by root domain. A tool may answer at page level or domain level depending on the view. A buyer who asks "did publisher X link to me" gets one answer at domain level and another at page level. Decide the level first. For delivery checks the level is always the single publisher URL and the single ordered target.
Letting the vocabulary drift
If one report says "live," the next says "found" and a third says "indexed," readers will treat these as synonyms when they are not. Live means present in the page source on the check date. Found means a tool or report listed it. Indexed is a claim about Google's index that none of these three sources states directly. Keep the four source values and five final labels fixed across reports.
Skipping the date
A source capture without a date and time cannot be compared to a later check. A tool row without a first-seen date cannot show when the link appeared. Date every cell that matters, and keep the check order consistent so that two reports from different weeks can be read side by side.
Over-escalating on a single signal
A missing Search Console row is the weakest of the three signals, because the documentation describes the report as incomplete. A missing tool row is slightly stronger but still depends on the vendor's coverage. Only a missing link in the page source is strong evidence of non-delivery. Escalate in that order: source first, then a re-check, then the seller.
A short worked comparison
Example scenario: A regional furniture workshop orders a link from a home-decor blog. On the check date the source shows the anchor pointing to the workshop's category page, with rel sponsored and descriptive text. The workshop's tool lists the page, but with the anchor text shortened. Search Console lists nothing for that category page.
Reading the three together: the source is the verdict, so the delivery is confirmed. The tool's shortened text is a tool display detail to note, not a delivery error, because the source text matches the order. Search Console's silence is logged as "not listed," with the next check date. The report row carries one line for the seller: "Delivered as ordered, verified in page source on the check date." Nothing in it claims that Google has counted the link or that it will influence rankings, because none of the three sources can show that.
Now change one fact: the source shows the href pointing to the workshop's home page instead of the category page. The tool and Search Console data are irrelevant to the verdict. The row becomes "delivered with errors," and the request to the seller names the exact address that was ordered and the address found.
Frequently Asked Questions
If a link is not in Search Console, does it not exist?
No. The help page says the Links report is not a comprehensive list, tables are limited to 1,000 rows and some URLs may be omitted. Only the page source can settle whether the link exists.
Why does a tool show a link that Search Console does not?
The two use different crawlers and records. A tool row does not show that Google processed the page. The gap can come from a page Google has not processed, a sampled report or a link that was removed. The page source separates these cases.
Which source is enough to prove delivery?
A dated capture of the page source showing the correct href, anchor text and rel value. Search Console and tool output are supporting evidence and cannot prove delivery alone.
Where can I see whether a link is nofollow?
The Search Console Links report does not specify whether a link is marked nofollow. Read the rel attribute in the page source. Some tools may show it, but check how the specific tool reports it.
Is viewing the page source enough when JavaScript inserts the link?
Not always. The raw source may not contain the link. Google's documentation says dynamically inserted links are crawlable when they use standard anchor markup and recommends checking rendered HTML. Inspect the live DOM in the browser developer tools and log it.
What do I tell a seller when the sources disagree?
Give the page source result with its check date and name the missing or wrong detail. Add the Search Console and tool data as context. Labeling visibility delay and delivery failure separately shortens the conversation.
Conclusion
Backlink data arrives from three sources that answer three different questions. Search Console offers a partial view of what Google reports, a tool shows what a vendor's crawler archived, and the page source proves what is written on the page today. Put the verdict on the page source, use the other two as visibility indicators, and fill every cell with present, absent, unknown or not checked. A report built this way holds up when a seller, a client or a manager asks how you know.
If you want links that come with checkable delivery records, take a look at our backlink packages.
Post a comment
Please log in to leave a comment. Login