The Machine-Readable About Page: A Teardown

When a retrieval system needs to answer "who is this person," there is one page it expects to do the heavy lifting. Here is what that page looks like when it is built for the reader that never scrolls: the parser.

Why is the About page the highest-leverage page you own?

Engines resolve people the way detectives resolve suspects: they collect statements from many sources and look for the version that everything else corroborates. Third-party mentions are scattered and partial. Your About page is the one place where the full, canonical statement lives: name, role, niche, history, proof, connections. When it is precise, every external signal snaps to it. When it is vague, the engine is left to assemble you from fragments, and fragments are how you end up misdescribed or, worse, merged with someone else. This page is also where Google's evaluators are explicitly told to look when assessing who is behind a site, per the guidance on people-first, E-E-A-T-aligned content.

So the design goal is not charm. It is extraction. A machine should be able to lift a complete, correct description of you from this page without inference. Charm can live on top.

The teardown, section by section

Section 1: Title tag and URL

The page lives at /about, not /my-story or /hello. The title tag carries your canonical name and your descriptor, because this page should rank for your name:

<title>About Jane Okafor: B2B SaaS Pricing Strategist</title>
<link rel="canonical" href="https://janeokafor.com/about">

One page, one canonical URL, no duplicate about-me variants competing with it. Two hygiene checks while you are here: the page must be indexable (no stray noindex inherited from a template), and its critical content must be present in the HTML your server actually returns. If your site builder injects the bio with JavaScript after load, some AI crawlers will fetch an empty shell and learn nothing. View source, not the rendered page, and confirm your name and descriptor are in the raw response.

Section 2: The H1 and the definitional paragraph

The H1 is your name. Not "My Story", not "Hi, I'm Jane". The first paragraph under it is the single most liftable passage on your site, so it is written like a knowledge-base entry: subject, role, niche, differentiator, proof, all in the first two sentences.

<h1>Jane Okafor</h1>
<p>Jane Okafor is a pricing strategist who helps B2B SaaS
companies between $5M and $50M ARR restructure their pricing.
She has led pricing projects for 40+ software firms since 2016
and writes the newsletter Priced In.</p>

Notice the shape: third person, present tense, specific scope, countable claims. That paragraph can be quoted verbatim by an engine, a journalist or a podcast host without edits, which is exactly the property you want. The craft behind that shape has its own playbook in Answer-Shaped Writing.

Section 3: The facts block

Next comes a scannable block of atomic, verifiable facts. Machines love structure they do not have to infer, so give the facts as labeled pairs rather than burying them in prose:

• Role: Founder and principal, Okafor Pricing
• Specialty: pricing and packaging for B2B SaaS
• Since: 2016, 40+ client engagements
• Based in: Austin, Texas, working with US and UK clients
• Education: MSc Economics, LSE

Every line here must match your LinkedIn, your bylines and your podcast bios word for word. Each mismatch is a small loan against your entity's coherence, the failure mode we call contradiction debt.

Section 4: The story, disciplined

Yes, keep the narrative. Humans hire humans, and the story is where trust forms for the 40% of readers who arrived skeptical. But discipline it: keep it under a third of the page, anchor it with dates and named employers or clients, and make sure it agrees exactly with the facts block above it. A story is machine-useful when it is a timeline wearing a nicer shirt.

Section 5: Third-party proof

A "featured in" or "as heard on" section, with each logo or outlet name linking to the actual article or episode. This does two jobs at once: it lets a crawler walk from your self-declaration to independent corroboration in one hop, and it tells human visitors that other people vouch for you. Unlinked logo walls do neither. If you have a separate press page, link it here too, and keep both fed by a steady digital PR pipeline.

Section 6: The Person JSON-LD block

This is the section that makes the page machine-readable in the literal sense. One Person object, in a single script tag, restating what the visible page already says:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jane Okafor",
  "jobTitle": "Pricing Strategist",
  "description": "Pricing strategist for B2B SaaS companies
    between $5M and $50M ARR. 40+ engagements since 2016.",
  "url": "https://janeokafor.com",
  "image": "https://janeokafor.com/img/jane-okafor.jpg",
  "worksFor": {"@type":"Organization","name":"Okafor Pricing"},
  "knowsAbout": ["SaaS pricing", "packaging strategy",
    "price localization"],
  "alumniOf": "London School of Economics",
  "sameAs": [
    "https://www.linkedin.com/in/janeokafor",
    "https://twitter.com/janeokafor",
    "https://github.com/janeokafor"
  ],
  "mainEntityOfPage": "https://janeokafor.com/about"
}
</script>

