Linkset for SEO and AI Visibility: The Typed Relationship Layer Nobody Is Using

I have a confession. I spend an unhealthy amount of time reading IETF specs that most SEOs will never open. Usually that habit pays off in small ways, a header trick here, a crawl insight there. Every once in a while, though, I find something sitting in plain sight that maps almost perfectly onto a problem the industry is actively wrestling with. That’s what happened when I dug into RFC 9264, better known as linkset.

Here’s the short version: RFC 9264 is an IETF Proposed Standard, published in July 2022 by Erik Wilde and Herbert Van de Sompel, that defines how to publish sets of typed links as standalone documents. Not links buried in HTML. Not links crammed into HTTP headers. A dedicated, machine-readable file whose entire job is to declare how resources relate to each other.

If schema defines what a page is, linkset defines how resources relate. That distinction sounds academic until you think about what AI retrieval systems are actually trying to do: resolve entities, trace provenance, pick canonical citation targets, and connect resources across domains. Those are all relationship problems. And right now, almost nobody in SEO is publishing relationships in a structured, standards-based way.

Let me share why I think that’s a missed opportunity, where linkset genuinely helps, and where it absolutely does not.

What linkset actually is

Strip away the RFC formatting and the concept is simple. The web already has a mature model for typed links, defined in RFC 8288 (Web Linking). Every time you see rel="canonical" or rel="author", you’re looking at that model in action. The problem is where those links live: embedded in HTML documents or squeezed into HTTP Link headers, both of which have real limitations. RFC 9264 calls out three motivating cases directly: links that need to come from a third party, applications that can’t easily write HTTP headers, and link collections too large or unpredictable for header fields.

Linkset solves this by letting you publish the links as their own document, in one of two formats:

application/linkset mirrors the HTTP Link header syntax almost exactly, with newlines allowed for readability. If you’ve ever written a Link header, you can write one of these.

application/linkset+json expresses the same abstract model in JSON. Each entry declares an anchor (the link context, meaning the resource the links are about), one or more relation types, and target objects with href values and optional attributes like type, hreflang, and title.

A minimal JSON linkset looks like this:

{ "linkset":
  [
    { "anchor": "https://example.net/article",
      "author": [
        { "href": "https://example.net/about/jane-doe" }
      ],
      "cite-as": [
        { "href": "https://example.net/article" }
      ]
    }
  ]
}

Discovery works through the IANA-registered linkset relation type. A resource points at its link set with rel="linkset" in an HTTP header or in the document body, and any client that understands the relation can go fetch the full relationship graph. The spec also recommends making linksets self-contained by giving every link an explicit anchor and using absolute URIs, so the document stays interpretable even when it’s consumed outside a live HTTP exchange. That last detail matters more than it looks, because “consumed outside a live HTTP exchange” is a pretty good description of what happens when your content gets chunked into a retrieval pipeline.

One more detail worth knowing: the JSON serialization optionally supports a JSON-LD context, which means a linkset can be interpreted as RDF triples. In plain English, your relationship manifest can bridge directly into graph tooling. For anyone already thinking in terms of an internal knowledge graph, that’s the hook.

Why SEOs should care about a spec Google never mentions

Let me be blunt about what linkset is not. It is not a ranking factor. Google has never mentioned it in a search context. No AI platform has documented support for it. If you publish a linkset tomorrow, your traffic will not move.

So why am I writing about it? Because I’ve watched this movie before. Structured data was ignorable right up until it wasn’t. Entity optimization was a niche obsession for patent readers years before knowledge panels made it mainstream. The pattern I’ve learned to trust is that machine-readable infrastructure tends to get consumed eventually, and the sites that published it early are the ones the machines already understand when the switch flips.

