Structured Data in Plain English

Every page on your website is written for people. A visitor reading your About page knows straight away that “Jordan Ellis” is a person, that “Executive Leadership Coach” is a job and that the little LinkedIn icon in the footer leads to Jordan’s profile.

A search engine has to work all of that out. It reads the words, looks at the layout and makes an educated guess. Most of the time it guesses well. When your name is shared with someone else, or your role is described three different ways across the web, it can guess wrong.

Structured data removes the guesswork. It’s a short block of code that sits on the page and states the facts plainly: this page is about a person, this is their name, this is their job, these are their other profiles. Google describes it as a standard way of providing information about a page and classifying its content¹.

This guide explains what that code is, what it does and doesn’t do, and how to add it to your own About page without a developer. You won’t need to learn to program. You will need to be precise.

What structured data actually is

Think of a form you fill in at a doctor’s surgery. There’s a box for your name, a box for your date of birth and a box for your GP. Nobody has to read a paragraph about you and pick out the facts, because each fact sits in a labelled box.

Structured data is that form, filled in on behalf of your web page. The boxes come from a shared vocabulary called schema.org, which the major search engines use. It defines types of thing, such as Person, Organization and WebPage, and the properties each can have. A Person, in schema.org’s own wry definition, can be alive, dead, undead or fictional². Properties include name, jobTitle, worksFor and sameAs.

So when your About page carries a small block saying the page is about a Person whose name is Jordan Ellis and whose jobTitle is Executive Leadership Coach, there’s nothing left to infer. The facts are labelled.

Two things are worth knowing from the start. First, the code is invisible to visitors. It changes nothing about your design. Second, Google expects the code to describe what’s already on the page¹. It’s a label for your content, not a place to add claims your page doesn’t make.

Why Google asks for it

Google gives structured data two jobs. The first is understanding: explicit clues about what a page means¹. The second is presentation: some types of markup make a page eligible for richer search results, such as recipes with star ratings or events with dates.

Google publishes a handful of brand case studies about that second job, rich results. They are worth seeing, with an important caveat.

These are case studies from individual brands, reported by those brands and published by Google, about markup that earned visible rich results in search. They are not about Person markup or knowledge panels, and they aren’t averages. Read them as proof that Google really does read this code, not as a forecast for your About page.

For an expert whose name is the business, the first job matters more. Person markup has no rich result of its own. Google’s gallery of supported search features lists 25 types, and Person isn’t one of them³. What Person markup does is tell Google, in a format it trusts, which person a page is about and which other profiles belong to the same person. Google has listed structured markup from site owners among the sources that feed its Knowledge Graph, alongside open databases and licensed data⁴. That graph is what your knowledge panel is built from.

Organization markup is similar. Google says it helps tell your organisation apart from others and can influence details such as the logo shown in search and what appears in a knowledge panel⁵.

What it doesn’t do

This is where a lot of advice goes wrong, so it’s worth being blunt.

Google’s general guidelines are explicit: passing a test doesn’t guarantee anything will appear, and Google may show a different feature or a plain result instead⁶. Its Organization documentation repeats the point⁵. Markup is one clear, well-formed signal. Whether Google shows a panel still depends on whether the rest of the web agrees with it.

Google’s quality rules say not to mark up content that isn’t visible to readers, not to use markup that misrepresents the page, and not to impersonate people or organisations⁶. If your About page doesn’t mention your degree, don’t add alumniOf. Add the sentence to the page first.

There’s also a cost to getting it wrong. Google can apply a manual action for structured data that breaks its guidelines. That removes the page’s eligibility for rich results, though Google says it doesn’t affect ranking⁶.

Features also come and go. In November 2025 Google said it was phasing out lesser-used search features to simplify the results page, and that it would drop some structured data types from Search Console from January 2026⁷. Markup written to chase a particular visual feature can lose its payoff overnight. Markup that accurately describes who you are keeps its value, because understanding doesn’t go out of fashion.

JSON-LD: the format Google recommends

Structured data comes in three formats. Google supports all of them, and says each is fine as long as it’s valid¹.

Google recommends JSON-LD because it’s the easiest to implement and maintain at scale, which in its words makes it less prone to user errors¹. For a non-developer the advantage is simpler still: it’s one block you paste in, and if it’s wrong you replace one block. You never have to edit your page’s design to fix it.

A JSON-LD block always has the same skeleton. It opens with @context, which says “I’m using the schema.org vocabulary”, and @type, which says what kind of thing is being described. Everything after that is a property and its value, written as "property": "value", separated by commas. Text goes in straight double quotes. Lists go in square brackets. A thing inside a thing, such as the company you work for, goes in its own curly brackets.

Most errors come from three slips: a missing comma between lines, an extra comma after the last line, and curly “smart” quotes pasted in from a word processor. Write markup in a plain text editor, never in Word or Google Docs.

A minimal Person, line by line

Here is the smallest Person markup worth publishing, for the fictional coach we used in our knowledge panel guide. Every name and URL is a placeholder.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Jordan Ellis",
  "jobTitle": "Executive Leadership Coach",
  "url": "https://www.example.com/about"
}

