Lecture 14: Structured Data and Rich Results

Short answer: Structured data is code added to web pages in JSON-LD format that communicates to search engines exactly what type of content exists on the page and the specific attributes of that content. Google uses this information to display rich results (enhanced visual elements in search results), which dramatically improve click-through rates. This lecture covers every major schema type, correct JSON-LD implementation, validation, and the most common implementation errors.

What You'll Learn in This Lecture

• What Structured Data Is and How It Works
• Why JSON-LD Is the Recommended Structured Data Format
• How to Implement Article and BlogPosting Schema
• How to Implement FAQPage Schema for Rich Results
• How to Implement HowTo Schema for Step-by-Step Content
• How to Implement Product Schema for E-Commerce
• How to Implement LocalBusiness Schema for Local SEO
• How to Implement Review and AggregateRating Schema
• How to Implement BreadcrumbList Schema
• How to Validate Structured Data and Fix Common Errors
• How to Monitor Rich Results Performance in Google Search Console

What Structured Data Is and How It Works

Structured data is additional code added to web pages that provides machine-readable information about the page content in a standardized format. Where the visible HTML tells a human visitor "this page is about chocolate chip cookies and here is a recipe," structured data tells a search engine's parsing system: "this is a Recipe entity, the recipe name is Chocolate Chip Cookies, the total time is 45 minutes, the calorie count is 320 per serving, the average user rating is 4.8 from 2,400 reviews, and the ingredients are [list]." The structured data communicates these attributes in a format that can be reliably extracted, verified against the visible page content, and used to generate enhanced search result displays.

Structured data is defined by a vocabulary standard called Schema.org, developed collaboratively by Google, Bing, Yahoo, and Yandex. Schema.org defines hundreds of entity types (Product, Recipe, Article, LocalBusiness, Person, Event, JobPosting, and many more) and the specific properties each entity type can have. Using Schema.org vocabulary ensures that the structured data is interpretable by all major search engines using a single standard.

The relationship between structured data and rich results: structured data is the input; rich results are the output that appears in search if Google validates the structured data, confirms it matches the visible page content, and determines that showing a rich result is appropriate for the query. Not all structured data types produce visible rich results. Some schema types (like Organization and Person) improve how Google understands an entity without producing a visible enhancement in standard search results. But schema types like FAQPage, HowTo, Recipe, Product, and Review produce visible rich result enhancements that directly improve click-through rate.

Example: A cooking website in Austin, Texas publishes 400 recipes. After adding Recipe schema to all 400 pages (covering recipe name, author, prep time, cook time, total time, serving size, calorie count, ingredients, instructions, and aggregate rating), Google begins displaying rich recipe results for 280 of the 400 pages. These rich results show a photo, the total time, the calorie count, and the star rating directly in the search result, before the user clicks. The pages with rich results see click-through rates 38% higher than pages at the same average position without rich results. Monthly organic traffic to recipe pages increases 34% year-over-year after schema implementation, driven entirely by the improved click-through rate on unchanged rankings.

Why JSON-LD Is the Recommended Structured Data Format

Structured data can be implemented in 3 formats: JSON-LD, Microdata, and RDFa. Google recommends JSON-LD as the preferred format because of several practical advantages over Microdata and RDFa.

JSON-LD (JavaScript Object Notation for Linked Data) is added as a separate script block in the HTML head or body, entirely independent of the visible page content. This means: adding, editing, or removing structured data does not require modifying the visible HTML of the page; structured data can be updated in one script block without touching the rest of the template; and the same JSON-LD block can be injected dynamically by JavaScript or server-side code. For CMS platforms, JSON-LD can be injected via a plugin or template without touching page content HTML.

Microdata and RDFa require adding attributes directly to the visible HTML elements that contain the structured data content. This tightly couples the structured data to the page's HTML structure, making it harder to maintain and more fragile to template changes. JSON-LD's separation of structured data from visible content makes it significantly easier to implement, maintain, and validate.

The basic format of a JSON-LD block: it is placed inside a <script type="application/ld+json"> tag. The content is a valid JSON object with an @context property set to "https://schema.org" and a @type property set to the Schema.org type (Article, Product, FAQPage, etc.). All other properties of the type are then listed as key-value pairs within the same JSON object.

