How I Made a Public Portfolio Discoverable to Agents

A public site already has two audiences. People read pages. Crawlers and agents look for contracts: which documents exist, which APIs are real, and whether the answers are authentic.

I treated that second audience as a product boundary, not as a badge. The work was to publish a small, honest discovery surface on jayantgoyal.com without pretending the portfolio is a store, an MCP runtime, or a second identity provider.

The problem was not a missing score

Search and agent scanners are useful regression tests. They are a poor product definition.

If a checker wants commerce protocols, the honest response for this site is still no. There is nothing to buy. Inventing x402, UCP, or ACP endpoints would make the catalog larger and the system less true.

The same rule applied to Web Bot Auth. Signing HTTP messages needs a key I am willing to operate. I was not going to mint a private key so a scanner could tick a box.

What I did ship is the part that belongs on a public editorial site: crawlable pages, machine-readable catalogs, DNS records agents can look up, and DNSSEC so those records can be authenticated.

People still get pages. Agents get catalogs.

Portfolio remains the public story. The homepage, Writing, Work, and résumé did not become a developer portal.

Alongside those pages, Portfolio now serves a discovery layer:

The important constraint is ownership. Human sign-in still lives on Auth. The Portfolio origin is a public resource. Anonymous agents may read published content. They do not receive a session, and they should not be redirected into a login flow that was built for people.

That is why resource metadata points at the Portfolio origin instead of at Supabase. A scanner that follows authorization_servers needs to land on the document that explains anonymous access, not on a hosted auth product that does not speak this protocol.

DNS-AID is not an HTTP file

HTTP catalogs are easy to ship in Next.js. Authenticated discovery is not.

DNS-AID asks for HTTPS/SVCB records under _index._agents and _catalog._agents, ServiceMode, ALPN h2/h3, port 443, targeting the canonical host. On older dig builds those records show up as TYPE65, not as the HTTPS mnemonic.

Those records lived at Cloudflare as soon as the zone was the nameserver. That was not enough for a checker that wants the chain of trust. DNSKEY in the zone without a DS at the parent is local signing. Authenticated DNS-AID needs the registry to publish DS.

The missing piece was the .com DS, not another well-known path. After the DS landed — key tag 2371, algorithm 13, digest type 2 — WHOIS moved to signedDelegation. The HTTPS records did not change. The parent finally attested to them.

SEO stayed in the implementation

The same pass cleaned on-page issues that a page audit actually measures: a single honest H1, image alts, unique anchors, Person JSON-LD with an image, and no X-Powered-By leak.

That work belongs in metadata, robots Content-Signal, and the renderer. It does not belong on the homepage as “97% SEO.” Scores move when the checker moves. The contracts should still be true.

What I refused to fake

• Commerce. The site does not sell. The catalog does not advertise checkout protocols.
• A live MCP or A2A runtime. Cards describe intent. They do not imply a process that is not running.
• Token issuance on Portfolio. Public reads stay anonymous. Auth remains the interactive owner.

Leaving those gaps visible is part of the design. A smaller true surface is easier to keep correct than a complete-looking one.

What I would keep watching

The public checks I care about are boring:

• /.well-known/ai-catalog.json still returns 200.
• _index._agents and _catalog._agents still answer TYPE65.
• dig DS jayantgoyal.com still returns the parent digest.

If those three hold, people and agents are looking at the same site. The score is a screenshot of that fact, not the product.