Schema Markup Examples That Still Earn Rich Results in 2026

Copy a schema markup example off most guides today and there is a fair chance you are pasting in a rich result Google has retired. The JSON validates. The page passes every structured data test you throw at it. Nothing new appears in search, because the feature behind the markup no longer exists.

Google's list of supported structured data has shrunk, and a lot of the advice ranking for this topic has not caught up. What follows is what still renders, what quietly died, and how to pick the right markup for the page you are actually working on.

Two schema types worth deleting from your templates

HowTo markup no longer produces anything in Google. Google removed the How-to structured data documentation on 14 September 2023, noting the rich result is no longer shown in search results on both desktop and mobile devices. There is no penalty for leaving the markup on a page. There is also no return on it.

FAQ markup took a slower route to the same place. Google first restricted FAQ rich results to well-known, authoritative government and health websites in 2023. It then went further: FAQ rich results stopped appearing in Google Search on 7 May 2026, and Google has since removed the FAQ documentation. On a commercial site, a FAQPage block earns nothing in the results today.

This is worth stating plainly because several pages currently ranking for schema markup examples still describe HowTo as a desktop-only feature and FAQ as something government and health sites can win. Both descriptions are stale. When you audit a site and find FAQPage or HowTo blocks, file them as dead weight to strip out at the next template change, not as an optimisation to defend. The one thing not to do is keep shaping content around a FAQ block because you believe it earns a rich result.

What Google still renders, and for which pages

Google's search gallery documents roughly two dozen structured data types, covering everything from vacation rentals to math solvers. Most sites will only ever need five or six. These are the ones that carry real weight on a typical content or commerce site:

Type	Use it on	What it can produce
Article	Blog posts, news, editorial pages	Headline, publish date and image treatment in results and Top stories
Product	Individual product pages	Price, availability, shipping and review stars
Review snippet	Pages carrying genuine ratings	Star rating in the listing
Breadcrumb	Any page below the top level	A readable hierarchy in place of the raw URL
Local business	Location and service-area pages	Hours, address and contact details
Organization	Homepage, about page	Logo, name and entity details in knowledge panels
Video	Pages with an embedded video	Thumbnail, key moments and video carousels
Event	Dated events with a venue	Date, location and ticket listings
Job posting	Careers and vacancy pages	Inclusion in Google's job search experience

Note what is not on that list. There is no generic "boost my ranking" markup, and there never was. Structured data changes how a result is displayed and how confidently a search engine can parse what a page is about. It does not act as a ranking lever you can pull.

Matching the right schema markup example to your page type

The fastest way to get this wrong is to bolt every type you can think of onto every page. Pick by what the page genuinely is:

• A blog post or guide: Article, plus Breadcrumb. That is usually the whole job. Article wants a headline, an image, a datePublished and an author with a real name or organisation behind it.
• A product page: Product, with an offers block carrying price, priceCurrency and availability. Add aggregateRating only if the ratings are real, visible on the page and collected from actual customers.
• A location or service-area page: LocalBusiness with address, geo coordinates and openingHoursSpecification. Use the most specific subtype that fits, such as Restaurant or Dentist, rather than the generic parent.
• Your homepage: Organization and WebSite, tied together by a shared @id so search engines treat them as one entity rather than two unrelated objects.
• Any page nested in a section: Breadcrumb. It is the most skipped type on this list and one of the cheapest to add sitewide from a template.

An Article schema markup example for a blog post

This is the whole job for most guides. Note the dateModified: update it when you genuinely revise the page, not on every deploy.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Audit Internal Links",
  "image": "https://example.com/images/internal-links.webp",
  "datePublished": "2026-03-12T09:00:00+00:00",
  "dateModified": "2026-09-02T09:00:00+00:00",
  "author": {
    "@type": "Person",
    "name": "Jane Smith",
    "url": "https://example.com/authors/jane-smith"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

A Product schema markup example with an offer

The offers block is what makes a product page eligible for price and availability in results. Every value must match what the visitor sees on the page.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Runner 2 Running Shoe",
  "image": "https://example.com/images/trail-runner-2.webp",
  "description": "Lightweight trail running shoe with a grippy outsole.",
  "sku": "TR2-BLK-42",
  "brand": {
    "@type": "Brand",
    "name": "Example"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/shoes/trail-runner-2",
    "price": "119.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

A LocalBusiness schema markup example

Here the subtype is Dentist rather than the generic LocalBusiness. Swap in the most specific type that fits your business, and keep the address identical to your Google Business Profile.

{
  "@context": "https://schema.org",
  "@type": "Dentist",
  "name": "Example Family Dental",
  "url": "https://example.com/",
  "telephone": "+1-305-555-0100",
  "image": "https://example.com/images/clinic.webp",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Miami",
    "addressRegion": "FL",
    "postalCode": "33101",
    "addressCountry": "US"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 25.7743,
    "longitude": -80.1937
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": [
        "Monday",
        "Tuesday",
        "Wednesday",
        "Thursday",
        "Friday"
      ],
      "opens": "08:00",
      "closes": "17:00"
    }
  ]
}

