The @type property is the primary classification mechanism in Schema.org structured data, specifying the exact class an entity belongs to—such as Person, Organization, Product, or Event. It tells a search engine's parser which specific set of properties and semantic rules apply to the described entity, moving beyond generic interpretation to precise, machine-readable categorization.
Glossary
@type
A fundamental Schema.org property used to define the specific class or category of an entity, such as Person, Organization, or Product.
SCHEMA.ORG FUNDAMENTAL
What is @type?
The @type property is the mandatory Schema.org attribute that defines the specific class or category of an entity, enabling search engines to disambiguate and classify data.
Without a valid @type, structured data is semantically orphaned and cannot be processed for rich results. The value must be a recognized Schema.org class, derived from the top-level Thing hierarchy. For example, a local business page would use "@type": "LocalBusiness" to unlock location-specific properties like address and openingHours, ensuring the entity is correctly indexed within the knowledge graph.
SCHEMA.ORG FUNDAMENTALS
Key Characteristics of @type
The @type property is the single most critical attribute in Schema.org markup, defining the class of an entity and determining which properties are valid for use. Without it, structured data is semantically meaningless to search engines.
01
Defines Entity Classification
The @type property explicitly declares what an entity is within the Schema.org hierarchy. It maps a JSON-LD node to a specific class—such as Person, Organization, Product, or Event—enabling search engines to apply the correct parsing rules and eligibility criteria for rich results.
- Must reference a valid Schema.org class name (case-sensitive)
- Determines which properties are semantically valid for that entity
- Incorrect @type values cause structured data to be ignored entirely
Example: "@type": "Product" tells Google this entity has an offers property, a brand, and a review—none of which would be valid on a Person node.
800+
Valid Schema.org Types
1
Required Per Entity Node
03
Root of the Type Hierarchy
All Schema.org types descend from Thing, the most generic class. The hierarchy branches into major categories—CreativeWork, Organization, Person, Place, Event, Intangible, and MedicalEntity—each with increasingly specialized subtypes.
- Thing → CreativeWork → Article → NewsArticle → ReportageNewsArticle
- Thing → Organization → LocalBusiness → Restaurant
- Thing → Intangible → Offer → AggregateOffer
Choosing the most specific applicable type improves semantic precision. A Dentist is more informative than LocalBusiness, which is more informative than Organization.
7
Top-Level Subtypes of Thing
5+
Levels of Depth in Hierarchy
04
Required for JSON-LD Graph Integrity
In JSON-LD, every node within a @graph array must declare its @type to establish a coherent linked data structure. Without @type, nodes become anonymous blank nodes that cannot be properly disambiguated or connected via properties like @id and sameAs.
- Enables cross-referencing between entities (e.g., a Product linking to its Organization manufacturer)
- Prevents entity collapse where distinct real-world things are merged into one
- Essential for Entity Linking strategies that connect your markup to Wikidata and Google's Knowledge Graph
Example: A page describing both a book and its author requires two nodes—one with "@type": "Book" and another with "@type": "Person"—connected via the author property.
06
Supports Multi-Type Entities
Schema.org allows an entity to declare multiple @type values as a JSON array when it legitimately belongs to more than one class. This is critical for entities that serve dual roles without creating redundant duplicate nodes.
"@type": ["Product", "CreativeWork"]— for a digital download that is both a commercial offering and a creative work"@type": ["LocalBusiness", "Organization"]— for a physical storefront that also operates as a corporate entity"@type": ["Event", "Course"]— for a scheduled workshop that is both an occurrence and an educational offering
Use multi-typing sparingly. Overuse dilutes semantic clarity and may confuse parsers. Prefer the single most specific applicable type when possible.
SCHEMA.ORG @TYPE
Frequently Asked Questions
Clear, technical answers to the most common questions about the Schema.org @type property and its role in defining entities for AI-driven search and knowledge graphs.
The @type property is a fundamental Schema.org keyword that defines the specific class or category of an entity within a structured data block. It acts as the primary classifier, telling a machine parser exactly what kind of 'Thing' is being described—whether it's a Person, Organization, Product, Event, or any other defined class in the Schema.org hierarchy. Without a valid @type, an entity is just an anonymous node; the @type gives it semantic meaning. For example, in a JSON-LD block, you would use "@type": "SoftwareApplication" to explicitly declare that the described entity is a software application, enabling search engines to apply the specific properties and rich-result eligibility rules associated with that class.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read more
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us