Schema Markup Examples

Use these schema markup examples to understand common JSON-LD patterns for organisations, local businesses, services, articles, FAQs, and breadcrumbs.

Intermediate10 min readUpdated 11 Apr 2026Bukhosi Moyo

Share this guide

0 shares

Many schema guides explain what structured data is but stop before showing how common implementations actually look on real SEO pages. That leaves teams with the right concept but no practical reference for service pages, articles, breadcrumb trails, or local business entities.

This page fills that gap. It is not a substitute for a full schema strategy, but it gives you usable JSON-LD patterns for the schema types most commonly deployed on marketing and content-led websites.

⚡ Quick Answer

Schema markup examples are useful because they show how JSON-LD is structured for specific page types, not just what each schema type means.
The most useful examples for many business websites are Organization, LocalBusiness or ProfessionalService, Service, Article, FAQPage, and BreadcrumbList.
Your markup should describe content that is genuinely present on the page and aligned with the real business entity.
JSON-LD should usually be kept clean, minimal, and valid instead of forcing every possible property into one block.
Good schema improves machine-readable understanding and can support rich-result eligibility, but it does not replace strong page content or technical quality.
Example code is only a starting point. Properties, URLs, and entity relationships still need to match the real site.

If you want the broader foundations behind these examples, start with Structured Data & Schema Markup.

When Schema Examples Are Most Useful

Examples are most useful when a team already knows the page type and needs a clean starting structure for implementation.

Typical use cases include:

adding business entity markup to the homepage
marking up a city or service page
improving blog or documentation article markup
validating breadcrumb markup across templates
checking whether FAQ markup matches visible content

This is also where examples help prevent a common technical SEO mistake: copying random schema blocks from generators without understanding which entity the page is actually describing.

Principles Before You Copy Any Example

Match the Visible Page

The structured data should reflect what users can actually see and verify on the page.

Match the Real Entity

The business name, URL, phone number, address, author, or service entity should map to the real thing, not a placeholder or SEO-edited variant.

Keep the Type Aligned to the Page

A service page should not be marked up as an Article only because there is text on it. An article should not be forced into LocalBusiness just to add extra properties.

Validate Before Publishing

Even small syntax issues can make valid-looking markup fail. Review the pattern in Google's Rich Results Test and the schema.org validator before rollout.

Example 1: Organization Schema

Use Organization on the homepage or other entity-defining pages when you want to describe the company itself.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Symaxx",
  "url": "https://symaxx.com",
  "logo": "https://symaxx.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/symaxx",
    "https://www.facebook.com/symaxx"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "contactType": "sales",
    "telephone": "+27-10-000-0000",
    "areaServed": "ZA"
  }
}

Use this when the page is primarily about the company, brand, or organisation entity rather than a specific local branch.

Example 2: Local Business or Professional Service Schema

Use LocalBusiness or a more specific subtype such as ProfessionalService when the page describes a real business serving a local market.

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Symaxx",
  "url": "https://symaxx.com/seo/pretoria",
  "telephone": "+27-10-000-0000",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Pretoria",
    "addressRegion": "Gauteng",
    "addressCountry": "ZA"
  },
  "areaServed": [
    {
      "@type": "City",
      "name": "Pretoria"
    }
  ]
}

This pattern fits local service pages better than a generic organisation block when the route is explicitly location-led.

Example 3: Service Schema

Use Service when the page is clearly about a specific service offering rather than the company as a whole.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Technical SEO Services",
  "serviceType": "Technical SEO",
  "provider": {
    "@type": "Organization",
    "name": "Symaxx",
    "url": "https://symaxx.com"
  },
  "areaServed": {
    "@type": "Country",
    "name": "South Africa"
  },
  "url": "https://symaxx.com/seo/technical-seo"
}

This is usually stronger when the page intent is service-led and the page is not pretending to be a product page.

Example 4: Article Schema

