AI-readable profile: what it is and how to publish one

Updated 2026-09-02

An AI-readable profile is an open, ungated web page about one person or one organisation that an AI system can fetch, parse and cite. Open means no login wall and no bot block; parse means the facts are in the HTML itself and in structured data, not painted on by JavaScript; cite means the page has a stable URL an assistant can hand back as its source. Nothing about the idea is proprietary: any page that meets those conditions is one, whoever hosts it.

This page defines the term, sets out the four things such a page has to get right, lists exactly what Hilyt publishes when it hosts one, says what Hilyt cannot promise, and ends with how to make one — by hand, with Hilyt, or by another route. It is a small category with no settled name yet; we use "AI-readable profile" because it says what the page is for.

What an AI-readable profile is

When someone asks an assistant who a person is, or which company does a thing, the assistant either answers from what it remembers or searches, fetches a few pages and reads them. The second path is the one you can influence, and it has a hard constraint: the fetch is a plain HTTP request by a crawler that usually does not run JavaScript, usually will not sign in, and reads what comes back in one pass. A profile that survives that pass is AI-readable. In practice that means four things on one URL:

• Crawlable HTML: the name, description and facts are in the response body, so a fetcher with no JavaScript engine still gets them.
• schema.org identity markup: a Person or Organization node in JSON-LD, with a stable @id, so a parser can tell which entity the page is about and merge it with the same entity described elsewhere.
• Dated claims with sources: the facts an assistant might repeat — roles, founding, work — each carrying a date range where known and a URL that backs it, with a label saying who vouches for it.
• A plain-text card: a text/plain version of the same facts (Hilyt serves it at /<username>/llm.txt) for readers that want the content without the markup.

The last of these is the least established. llms.txt is a young convention with no vendor-confirmed consumer; a plain-text twin costs nothing to publish and may help some readers, but it is the least important of the four and no page is AI-readable on the strength of it alone.

How it differs from LinkedIn, a CV, a link page and a personal website

LinkedIn is where most professional facts live, and it is login-walled to most automated fetchers: a crawler without a session gets an interstitial, a stub, or nothing. Some fetchers get more than others and the behaviour changes without notice, so the honest statement is "most, not every" — which is why a profile only on LinkedIn is a weak source at answer time. Can ChatGPT read your LinkedIn profile? and why LinkedIn can't get you cited by AI go through what is actually served.

A CV or PDF is a document you hand to someone, not a page a machine finds. It lives in inboxes and applicant-tracking systems; hosted on your own site it is fetchable, but a PDF carries no identity markup and is extracted less reliably than HTML — see can AI read Notion, Substack, Medium or your PDF CV?.

A Linktree-style link page is reachable and usually crawlable, but it is a list of buttons: it rarely states who you are in sentences, almost never carries Person or Organization markup, and its facts are elsewhere. It answers "where can I find this person", not "who is this person".

A personal website is the best home for an AI-readable profile, and an AI-readable profile is not a replacement for one. If you already have a site with real content, the right move is to make its about page meet the four requirements below and keep it. A hosted profile complements a site — it is a second, consistent statement of the same identity that links to the site and is linked from it — and it is the only option for people who have no site and do not want to run one.

The four requirements: reachable, extractable, identifiable, corroborated

These are the conditions a page has to meet to be read, understood and trusted by a machine. They are cumulative: a page that fails an earlier one is not rescued by passing a later one.

Reachable

A crawler can request the page and get the page. It fails when robots.txt disallows the search or user-tier crawler tokens, when a CDN's bot protection challenges or blocks unrecognised fetchers, when the URL needs a session, or when the server answers with an error. Whether a specific vendor's crawler is let in is decided by that vendor's token and, on CDNs, by its published IP range — so "my browser can open it" proves little. robots.txt rules for AI crawlers and Cloudflare blocking AI crawlers cover the two common failures.

Extractable

The response body contains the content. It fails when the page is a JavaScript shell that renders client-side, when the text is inside images, when a soft 404 returns a 200 with a not-found page, or when the substantive text is a few hundred characters wrapped in navigation. Semantic HTML for AI readability and JS shells and soft 404s describe what a fetcher actually sees.

Identifiable

A parser can tell which entity the page is about and separate it from others with the same name. It fails when there is no Person or Organization markup, when the markup is a WebSite node alone, when the entity appears only as a property of something else (an article's author, a site's publisher), when the name on the page does not match the name in the markup, or when nothing links the page to the same entity elsewhere. The conflation case — an assistant describing a different person with your name — is the usual symptom; AI is confusing you with someone else and the Person and Organization schema AI actually uses are the fixes.

Corroborated

Something the entity does not control agrees with the page. It fails when every source for every fact is the entity's own site, when no independent page links to or names it, and when the identity links point one way only. A self-published page can be perfectly reachable, extractable and identifiable and still be treated as a claim rather than a fact — which is the correct behaviour for a system that cannot check. Corroboration is the slowest requirement and the one no host can supply for you; how to become an entity AI models recognise is the guide to it.

What Hilyt publishes for a profile

