Schema.org is a shared vocabulary that lets websites communicate structured information to search engines and AI systems in a format those systems can interpret without ambiguity. The vocabulary is built around two core concepts: Types, which define what something is, and Properties, which describe its characteristics. Understanding how these two elements relate and how inheritance connects them – is the practical foundation for implementing structured data correctly on any site, from a SaaS product page to a local medical clinic.

Schema.org Type is a category that classifies a real-world entity or concept, such as a person, organization, product, or article, so that machines can interpret what a page is about rather than just what words it contains.

Schema.org Property is an attribute that describes a characteristic of a Type, such as a name, price, or date, providing the specific detail that makes structured data actionable for search engines and AI systems.

Step 1: Understand the Vocabulary's Hierarchy

Schema.org organizes its vocabulary as a hierarchy rooted in a single ancestor Type called Thing. Every Type in the vocabulary either is Thing directly or extends from it through one or more levels of inheritance.

The top-level Types you will encounter most often are:

  • Thing: The root of all Types
  • CreativeWork: Articles, books, software, videos, and other authored content
  • Event: Occurrences at a time and place
  • Intangible: Abstract entities such as services, offers, brands, and roles
  • MedicalEntity: Medical conditions, procedures, drugs, and clinical concepts
  • Organization: Businesses, nonprofits, government bodies, and institutions
  • Person: Individual humans
  • Place: Physical locations, including businesses and geographic features
  • Product: Goods offered for sale

Each of these branches further. Organization extends into LocalBusiness, which extends into MedicalBusiness, which extends into MedicalClinic. Following that chain tells you exactly which Type best describes the entity you are marking up. Structured data fundamentals ground this hierarchy in the broader context of how machines read web content.

Step 2: Distinguish Types From Properties

Every schema.org implementation requires you to assign a Type and then populate it with Properties. These two elements serve different functions and cannot be substituted for each other.

What a Type Does

A Type tells a search engine or AI system what category of thing a page describes. When you declare "@type": "Product", you are signaling that the page represents a purchasable item, not an article, not a business, not a person. That classification determines which Properties are relevant and which rich results Google is eligible to display – how rich results are earned depends entirely on choosing an appropriate Type first.

What a Property Does

A Property fills in the detail within a Type. For a Product, Properties like name, description, sku, offers, and aggregateRating tell the search engine what the product is called, how much it costs, and how customers have rated it. Without Properties, a Type declaration is a category label with no content. Without a Type, a list of Properties has no interpretive frame.

The Relationship Between Them

Think of a Type as the noun and a Property as the adjective or verb. Organization is the noun; name, url, address, and foundingDate are the attributes that make that organization distinct. This noun-attribute relationship holds throughout the entire vocabulary.

Step 3: Grasp How Inheritance Works

Inheritance is the mechanism by which child Types automatically receive all the Properties defined for their parent Types. This is the most practically important aspect of the schema.org vocabulary, and the one most often misunderstood.

The Inheritance Chain

When LocalBusiness inherits from Organization, which inherits from Thing, every Property defined at the Thing level – including name, description, url, image, and sameAs – is automatically available to LocalBusiness. Every Property defined on Organization – such as address, telephone, email, and numberOfEmployees – is also available. And LocalBusiness adds its own Properties on top: openingHours, priceRange, and currenciesAccepted.

You do not need to redeclare inherited Properties. They are available simply by virtue of the Type you have chosen.

Why Inheritance Matters for Implementation

Inheritance determines which Properties are valid for a given Type. If you attempt to use a Property on a Type that does not define or inherit it, schema.org considers the markup invalid. Google may ignore the markup entirely or trigger a validation warning in its Rich Results Test. The distinction between required and recommended properties also follows inheritance: required Properties at the parent level remain required in all child Types.

A Practical Example

A dental practice marked up as Dentist inherits from Dentist → MedicalBusiness → LocalBusiness → Organization → Thing. This means the markup can legitimately include @type: "Dentist" while populating name (from Thing), address (from Organization), openingHours (from LocalBusiness), and medicalSpecialty (from MedicalBusiness). Each Property is valid because it exists somewhere in the inheritance chain.