Five lines of substance. Here’s what each one tells Google.

The job title deserves a second look. Google is trying to work out what you do, and it compares your own description with every other mention of you. If your markup says “Executive Leadership Coach”, your LinkedIn says “Founder & CEO” and your speaker bio says “Organisational Psychologist”, the markup is outvoted. Pick one primary title and use it word for word everywhere. We go into how Google weighs your role in how Google reads your LinkedIn headline.

The fuller version: sameAs, worksFor and alumniOf

The minimal version states who you are. The fuller version connects you to everything else that proves it.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://www.example.com/about#person",
  "name": "Jordan Ellis",
  "alternateName": "Jordan A. Ellis",
  "jobTitle": "Executive Leadership Coach",
  "description": "Jordan Ellis is an executive leadership coach who helps first-time founders build and lead their teams, and the author of The First Hundred Hires (2025).",
  "url": "https://www.example.com/about",
  "image": "https://www.example.com/images/jordan-ellis.jpg",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://www.example.com/#organization",
    "name": "Ellis Leadership Partners",
    "url": "https://www.example.com/"
  },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Example State University"
  },
  "knowsAbout": [
    "Executive coaching",
    "Leadership development",
    "Startup hiring"
  ],
  "sameAs": [
    "https://www.linkedin.com/in/example-jordan-ellis",
    "https://www.youtube.com/@examplejordanellis",
    "https://x.com/example_jellis"
  ]
}

Why sameAs matters most

If you only add one property beyond the minimum, make it sameAs. schema.org defines it as the URL of a reference page that unambiguously indicates the item’s identity⁸. In plain English, it’s you pointing at your other profiles and saying “that’s me too”.

That’s exactly the question Google is trying to answer when it decides whether your website, your LinkedIn and a podcast page all describe one person. sameAs lets you answer it yourself. Two rules keep it honest. List only profiles that are really yours and really about you, not your firm’s page or a profile you abandoned years ago. And make sure each of those profiles links back to your About page, so the claim runs both ways.

Google uses the same idea for article authors. Its Article documentation says it can use either url or sameAs to tell authors apart⁹.

Why worksFor and @id matter

worksFor ties you to your firm, and the firm gets its own description. The @id lines are what make that tie precise. Your home page can describe Ellis Leadership Partners with the identifier https://www.example.com/#organization, and your About page can point to the same identifier. The two pieces of markup then state outright that they describe one organisation, rather than two that happen to share a name.

An @id looks like a web address, but nothing has to load there. It’s simply a unique label. Pick one per person and one per organisation, and never change them.

Wrapping it in a ProfilePage for your About page

Your About page is a page about one person. schema.org has a type for exactly that: ProfilePage, a kind of web page whose main subject is a profile¹⁰. Google documents it too. It says the page’s primary focus must be a single person or organisation connected to the site, and it lists blog “About Me” pages, news author pages and employee pages on a company website among the valid examples¹¹.

The structure is simple. The ProfilePage describes the page. Its mainEntity is the Person you’ve already written. Here’s the whole thing as it would sit on Jordan’s About page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "url": "https://www.example.com/about",
  "name": "About Jordan Ellis",
  "dateCreated": "2024-03-04T09:00:00+00:00",
  "dateModified": "2026-09-10T14:30:00+01:00",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://www.example.com/about#person",
    "name": "Jordan Ellis",
    "jobTitle": "Executive Leadership Coach",
    "description": "Jordan Ellis is an executive leadership coach who helps first-time founders build and lead their teams, and the author of The First Hundred Hires (2025).",
    "image": "https://www.example.com/images/jordan-ellis.jpg",
    "worksFor": {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Ellis Leadership Partners",
      "url": "https://www.example.com/"
    },
    "alumniOf": {
      "@type": "CollegeOrUniversity",
      "name": "Example State University"
    },
    "sameAs": [
      "https://www.linkedin.com/in/example-jordan-ellis",
      "https://www.youtube.com/@examplejordanellis",
      "https://x.com/example_jellis"
    ]
  }
}
</script>

A word on expectations. Google built its ProfilePage feature for sites where creators share first-hand perspectives, such as forums and publishers with author pages¹¹. A coach’s About page qualifies as a valid profile page, but don’t expect a special search feature from it. The value is the same as Person markup on its own: a clear statement of who the page is about. If you write articles on your site, Google also recommends that each article’s author link points to a profile page marked up this way⁹.

Keep dateModified honest. Change it when you genuinely update the profile, not every time the site rebuilds.

Your firm and your site name, on the home page

Person markup belongs on your About page. Your home page is where you describe the firm and the website itself. Google recommends putting Organization markup on the home page or a single page about the organisation⁵, and it reads WebSite markup on the home page to choose the site name it shows in results¹².

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "name": "Ellis Leadership Partners",
      "alternateName": ["Ellis Leadership", "ELP"],
      "url": "https://www.example.com/"
    },
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Ellis Leadership Partners",
      "url": "https://www.example.com/",
      "logo": "https://www.example.com/images/elp-logo.png",
      "founder": { "@id": "https://www.example.com/about#person" },
      "sameAs": ["https://www.linkedin.com/company/example-ellis-leadership"]
    }
  ]
}
</script>

