What a Search Operator Can and Can't Confirm About a Link

You have two kinds of evidence about any backlink, and they are not interchangeable. One is a row in a link index: a record that some vendor’s crawler fetched a page at some point and extracted an anchor pointing at you. The other is what you can observe right now by putting a query into a search engine and reading the result page it returns.

People treat the second as an audit of the first — “I searched and it’s there, so the link is real,” or worse, “I searched and it’s not there, so the tool is wrong.” Neither inference holds, and the reason is structural: the two channels answer different questions, and only one of them knows anything about links at all.

The link graph is not addressable from a result page

This is the part that surprises people who started SEO recently. There is no query you can type that returns the pages linking to a URL. The operator that once did this was link:, and it has been dead for years — long enough that its absence is now just an assumed fact of the job rather than a change anyone remembers.

It’s worth being precise about the current operator surface, because folklore keeps a few zombies alive. Serply’s guide to Google’s search operators sorts the set into three buckets: operators that work reliably, operators that behave inconsistently, and operators deprecated by Google. link: sits in the deprecated group, alongside cache: — which that guide dates to 2024 — and inanchor:, the one people reach for when they want anchor-level evidence, sits in the unreliable group rather than the working one.

The consequence for measurement is total. Every backlink count you have ever quoted came from a third party’s crawl, because the search engine does not expose its own link data through its query language, and never has for anyone but the site owner. What Search Console shows you is a separate, restricted feed with its own quirks, covered in reading the Search Console links report.

What an operator can settle

Operators are still useful for link work — just not for link questions. What they give you are present-tense facts about the referring page.

That a page is retrievable for some query. A distinctive phrase in quotes, optionally narrowed with a site: restriction, returning that page is real evidence the page exists in a form the engine will surface. That’s a fact your index row does not contain.

That specific text is currently on it. A phrase match tells you the string was present in whatever version the engine holds. If the phrase is the anchor your report claims, that’s meaningful corroboration.

That the title or URL shape matches what your export recorded. intitle: and inurl: are cheap consistency checks against the metadata in your rows.

Each of these is a fact about a page, in the present tense, and each is only informative in the positive direction.

Why a miss proves nothing

A query that fails to surface the page is compatible with the page being perfectly well indexed and simply not competitive for the string you chose. Result counts are estimates. Ranking, filtering, and deduplication all sit between the index and what you see, and the observation is conditioned on your location and device.

That asymmetry — a hit is suggestive, a miss is nearly uninformative — is the same one that limits every attempt to establish index status from the outside, set out in whether the linking page is indexed. Operators do not escape it. They are ordinary searches with extra constraints, not a window into the index.

The tense problem

Put the two evidence types side by side and the mismatch is obvious.

An index row is past tense with an unknown timestamp. It says a crawler saw this once, and the date attached to that observation means whatever the vendor’s policy says it means — see what first seen and last seen mean. It says nothing about right now.

An operator hit is present tense but scoped to one observation: one query, one location, one device, one moment. It says nothing about the past, and it does not generalise to what someone else’s result page shows.

You cannot average these into a single claim like “the link exists.” They are two partial observations of different objects — a crawl artefact and a live query answer — and a report that blends them without saying which is which is making a stronger claim than either supports.

Using an operator honestly in a link report

Use it as a liveness check, not an index audit. “The referring page is publicly retrievable as of this date” is a defensible line. “The referring page is indexed” is not, unless you own the page.

Record the vantage. If you ran the query from a specific country or on mobile, that’s part of the observation. Someone re-running it elsewhere may see something different and conclude you were careless.

Never let an operator result overwrite a row. If your tool lists a link and your query doesn’t surface the page, you have learned that the page didn’t rank for your phrase. You have not learned that the link is gone. The only check that settles that is fetching the referring URL yourself and reading the markup.

Say which channel each number came from. A report that mixes crawl-derived counts with hand-run queries and presents both as “verified” is exactly the kind of thing building a link report you can defend exists to prevent.

What nobody outside Google knows

Whether the link data behind link: still exists internally in any recognisable form. Why the unreliable operators are unreliable — whether they’re degraded, sampled, partially retired, or simply low priority. Whether an operator-scoped result set is drawn from the same index as an ordinary search or a subset of it.

None of that is documented, and none of it is inferable from the outside with any confidence. What is safe to say is the boring version: the query language was never a link-measurement tool, the one operator that pretended to be is gone, and everything you report about links comes from somebody’s crawl.