Use Article for blog posts, guides, or documentation pages where authorship and publishing dates matter.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup Examples",
  "description": "Practical JSON-LD patterns for common SEO page types.",
  "author": {
    "@type": "Person",
    "name": "Bukhosi Moyo"
  },
  "datePublished": "2026-04-11",
  "dateModified": "2026-04-11",
  "mainEntityOfPage": "https://symaxx.com/resources/seo/technical-seo/schema-markup-examples"
}

If your documentation or blog templates already output article-style metadata, this is often one of the easiest schema types to keep consistent.

Example 5: FAQPage Schema

Use FAQPage only when the page visibly contains the same questions and answers shown in the markup.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does schema markup improve rankings directly?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Schema markup does not act as a direct ranking boost on its own, but it can improve how search engines understand the page and support rich-result eligibility."
      }
    },
    {
      "@type": "Question",
      "name": "Should every page have FAQ schema?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Only use FAQPage when the page genuinely includes a visible FAQ section that deserves that markup."
      }
    }
  ]
}

This is one of the most commonly abused schema types. If the questions are hidden, duplicated, or added only for markup, the implementation is weak.

Example 6: BreadcrumbList Schema

Use BreadcrumbList when the page has a logical hierarchical position and your site already reflects that breadcrumb path.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Resources",
      "item": "https://symaxx.com/resources"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO",
      "item": "https://symaxx.com/resources/seo"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Technical SEO",
      "item": "https://symaxx.com/resources/seo/technical-seo"
    }
  ]
}

Breadcrumb markup is especially useful on documentation sites because the page hierarchy is already stable and machine-readable.

Which Schema Type Fits Which Page

Page type	Most common schema fit
Homepage	`Organization`
Local service page	`LocalBusiness` or `ProfessionalService`
Generic service page	`Service`
Blog post or docs article	`Article`
FAQ-heavy help page	`FAQPage`
Pages with clear hierarchy	`BreadcrumbList`

Use this as a first-pass mapping, not an absolute rule. Some templates legitimately combine types, but that should happen deliberately.

Common Implementation Mistakes

Marking Up Content That Is Not On the Page

If the page does not visibly support the claim, the schema should not either.

Using the Wrong Entity Type

Choosing a vague or mismatched schema type can make the markup harder to trust and maintain.

Stuffing Every Optional Property

More properties do not automatically mean better markup. A clean valid implementation is usually stronger than a bloated one full of weak fields.

Forgetting Template Consistency

Schema should be maintained at the template level where possible, especially for articles, breadcrumbs, and recurring service-page patterns.

Failing To Re-Test After Template Changes

Markup can break quietly when templates, CMS fields, or component props change. That makes ongoing validation part of technical SEO maintenance rather than a one-time task.

How To Use These Examples Safely

Use the examples as implementation references, then adjust them to the actual page and data model.

Check each draft against three questions:

Is this the right schema type for the page?
Does the markup describe visible and verifiable content?
Are the URLs, names, authors, and business details accurate?

If the answer to any of those is no, fix the model before rollout.

Key Takeaways

Schema markup examples are useful when they are tied to a real page type and real entity data.
The most practical patterns for many SEO-driven sites are Organization, LocalBusiness or ProfessionalService, Service, Article, FAQPage, and BreadcrumbList.
JSON-LD examples should be treated as starting structures, not plug-and-play SEO shortcuts.
Good schema supports machine-readable clarity and rich-result eligibility, but it cannot compensate for weak content or misleading page structure.
The safest schema strategy is accurate, minimal, validated, and aligned with the visible page.

Quick Schema Example Checklist

Correct schema type chosen for the page
JSON-LD matches visible page content
Entity details are accurate
Required properties are present
Markup validated before launch
Template output monitored after release

Tools & Resources (Coming Soon)

Schema Example Generator (Coming soon)
JSON-LD Validation Checklist (Coming soon)
Rich Result QA Worksheet (Coming soon)