This original fictional directory entry describes a person and the organization they work for. It is an example of nesting, not a real profile to publish:
<article itemscope itemtype="https://schema.org/Person">
<h2 itemprop="name">Mira Chen</h2>
<p itemprop="jobTitle">Workshop coordinator</p>
<p>Works for
<span itemprop="worksFor" itemscope
itemtype="https://schema.org/Organization">
<span itemprop="name">North Workshop</span>
</span>
</p>
</article>
The Person has a name, a job title and a worksFor property. That last property's value is another item, an Organization with its own name. The WHATWG microdata specification defines these item boundaries. Schema.org's Person vocabulary defines jobTitle and worksFor. Both were checked October 24, 2026.
Keep all three attributes in their roles
itemscope is a Boolean attribute. Writing itemscope="false" still creates an item because the attribute is present. Remove the attribute if you mean to remove that boundary.
itemtype names a vocabulary type using a URL. It does not load a script or change the visual layout. Use property names defined for that vocabulary rather than guessing a spelling that resembles your database column.
itemprop names a property. On an ordinary span its value generally comes from text; on a link it comes from the resolved href; on a time element it comes from datetime. The element you choose therefore changes the value an extractor receives. The MDN microdata guide explains the attributes and their relationship.
Check the item boundary before adding more properties
Without the inner itemscope and itemtype, the inner name is no longer the name of a distinct Organization item. A page can look exactly right while describing the wrong structure.
For the example, the expected structure is:
Person
name: Mira Chen
jobTitle: Workshop coordinator
worksFor:
Organization
name: North Workshop
Inspect an extractor's item tree against that outline. A DOM query such as article.querySelectorAll('[itemprop]') finds nested descendants too; its flat list is not a microdata parser and does not prove that all properties belong to the Person.
Annotate the information that is actually on the page
Replace fictional names and roles with verified profile information before using this pattern. Do not add invented credentials, reviews, ratings or employers because a vocabulary permits those fields. A correctly spelled property can still contain a false claim.
If the page already carries structured data through another mechanism, inspect it before adding microdata. Two descriptions maintained separately can disagree after a profile edit. Choose an intentional source of truth for the person and organization records.
The semantic HTML guide covers the article and heading structure that readers use. Microdata adds named relationships to that content; it does not replace clear prose or guarantee a search feature. Finish by comparing the extracted Person and Organization with the visible directory entry, especially after moving a name or job title between containers.