This list is the product contract, stated as what the edge worker actually emits for a published profile at https://i.hilyt.it/<username>. Anything not on it is not something Hilyt does.

• A stable, ungated URL. No login, no paywall, no interstitial, and the same URL for the life of the profile. Reserved and unpublished profiles return a real 404, not an empty page.
• Server-rendered HTML for recognised crawlers. A request whose user-agent matches a recognised crawler or fetcher family — the AI search, user and training tiers in the AI crawler user-agents list, plus ordinary search and preview bots — gets semantic HTML built at the edge from the same data the app shows: h1, description, claims, links, testimonials and FAQ, with a Vary: User-Agent header so caches keep the two variants apart. A fetcher Hilyt does not recognise gets the JavaScript app, which is why the plain-text card below exists.
• ProfilePage JSON-LD wrapping a Person or Organization with a stable @id. The person id is the profile URL plus #person; an organisation's id is its own website plus #organization, so the same entity described on hilyt.it and on its own site can be merged. For an organisation, url is its own site and the Hilyt page is mainEntityOfPage — the markup never claims Hilyt is the company's website. The page carries dateCreated and a dateModified taken from the latest of the profile record and its dated claims, links, FAQs and testimonials. A FAQPage block is added when the profile has FAQ items.
• Claims with dates, sources and a provenance label. Each claim renders its text, its date range where the owner gave one, a link to its source URL where one was attached, and one of three labels: owner supplied, owner confirmed, or source attached — and never the word "verified". "Owner confirmed" means the profile's owner ticked that wording; it appears only on a profile an email-verified owner has claimed, and editing a claim's content clears it. No claim on Hilyt is independently checked by Hilyt.
• Links, split by kind. A link to an identity page on a known identity host (GitHub, LinkedIn, X, Bluesky, Mastodon, Wikidata, Wikipedia, ORCID, Companies House and similar), or a person's own labelled website, is emitted as schema.org sameAs and rel="me". Everything else — a blog, a product, a Hilyt page — is an ordinary link, so a model is never told that a guides page is the same entity as a person.
• FAQ items and testimonials. FAQ pairs are drafted from the profile and editable by the owner. Testimonials arrive through a public vouch form and appear only once the owner approves them; the page says so.
• A plain-text card at /<username>/llm.txt. The same facts as text/plain with the same labels, linked from the HTML page as rel="alternate", served to every fetcher without any user-agent recognition. Its identity links are listed under a separate heading so a text reader does not mistake a plain link for a sameAs reference.
• Directory, sitemap and llms.txt inclusion. A published profile is listed at hilyt.it/directory (an ItemList, split into people and businesses), in https://i.hilyt.it/sitemap.xml with a lastmod, and in https://hilyt.it/llms.txt with its card URL. All three follow the same switch as the page: unpublish it and it leaves all of them.
• A log of crawler reads, by bot and by surface. Every fetch of the profile page or the card by a recognised AI user-agent is recorded, and the owner's dashboard shows the count, which bots, which surface (page or card), and when — with fetches by user-tier agents (Claude-User, ChatGPT-User, Perplexity-User and their peers, the requests made because a person just asked about you) called out separately, and ordinary search crawlers shown but not counted as AI reads.
• An explicit publication control. A profile reaches crawlers, the directory, the sitemap and llms.txt only while its owner has switched it to discoverable; the first publish runs a one-time screen that rejects impersonation, scams, illegal content and keyword spam and allows everything else. The owner can unpublish at any time, and a corrections-or-removal route is printed on every page and card.
• A maintenance path with confirmation. The same profile can be edited from the dashboard, over a token-authed REST API, or by an AI assistant through the MCP server — in every case a fact is saved only when the owner confirms it, and new claims start as owner supplied.

What Hilyt cannot guarantee

A published profile is an input to systems Hilyt does not run. The following are outside anyone's control, and any product that promises them is promising something it cannot deliver:

• That creating a profile will cause ChatGPT, Claude, Perplexity or any assistant to recommend you, or to mention you for a question that does not name you.
• That llms.txt or the plain-text card will be consumed by a particular answer engine. No vendor has confirmed reading either.
• That schema.org markup will cause a citation. Valid structured data makes a page eligible to be understood; it does not make anything display or rank.
• That a training crawler's read will change a model. A GPTBot or ClaudeBot fetch is a corpus event whose effect, if any, arrives with a future model and cannot be traced to one page.
• That a crawler user-agent equals a user-facing answer. A fetch from a search-tier or even user-tier agent means the page was retrieved, not that the reply quoted, cited or agreed with it.
• That a profile will rank, or be resolved as the right entity, without corroboration and ordinary search visibility. A page nothing else refers to is a claim in a well-formed envelope.

What Hilyt can show is narrower and testable: that the URL is stable and ungated, that crawlers receive substantive HTML and structured identity data, that claims carry dates, sources and honest labels, that a plain-text representation exists, that requests from recognised AI user-agent families are logged, that the owner controls publication, and that an assistant can maintain the page with the owner's confirmation. The two measurements Hilyt publishes — a readiness check for any site and a benchmark of its own visibility — are described at AI visibility.

