Why Our Canonicals Point at Your Site, Not Ours

Start with the honest version of the problem

A FAIND Knowledge Graph is a full machine-readable representation of a company's substance, live on a subdomain of the company's own domain. Stated plainly: that is a structure which, left naive, absolutely could compete with the website it serves. Same facts, same domain family, engineered for machine legibility, if we did nothing, Google would eventually have to choose between a customer's product page and our restructured version of it, and "eventually" is not a risk profile anyone should accept for their existing rankings.

Any vendor who tells you this risk doesn't exist hasn't thought about it hard enough. The right response isn't to deny the failure mode; it's to make it structurally impossible. That's what the canonical policy does.

Canonical tags, in one paragraph

rel="canonical" is a page-level declaration that tells search engines: of the pages carrying this content, treat that URL as the authoritative one, consolidate ranking signals there, index that version. It's the web's standard instrument for saying "this page exists, but that page is the one that counts." Crucially, it governs index consolidation, not access: a page with a canonical pointing elsewhere is still public, still fetchable, still fully readable by any crawler. That distinction carries the whole design, as you'll see in a moment.

The policy: two kinds of pages, two rules

Every page in the layer is classified into one of two categories, and the categories get opposite treatment:

Cannibalizing pages, canonical to the original. Wherever the layer's page overlaps a page that exists on your website, your product page, your solution page, your homepage-adjacent content, the layer's version carries a canonical tag pointing at your URL. In Google's eyes, your page is the one that counts; every signal the layer's version might accrue is handed to yours. The layer forfeits the ranking contest before it can start. This is why, in four months of the BFE deployment, spanning a full website replatform, the moment of maximum ranking fragility, the count of layer-vs-site ranking conflicts was zero.

Additive pages, self-canonical. Where the layer covers ground your website simply doesn't, the machine-structured entity records, specification sets, and coverage of long-tail questions your site never built pages for, there is no original to defer to. These pages stand as their own canonical. They can only ever add search footprint where you had none; by construction, there's nothing of yours for them to take. This is the mechanism behind the "new search footprint" in the BFE numbers: impressions growing month over month, built from territory the site had never occupied.

One line summarizes the whole policy: where you have a page, yours wins by declaration; where you don't, the layer builds you one.

Why LLM retrieval doesn't care about any of this

Here's the part that makes the policy free rather than a trade-off. Canonical tags are instructions to search engine indexing. The retrieval systems behind AI assistants, the fetchers grounding ChatGPT, Claude and Perplexity answers mid-generation, read pages, not index politics. A layer page that canonicalizes to your site is still fully public, still served in milliseconds, still the cleanest machine-readable representation of your facts available. The AI crawlers demonstrably treat it that way: on the BFE domain, 97.8% of 16,502 AI-crawler requests went to the layer, canonicals and all.

So the two channels get exactly what each needs, from the same pages: Google gets an unambiguous instruction to keep ranking your original site. Assistants get an unrestricted, optimized grounding source. The canonical tag is the switch that separates the channels, visible to the system that ranks, irrelevant to the systems that read.

What we gave up, and why it's the right trade

Transparency cuts both ways, so here's the cost side. By canonicalizing overlapping pages to the originals, we forfeit the layer ever ranking in Google for terms your site already covers, including cases where, frankly, the layer's version might have ranked well. A more aggressive vendor could chase those rankings and show you a bigger "pages ranking" number in the first quarterly review.

We take the other side of that trade every time, for two reasons. First, the aggressive version converts your vendor into your competitor, slowly, structurally, and hardest to detect exactly when it's working best. Second, the layer's job was never to win rankings; it's to win fetches, to be what machines read when they assemble answers about you, while every citation and all credit routes to your domain. A layer that ranks is a layer with divided loyalties. Ours has one.

Two honest footnotes for the SEO professionals reading. Canonical tags are a strong signal Google honors in the overwhelming run of cases, but formally a hint, not a directive, which is why our monitoring watches for canonical flips as a standing check rather than assuming them away. And the cannibalizing/additive classification is maintained continuously, not set once: when your site publishes a new page on ground the layer already covered, the layer's page flips from self-canonical to deferring, your new page inherits the territory automatically.

Verify it yourself

The policy's best property is that it's inspectable in thirty seconds, no trust required: open any overlapping page on a live layer, the live Knowledge Graphs are linked from our homepage, view source, and read the canonical. It points home. It always points home.

If your SEO team is the one holding the risk assessment, send them this article and the five worries, audited together, between them, that's the whole technical case, with the four-month audit attached.

Sources: FAIND deployment architecture; BFE Institut deployment telemetry (Feb-Jun 2026: zero ranking conflicts, 97.8% of 16,502 AI-crawler requests to the layer); econ solutions case (average Google position 21.3 → 12.4 with the layer live).