Schema markup should describe facts the page can defend.

Structured data gives machines an explicit description of information that already exists. For some supported types, valid markup can make a page eligible for a particular search appearance. Eligibility is not a promise that the appearance will show, and markup is not a general ranking upgrade.

That distinction changes implementation. The goal is not to fill every available property. It is to maintain a small, accurate representation of the page. Google's own introduction says fewer complete and accurate properties are more important than a larger set of incomplete or inaccurate ones.

Article: connect the work to a real author

This example assumes the page visibly shows the headline, dates, and named author, and that the author URL resolves to a page about that person. If no person accepts authorship, do not invent one for the graph.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to choose a rain jacket",
  "datePublished": "2026-08-01",
  "dateModified": "2026-08-12",
  "mainEntityOfPage": "https://example.com/rain-jacket-guide/",
  "author": {
    "@type": "Person",
    "name": "Mina Patel",
    "url": "https://example.com/about/mina-patel/"
  }
}

dateModified should change when the article changes materially, not whenever a build runs. The author object describes who created the article. It does not prove that person's expertise, and adding credentials that cannot be verified makes the markup less trustworthy rather than more complete.

Organization: publish a small identity claim once

Google recommends Organization markup on the homepage or a single page that describes the organization; it does not need to appear on every page. Only use properties that apply. A remote business should not add an address or LocalBusiness subtype merely because a generator asks for one.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "email": "[email protected]"
}

If the publishing identity is a person rather than an organization, a Person node may be the more accurate representation. Schema types should follow the real entity, not the keyword the site wants to rank for.

BreadcrumbList: represent a useful path

Breadcrumb markup can describe a typical user path even when the URL structure is flat. The visible page should give the user comparable navigational context. Do not construct an imaginary hierarchy solely to produce a richer-looking trail.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Guides",
      "item": "https://example.com/guides/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Rain jackets"
    }
  ]
}

A release sequence that prevents most schema defects

1. Name the page's main thing. An article, product, event, recipe, organization, and local business are different claims.
2. Open the current feature documentation. Schema.org vocabulary is broader than what Google supports for search appearances.
3. Map each property to visible or controlled evidence. If you cannot point to the source of a value, omit it.
4. Generate from the same source as the page. Duplicate hand-maintained values drift.
5. Validate syntax and meaning. The Rich Results Test can catch implementation errors; a human still has to catch a false claim.
6. Inspect the rendered URL. Confirm Google can retrieve the markup, then monitor enhancement reports where the feature has one.

Schema cannot install E-E-A-T

Markup can identify an author, publisher, date, or relationship. It cannot make an invented author experienced, turn a badge into authority, or create trust in unsupported content. The E-E-A-T diagnostic starts with evidence and accountability on the page. Structured data follows those facts.