The current AI visibility stack has a shape. We have schema for describing entities on a page. We have sitemaps for enumerating URLs. We have emerging proposals like llms.txt for orienting AI systems at the site level. What’s missing from that stack is a dedicated layer for typed relationships between resources: this article cites that source, this page describes that entity, this version supersedes that one, this brand relates to that property. Right now those relationships live implicitly in anchor text and unstructured mentions, and we’re asking retrieval systems to infer them. Linkset lets you declare them.

Frame it as an infrastructure play for AI visibility, not a traffic lever, and the cost-benefit gets interesting fast, because the cost is nearly zero if you already maintain structured entity data.

Use case one: citation engineering for AI

This is where linkset gets practical fastest. A handful of registered relation types map directly onto what AI-oriented publishing needs:

• cite-as declares the canonical citation target for a resource
• describedby points to an authoritative description, such as a schema document or entity profile
• author connects content to its author entity
• license declares usage terms in a machine-readable way
• type and alternate qualify formats and variants

If you want an existence proof that this combination works, look at the scholarly web. The FAIR Signposting initiative, which Van de Sompel also drives, uses exactly these typed links, delivered partly through linksets, to make research objects discoverable and citable by machines. Repositories publish cite-as, author, describedby, and item links so that automated agents can navigate from a landing page to the actual content, its metadata, and its canonical identifier without guessing.

Swap “research object” for “cornerstone article” and the parallel writes itself. An AI system deciding how to attribute a claim faces the same problem a scholarly crawler does: which URL is canonical, who wrote this, and where is the authoritative description? Signposting answers those questions with typed links. There’s no reason a publisher-side linkset can’t do the same for commercial content.

Use case two: the relationship sitemap

Here’s the mental model I keep coming back to. An entity map gives machines the nodes: here are the entities this site knows about, here’s what they are. A linkset gives machines the edges: here’s how those entities and resources connect. Nodes without edges is a parts list. Nodes with edges is a graph.

The versioning relations make this concrete. RFC 9264’s own examples show a resource declaring its latest-version, chaining predecessor-version links back through its history, and identifying its author, all in one document. For content operations, that’s a machine-readable changelog: canonical current version, full lineage, clear authorship. For AI retrieval, it’s a de-duplication and freshness signal, a structured answer to “which of these five similar URLs is the current, authoritative one?”

And because the JSON format can carry a JSON-LD context, the whole thing can be lifted into RDF and merged with your existing schema graph. The edges you declare in a linkset don’t have to live in a silo; they can become part of the same knowledge graph your @id references and sameAs arrays already feed.

Use case three: cross-domain brand consolidation

Now for the part that made me sit up. RFC 9264 explicitly supports third-party links, meaning one server can publish links about resources hosted somewhere else. The spec’s stated motivations include declaring links the hosting server doesn’t know about and managing links in a dedicated external service.

Think about what that enables for anyone running a brand cluster. A parent company can publish a single linkset asserting typed relationships across every property in the portfolio: this subsidiary site is describedby the parent’s entity page, these regional domains are alternate versions of each other, this microsite’s content is cite-as the flagship domain. Agencies managing multi-brand portfolios could maintain relationship manifests centrally instead of begging every property’s dev team for header changes.

The spec is honest about the catch, and so should we be. Its security considerations note that consumers need to decide whether a third party is trustworthy enough to assert links about someone else’s resources. Translation: a third-party linkset is a claim, not a fact. The sensible play is corroboration. When the linkset says two properties are related, and both properties’ schema sameAs arrays agree, and the relationship shows up in editorial content, a machine has three independent signals pointing the same direction. Any one alone is weak. Together they’re hard to dismiss.

Third-party linksets don’t create co-occurrence, but they make co-occurrence legible

I want to be precise here, because this is where the spec could easily get oversold. Co-occurrence, in the sense SEOs use it, comes from entities and terms repeatedly appearing together in context across documents. That’s how text mining systems actually extract co-occurrence signals: contextual proximity in real content, measured across a corpus. A link manifest doesn’t create that. Publishing a linkset that says Brand A relates to Brand B does not conjure the hundreds of natural co-mentions that make an association real.

