JSON-LD becomes much easier once you stop thinking of it as an SEO ornament and start treating it as a description of the things a page is genuinely about. A page may describe an article, a person, a company, a product, an event, or several connected entities. JSON-LD gives those entities names, types, properties, and relationships that machines can read without reverse-engineering the interface.
This guide covers twelve practical JSON-LD use cases for modern websites. The goal is not to mark up everything. It is to choose the smallest truthful graph that describes the visible content and supports a real search or discovery use case.
What JSON-LD is used for
JSON-LD is a format for linked data. On a website, it normally appears in a <script type="application/ld+json"> element and uses the Schema.org vocabulary. Search engines can use it to understand entities and, for supported types, evaluate a page for enhanced search appearances.
It does not guarantee rankings or rich results. Its practical value is clarity: it makes explicit what the page represents, which facts belong to which entity, and how those entities relate.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "JSON-LD Examples and Use Cases",
"url": "https://example.com/json-ld-examples"
}
</script>1. Organization: define the company behind the site
Use Organization on an authoritative page about a business, normally the home or about page. It can connect the company name, canonical URL, logo, contact details, and verified public profiles. Keep one stable @id and reuse it when other objects reference the organization.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Studio",
"url": "https://example.com/",
"logo": "https://example.com/logo.png",
"sameAs": ["https://www.linkedin.com/company/example-studio"]
}Best for: agencies, companies, nonprofits, institutions, and brands with a distinct identity.
2. Person: establish a creator or professional identity
Use Person when a page is primarily about an individual: a portfolio, author profile, speaker page, or personal site. Useful properties include name, url, jobTitle, worksFor, and sameAs. Only link profiles that genuinely represent the person.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/#person",
"name": "Alex Rivera",
"url": "https://example.com/",
"jobTitle": "UX Engineer",
"sameAs": ["https://www.linkedin.com/in/alex-rivera"]
}Best for: portfolios, consultants, creators, authors, and public professional profiles.
3. WebSite: describe the site as a whole
WebSite represents the entire website rather than an individual page. It is commonly paired with Organization or Person and identified from the homepage. Do not use it as a substitute for describing the actual content on every URL.
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"name": "Example Studio",
"publisher": { "@id": "https://example.com/#organization" },
"inLanguage": ["en", "es"]
}Best for: declaring the site name, publisher, language, and relationship to the main entity.
4. Article and BlogPosting: identify editorial content
Use Article, BlogPosting, or NewsArticle when the page is an editorial work. The markup should match the visible headline, author, dates, and image. Google documents additional recommendations for article structured data.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "JSON-LD Examples: 12 Practical Use Cases",
"datePublished": "2026-09-01",
"dateModified": "2026-09-01",
"author": { "@id": "https://example.com/#person" },
"image": "https://example.com/images/json-ld-guide.jpg",
"mainEntityOfPage": "https://example.com/json-ld-examples"
}Best for: blog posts, reports, news, tutorials, and long-form editorial pages.
5. BreadcrumbList: make the page hierarchy explicit
BreadcrumbList describes a page's position inside a hierarchy. The items should correspond to a real, logical navigation path—not a list invented solely for markup. Google maintains specific breadcrumb guidelines.
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://example.com/blog" },
{ "@type": "ListItem", "position": 2, "name": "Technical SEO", "item": "https://example.com/blog/technical-seo" },
{ "@type": "ListItem", "position": 3, "name": "JSON-LD Examples" }
]
}Best for: ecommerce, documentation, publications, and sites with meaningful categories.
6. Product: describe something that can be purchased
Use Product for a specific product or product variant. Price, availability, ratings, and reviews must reflect information users can see on the page. Google's product documentation separates merchant listings from product snippets and defines the supported requirements.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Field Notebook",
"image": "https://example.com/notebook.jpg",
"sku": "FN-01",
"offers": {
"@type": "Offer",
"priceCurrency": "EUR",
"price": "24.00",
"availability": "https://schema.org/InStock",
"url": "https://example.com/products/field-notebook"
}
}Best for: physical goods, product variants, and purchasable digital products. It is not appropriate for a generic services page.
7. SoftwareApplication: explain an app or software product
SoftwareApplication can describe a mobile app, web application, desktop product, or other software. Use a more specific subtype such as MobileApplication or WebApplication when it accurately fits.
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "Focus Timer",
"applicationCategory": "ProductivityApplication",
"operatingSystem": "Web, iOS, Android",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "EUR"
}
}Best for: product landing pages for apps, SaaS tools, browser applications, and downloadable software.
8. Event: publish a real event with a time and place
Use Event for something that happens at a defined time: a conference, webinar, workshop, performance, or community event. Status and attendance mode are important when an event is postponed, cancelled, online, or hybrid. Follow Google's current event guidelines.
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Structured Data Workshop",
"startDate": "2026-10-15T18:00:00+02:00",
"endDate": "2026-10-15T20:00:00+02:00",
"eventAttendanceMode": "https://schema.org/OnlineEventAttendanceMode",
"eventStatus": "https://schema.org/EventScheduled",
"location": { "@type": "VirtualLocation", "url": "https://example.com/workshop" }
}Best for: individual event pages, not category pages containing an undifferentiated calendar.
9. VideoObject: provide the facts around a watchable video
VideoObject helps describe a video embedded on a page. The thumbnail, upload date, duration, description, and video URL should be accurate and accessible. Google's video documentation explains supported properties and indexing requirements.
{
"@context": "https://schema.org",
"@type": "VideoObject",
"name": "How JSON-LD Connects Website Entities",
"description": "A visual explanation of a connected Schema.org graph.",
"thumbnailUrl": "https://example.com/video-thumbnail.jpg",
"uploadDate": "2026-09-01",
"duration": "PT6M20S",
"contentUrl": "https://example.com/videos/json-ld.mp4"
}Best for: pages where the video is a primary, watchable part of the content.
10. JobPosting: structure a genuine open role
Use JobPosting for a single, currently open position. The description, employer, location, employment type, publication date, and expiry should agree with the visible listing. Never leave expired roles marked as open. Google's job posting policies are particularly strict because the markup represents a real opportunity.
{
"@context": "https://schema.org",
"@type": "JobPosting",
"title": "Senior UX Engineer",
"datePosted": "2026-09-01",
"validThrough": "2026-10-01T23:59:59+02:00",
"employmentType": "FULL_TIME",
"hiringOrganization": { "@id": "https://example.com/#organization" },
"jobLocationType": "TELECOMMUTE",
"applicantLocationRequirements": { "@type": "Country", "name": "Spain" }
}Best for: a dedicated page for one active vacancy.
11. LocalBusiness: connect a business to a physical location
LocalBusiness is an Organization subtype for a business with a customer-facing physical presence. Choose the most specific subtype that truthfully applies. Address, telephone, opening hours, and geographic information should match the page and other authoritative listings.
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "Example Research Studio",
"url": "https://example.com/",
"telephone": "+34 900 000 000",
"address": {
"@type": "PostalAddress",
"streetAddress": "Example Street 10",
"addressLocality": "Barcelona",
"postalCode": "08001",
"addressCountry": "ES"
}
}Best for: shops, restaurants, clinics, studios, and local professional services. Remote-only businesses should normally use Organization instead.
12. CreativeWork: model portfolios and case studies honestly
CreativeWork is useful when a page presents a project, design, report, dataset, or other creative output. Schema.org does not currently define a CaseStudy type, so inventing one produces invalid vocabulary. A portfolio case study can instead be an Article or BlogPosting whose about property references a CreativeWork.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Redesigning a Travel Planning Experience",
"author": { "@id": "https://example.com/#person" },
"about": {
"@type": "CreativeWork",
"name": "Travel Planning Redesign",
"creator": { "@id": "https://example.com/#person" },
"keywords": ["UX research", "product design", "travel"]
}
}Best for: portfolios, design projects, research outputs, and project case studies. I cover the model in more detail in JSON-LD for UX case studies.
How to combine multiple JSON-LD types
A page often needs several connected objects. An article can belong to a website, name a person as its author, reference an organization as publisher, and include breadcrumbs. Instead of duplicating each entity, use stable @id values and connect the objects inside an @graph.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"@id": "https://example.com/#person",
"name": "Alex Rivera"
},
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com/",
"author": { "@id": "https://example.com/#person" }
},
{
"@type": "BlogPosting",
"@id": "https://example.com/json-ld-examples/#article",
"headline": "JSON-LD Examples and Use Cases",
"author": { "@id": "https://example.com/#person" },
"isPartOf": { "@id": "https://example.com/#website" }
}
]
}The graph is not better merely because it is larger. Add an entity when it clarifies a real relationship or supports the page's purpose.
How to choose the right schema type
Start with the page's main thing. Is it an article, product, event, person, job, or application?
Use the most specific valid subtype. BlogPosting is more precise than CreativeWork for a blog post, but only when it remains accurate.
Check visible-content parity. A property should not claim a price, rating, author, or availability the user cannot verify on the page.
Check Google's documentation separately. Schema.org validity and Google feature eligibility answer different questions.
Prefer stable entity identifiers. Reuse canonical
@idvalues for the same person, organization, and website.
Common JSON-LD mistakes
Inventing schema types. If a type is absent from Schema.org, using the name does not make it valid.
Adding invisible claims. Markup must not present ratings, prices, jobs, or events that the page does not show.
Using the wrong entity. Product is not a generic label for a service, and LocalBusiness is not appropriate for every company.
Duplicating contradictory objects. Plugins, themes, and custom scripts can each output competing schema.
Leaving stale facts. Expired jobs, past events, old prices, and changed availability make structured data unreliable.
Expecting schema to repair weak content. Markup describes a page; it does not create authority, relevance, or usefulness.
How to validate JSON-LD before publishing
Validate vocabulary and graph structure with the Schema.org Validator.
Test Google-supported features with the Rich Results Test.
Compare every important property against the visible page.
Inspect the deployed URL, not only a CMS preview.
Monitor Search Console for detected structured-data issues.
If you implement JSON-LD through a CMS, escape dynamic values as JSON and test several records—not only the cleanest example. Quotes, missing images, optional fields, translations, and empty values are where templates usually break. For a concrete implementation workflow, see structural SEO and JSON-LD in Framer.
The practical rule
Use JSON-LD to express what a thoughtful reader can already learn from the page. Choose the main entity, describe it with the narrowest accurate type, connect related entities with stable identifiers, and stop before the graph becomes speculative. The best structured data is not the most elaborate. It is the easiest to verify and maintain.