Step 4: Navigate Schema.org to Find the Right Type

Schema.org's documentation at schema.org is the authoritative reference, but its layout can obscure what you need. These steps make navigation efficient.

Before opening schema.org, define in plain language what the page represents. A page about a software product that manages clinic appointments is a SoftwareApplication. A page describing a physician's profile is a Physician (a child of MedicalBusiness). A blog post explaining a medical condition is a MedicalWebPage. Starting with the entity prevents the common error of defaulting to WebPage or Article for content that warrants a more specific Type.

Step 4b: Use the Type Hierarchy Page

The full type hierarchy at schema.org/docs/full.html displays every Type in the vocabulary organized by inheritance. Scan this page to locate where your entity sits in the tree. Once you identify the Type, click through to its dedicated page.

Step 4c: Read the Type's Properties Table

Each Type page on schema.org displays three categories of Properties:

  1. Properties from the Type itself: Defined specifically for this Type
  2. Properties from parent Types: Inherited and fully valid for use
  3. Expected types for each Property: The Value Type a Property accepts

The "Expected type" column is critical. It tells you whether a Property expects a plain text string, a URL, a number, a date, or another schema.org Type. The author Property on Article, for example, expects a Person or Organization Type – not a plain text string. Article versus BlogPosting versus NewsArticle differences become clear once you read each Type's Properties table in this way.

Step 4d: Check for Pending or External Extensions

Schema.org marks some Types and Properties as "pending" – meaning they have been proposed but not yet fully ratified. Pending items appear on the type page with a pink background. Google may or may not support pending Types in its structured data features. For production implementations, prefer stable, fully ratified Types unless a specific use case requires a pending one.

Step 5: Match Properties to Your Content

Choosing the right Properties is as consequential as choosing the right Type. Over-declaring Properties with fabricated values creates misleading structured data; under-declaring them reduces the richness of what search engines and AI systems can extract.

Step 5a: Identify What Content You Actually Have

List the factual elements present on the page: a title, a price, a date, an author, a rating, an address, a phone number. Each element you can accurately populate becomes a candidate Property. Do not declare Properties for information the page does not contain.

Step 5b: Prioritize Required Properties First

Google's documentation specifies required Properties for each rich result type. Omitting a required Property disqualifies the page from that rich result entirely. Required Properties vary by rich result feature: a Product page needs name and offers to be eligible for product rich results; a FAQPage needs mainEntity with nested Question and acceptedAnswer elements. After covering required Properties, layer in recommended Properties that improve the richness of what gets surfaced.

Step 5c: Nest Types Within Properties

Many Properties accept another schema.org Type as their value, not just a plain string. The address Property on Organization expects a PostalAddress Type with its own Properties: streetAddress, addressLocality, addressRegion, postalCode, and addressCountry. Nesting correctly structured child Types within parent Properties is what produces machine-readable markup rather than loosely structured hints. Organization schema markup illustrates this nesting pattern in detail.

Step 5d: Confirm the Format Type for Each Value

Schema.org specifies expected value formats:

Value Format Example
Text Plain string: "name": "Acme Corp"
URL Full URL: "url": "https://example.com"
Date ISO 8601: "datePublished": "2024-03-15"
Number Integer or float: "ratingValue": 4.7
Boolean True/false: "isAccessibleForFree": true
Nested Type Object with its own @type: "author": {"@type": "Person", "name": "Jane Smith"}

Mismatching format types – for example, passing a plain string where a nested PostalAddress Type is expected – produces technically invalid markup that validators will flag.

Step 6: Write the JSON-LD Block

JSON-LD (JavaScript Object Notation for Linked Data) is the format Google recommends for structured data. Why Google recommends JSON-LD comes down to its separation from HTML content, making it easier to implement, update, and validate. The three implementation formats – JSON-LD, Microdata, and RDFa – differ in how they embed schema data, but JSON-LD's <script> tag approach keeps structured data cleanly separated from page markup.

A complete JSON-LD block for a SaaS product page follows this structure:

