Structured Data Fundamentals: JSON-LD, Microdata, and RDFa

Structured data tells search engines what your content means, not just what it says.

When a page mentions “Blue Ridge Bakery, 4.8 stars, Nashville,” humans understand that’s a highly-rated Nashville bakery. Search engines see text strings. Structured data bridges this gap by explicitly labeling entities and their relationships.

The payoff is visibility. Rich results, knowledge panels, and enhanced SERP features increasingly depend on structured data. A Nashville restaurant client saw their click-through rate jump 34% after implementing proper review and menu schema. The content didn’t change. The presentation in search results did.

This guide covers the three structured data formats, how to implement them correctly, and how to avoid the mistakes that prevent rich results from appearing.

What Structured Data Accomplishes

Search engines parse text reasonably well. They can extract that a page discusses recipes or products. Structured data eliminates ambiguity and adds information that plain text doesn’t convey.

Consider a product page. The text mentions a price, but is that the current price, original price, or competitor’s price? Is the product in stock? What currency? Structured data answers these questions explicitly.

Without Structured Data	With Structured Data
Search engine infers content type	Content type explicitly declared
Relationships guessed from context	Relationships explicitly defined
Attributes may be misidentified	Attributes precisely labeled
Rich results unlikely	Rich results possible (if eligible)
Knowledge graph contribution minimal	Knowledge graph signals strengthened

Structured data doesn’t guarantee rich results. Google decides what to display based on content quality, search intent, and their own testing. But without structured data, many rich result types are simply unavailable to your content.

Three Formats, One Vocabulary

Schema.org provides the vocabulary: standardized types (Person, Product, Article, Recipe) and properties (name, price, author, datePublished) that describe web content.

Three formats exist for embedding this vocabulary in web pages:

JSON-LD (JavaScript Object Notation for Linked Data):
The format Google recommends. It separates structured data from HTML content, making it easier to maintain and less likely to break when page templates change.

Microdata:
An older format that embeds structured data directly in HTML elements. Still supported but increasingly discouraged for new implementations.

RDFa (Resource Description Framework in Attributes):
Similar to Microdata in embedding approach. Used less frequently for SEO purposes.

For new implementations, use JSON-LD unless you have specific reasons not to. Google explicitly recommends it, and it’s substantially easier to implement and debug.

Format	Embedding Method	Google Preference	Maintenance Difficulty
JSON-LD	Script block in head or body	Recommended	Low
Microdata	HTML attributes on elements	Supported	Medium
RDFa	HTML attributes on elements	Supported	Medium

JSON-LD Implementation

JSON-LD structured data lives in a <script> tag, typically in the page’s <head> section.

Basic structure:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data Fundamentals",
  "author": {
    "@type": "Person",
    "name": "Author Name"
  },
  "datePublished": "2025-01-15",
  "publisher": {
    "@type": "Organization",
    "name": "Publisher Name",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}
</script>

Key syntax rules:

Every JSON-LD block needs @context pointing to schema.org and @type declaring what you’re describing. Properties follow schema.org documentation for that type.

Nested objects represent related entities. The author property above isn’t just a string; it’s a Person entity with its own properties.

Escaping requirements:

JSON has strict syntax. Property names and string values require double quotes. Special characters in strings need escaping. A single syntax error breaks the entire block.

// Wrong: unescaped quote breaks JSON
"description": "He said "hello" and left"

// Correct: escaped quotes
"description": "He said "hello" and left"

Multiple entities:

Pages often describe multiple things. Use an array to include multiple independent entities:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Article Title"
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [...]
  }
]
</script>

Schema.org Vocabulary Essentials

Schema.org defines hundreds of types. For SEO purposes, a smaller subset drives most value.

High-impact schema types:

Type	Use Case	Potential Rich Results
Article	Blog posts, news articles	Article carousel, headline display
Product	E-commerce product pages	Price, availability, reviews
LocalBusiness	Location-based businesses	Knowledge panel, local pack
Recipe	Cooking content	Recipe cards with images, time, ratings
FAQPage	FAQ sections	Expandable FAQ in search results
HowTo	Step-by-step instructions	Step display with images
BreadcrumbList	Navigation path	Enhanced breadcrumb display
Organization	Company information	Knowledge panel, logo
Person	Author, person pages	Knowledge panel contribution
Review	Reviews of products/services	Star ratings in results

Required versus recommended properties:

Each schema type has required properties (must include for validity) and recommended properties (enhance the markup but aren’t mandatory). Google’s documentation distinguishes these clearly.

For Article schema:

Required: headline, author, datePublished
Recommended: dateModified, image, publisher

Missing required properties means the markup is invalid. Missing recommended properties means you’re leaving potential value on the table.

Microdata Implementation

Microdata embeds structured data directly in HTML using specific attributes.

Core attributes:

itemscope: Declares an item
itemtype: Specifies the schema.org type URL
itemprop: Labels properties within the item

Example:

<article itemscope itemtype="https://schema.org/Article">
  <h1 itemprop="headline">Article Title</h1>
  <span itemprop="author" itemscope itemtype="https://schema.org/Person">
    <span itemprop="name">Author Name</span>
  </span>
  <time itemprop="datePublished" datetime="2025-01-15">January 15, 2025</time>
</article>

The advantage: structured data and visible content stay synchronized since they’re the same HTML. The disadvantage: HTML changes can inadvertently break structured data, and complex schema relationships become unwieldy.

