Home / Blog / Teardown

The Machine-Readable About Page: A Teardown

Teardown2026-07-1411 min read
TL;DR

Your About page is the canonical record engines check every other fact against. Most About pages are mood boards: a hero quote, a journey story, zero verifiable claims. This teardown rebuilds the page section by section, from the definitional first paragraph to the Person JSON-LD block, so a machine leaves knowing exactly who you are, what you do, for whom, and why it should believe you.

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:

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 test

Paste your About page into a chatbot and ask: "Based only on this page, who is this person, what do they do, and for whom?" If the summary comes back vague or wrong, the page failed its primary reader.

The five failures that sink most About pages

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

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.

FAQ

Does an About page actually matter for AI visibility? +
Yes, disproportionately. When an engine tries to resolve who you are, your About page is the canonical self-declaration it checks other sources against. A vague or outdated About page weakens every third-party signal you have earned.
Should an About page be written in first or third person? +
Body copy can be first person, it reads more honestly to humans. But include one third-person definitional paragraph, name plus role plus niche plus proof, because that is the sentence engines and journalists lift verbatim.
What structured data belongs on an About page? +
One Person object as JSON-LD: name, jobTitle, description, url, image, worksFor, knowsAbout, and a sameAs array pointing to every profile that is genuinely you. Add mainEntityOfPage so the page is explicitly about that Person.

Find out what AI says about you today.

Start with a baseline. See the exact words the engines return about your name, then decide.

Claim your name →