Extracto
Start free

Person schema for web extraction

The Person schema is a copy-and-paste shape for turning a public profile page into typed, validated JSON. Instead of writing CSS selectors or XPath against a bio page, an about-me section, a conference speaker card or a company team listing, you describe the fields you want (name, jobTitle, organization, location, bio, sameAs) and Extracto renders the page in a real headless browser and returns exactly those fields, validated against the schema. Anything the page does not actually state comes back as null rather than a guessed or hallucinated value, which matters a great deal when the subject is a real human being. Person data is structurally messy: the same role might be labelled "Title", "Position" or "Role", the employer might live in a byline, a logo alt-text or a sidebar, and social links are scattered across header icons, footers and inline mentions. Describing fields instead of selectors lets one schema generalize across very differently built profile pages. Because Extracto includes a managed anti-bot bypass layer with proxies handled for you, the same schema works on JavaScript-rendered profile widgets and on profiles served behind Cloudflare, DataDome or PerimeterX without any setup on your side. The one shape it will not reach is login-gated content that needs your session cookies. Important: people are personal data. Use this schema on public profiles only, keep volume modest, respect each site's Terms of Service and robots.txt, and treat anything you collect under your applicable privacy obligations such as the GDPR, including having a lawful basis and honouring deletion requests. Treat this entry as a starting point you trim or extend to the specific page you are reading.

Fields in a Person schema

The fields teams most often extract for a person, what type each one is, and whether it is usually present.

Field Type Required Notes
name string yes The person's full display name as written on the page. Typing it as a required string means a profile that renders without a recognizable name fails validation loudly instead of silently returning a half-empty record you would later have to clean.
jobTitle string optional The current professional role or title, such as 'Senior Staff Engineer' or 'Head of Product'. Pages label this inconsistently (Title, Position, Role), so describing the field rather than a selector lets one schema read it across differently structured bios; if the page never states a title it returns null, not an invented one.
organization string optional The employer, company or affiliation the person is associated with. Returning it as its own typed field separates the where-they-work signal from the free-text bio, which is what makes the record joinable against a company table instead of needing a second parse.
location string optional The stated location or base, for example 'Berlin, Germany' or 'Remote'. Kept as a plain string because profile pages rarely break city and country into separate elements; null here honestly signals the page did not disclose a location rather than guessing from a flag emoji or timezone.
bio string optional The biographical summary or about paragraph in the person's own framing. Capturing it verbatim as a string preserves the source wording for E-E-A-T and provenance, and avoids the model paraphrasing or compressing claims the person did not actually make.
sameAs string[] optional An array of canonical profile URLs linking the person to other platforms (personal site, LinkedIn, GitHub, Mastodon). Typing it as a list of strings mirrors the schema.org sameAs convention and is what lets you disambiguate two people with the same name; an empty array cleanly means no links were found.
pronouns string optional Self-stated pronouns when the profile lists them, such as 'she/her' or 'they/them'. Returned only when present and null otherwise, so you never attribute pronouns the person did not publish, which is both more accurate and more respectful of the individual.
profileImageUrl string optional The absolute URL of the headshot or avatar shown on the profile. Typed as a string URL so it is immediately usable in a UI; if the page uses a generic placeholder or no image, the field returns null rather than a misleading default-avatar link.

The schema

Copy this and send it with any URL.

{
  "name": "string",
  "jobTitle": "string",
  "organization": "string",
  "location": "string",
  "bio": "string",
  "sameAs": "string[]",
  "pronouns": "string",
  "profileImageUrl": "string"
}

Example output

Validated JSON back, matching the schema.

{
  "name": "Tim Berners-Lee",
  "jobTitle": "Computer Scientist, Inventor of the World Wide Web",
  "organization": "World Wide Web Consortium (W3C)",
  "location": "London, United Kingdom",
  "bio": "British computer scientist best known as the inventor of the World Wide Web in 1989. He is a professor at the University of Oxford and MIT, and directs the W3C, which oversees the continued development of the web.",
  "sameAs": [
    "https://www.w3.org/People/Berners-Lee/",
    "https://en.wikipedia.org/wiki/Tim_Berners-Lee"
  ],
  "pronouns": null,
  "profileImageUrl": "https://upload.wikimedia.org/wikipedia/commons/Tim_Berners-Lee.jpg"
}

Try this person schema against a real page in the live demo, or read the docs to use it via the API.

Person schema: FAQ

Can Extracto extract a Person profile from a site protected by Cloudflare or DataDome?
Yes. Every request runs through a managed anti-bot bypass layer with proxies handled for you, so public profile pages served behind Cloudflare, DataDome or PerimeterX, including JavaScript-rendered profile widgets, are read by a real headless browser without any setup on your side. The single limitation is login-gated content that needs your own session cookies, such as private profile data on LinkedIn, X or Instagram; that is available on the Enterprise plan.
What happens when a profile page does not list a job title, location or social links?
Each missing field is returned as null (or an empty array for sameAs) instead of a guessed value. Extracto validates the rendered page against your schema and only fills a field when the page actually states it, so you can trust that a null genuinely means absent rather than a model inventing a plausible-looking title or city. This is especially important for person data, where a fabricated employer or location attached to a real individual is both inaccurate and a potential privacy problem.
Do I need to write CSS selectors to map name, organization and bio?
No. You describe the fields you want in a JSON schema and Extracto figures out where they live on the page. Profile pages label the same concept very differently (Title vs Position vs Role, employer in a byline vs a logo alt-text), so describing fields instead of selectors lets one Person schema generalize across many differently built about pages, speaker cards and team listings without per-site selector maintenance.
Is it legal and safe to scrape people's profiles with this schema?
Use it on public profiles only and treat the output as personal data. Respect each site's Terms of Service and robots.txt, keep request volume modest, and meet your own privacy obligations such as the GDPR, including having a lawful basis for processing and honouring access or deletion requests. Extracto returns what a page publicly displays; deciding whether you may collect and store a given person's data is your responsibility as the controller, so scope your extraction narrowly and avoid sensitive categories.
How does sameAs help me match the same person across sites?
sameAs returns an array of canonical profile URLs (personal site, GitHub, Mastodon, an organization staff page) that the profile itself links to. Because two different people can share a name, these URLs are the disambiguation key: matching on a shared canonical link is far more reliable than matching on name plus title alone. Returned as a typed list of strings, it drops straight into an entity-resolution step, and an empty array honestly tells you the page exposed no outbound profile links.