Example: A home improvement website in Dallas, Texas implements structured data for their how-to guides. Using Microdata would require adding itemscope, itemtype, and itemprop attributes to every HTML element that contains guide content. With JSON-LD, they add a single script block at the top of each guide page that contains all the structured data. The JSON-LD block for their "How to Install a Ceiling Fan" guide specifies the HowTo type, the name, the estimated time, the required tools, and all 12 steps. When the guide template is redesigned, the visible HTML changes completely but the JSON-LD block in the head is unaffected and continues to provide valid structured data without any update. The entire schema implementation persists across the redesign because it is independent of the visible HTML structure.

How to Implement Article and BlogPosting Schema

Article schema (or the more specific BlogPosting subtype for blog content) tells search engines that a page is a written article with a specific author, publication date, and publisher. It does not reliably produce rich result enhancements in standard search results, but it is valuable for several other reasons: it clearly establishes authorship for E-E-A-T purposes, provides recency signals through the datePublished and dateModified properties, and is a prerequisite for other features like Google's "Top Stories" carousel for news publishers.

A complete BlogPosting schema implementation includes: @type set to BlogPosting, headline (the article title), image (a URL to the article's featured image, must meet minimum dimensions: 1200x630px recommended), author (a Person or Organization object with name and optional url properties), publisher (an Organization object with name and logo URL), datePublished (ISO 8601 format: YYYY-MM-DD), dateModified (updated whenever the article is significantly changed), description (a brief summary of the article content, matching the meta description), and url (the canonical URL of the article).

The most important property for practical SEO impact is dateModified. When an article is refreshed with updated information, updating the dateModified value signals to Google that the content is current, which supports recency signals for time-sensitive queries. Always update dateModified when making meaningful content updates, not just minor corrections.

Example: A technology media publication in San Francisco, California implements Article schema across all 2,800 articles. Each article's JSON-LD block is dynamically generated from CMS fields: the headline pulls from the article title, the author pulls from the CMS author profile, datePublished and dateModified pull from the CMS timestamp fields (auto-updated on every save), and the image URL pulls from the featured image field. When the site's editorial team refreshes 300 articles with 2026 data in January, the dateModified is automatically updated to the refresh date on each article. In Google's indexing systems, 180 of the 300 refreshed articles are recrawled within 48 hours (an unusually fast recrawl speed the site attributes to the clear dateModified update signal in the structured data). Several time-sensitive topics where their articles had drifted to positions 8-12 recover to positions 2-5 within 2 weeks of the refreshed dateModified dates being processed.

How to Implement FAQPage Schema for Rich Results

FAQPage schema is one of the highest-impact structured data types for click-through rate improvement. When implemented correctly on a page that contains an FAQ section, Google can display up to 3 of the FAQ questions as expandable accordion items directly in the search result. This creates a result that occupies 2 to 4 times more vertical space than a standard result, dramatically increasing visual prominence and click-through rate.

FAQPage schema requirements: the page must contain a visible FAQ section with actual questions and answers on the page. The schema must accurately reflect the visible content (Google cross-references the schema against the visible page content and rejects implementations where they do not match). Each Q&A pair is represented as a Question object with an acceptedAnswer property containing the answer text. The answer text in the schema must exactly match the visible answer text on the page.

The JSON-LD implementation for FAQPage schema: @type is FAQPage, the mainEntity property is an array of Question objects. Each Question object has @type set to Question, a name property containing the question text, and an acceptedAnswer property containing an Answer object with @type set to Answer and text containing the answer. The questions and answers must be verbatim matches to the visible page content.

Important caveat for FAQPage rich results: Google announced in 2023 that FAQPage rich results would be limited to "highly authoritative government and health websites" for most queries, with other sites seeing reduced frequency of FAQPage rich results. As of 2026, FAQPage rich results still appear for many sites on informational queries, but the frequency has reduced compared to pre-2023. Despite this reduction, FAQPage schema is still worth implementing because: it still appears for many queries, it improves how Google understands page content even when no rich result is shown, and it costs nothing to implement once the FAQ section exists on the page.

Example: A tax preparation service in Chicago, Illinois adds FAQPage schema to their service pages where FAQ sections covering common tax questions are present. The service page for "small business tax preparation" has an FAQ section with 8 questions. After adding FAQPage schema matching each visible Q&A pair: Google shows a rich result with 3 expandable FAQ items beneath the standard title and description. The rich result takes up 280px of vertical space on a mobile screen compared to 80px for a standard result. Click-through rate on the page increases from 3.2% to 7.8% (a 144% improvement). The expanded SERP footprint also pushes competing results lower on the page, further increasing their share of organic clicks for this service page's keywords.

How to Implement HowTo Schema for Step-by-Step Content

HowTo schema is used for articles that explain how to complete a specific task in a series of steps. When valid HowTo schema is present, Google can display the steps as a numbered list in the search result (similar to featured snippet formatting), or show a carousel of steps with images in some contexts. The key requirement: the content must be an actual how-to guide with clear, sequential steps that a reader follows to complete a task.

HowTo schema properties: @type set to HowTo, name (the guide title), description (brief summary), totalTime (ISO 8601 duration format: PT30M for 30 minutes, PT1H for 1 hour), supply (an array of HowToSupply objects for physical items needed), tool (an array of HowToTool objects for tools required), and step (an array of HowToStep objects, each with name and text properties). Each HowToStep's text must match the corresponding step visible on the page.

Not all content types qualify for HowTo schema. HowTo is appropriate for: home improvement guides, cooking and recipe instructions (though Recipe schema is more specific and appropriate for food), software tutorials, craft project instructions, and maintenance procedures. HowTo is not appropriate for opinion pieces, listicles, informational articles, or any content that is not organized as sequential steps to complete a specific task. Using HowTo schema on inappropriate content types triggers Google's structured data spam policies.

Example: A home improvement retailer in Denver, Colorado publishes step-by-step project guides for their DIY customer base. Their guide "How to Install Laminate Flooring" has 11 clearly numbered steps. After adding HowTo schema with all 11 steps, Google begins showing a rich result for this guide that displays steps 1 through 3 with the step titles visible in the search result, followed by a "More steps" link that expands to show all 11 steps. This rich result appears when someone searches "how to install laminate flooring" from a mobile device. The guide's click-through rate increases from 4.1% to 11.3% in position 4 because the rich result shows enough of the guide's content to establish that it covers exactly the task the searcher wants to accomplish. Monthly organic visits to project guide pages: up 67% after HowTo schema is implemented across all 85 project guides on the site.

How to Implement Product Schema for E-Commerce

Product schema enables e-commerce product pages to show rich results that include product name, image, price, availability, and star ratings directly in search results. For e-commerce sites, Product schema is among the highest-impact structured data implementations available, as product rich results appear directly in standard Google search results and give products a visual advantage over competitors without product schema.

Required Product schema properties for rich results eligibility: @type set to Product, name (the product name), image (URL of product image, minimum 50x50px, maximum quality image available), offers (an Offer object containing price, priceCurrency, availability, and url), and aggregateRating (an AggregateRating object with ratingValue and reviewCount if reviews exist on the page). The availability property uses Schema.org values: "InStock," "OutOfStock," or "PreOrder."

Merchant Center integration: Product schema on product pages can be combined with Google Merchant Center product feeds. When product pages have valid Product schema and the domain is verified in Merchant Center, Google can pull product data directly from the structured data on the pages rather than requiring a separate feed upload for some products. For large catalogs that are updated frequently, maintaining accurate Product schema (especially price and availability) on every product page is critical: incorrect schema data that contradicts the actual page content causes Google to suspend rich results for the entire domain.

Example: A sporting goods retailer in Seattle, Washington implements Product schema on all 8,000 product pages. Each product page dynamically generates JSON-LD pulling data from the product database: name, price (updated in real-time), currency, availability (InStock/OutOfStock based on inventory), and the page's average user rating with review count. For products that are on sale, the offers object includes both price (sale price) and highPrice (original price), which enables Google to show the discount badge in rich results. After implementation, 6,400 of the 8,000 products qualify for Google Shopping rich results (showing product image, price, and rating in organic search results). Average CTR for product pages that gain rich results: increases from 2.8% to 5.1% at the same average position. Annual revenue attributed to organic product page traffic: up 43% in the 12 months following schema implementation.

How to Implement LocalBusiness Schema for Local SEO

LocalBusiness schema explicitly identifies a web page as representing a physical local business with a specific address, phone number, hours of operation, and service area. For local businesses, this schema supports Google's understanding of the business entity (linking the website to the Google Business Profile entity) and can influence local search result formatting.

LocalBusiness schema core properties: @type set to LocalBusiness (or a more specific subtype: Restaurant, Dentist, LegalService, Plumber, etc. -- the most specific applicable subtype from Schema.org should be used), name (business name, exactly matching the Google Business Profile name), address (PostalAddress object with streetAddress, addressLocality, addressRegion, postalCode, addressCountry), telephone, url, openingHoursSpecification (specifying days and hours), geo (GeoCoordinates with latitude and longitude), and sameAs (array of URLs to the business's profiles on authoritative directories: Google Business Profile URL, Yelp, Better Business Bureau, etc.).

For businesses with multiple locations, each location page should have its own LocalBusiness schema with that location's specific address, phone, and hours. A single LocalBusiness schema on the homepage trying to represent multiple locations is not appropriate and may cause confusion between the locations in Google's entity understanding.

Example: A dental practice chain in Houston, Texas with 6 locations adds LocalBusiness (Dentist subtype) schema to each location page. Each page's JSON-LD specifies the exact location address, local phone number, hours (which differ by location), and a sameAs link to the specific Google Business Profile URL for that location. For the flagship location, additional schema properties include: medicalSpecialty (general dentistry, cosmetic dentistry), paymentAccepted (insurance providers accepted), and priceRange ($ for the Schema.org price range indicator). After implementation, Google's understanding of each location as a distinct Dentist entity improves: the local Knowledge Panels for each location become more complete, and the association between the website location pages and their respective Google Business Profiles strengthens, contributing to improved local pack ranking stability across all 6 locations.

How to Implement Review and AggregateRating Schema

Review and AggregateRating schema displays star ratings in search results for eligible pages, providing one of the most powerful visual differentiation signals available. A 4.7/5 star rating displayed in a search result is immediately visible and builds trust before the user clicks. Pages with star ratings consistently achieve higher click-through rates than pages at the same position without ratings.

AggregateRating schema (for displaying an overall rating from multiple reviews) requires: @type set to AggregateRating (used as a property within a Product, LocalBusiness, Recipe, or other type), ratingValue (the numeric average rating, e.g., 4.7), bestRating (the maximum rating scale, typically 5), worstRating (the minimum, typically 1), and reviewCount (the number of reviews contributing to the average). The reviews represented by the AggregateRating must be real user reviews visible on the page or linked from the page -- Google does not permit aggregating ratings from external platforms in AggregateRating schema unless the reviews themselves are present on the page.

Individual Review schema (for a single user review on a page) requires: @type set to Review, author (Person object with name), reviewRating (Rating object with ratingValue), and reviewBody (the text of the review). Individual Review schema is used on pages that display specific user reviews (product detail pages, service review pages) rather than just an aggregate rating.

Critical compliance requirement: Google's structured data spam policy strictly prohibits using AggregateRating schema on pages where no actual user reviews are present on the page. Self-written ratings, staff ratings presented as customer ratings, or ratings pulled from external platforms not displayed on the page all violate Google's policies and will result in the rich result being suppressed or a manual action against the site. Only implement AggregateRating schema where genuine user reviews are visible on the page itself.

Example: An e-learning platform in Boston, Massachusetts has course pages with real student review sections. Each course page has between 40 and 800 verified student reviews with star ratings. After implementing AggregateRating schema on all 120 course pages (pulling average rating and review count dynamically from the review database), 98 of the 120 course pages begin showing star rating rich results in Google. For the "Python for Data Science" course page (4.9 stars, 2,840 reviews), the rich result shows "4.9 star (2,840 reviews)" below the title in search results. Click-through rate on this course page increases from 5.2% to 14.1% at the same position. The trust signal of showing 2,840 verified student reviews with a near-perfect rating before the user even visits the page dramatically reduces the perceived risk of clicking and increases commitment.

How to Validate Structured Data and Fix Common Errors

Structured data must be valid (syntactically correct JSON, using Schema.org vocabulary correctly, and matching visible page content) to be eligible for rich results. Implementing invalid structured data is worse than no structured data in some cases, because Google may downgrade the page's structured data quality signals if invalid schema is consistently present.

The primary validation tool is Google's Rich Results Test (search.google.com/test/rich-results), which tests a URL or code snippet and shows: which rich result types are detected and eligible, which schema properties are present and valid, and which properties are missing or invalid (with specific error messages). The Rich Results Test is the only validation tool that accurately reflects what Google will use for rich results -- third-party schema validators may show syntactically valid schema that Google's system still rejects due to policy or content-matching requirements.

The Schema.org Validator (validator.schema.org) is a complementary tool that validates the JSON-LD structure and property types but does not validate against Google's specific rich results requirements. Use the Rich Results Test as the primary validation tool and the Schema.org Validator for debugging JSON syntax errors.

Common structured data errors: missing required properties (FAQPage without mainEntity, Product without offers), incorrect data types (a number provided where a URL is expected), mismatched schema content (schema says rating is 4.8 but no rating is visible on the page), invalid JSON syntax (missing commas, unclosed brackets, quote characters from other encodings), and using deprecated or unsupported properties (Schema.org vocabulary updates periodically and some properties are deprecated).

Example: An online furniture store in Los Angeles, California implements Product schema across all 3,200 product pages using a template. Running the Rich Results Test on 10 sample pages reveals 3 systematic errors: (1) The "availability" property is being set to "In Stock" as plain text, when it should be a URL: "https://schema.org/InStock". (2) The "priceCurrency" property is using "USD" correctly but the "price" property is including a "$" currency symbol in the numeric value ("$299.99" instead of "299.99" as a number). (3) The "image" property is using a relative URL (/images/product/chair.jpg) instead of an absolute URL (https://domain.com/images/product/chair.jpg). All 3 errors are present in the shared template, meaning all 3,200 product pages have the same validation failures. After fixing the template to use the Schema.org URL for availability, strip the currency symbol from the price value, and use absolute image URLs, re-running the Rich Results Test shows all 3 errors resolved. Google processes the corrected schema within 2 weeks and begins showing product rich results (price and rating visible in search results) for all 3,200 product pages.

How to Monitor Rich Results Performance in Google Search Console

Google Search Console provides a dedicated "Rich Results Status" section (accessible under the Enhancements menu or via the Search Appearance section) that shows the indexing status and performance of each rich result type present on the site. For each schema type (FAQPage, HowTo, Product, etc.), Google shows: valid pages (pages where the schema is correct and rich results are eligible), pages with warnings (valid schema but missing recommended properties), and pages with errors (invalid schema that disqualifies the page from rich results).

Monitoring rich results performance: check the Rich Results Status for each schema type monthly. Any increase in "Error" count indicates a template or implementation change that has broken structured data for affected pages. Investigate and fix errors promptly, as pages with invalid schema lose rich result eligibility immediately. For Product schema, also monitor the Merchant Center performance if applicable, as Merchant Center has additional data quality requirements beyond the basic schema validation.

Measuring the business impact of rich results: use Google Search Console's Performance report to compare click-through rate for pages with rich results vs. without. Filter by search appearance type (Rich Result) to see the impressions and clicks generated specifically through rich result formats. This data directly shows the incremental click-through rate contribution from structured data implementation.

Example: A recipe website in New York, New York monitors their Recipe rich results in GSC monthly. In March, the "Valid pages" count drops from 680 to 420 and the "Error" count rises from 12 to 270. Investigating the errors: they all report "Invalid value in field 'cookTime'" -- the development team deployed a CMS update that changed the cook time format from the ISO 8601 duration format (PT30M) to a plain text format ("30 minutes"), which is invalid in Recipe schema. The errors are flagged in the same week as the deployment. After reverting the cook time format back to ISO 8601 in the CMS template and redeploying, the errors clear within 10 days. Because they caught the issue within the same month, the rich result suppression was brief (2.5 weeks), and organic traffic impact was limited. Without monthly monitoring, the same error might have persisted for months before being discovered.

Common Mistakes to Avoid

• Using schema types on page content that does not match the schema type (implementing HowTo schema on a listicle article, or FAQPage schema on a page with no visible Q&A content).
• Using relative URLs in schema properties that require absolute URLs (image, url, sameAs), causing validation errors that disqualify the page from rich results.
• Implementing AggregateRating schema with ratings that are not from real user reviews visible on the page, violating Google's structured data spam policies.
• Using Microdata or RDFa in the page HTML instead of JSON-LD, making structured data harder to maintain and more fragile to template changes.
• Validating only with the Schema.org validator (which validates JSON syntax) instead of Google's Rich Results Test (which validates against Google's rich results eligibility requirements).
• Never checking the Rich Results Status in GSC after CMS updates or template changes, allowing structured data errors to silently suppress rich results for weeks or months.

Action Checklist

• Identify all page types on your site that qualify for rich results schema (articles, FAQs, how-to guides, products, local business pages, reviews).
• Implement the appropriate schema type in JSON-LD format for each eligible page type.
• Validate all schema implementations using Google's Rich Results Test before publishing.
• Check Google Search Console's Rich Results Status for all existing schema types and resolve any errors or warnings.
• For Product schema on e-commerce sites, confirm that price, availability, and rating data is being populated dynamically from the product database rather than hardcoded in templates.
• Set a monthly reminder to check the Rich Results Status in GSC for any new errors introduced by recent CMS or template changes.

Practice Task

Identify the top 3 schema types most applicable to your site and complete this implementation planning table.

Schema Type	Pages Applicable	Required Properties	Data Source	Implementation Method	Rich Results Test Status
e.g., FAQPage	e.g., All service pages with FAQ sections	mainEntity, Question, acceptedAnswer	CMS FAQ fields	Plugin / Hardcoded / Dynamic template	Valid / Errors found
e.g., Article	e.g., All blog posts	headline, author, datePublished, image	CMS post fields	Plugin / Hardcoded / Dynamic template	Valid / Errors found
e.g., LocalBusiness	e.g., Contact and location pages	name, address, telephone, openingHours	Manually entered	Plugin / Hardcoded / Dynamic template	Valid / Errors found

Related Lessons Across SEO, AEO, GEO, SEM, and PPC

Use these connected lessons to move through organic search, answer engines, generative AI visibility, paid search, and PPC without losing the bigger strategy.

• Lecture 1: SEO Fundamentals for Beginners (SEO) - return to the course foundation when you need the big picture.
• Lecture - 5: FAQ Schema and Structured Answer Markup (AEO) - make answer content easier to understand with FAQ markup.
• Lecture - 8: Structured Data and Schema for Generative Engine Visibility (GEO) - extend schema signals into generative search.
• Lecture - 7: How AI Chatbots (ChatGPT, Gemini, Perplexity) Answer Questions (AEO) - understand how answer systems choose sources.
• Lecture - 1: What Is AEO? How Answer Engines Are Different From Search Engines (AEO) - see how answer engines build on SEO foundations.

Course Links

• Back to Lecture 13: Speed, Mobile, Security, Core Web Vitals
• Continue to Lecture 15: Link Building and Authority
• Run a Free SEO Audit on Your Site

Trusted References

For structured data documentation, see Google's Structured Data Introduction. To validate schema, use Google's Rich Results Test. For the full Schema.org vocabulary reference, see Schema.org Full Hierarchy.

FAQs

Can You Add Multiple Schema Types to a Single Page?

Yes. A page can have multiple JSON-LD blocks in the head, each defining a different schema type. A local business landing page might have LocalBusiness schema, FAQPage schema (for an FAQ section), and BreadcrumbList schema simultaneously. All 3 are valid because they describe different aspects of the same page. Alternatively, multiple schema types can be combined in a single JSON-LD block using an array: the @type property can accept an array of type strings when the entity belongs to multiple types. For example, a restaurant's homepage might use "@type": ["Restaurant", "LocalBusiness"] to apply properties from both types.

How Long Does It Take for Rich Results to Appear After Adding Schema?

After implementing valid structured data, Google needs to recrawl the page, validate the schema, and determine whether to display rich results for that page's content. This typically takes 1 to 4 weeks. Pages that are crawled frequently (because they have high link equity or are regularly updated) will be processed faster. To request faster recrawling after adding schema, use the URL Inspection tool in Google Search Console and click "Request Indexing" for the specific pages with new schema implementation.

Does Schema Markup Directly Improve Rankings?

Schema markup does not directly improve rankings for most schema types. It is not a ranking signal in the traditional sense (adding Product schema to a page does not cause it to rank higher). The ranking benefit from schema comes indirectly through improved click-through rates (if pages with rich results get more clicks from the same position, Google may interpret higher CTR as a relevance signal) and through clearer entity understanding (schema that helps Google better understand what a page is about may help it rank for more relevant queries). The primary, direct benefit of schema is rich result eligibility and the click-through rate improvement that comes from richer search results.