@graph just means “here are several things at once”. The founder line points back to Jordan’s @id, which closes the loop: the About page says Jordan works for the firm, and the home page says the firm was founded by Jordan. Google lists no required properties for Organization, and asks that a logo be at least 112 by 112 pixels⁵. For WebSite, only name and url are required, and the markup belongs on the home page alone¹².

Where to paste it

The code is the same everywhere. What changes is where your website builder lets you put it. Google accepts JSON-LD in either the page’s head or its body¹, but the head is the tidiest choice where you have it.

On Squarespace, the per-page field matters. The site-wide Code Injection header puts the code on every page¹³, and your Person markup should live on one page, not all of them. On Wix, the Advanced SEO panel accepts only JSON-LD, so paste the code block itself rather than any other format¹⁴. On WordPress, check what your SEO plugin already outputs before adding anything. Yoast, for example, builds Person or Organization markup from its Site representation settings¹⁶, and two competing Person descriptions on one page are worse than one.

1. 1

   Write the bio on the page first

   Your name, title, one-sentence bio, photo and profile links should all be visible on your About page before any markup describes them.

2. 2

   Copy the ProfilePage example into a plain text editor

   Swap every example.com address and every Jordan Ellis detail for your own. Delete any property your page doesn’t support.

3. 3

   Paste it into your platform’s field

   Use the per-page option for your About page. Use the home page for Organization and WebSite markup.

4. 4

   Publish, then test the live page

   Run the live address through the Schema Markup Validator and the Rich Results Test, as described below.

5. 5

   Ask Google to recrawl

   In Search Console, inspect the URL and request indexing so Google sees the change sooner.

How to test it, and the tool that no longer exists

Plenty of older guides, including some that still circulate as PDFs, tell you to check your code in Google’s Structured Data Testing Tool. You can’t. Google retired it.

1. July 2020

   Rich Results Test leaves beta

   Google says the older Structured Data Testing Tool will be deprecated.¹⁷

2. 15 December 2020

   A change of plan

   After feedback, Google says the tool will move to schema.org, check markup against schema.org standards and stop checking Google’s rich result types.¹⁷

3. 11 May 2021

   Schema Markup Validator announced

   schema.org announces the new home of the old tool, still under development.¹⁷

4. 9 August 2021

   The old tool redirects

   The validator is declared stable and Google sends visitors of the old tool to a page that helps them pick the right one.¹⁷

Today there are two tools, and they answer different questions¹⁸.

Use the validator first. It will show your Person, with each property listed underneath, and flag any typo or unknown property. Then run the Rich Results Test, which also confirms Google can fetch the page and read the code. Google’s guidelines recommend the Rich Results Test and the URL Inspection tool in Search Console for catching technical errors⁶.

What the results won’t tell you

A clean result means the code is readable. It doesn’t mean Google believes it, and it won’t produce a panel by itself⁶. If your markup says one thing and your LinkedIn, your speaker bios and your firm’s team page say another, the markup is one voice against several. Our name search checklist is a quick way to hear what those other voices say.

The mistakes we see most often

These come up again and again when experts add markup themselves.

• Markup that describes a different page. A Person block copied onto every page of the site, or left on a home page that’s really about the firm. Put Person markup on the page about the person⁶.
• Facts the page doesn’t show. An award, a degree or a job title in the markup that appears nowhere on the page. Google’s rules require markup to describe visible content⁶.
• A job title that doesn’t match anywhere else. The markup is the last place to experiment with a new title. Change it everywhere at once, or not at all.
• sameAs pointing at the wrong things. Your firm’s company page, a profile you no longer control or a namesake’s account. Each sameAs link is a claim that the page is you.
• Two Person blocks on one page. Usually a plugin’s markup plus a hand-added block, each with slightly different details.
• Stale facts. A role you left, a firm you sold or a headshot from ten years ago. Google won’t show a rich result for time-sensitive content that’s no longer relevant⁶, and out-of-date identity facts work against you.
• Smart quotes and stray commas. The validator catches these. Run it every time you edit.

Where to start

Structured data is the plainest thing you can give Google: your own facts, in labelled boxes, on the page that’s about you. It won’t earn a knowledge panel on its own, and anyone who promises it will is overselling. What it does is remove ambiguity on the one page you fully control, so that when Google compares your About page with the rest of the web, your version is clear and easy to match.

Start with the page, not the code. Make your About page say who you are in one clear sentence, with your title, photo and profile links visible. Then add the ProfilePage markup above, test it and keep it in step with every profile you own. If you want to know whether Google already recognises you, run your name through the free Knowledge Panel Checker. And if you’d rather have someone review your markup and the signals around it, book a free audit.

Keep reading

Knowledge PanelsWhat Is a Google Knowledge Panel, and Why Do Some People Get One?Shobin K Jose · 19 Oct 2026 · 23 min readGuidesHow Google Reads Your LinkedIn HeadlineShobin K Jose · 29 Sep 2026 · 15 min readKnowledge PanelsHow to Claim and Edit Your Knowledge PanelShobin K Jose · 22 Sep 2026 · 17 min read