Three rules govern this block. First, it must mirror the visible content, never extend it, because structured data that claims things the page does not show is a trust liability. The full property reference lives at schema.org/Person, and Google's implementation rules are in the structured data documentation. Second, the sameAs array only lists profiles that are genuinely, currently you; it is the identity-resolution workhorse, and it earns its own deep dive in sameAs: The Most Underrated Line in Your Markup. Third, mainEntityOfPage declares that this page is about this Person, which is the whole point of the exercise.

Then validate. Paste the URL into the Rich Results Test or the schema.org validator and fix every error before shipping. A malformed JSON-LD block is worse than none, because it signals carelessness on the one page where you are claiming to be careful. And keep a matching photo: a real headshot at the image URL, with your name in the alt text, reused across your profiles so reverse-image lookups reinforce the same identity rather than scattering it.

Section 7: The FAQ tail

Close the page with three to five real questions people ask about you: "What does Jane actually do?", "Who is a fit?", "Where can I read her work?" Each answered in two or three self-contained sentences. Questions match how retrieval queries arrive, so this section frequently becomes the part an engine quotes. Write the answers the way you would want them read aloud to a prospect: "Jane works with B2B SaaS companies between $5M and $50M ARR that are repricing ahead of a funding round or a major launch. Engagements run six weeks and start with customer research, not spreadsheets." Complete, specific, quotable.

Section 8: Contact and consistency footer

End with your canonical contact details, identical to those everywhere else, and links to your key properties. This is boring by design. Boring, consistent and repeated is what identity resolution rewards, and it is the same principle we built out in Structure Your Identity for Machines.

The five failures that sink most About pages

Having torn down a lot of these pages, the same wrecks keep washing up:

• The manifesto: eight hundred words about your philosophy of work, zero extractable facts. A machine leaves knowing your vibe and not your job.
• The résumé dump: every role since university, no hierarchy, no current descriptor. The engine cannot tell which facts are load-bearing now.
• The clever headline: "Professional troublemaker. Coffee enthusiast." Charming to humans, noise to a parser trying to fill the jobTitle field.
• The orphan: a fine page that nothing links to and that links to nothing, unreachable in two hops from anywhere that matters.
• The time capsule: accurate in 2023, never touched since, quietly contradicting the newer story your press tells. Stale canon is worse than thin canon, because it actively outvotes your own updates.

The 10-point machine-readable About page checklist

1. Lives at /about with one canonical URL.
2. Title tag: canonical name plus descriptor.
3. H1 is the name itself.
4. First paragraph is a third-person, liftable definition with specifics.
5. Atomic facts block: role, niche, scope, location, credentials.
6. Narrative anchored to dates, capped at a third of the page.
7. Third-party proof section with real links, not logo wallpaper.
8. One Person JSON-LD block mirroring the visible content, sameAs included.
9. FAQ tail answering the questions buyers actually ask about you.
10. Every fact identical to every other bio you have published anywhere.

Ship all ten and your About page stops being a brochure and starts being what the machine always wanted it to be: the primary source. If you want the surrounding architecture too, the site-wide version of this exercise is building a knowledge base AI will cite, and our services page covers what it looks like done for you.

How does the About page feed your sameAs footprint and knowledge graph presence?

The About page is not an isolated artifact. It is the anchor node that everything else, your sameAs array, your Wikidata item if you have one, your entries in Google's Knowledge Graph, points back to. When a knowledge graph process tries to decide whether a LinkedIn profile, a GitHub account and a conference bio all describe the same human, it looks for a hub page that claims all of them at once and states the underlying facts identically. Your About page, with its Person JSON-LD and its sameAs list, is that hub. Get the hub wrong and every spoke inherits the error.

This is why the sameAs array deserves the same rigor as the facts block above it. Every URL in that array should resolve to a profile that is unambiguously you, actively maintained, and consistent with the name form and role you use on the About page itself. A stale handle you abandoned years ago, or a profile URL for a namesake you copied by mistake, does not sit there harmlessly. It becomes a false corroborating signal that a resolver may use to attach someone else's activity to your entity, a version of the identity blending covered in depth in name collisions and how PEO handles them. The full mechanics of why sameAs carries this much weight, and how it differs from a plain hyperlink, are worked through in sameAs: the most underrated line in your markup.

