Structured data for a person and a small company

Structured data is a machine-readable description of what a page is about: a person, an organisation, a site, an article. It does not change how the page looks. What it does is remove guesswork for software reading the page, and for a small site with a distinctive name, that is mostly what you want. This page shows a compact setup and the rules that stop it from being wrong.

Formats, and which to use

schema.org defines the vocabulary: types such as Person and properties such as name. There are three ways to write it into a page: JSON-LD, microdata and RDFa. Google supports all three and, in its general guidelines, marks JSON-LD as recommended. Its introduction to structured data says all three are equally fine as long as the markup is valid, and that in most cases JSON-LD is the easiest to implement and maintain, because it sits in a single <script type="application/ld+json"> block instead of being woven through your HTML attributes. Use it unless your CMS forces another format.

One rule applies whatever you write: the markup must describe content that is visible on the page. Google's guidelines say not to mark up content that readers cannot see, even if it is accurate, and not to mark up irrelevant or misleading information. If the JSON-LD names a person, the page must be about that person.

The four types worth having

For a personal or small-company site, four types cover almost everything useful.

You can add BreadcrumbList for navigation trails on deeper pages. Nothing else is needed to start, and extra types that do not match visible content only add ways to be wrong.

One graph, linked by @id

Rather than disconnected blocks, describe the home page entities in one @graph and connect them with @id references. An @id is a stable identifier, usually the page URL plus a fragment, that other nodes can point to. It lets you say "the publisher of this site is that person" without repeating the details.

Everything below is fictional: a made-up person, a made-up company, and example.com addresses.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Ada Example",
      "alternateName": "Ada Example Studio",
      "inLanguage": "en-CA",
      "publisher": { "@id": "https://example.com/#person" }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/#person",
      "name": "Ada Example",
      "url": "https://example.com/about/",
      "jobTitle": "Founder",
      "worksFor": { "@id": "https://example.com/#studio" },
      "sameAs": ["https://example.org/ada-example"]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#studio",
      "name": "Example Studio",
      "url": "https://example.com/",
      "logo": "https://example.com/img/logo.png"
    }
  ]
}
</script>

An article page then carries its own block. Google documents no rule for resolving an @id that is defined only on another page, so the article block repeats the minimal author and publisher nodes it needs instead of pointing at the home page:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/journal/sample-post/#article",
      "headline": "A sample post",
      "datePublished": "2026-10-17T09:00:00-04:00",
      "dateModified": "2026-10-17T09:00:00-04:00",
      "author": {
        "@type": "Person",
        "@id": "https://example.com/#person",
        "name": "Ada Example",
        "url": "https://example.com/about/"
      },
      "publisher": {
        "@type": "Organization",
        "@id": "https://example.com/#studio",
        "name": "Example Studio"
      },
      "mainEntityOfPage": "https://example.com/journal/sample-post/"
    }
  ]
}

Points that decide whether this works:

• Keep @id values constant. Changing them between pages makes every page describe a different entity.
• Use absolute URLs everywhere. Relative paths in structured data are a common source of silent errors.
• Give dates in ISO 8601. Google's Article guidance recommends including time zone information, otherwise it defaults to the time zone used by Googlebot; the sample uses -04:00, which is Toronto time in October. Dates must match what the page shows.
• Google's Article guidance lists no required properties and recommends author, headline, dates and an image. For author.name, put only the name: no job title, no "posted by". Google recommends adding url or sameAs to help it tell who the author is, which the sample does.
• Use exactly the properties that fit. Do not fill in jobTitle or worksFor unless the page also says so.

Site names have a scope

Google's site names guidance says that the WebSite markup must be on the home page, that a site is a domain or subdomain, and that subdirectory-level site names are not supported. A bilingual site with /fr/ therefore cannot give its French section its own site name. The name should be a concise, commonly recognised name, and Google says a generic name is unlikely to be chosen. If a preferred name may be unavailable or the site is better known by an acronym, alternateName gives the system a second option. If the home page already has WebSite markup, nest the name properties in that node instead of adding a second WebSite block, and use the same markup on duplicate home pages (such as www and non-www).

sameAs: use it for identity, nothing else

sameAs is a list of URLs that refer to the same entity. schema.org describes it as the URL of a reference web page that unambiguously indicates the item's identity, such as a Wikipedia page, a Wikidata entry or an official website. Google's Organization guidance describes it as a page on another website with more information about the organisation, for example a profile on a social media or review site, and allows several. That makes it powerful and easy to abuse.

• Include only profiles you control or that are verifiably the same person or company.
• Never add a profile belonging to someone with a similar name, a page you merely like, or an unverified account.
• Keep it consistent with the visible page. If a profile is linked in the footer, it can be in sameAs; if you would not link it publicly, do not assert it in markup.
• Check each URL returns a live page while signed out, because a dead or private URL says nothing.

A wrong sameAs link bridges two identities, which is the opposite of what clean entity data is for.

What it does and does not do

Be realistic about outcomes.