A Breadcrumb schema markup example

The last crumb is the current page, so it carries no item URL.

{
  "@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": "How to Audit Internal Links"
    }
  ]
}

For the homepage pairing of Organization and WebSite, with a shared @id, there is a complete copy-and-paste version in our JSON-LD guide.

Every schema markup example on this page shares one rule: the markup has to describe content a visitor can actually see on the page. Marking up a price that does not appear, or a rating you invented, is the fastest route to a manual action against structured data. Google treats it as spam, and rightly so.

Which format should you write it in?

JSON-LD, effectively without exception. Google recommends it, and unlike Microdata or RDFa it lives in a single block instead of being threaded through your HTML attributes, which means a designer changing a template cannot silently break your markup. If you want the mechanics of how that block is constructed and where it belongs in the document, we covered it in what JSON-LD is and how search engines read it.

The practical benefit shows up during maintenance. A single JSON-LD block can be generated from the same template variables that render the visible page, so the markup and the content drift apart far less often than they do with inline approaches.

The property most people leave out

Required properties get attention because validators complain about them. Recommended properties get skipped, and they are usually what decides whether the rich result actually appears. Google can withhold a rich result from technically valid markup that is thin on detail.

A Product block with nothing but a name and a price is valid, and it will often render nothing. Add the image, the brand, the SKU, the availability and a genuine review count, and the same page becomes eligible for the treatment you wanted. The same pattern holds for Article, where a missing image or a vague author field quietly costs you the enhanced presentation.

Two types are worth setting up carefully once, because they anchor everything else: Organization schema establishes who publishes the site, and Breadcrumb schema tells search engines how a page sits inside your structure. Both are template-level jobs, done once, benefiting every page.

Does schema markup help you get cited by AI answer engines?

Not in the direct way most people hope, and it is worth being honest about that. There is no documented mechanism where adding a JSON-LD block causes ChatGPT or an AI Overview to quote you. Large language models are trained largely on rendered text, and structured data is not a citation lever you can pull.

What schema does do is remove ambiguity. It states, in machine-readable form, who published a page, when it was updated, what entity it concerns and how it relates to the rest of your site. Systems that ground their answers in live search results work from that parsed understanding. Clean entity markup will not manufacture a citation, but muddled or absent markup makes it harder for anything to work out what your page is and who stands behind it.

Treat it as hygiene rather than strategy. The content still has to answer the question better than the alternatives. Schema just makes sure the machine reading it knows what it is looking at. If AI visibility is the actual goal, the content and entity clarity do the heavy lifting, and markup supports them.

Check the markup before it ships, not after

Validation catches a narrow class of problems: syntax errors and missing required fields. It will happily pass markup that describes the wrong page, references an image that 404s, or duplicates an Organization block already injected by your CMS. Duplicate and conflicting blocks are among the most common issues on real sites, precisely because a theme and a plugin can each add one without knowing about the other.

A workable sequence before any template change goes live:

1. Validate the block in isolation to catch syntax and required-property errors.
2. Test the live URL, so you see the markup as it renders after JavaScript, not as it looks in your template file.
3. Check for duplicates. More than one Organization or Article block on a page sends conflicting signals.
4. Confirm every marked-up value appears in the visible content.
5. Re-check after the next theme or plugin update, which is when working markup usually breaks.

Step five is the one teams skip, and it is where most regressions originate. Markup is not a task you finish, it is a template property that needs the same regression checks as anything else you ship.

If you want to see what a page currently emits and where the gaps are, run the URL through the CrawlTide schema markup checker and start with whichever page type earns you the most traffic.