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.

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.