What it does is make the association legible. Instead of forcing retrieval systems to infer a relationship from scattered unstructured mentions, you hand them a typed, structured statement of it. That’s closer to structured co-occurrence than to classic co-occurrence mining, and the two work best as a pair. The strongest setup I can see is layered: editorial co-mentions doing the organic work, schema and sameAs corroborating identity, and a linkset declaring the explicit typed edges on top. Machines connecting the dots is the goal. The linkset doesn’t draw the dots; it draws the lines between dots that already exist.

The proof it’s real: GS1 Digital Link

Every emerging spec needs one adopter that ends the “but does anyone actually use this?” conversation. For linkset, that adopter is GS1, the standards body behind the barcodes on essentially every product you’ve ever bought.

GS1 Digital Link turns product identifiers into web addresses, so a single scan can resolve to product information, instructions, and related resources. Under the hood, GS1’s resolver architecture serves exactly the kind of link sets RFC 9264 describes; the RFC’s own profile examples are drawn from GS1’s implementation, with product identifiers resolving to typed links for product pages, pack contents, and related video in multiple languages.

That’s not a pilot program. That’s global commerce infrastructure using linksets to connect identifiers to structured sets of resources. When people ask me whether this spec has legs, GS1 is the answer.

How I’d implement it today

If you already maintain structured entity data, adding a linkset is an afternoon, not a project. Here’s the pragmatic path:

Pick a stable, discoverable URL. Something like https://yourdomain.com/linkset.json works fine. One honest note: unlike security.txt, there is no IANA-registered well-known path for linksets, so discovery runs through the linkset relation rather than a magic location. Expose it with a Link: <...>; rel="linkset"; type="application/linkset+json" HTTP header on key pages, or a <link rel="linkset"> element if headers aren’t practical in your stack.

Start with a small set of high-value relations. My short list: cite-as, describedby, author, license, latest-version, and alternate. Six relations, applied to your cornerstone content and entity pages, covers citation targets, authorship, canonical descriptions, and versioning. Resist the urge to model everything.

Make it self-contained. Explicit anchor on every link, absolute URIs everywhere, exactly as the spec recommends. Assume the document will be read far away from your server, because in a retrieval pipeline, it will be.

Corroborate, don’t freelance. Every relationship you declare in the linkset should agree with your schema, your sameAs data, and your actual editorial content. A linkset that contradicts your other signals is worse than no linkset.

Add the JSON-LD context if you’re graph-minded. It costs a few lines and turns your link manifest into RDF-compatible data that can merge with the rest of your structured data ecosystem.

Through my testing of other early-stage machine-readability standards, the pattern has been consistent: the publishing cost is trivial, the maintenance cost is near zero if you generate the file from data you already have, and the downside risk is essentially nil. That asymmetry is the whole argument. You’re not betting that linkset wins. You’re spending an afternoon so that if it does, you were already there.

Where I land on this

I’m not going to tell you linkset is the next big thing, because I genuinely don’t know, and neither does anyone else. What I can tell you is that the direction of travel is unmistakable. Retrieval systems keep getting hungrier for structure, provenance keeps getting more valuable, and the gap between sites that are machine-legible and sites that merely rank keeps widening. Typed relationships are the layer of that legibility stack that almost nobody has claimed yet, and there’s a boring, stable, IETF-blessed standard for publishing them just sitting there.

I’m adding linksets to my own testing roadmap alongside the rest of the AI visibility file stack, and I’ll report back on how the major crawlers and AI platforms handle them. If you beat me to it, or you’re already publishing linksets in production, I’d genuinely love to hear what you’re seeing. That’s exactly the kind of early-adopter data this industry needs more of.

Written by Brian Winum

Digital marketing veteran, partner at MAXBURST and MAXPlaces, and creator of LLMS Amplifier and Authority Amplifier.

About Brian Work with me