For existing Microdata implementations that work, there’s no urgent need to migrate. For new implementations, JSON-LD is preferable.

Validation and Testing

Invalid structured data doesn’t help. It may actively hurt if it signals low quality or attempted manipulation.

Testing tools:

Google’s Rich Results Test (https://search.google.com/test/rich-results) validates structured data and shows whether content qualifies for specific rich result types. This should be your primary testing tool.

Schema.org’s validator (https://validator.schema.org) checks syntax validity against the full schema.org specification, including types Google doesn’t use for rich results.

What validation catches:

JSON syntax errors (missing commas, unescaped characters)
Missing required properties
Wrong property types (string where URL expected)
Invalid @type values
Properties not defined for the declared type

What validation doesn’t catch:

Mismatch between structured data and visible content
Spam or misleading markup
Properties with incorrect but syntactically valid values

A page claiming Product schema with price “$10” passes validation even if the visible price is $100. Google’s systems detect these mismatches, and they hurt rather than help.

Rich Results Connection

Structured data enables rich results but doesn’t guarantee them. Google decides what to show based on multiple factors.

Requirements for rich results:

Valid structured data for an eligible type
Content that meets Google’s quality guidelines
Content that matches the structured data claims
User query context where Google chooses to show rich results

Why eligible content sometimes doesn’t get rich results:

Google is testing and may not show rich results consistently
Query context may favor other result types
Competing pages may have stronger signals
Content quality may not meet Google’s threshold
Manual actions or penalties may suppress rich results

Monitor Search Console’s Enhancement reports for structured data issues. These reports show validation errors, detected structured data, and rich result impression data.

Common Schema Types in Detail

Article Schema:

For blog posts, news articles, and editorial content.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Full Article Title Here",
  "image": "https://example.com/image.jpg",
  "author": {
    "@type": "Person",
    "name": "Author Name",
    "url": "https://example.com/author-page"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Publisher Name",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2025-01-15T09:00:00-06:00",
  "dateModified": "2025-01-15T14:30:00-06:00"
}

LocalBusiness Schema:

For businesses with physical locations.

{
  "@context": "https://schema.org",
  "@type": "Restaurant",
  "name": "Business Name",
  "image": "https://example.com/photo.jpg",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Nashville",
    "addressRegion": "TN",
    "postalCode": "37203",
    "addressCountry": "US"
  },
  "telephone": "+1-615-555-0123",
  "priceRange": "$$",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "11:00",
      "closes": "22:00"
    }
  ]
}

Use specific subtypes (Restaurant, Dentist, RealEstateAgent) rather than generic LocalBusiness when applicable. More specific types enable more relevant rich result features.

FAQPage Schema:

For pages with question and answer content.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the question?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The answer to the question."
      }
    }
  ]
}

FAQ schema requirements have tightened. The questions and answers must be visible on the page (not just in structured data), and FAQ rich results now appear less frequently than they did previously.

Implementation Best Practices

Match structured data to visible content:

Every claim in structured data should correspond to visible page content. If your Article schema says the author is Jane Smith, the page should visibly credit Jane Smith as the author.

Don’t markup hidden content:

Structured data describing content users can’t see violates Google’s guidelines. This includes content behind tabs, accordions, or login walls (with limited exceptions for paywalled content using specific schemas).

Use specific types over generic:

Restaurant is more useful than LocalBusiness. NewsArticle can enable features Article doesn’t. When schema.org offers a more specific type that fits your content, use it.

Keep structured data current:

Outdated structured data (old prices, changed hours, former authors) creates mismatches that hurt credibility. Dynamic content should have dynamically generated structured data.

One primary entity per page:

Pages can have multiple schema objects, but the primary content should have one clear primary schema. A product page’s main schema is Product. Supporting schemas (breadcrumbs, organization) supplement rather than compete with it.

What Not to Do

Spammy schema:

Markup that doesn’t represent actual page content. Claiming review stars for pages without reviews. Marking up content that exists only in structured data. These practices risk manual penalties.

Over-markup:

Not everything needs structured data. Marking up every paragraph as Article, every image as ImageObject, and every link as WebPage adds complexity without value. Focus on schemas that enable specific features.

Deprecated approaches:

Avoid outdated patterns that some older guides still recommend. @id circular references, entity chaining without purpose, and complex graph structures rarely help and often confuse validation.

Testing only in development:

Structured data can break when content templates change. Implement monitoring that alerts you to validation failures in production, not just pre-launch testing.

Monitoring and Maintenance

Search Console provides the primary feedback loop for structured data performance.

Key reports:

Enhancement reports for specific rich result types
Page indexing reports for markup validation issues
Performance reports filtered by search appearance type

Review these monthly at minimum. Validation errors that appear after template changes should be addressed promptly.

For sites with dynamic structured data (e-commerce, listings), automated testing that verifies structured data validity across sample pages catches issues before Google does.

The goal isn’t structured data everywhere. It’s valid, accurate structured data on content that benefits from rich result eligibility.

Sources

Google Search Central: Structured data guidelines

https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data

Schema.org documentation

https://schema.org/

Google Rich Results Test

https://search.google.com/test/rich-results

Google Search Central: Article structured data

https://developers.google.com/search/docs/appearance/structured-data/article

Note: Rich result availability changes as Google tests new formats and retires others. Validate current documentation before implementing schema types for specific rich result features.