• It does not set rankings. Google describes structured data as helping it understand content and enabling rich results. Its guidelines even note that a structured data manual action removes eligibility for rich results and does not affect how the page ranks in web search. It does not present markup as a ranking lever.
• It does not guarantee any feature. Google states that it does not guarantee your structured data will show up, even if the page passes the Rich Results Test, because a feature being enabled does not mean it will be shown.
• Organization markup can influence some visible details. Google's Organization guidance says it can help Google understand administrative details and disambiguate your organization, and that some properties can influence which logo is shown in results and in a knowledge panel. It sets no required properties and makes no promise that a panel will appear. The logo image must be crawlable and at least 112 by 112 pixels.
• Person markup has no standalone rich result in Google's documentation. Google's gallery of supported features, as fetched for this article, lists Organization and Profile page but no Person entry. Person is still useful as the author or main entity that those features refer to.
• WebSite markup can feed the site name shown in results, alongside other signals such as og:site_name, the title element and the home page headings, with WebSite markup the most important if you want to state a preference.
• Article markup is optional. Pages appear in search without it. Google says it helps with title text, images and date information in results.
• Some features have ended. Google's documentation updates log says the FAQ rich result stopped appearing in Google Search from May 7, 2026, and the FAQ documentation was removed on June 15, 2026. The same log records that the HowTo structured data documentation was removed in 2023 because that rich result no longer appeared. Do not add FAQ or HowTo markup expecting a result.

If you want a clean entity, the benefit is consistency: the same name, the same URL, the same short description everywhere, written in markup and in visible text.

Validate before you ship

Use two tools because they ask different questions.

1. The Schema Markup Validator (validator.schema.org) checks that the markup is valid schema.org vocabulary and shows how it parses.
2. Google's Rich Results Test checks whether the page is eligible for Google's specific features, and shows warnings for missing recommended properties.

Then verify what search engines see. Google says it can read JSON-LD that is injected dynamically by JavaScript, but markup in the HTML sent by the server removes one thing that can go wrong. Test the rendered page with URL Inspection if you inject it. This is another reason to prefer static HTML first. After launch, Search Console's rich result reports list the valid and invalid items it finds for each type of rich result on your property. They show a sample, not every item.

A syntax check you can run locally

Before either validator, a ten-line script catches the two commonest failures: JSON that does not parse, and an @id reference to a node that is not defined on the same page. Save a built page as page.html and run it with Node:

import { readFileSync } from 'node:fs';
const html = readFileSync(process.argv[2], 'utf8');
const blocks = [...html.matchAll(/<script type="application\/ld\+json">([\s\S]*?)<\/script>/g)];
const defined = new Set(), used = new Set();
const walk = (n) => {
  if (Array.isArray(n)) return n.forEach(walk);
  if (n && typeof n === 'object') {
    const keys = Object.keys(n);
    if (n['@id']) (keys.length === 1 ? used : defined).add(n['@id']);
    keys.forEach((k) => walk(n[k]));
  }
};
blocks.forEach((b, i) => {
  try { walk(JSON.parse(b[1])); console.log('block ' + i + ': valid JSON'); }
  catch (e) { console.log('block ' + i + ': ' + e.message); }
});
for (const id of used) if (!defined.has(id)) console.log('dangling @id reference: ' + id);

Run on a fictional page containing the two blocks above, it printed block 0: valid JSON and block 1: valid JSON. Deleting one comma after "jobTitle": "Founder" made it print Expected ',' or '}' after property value in JSON at position 518 (line 20 column 7), and renaming the Organization's @id to #studios produced dangling @id reference: https://example.com/#studio. A parse error like the first one is how a small template edit silently removes all of a page's markup. The script does not check schema.org vocabulary, so it complements the validators rather than replacing them.

Keeping it accurate over time

Markup rots quietly because nobody looks at it. A few habits prevent that:

• Generate the JSON-LD from the same data that renders the visible page: one source for the name, the headline and the dates, so they cannot drift apart.
• Change dateModified only when the content really changed in a way a reader would notice. A date that updates on every build is a signal that means nothing.
• For a bilingual site, set inLanguage on each page's own nodes, and describe each language version on its own URL rather than merging them.
• Re-run the checks after a redesign or a template change, since a small edit can break the JSON and stop all the markup from parsing.
• Review sameAs whenever a profile is renamed, deleted or moved.

Google also documents ProfilePage markup, designed for sites where creators, people or organisations, share first-hand perspectives. It requires mainEntity, the person or organisation the page is about, and name. The Article guidance suggests it directly: if an author's url points to an internal profile page, mark that page up with profile page structured data. So if your author page is a real profile of one person, ProfilePage on that page is the documented fit; for the home page, the graph above is enough.

Common mistakes

For how markup interacts with titles, see titles, descriptions and snippets. For making sure each page has one preferred address, see canonical URLs, redirects and the www question.

Checklist

• Write JSON-LD with stable absolute @id values, and repeat the minimal nodes a page references.
• Mark up only what the visible page says.
• Put sameAs links only where identity is verified and the page is live.
• Validate with the Schema Markup Validator and the Rich Results Test, and parse the JSON yourself.
• Expect clarity, not rankings or guaranteed features.