HTTP Link Headers for AI Agents and Machine Clients

An HTTP Link response field can tell a machine client that the current resource has a feed, a security contact, an alternate representation, or another typed relationship. The client receives this standardized metadata before it parses the response body.

That timing makes the field useful for agent-readable publishing and makes inaccurate links costly. A client may follow a relation without the visual context a person would use to question it. Verify the target first. Then select the relation type that describes it and assign ongoing ownership.

TKOResearch now advertises two resources through Link: its RSS feed and its RFC 9116 security contact. We didn't add links for APIs, agent services, authentication metadata, or payment endpoints because those services aren't present.

The RFC 8288 link model

RFC 8288 defines Web Linking. A link has a context, a relation type, a target, and optional target attributes. In an HTTP response, the context is normally the effective request URI unless an anchor parameter changes it.

The relation type explains how the target relates to the context. Registered short names include alternate, canonical, describedby, and security. An extension relation can be an absolute URI. The target is enclosed in angle brackets, followed by semicolon-delimited parameters:

Link: </feed.xml>; rel="alternate"; type="application/rss+xml"; title="TKOResearch Insights"

Here the requested page is the context, /feed.xml is the target, alternate is the relation, and type plus title are target attributes. The type value is a hint. A client still needs to request the target and inspect its actual response.

The distinction between relation and attribute matters. rel defines the link's semantics. type, hreflang, media, and title provide information about the target or intended use. Adding type="application/json" to an arbitrary URL doesn't make that URL an API, and attaching rel="alternate" doesn't establish that two resources contain equivalent material.

Multiple values and parsing

The Link field uses a comma-separated list of link-values. A server can send one field with several values:

Link: </feed.xml>; rel="alternate"; type="application/rss+xml", </.well-known/security.txt>; rel="security"; type="text/plain"

It can also send separate Link field lines. RFC 8288 treats these forms as equivalent after normal HTTP field combination:

Link: </feed.xml>; rel="alternate"; type="application/rss+xml"
Link: </.well-known/security.txt>; rel="security"; type="text/plain"

Don't split the combined value on every comma. Quoted parameter values and extension relation URIs have syntax that a conforming parser must respect. Use an RFC-aware library when consuming untrusted fields. For publishers, quote parameter values consistently and keep each link-value simple enough to inspect in a raw response.

A single rel parameter may contain several space-separated relation types that share the same context, target, and attributes. That is different from publishing several targets. Repeating a rel parameter within one link-value is invalid; RFC 8288 says parsers use the first occurrence.

Relative targets are allowed. A client resolves them against the applicable base URI. For a site-wide configuration, root-relative paths are easier to audit than page-relative paths because the meaning doesn't depend on directory depth.

Security contact discovery

RFC 9116 defines the security.txt format and the security link relation. The canonical Web location uses /.well-known/security.txt. A publisher may attach this relation to other responses:

Link: </.well-known/security.txt>; rel="security"; type="text/plain"

The target has its own requirements. It needs a Contact field, an Expires field, HTTPS delivery for Web use, and a current expiration date. A header that points at an expired or missing file is not useful discovery. It creates a failed escalation path at the moment a reporter needs it.

Our implementation first verified that the canonical .txt route was maintained by the application. That check exposed an older path mismatch, which was corrected before the link was published. This sequence is important: verify the resource, then advertise it.

Why `preconnect` doesn't advertise a machine resource

Frameworks and browsers often emit performance links such as:

Link: </>; rel=preconnect; crossorigin=""

This can be a valid link. The preconnect relation tells a user agent that opening a connection to an origin may improve future fetch performance. It says nothing about an API description, a feed, an MCP server, or an agent-oriented representation.

A readiness checker that asks only whether any Link field exists can misclassify this response. The correct question is whether the response contains a relevant relation whose target resolves to the claimed resource. Presence of preconnect proves that Web Linking syntax is in use. It does not prove machine-service discovery.

The same caution applies to preload, dns-prefetch, stylesheet, and icon relations. They serve browser loading and presentation. Agents may process them, but they don't substitute for a relation that identifies the intended operational resource.

Publishing links in Next.js

For a stable site-wide relationship, Next.js can attach a response field through headers() in next.config.ts. TKOResearch uses one combined value:

{
  key: 'Link',
  value: '</feed.xml>; rel="alternate"; type="application/rss+xml"; title="TKOResearch Insights", </.well-known/security.txt>; rel="security"; type="text/plain"',
}

This is appropriate because both targets are public and apply across the site. A relation that applies only to one resource should be emitted by that route instead. Over-broad publication can imply a relationship that isn't true for every response, including error pages or private variants.

Configuration is only one layer. A CDN can combine, replace, or cache fields. Validate the deployed response with GET and HEAD requests:

curl -sSI https://www.tkoresearch.com/
curl -sSI https://www.tkoresearch.com/feed.xml
curl -sSI https://www.tkoresearch.com/.well-known/security.txt

Then request each target body. Confirm status, content type, canonical URL, redirects, and freshness. If the target requires authentication, decide whether advertising it on public responses reveals an unwanted surface.

Review and maintenance checklist

Before adding a link relation, record the following:

The governing specification or registered relation definition.
The exact context to which the relation applies.
The production target and expected media type.
The team responsible for availability and retirement.
The client behavior that following the link is expected to trigger.

Test duplicate fields and edge caching as well. Confirm that an upstream proxy doesn't remove quotes, truncate a long value, or append a conflicting target. Monitor the destination, not merely the presence of the source field.

Remove discovery when the resource is retired. A 410 Gone response can be a deliberate transition, but an indefinite header pointing at a dead route is an operational defect.

The implementation rule

Use Link when you can name a real relationship and a maintained target. It is a precise protocol feature, not a generic badge for agent readiness.

For TKOResearch, an RSS alternate and a security contact meet that rule. The existing preconnect link remains valid for its own purpose. None of these links claims that the site operates an API, an authentication system, an agent endpoint, or a commerce service. If those products launch later, their discovery relations should ship with the services and their operational controls.