Structured Data for Articles, Breadcrumbs, and Organizations

A website publishes an article, has a breadcrumb trail, and names the organization behind the site. These are three different facts. Structured data can express them in machine-readable form, but it should describe visible, truthful page content. Markup is useful when it clarifies a page's identity; it cannot replace an accurate article or guarantee a special search appearance.

Start with the page and its real entities

Inspect the rendered page before writing JSON-LD. Is it an article with a headline, author, publication date, and a meaningful body? Does its navigation show a real path through the site? Is there a clear organization identity on the home or about page? Decide which facts are genuinely present and maintained.

Google's general structured data guidelines say markup should represent the page content and meet quality requirements as well as syntax requirements. A technically valid object can still be misleading. Do not invent an author, inflate an update date, or mark a sales page as an editorial article to seek a result type.

Keep one source of truth for each field. If the article title, visible byline, and JSON-LD headline are generated from different data stores, they can drift. Connect markup to the same content record used by the page, then test how it renders after publishing and editing.

Model the article accurately

Google's Article documentation describes Article, NewsArticle, and BlogPosting markup and relevant fields such as headline, image, dates, and author. Choose the subtype that describes the actual page. A general guide does not become news merely because it discusses a current topic.

Use the visible headline as the headline value. Supply the actual author identity if one is shown and maintained. A dateModified value should reflect a substantial content change, not the most recent build or footer edit. If an image is specified, make sure its URL resolves to the image actually associated with the page and that the site has rights to use it.

Do not stuff every optional field with guesses. A short, accurate object is easier to maintain than an elaborate schema that breaks when the CMS changes. Check whether multiple articles appear on a page; a listing page and an individual article page have different primary subjects.

Describe navigation with breadcrumbs

Google's BreadcrumbList guidance explains a sequence of ListItem entries with positions, names, and URLs. The trail should reflect a useful hierarchy for the reader, not a fabricated chain of keywords. Use the canonical destination for each step and keep names consistent with visible navigation.

For a guide under “Learn” and then “Web publishing,” the breadcrumb may follow Home, Learn, Web publishing, Guide. But if the site has no Web publishing section, do not add one only in markup. Keep URL changes and redirects in mind: old breadcrumb URLs can survive in templates long after navigation is redesigned.

Validate more than the JSON syntax. Open each destination. Check that the sequence makes sense on mobile and desktop. A search engine may use breadcrumb data differently across surfaces, so measure your implementation by accuracy and valid parsing rather than a promised display shape.

Identify the organization once and consistently

Google's Organization guidance recommends placing organization information on the home page or one page that describes it, such as an about page; it need not be repeated everywhere. Include facts that actually apply, such as name, URL, logo, or public contact details. An individual creator should not invent a corporation to fill a schema template.

Use a stable organization name and URL across page content, contact information, and markup. If there are multiple legal entities, brands, or regional sites, decide which entity operates the specific page before assigning properties. A logo URL should point to an accessible image with a legitimate relationship to that organization.

Separate the publisher from an article's author when they differ. A named person can write an article published by an organization. Conflating those roles may make the page less clear even if a validator accepts the fields.

Hypothetical implementation review

Hypothetical example: A small publication has a guide with a visible author and a “Guides” breadcrumb. Its CMS emits Article markup but always sets dateModified to today's date, while the page's visible updated date is two years old. The home page also emits Organization markup with an outdated logo URL.

The editor changes the date field to use the content record's substantive revision timestamp, checks the breadcrumb URLs against the current navigation, and updates the organization logo reference on the home page. They run a syntax test and inspect the rendered page and source values together. This describes a review method; it is not a claim that any real site gained a search feature.

1. Identify the article, navigation trail, and site entity on the rendered page.
2. Map each markup field to a maintained content source.
3. Add only relevant types and truthful values.
4. Validate syntax and compare markup with visible content and URLs.
5. Recheck after CMS, navigation, date, or logo changes.

Structured data checklist

• Does each type describe the actual page rather than a hoped-for search result?
• Do headline, author, dates, image, and organization fields match visible facts?
• Do breadcrumb positions and URLs follow the live site hierarchy?
• Are canonical URLs and image resources accessible?
• Have template changes been checked on several representative pages?
• Have syntax results been separated from search appearance expectations?

Structured data is a maintenance obligation. When an article moves, an author name changes, or the site's identity is updated, the markup needs the same editorial care as the visible page. Keep the implementation small enough that your team can verify it each time the content changes.