{
 "@context": "https://schema.org",
 "@type": "SoftwareApplication",
 "name": "AuthorityStack",
 "applicationCategory": "BusinessApplication",
 "operatingSystem": "Web",
 "description": "AI visibility platform for tracking brand citations across ChatGPT, Claude, Gemini, and Perplexity.",
 "offers": {
 "@type": "Offer",
 "price": "49.00",
 "priceCurrency": "USD"
 },
 "aggregateRating": {
 "@type": "AggregateRating",
 "ratingValue": "4.8",
 "reviewCount": "134"
 }
}

Every element maps back to a decision made in the earlier steps: the Type (SoftwareApplication) was chosen to match the entity; the Properties (name, applicationCategory, offers) were selected from those the Type inherits or defines; nested Types (Offer, AggregateRating) provide structured values where plain strings are insufficient. The schema markup for SaaS products covers this pattern in full.

Step 7: Validate and Publish

A syntactically complete JSON-LD block can still contain semantic errors – Properties assigned to the wrong Type, required fields missing, or value formats mismatched. Validation catches these before they reach production.

Step 7a: Run the Rich Results Test

Google's Rich Results Test at search.google.com/test/rich-results accepts a URL or code snippet and reports which rich results the markup qualifies for, which required Properties are missing, and which fields contain errors. Fix all errors before publishing; warnings indicate recommended improvements but do not disqualify a page.

Step 7b: Run the Schema Markup Validator

The Schema Markup Validator at validator.schema.org checks conformance against the schema.org specification itself, independent of Google's rich result requirements. A page may pass Google's test (for a narrower feature set) and still have spec-level errors that affect how AI systems and other search engines interpret the markup.

Step 7c: Check for Structured Data in Search Console

After publishing, Google Search Console's Enhancements reports surface any structured data issues detected during crawling. Errors in this report mean Google has found markup on live pages that it cannot process correctly. Validating and fixing structured data errors covers the full remediation workflow.

When you need to generate accurate markup quickly across many page types – particularly for complex cases like healthcare schema – the AI-powered schema markup generator at AuthorityStack.ai reads the full content of a page and selects the correct Type and Properties automatically, rather than pattern-matching on keywords the way rule-based tools do.

Step 8: Extend to Additional Page Types

A single implementation covering one page type establishes the pattern. Extending schema.org across a site requires applying the same Type-Property-inheritance logic to each distinct page category.

Common Extensions by Business Type

For ecommerce sites, Product and Offer markup applied at scale – with accurate pricing, availability, and aggregateRating data – drives product rich results and feeds AI shopping responses. Ecommerce schema implementation covers the full range of Types relevant to product catalogues.

For local and service businesses, LocalBusiness with correctly nested PostalAddress, openingHoursSpecification, and GeoCoordinates Properties supports local knowledge panels and location-based AI answers. Local business schema explains which Properties have the greatest impact on local discovery.

For healthcare and medical sites, the MedicalEntity branch provides highly specific Types – MedicalCondition, MedicalProcedure, Physician, Hospital, Drug – that communicate clinical accuracy to search engines. The healthcare schema markup guide details how these Types interact and which Properties are essential for clinical content to earn citations from AI systems answering health queries.

For SaaS and software companies, SoftwareApplication, WebApplication, and FAQPage Types applied to product, pricing, and support pages build the entity signals that AI systems use when recommending tools. FAQ schema implementation is particularly effective for SaaS because it directly targets the question-and-answer format that AI-generated responses favor.

How Schema Connects to AI Citation

Structured data is one of the five authority layers that determine whether AI systems cite a brand. Schema markup contributes to entity clarity – making your brand, its products, and its subject matter unambiguous to machine readers – which is a prerequisite for consistent AI citation. The relationship between schema markup and AI search citations is increasingly direct: pages with correctly implemented structured data give AI systems a machine-readable confidence signal that unstructured pages cannot provide.

FAQ

What Is the Difference Between a Type and a Property in Schema.org?

A Type defines what something is – for example, Product, Person, or Organization – while a Property describes a characteristic of that Type, such as name, price, or telephone. Types classify entities; Properties populate them with detail. Both are required for valid, functional structured data: a Type without Properties provides category context only, and Properties without a Type have no interpretive frame.

How Do I Know Which Type to Use for My Page?