Wikidata deserves a specific mention because it sits upstream of Google's Knowledge Graph for a large share of entity resolution. If you qualify for a Wikidata item, notability rules apply and are stricter than most people expect, it becomes one of the highest-trust sameAs targets you can list, because Wikidata is itself heavily structured, community reviewed and machine parsed by nearly every major model's training pipeline. The relationship between your own site's markup and these external graphs is covered end to end in how knowledge graphs connect facts about people, but the operational takeaway for this page is narrow: keep the About page and the sameAs array in lockstep, and treat every profile you list as a promise you are making about your own identity.

A worked rebuild: turning a thin About page into a citable one

Abstract advice is easy to nod along to and hard to execute at your keyboard, so it helps to walk through an actual rebuild. Consider a hypothetical operations consultant named Marcus Webb, whose existing About page opens with a photo, the line "Hey, I'm Marcus, glad you're here," two paragraphs about his childhood interest in logistics, and a contact form. There is no jobTitle, no scope, no dates and no structured data at all. An engine asked "who is Marcus Webb" would have almost nothing extractable to work with.

A six-step sequence for converting a narrative-only About page into one an engine can extract cleanly.

The order matters more than it looks. Writing the facts block before the narrative forces discipline on the story that follows, because Marcus cannot casually round his twelve years of operations consulting into "over a decade" in one paragraph and "since 2013" in another once the facts block has already committed him to a number. Writing the JSON-LD last, instead of first, guarantees it mirrors a page that already exists rather than describing an aspirational one that does not.

Which Person schema properties are worth the extra effort?

Not every property on schema.org/Person carries equal weight for an About page. Some are load-bearing for identity resolution, some are decorative, and a few are actively risky if you fill them with anything less than a verified fact. The table below is the property triage worth running on any About page rebuild.

A property-by-property triage for the Person block on a machine-readable About page.

Notice that every risk column describes a failure of coherence, not a failure of volume. Schema markup does not reward you for filling in more fields. It rewards you for filling in the fields that are true, current and load-bearing, and leaving the rest empty rather than guessed. An About page with four accurate properties beats one with fourteen properties where three are stale.

How do AI crawlers actually reach and read this page?

None of the structure above matters if the page never gets fetched, or gets fetched and then discarded because it looked empty. Two separate gates sit in front of your About page before an engine can use it. The first is whether the relevant crawler is allowed in at all, which is a robots.txt question, covered fully in the AI crawler directory and robots.txt guide. A blanket disallow written for search engines years ago can quietly block the exact bots you now want reading your entity data.

The second gate is whether the page's content survives whatever your site does before serving it. If your About page is a single-page-app route that renders the definitional paragraph and the Person JSON-LD only after JavaScript executes, some crawlers fetch the pre-render shell and see nothing. Check this by viewing the raw HTML response your server sends, not the browser's rendered DOM. If the name, the facts block and the JSON-LD script are not present in that raw response, they may as well not exist for a large share of the crawlers that matter.

A newer, complementary path is publishing a dedicated machine-facing summary, an llms.txt file, alongside the human-facing About page. It does not replace structured data or a well-written page, but it gives retrieval systems a compact, unambiguous pointer to your key facts and canonical URLs, and it is worth pairing with your About page rebuild. The format and placement rules are in llms.txt for personal sites.

How often does a machine-readable About page need to be revisited?

Treat it on two clocks. The fast clock is factual: any time your role, your primary offer, your client count milestone or your location changes, the About page and its JSON-LD get updated the same week, because a stale fact here outvotes a correct fact anywhere else your bio lives. The slow clock is structural: once or twice a year, run the extraction test described earlier in a fresh session on more than one engine, re-check that every sameAs link still resolves to an active profile, and re-validate the JSON-LD, since schema.org properties and the supported feature sets of major engines both evolve.

The failure to watch for is asymmetry between the two clocks. Pages that get their narrative paragraph updated but never their facts block, or that get the visible page refreshed while the JSON-LD sits untouched in the head, end up contradicting themselves in the one place contradiction is most expensive. If you are already tracking your broader entity health on a schedule, fold the About page check into the AI visibility tracking routine rather than running it as a separate, easy-to-forget task.