How OneFront actually works

The core problem: client-side rendering

Most link-in-bio tools, including Linktree, render page content with client-side JavaScript after the initial HTML loads. Crawlers that don't execute JavaScript — or that time out before it runs — see an empty shell. This includes many AI crawlers, which tend to be more conservative about JavaScript execution than Googlebot.

What OneFront does differently

• Server-rendered by default. Every public profile page (onefront.org/<username>) is rendered on the server. There is no client-side dependency for content to appear — view-source shows the same content a browser does.
• Real schema.org JSON-LD. Every profile emits a validating Person or Organization node (with name, url, image, sameAs populated from linked social accounts) plus an ItemList of the profile's links, in a <script type="application/ld+json"> tag in the page head.
• An AI-crawler-allowlisted robots.txt. /robots.txt explicitly allows GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and standard search crawlers.
• llms.txt. A site-wide /llms.txt summarizes what OneFront is and links to every public profile. Each profile also has its own plain-text summary at /<username>/llms.txt, built for direct LLM consumption rather than HTML parsing.
• A public MCP server. /api/mcp implements the Model Context Protocol (streamable HTTP, stateless, no auth required) with tools to query a profile's identity, links, and social accounts, and to record a link click — so an AI agent acting on a user's behalf can interact with the same data structurally, instead of scraping rendered HTML.
• rel=me account verification. Verified badges use the IndieWeb rel=me pattern (the same mechanism Mastodon and Threads use for their verified-link checkmarks): a OneFront profile links out to a social account with rel="me", and we check that account's page for a link back to the OneFront profile, also marked rel="me". Only when both directions match do we mark it Verified — no third-party identity vendor, no KYC.
• WebFinger. A /.well-known/webfinger endpoint resolves acct:username@onefront.org to profile data, the same discovery mechanism used across the fediverse (Mastodon, etc.).
• Gravatar avatar fill. At signup, we check (via Gravatar's public hash-based avatar API, no auth) whether an avatar already exists for your email and use it as a starting point — nothing is fabricated if none exists.

Auto-updating feeds → typed structured data

A profile can subscribe to RSS 2.0, Atom, or podcast (iTunes-namespace) feeds. A scheduled job fetches each with conditional GET (ETag / If-Modified-Since), parses new entries, and upserts them idempotently on the feed's own GUID — so a podcast host publishing episode 43 makes it appear on the page with no manual edit.

The payoff is what those entries become: each is emitted as the schema.org type that fits its source — PodcastEpisode (inside a PodcastSeries), VideoObject, or BlogPosting — carrying datePublished, timeRequired/duration, episode number, and the playable media URL. That is the difference between an AI answer engine seeing "a link" and being able to answer "their latest episode is #43, published Tuesday, 48 minutes long," with the audio one field away. The newest items also flow into the profile's llms.txtand its MCP tools, so every consumer — page, structured data, plain-text, and agents — reports the same "latest."

Feed URLs are fetched behind an SSRF guard (DNS-resolved public-address check, re-validated on every redirect hop) with a size cap, since the URL is creator-supplied and fetched server-side.

Verifying it yourself

View source on any OneFront profile page and you'll find the JSON-LD inline in the initial HTML response — no JavaScript execution required. You can also paste a profile URL into Google's Rich Results Test or the schema.org validator directly.