Start by defining in plain language what the page represents – a product, a blog post, a medical professional, a local business – then locate that entity in the schema.org type hierarchy at schema.org/docs/full.html. Choose the most specific Type that accurately describes the entity. A dental practice page should use Dentist, not the more generic LocalBusiness, because the more specific Type inherits all parent Properties while adding its own clinically relevant ones.

What Does Inheritance Mean in Schema.org?

Inheritance means a child Type automatically has access to all Properties defined by its parent Types, without those Properties needing to be redeclared. A LocalBusiness inherits Properties from Organization and Thing, so Properties like name, url, address, and telephone are all valid on a LocalBusiness even though they are not defined on LocalBusiness itself. This matters practically because it determines which Properties are valid for any given Type without needing to consult each parent separately.

Can I Use Multiple Types on the Same Page?

Yes. Schema.org supports multiple @type declarations on a single entity when the entity genuinely belongs to more than one category – for example, a restaurant that is also a CafeOrCoffeeShop. JSON-LD handles this with an array: "@type": ["Restaurant", "CafeOrCoffeeShop"]. Each Type contributes its own set of valid Properties. Using multiple Types should reflect genuine attributes of the entity, not an attempt to qualify for additional rich results.

What Happens If I Use a Property That Does Not Belong to My Chosen Type?

Google's validators will flag it as an error, and the Property value will likely be ignored. Schema.org specifies for each Property which Types it applies to. If a Property is not defined on the Type you are using and is not inherited from a parent Type, the markup is technically non-conformant. In practice, search engines may tolerate minor mismatches, but validated, spec-conformant markup produces more reliable rich results and stronger AI citation signals.

How Do I Handle Properties That Expect a Nested Type Rather Than a Plain String?

Declare the nested Type as a JSON object with its own @type declaration inside the parent Property. For example, the address Property on Organization expects a PostalAddress Type, so it should be written as "address": {"@type": "PostalAddress", "streetAddress": "123 Main St", "addressLocality": "Austin", "addressRegion": "TX", "postalCode": "78701", "addressCountry": "US"}. Passing a plain string like "address": "123 Main St, Austin TX" is syntactically valid JSON but semantically non-conformant schema.

Where Can I Verify Which Properties Are Required Vs. Optional?

Google's structured data documentation at developers.google.com/search/docs/appearance/structured-data lists required and recommended Properties for each rich result feature. Schema.org itself does not distinguish required from optional – that distinction comes from the specific rich result type Google is evaluating. Required Properties at the Google level are a subset of everything the schema.org specification allows; meeting Google's requirements does not mean you have used all available Properties, only the minimum for eligibility.

Does Getting Schema Markup Right Actually Affect AI Citations?

Correctly implemented schema markup improves AI citation rates by making content machine-readable in a format AI systems can interpret with high confidence. Pages with accurate structured data provide an explicit entity signal – who created this, what it describes, and how it relates to other entities – that unstructured pages lack. The impact of schema markup on AI search citations shows that structured data is one of the clearest controllable signals for improving AI visibility.

What to Do Now

  1. Identify your highest-priority page types. Product pages, author profiles, service pages, and FAQ content are the most impactful starting points for most SaaS, agency, ecommerce, and local business sites.
  2. Map each page type to its correct schema.org Type using the full hierarchy at schema.org/docs/full.html, then list the Properties you can accurately populate from existing page content.
  3. Write or generate JSON-LD blocks for each page type. If you are starting from scratch or working across many page types simultaneously, the free schema generator at AuthorityStack.ai scans any URL and generates ready-to-paste JSON-LD markup automatically.
  4. Validate every block with Google's Rich Results Test and the Schema Markup Validator before publishing. Fix all errors; address warnings where the content supports it.
  5. Publish and monitor through Google Search Console's Enhancements reports. Treat structured data as a living layer of your site, not a one-time task – new page types, product updates, and content additions each require corresponding schema updates.

Structured data implemented correctly at the Type and Property level builds entity clarity that search engines and AI systems depend on when deciding which sources to cite. Generate JSON-LD Schema for your highest-priority pages today and establish the machine-readable foundation your AI visibility strategy requires.