Person and business profiles

A Hilyt profile is either a person or an organisation, and the entity type decides the markup. A person page emits Person: its url is the Hilyt page itself, its jobTitle and worksFor come from the role and company fields, and its sameAs is the identity links plus the one link the person labelled as their own website. A business page emits Organization: its url is the organisation's own site, the Hilyt page is mainEntityOfPage, its sameAs is identity links only and never repeats url, its location is a Place (where it is based, not where it serves), and a parent company appears as parentOrganization.

The founder relationship is an edge between the two. An organisation profile names its founder by username, and the page emits founder as a Person carrying the founder's own @id; the founder's page lists the organisations that name them under "Products and organisations founded", with each one's own site. Publish the organisation and the edge appears on both pages; unpublish it and it disappears from both — it is derived, never stored twice.

Two worked examples

The person example is Hilyt's founder: https://i.hilyt.it/jack and its card at https://i.hilyt.it/jack/llm.txt. Read the HTML source and you will find one ProfilePage block whose mainEntity is a Person with the @id https://i.hilyt.it/jack#person, a claims list with the three provenance labels, identity links marked rel="me", and the organisations that name him as founder. The card repeats the same facts under plain headings, with sameAs links under "Same entity elsewhere".

The organisation example is Hilyt itself: https://i.hilyt.it/hilyt and https://i.hilyt.it/hilyt/llm.txt. Its Organization node carries the @id https://hilyt.it/#organization — the same id the hub homepage's graph uses, so the two pages describe one entity — with url https://hilyt.it, the profile as mainEntityOfPage, and the founder edge back to the person page. It is also a fair illustration of the corroboration limit: its claims cite Hilyt's own pages, which is the weakest kind of source, and the page says so through its labels rather than dressing it up.

Both are ordinary profiles served by the same code as everyone else's. The useful exercise is to fetch each URL with a crawler user-agent and with a browser and compare what comes back; the difference is the whole point of the category.

Crawler reads are not citations

A read is logged when a request for the page or the card arrives with a user-agent Hilyt recognises as an AI crawler or fetcher. It is evidence that the page was reachable and that a system asked for it — nothing more. A training-tier read (GPTBot, ClaudeBot, CCBot) says the page entered a corpus. A search-tier read (OAI-SearchBot, Claude-SearchBot, PerplexityBot) says an index fetched it. A user-tier read (ChatGPT-User, Claude-User, Perplexity-User) is the closest to a person asking, and still says only that the page was fetched during an answer, not what the answer said.

A citation is a different event: the assistant's reply names the page as a source. Hilyt does not observe replies for profiles, so a read count is never presented as a citation count. What the two measurements Hilyt does publish are, and which of these events each one can see, is set out at AI visibility.

How to create one

By hand, on a site you own

Work through the four requirements in order, because each one is invisible until the previous one passes. This is the checklist, with the guide that covers each step:

• Reachable: allow the search and user-tier crawler tokens in robots.txt, and check that any CDN bot rule lets them through — robots.txt rules for AI crawlers, Cloudflare blocking AI crawlers.
• Extractable: serve the name, description and facts in the HTML response, with a real title, meta description and a 404 that says 404 — semantic HTML for AI readability, JS shells and soft 404s.
• Identifiable: add a Person or Organization JSON-LD block with a stable @id and identity-only sameAs, keep the name consistent across title, h1 and markup, and optionally publish a plain-text card — a Person schema JSON-LD example, Person schema on WordPress without a plugin, what llms.txt is and how to write one.
• Corroborated: link the page from every profile you already have, get it linked from pages you do not control, and add the registries that apply to you — how to become an entity AI models recognise, how to add yourself to Wikidata, do you need Wikipedia for AI to know you?.

Then run the AI readiness check against the page. It tests the first three requirements the way a plain fetcher sees them and says which rule each result came from; it cannot test the fourth.

With Hilyt

i.hilyt.it/try takes a name and, optionally, a site: it fetches the site's text and drafts a profile from it — name, one-liner, description, skills and FAQ — shown exactly as it would publish, next to the plain-text card. Nothing is published at this step. Claiming the draft creates a private profile you edit: add claims with dates and sources, add the identity links that should become sameAs, set the entity type. Publishing is the discoverable switch in the dashboard — the first time it runs the moderation screen described above — and from then on the page, card, directory, sitemap and llms.txt entries exist together and disappear together. Maintenance is the dashboard, the REST API, or an assistant over MCP with your confirmation (connect Claude to your Hilyt profile).

Other routes

Hilyt is one way to publish such a page, not the only one. Your own site with the markup above is the fullest option and the one every other route should point at. A GitHub profile README serves developers reasonably well as a reachable, extractable page, and an ORCID record does the same for researchers with a registry-grade identifier. A Google Business Profile is the identity page that matters most for a local business and is fed to Google's own answer surfaces directly. Each covers part of the four requirements; none of them, and no hosted profile either, supplies corroboration on its own.

AI-readable profiles · AI visibility · Run the AI readiness check · How the score works · Benchmark · Guides · hilyt.it