Configure

Pick a schema.org type and fill in the fields. Required fields are marked with *.

Schema type

Article

Headline*

0/110

Headline is required for valid Article schema.

Description

Image URL

Date Published*

Required field.

Date Modified

Author

Author Name*

Author name is required.

Author URL

Publisher

Publisher Name

Publisher Logo URL

Page

Main Entity of Page (URL)

Output

Copy into a script[type=application/ld+json] tag in your page head.

schema.jsonld

{
  "@context": "https://schema.org",
  "@type": "Article"
}

Test in Google Rich Results

Your robots.txt is ready - but it's one of 99+ SEO signals.

Run a free audit →

What is structured data and why does it matter?

Structured data is a layer of metadata you add to a web page that describes its content in a machine-readable format. The page body is what humans see; structured data is what search engines, voice assistants, and content aggregators read to understand what the page is about. A blog post becomes a clearly identified Article with an author, publication date, and headline. A product page becomes a Product with price, availability, and reviews. A business location becomes a LocalBusiness with address, hours, and phone number. The vocabulary that defines all these types is Schema.org, a collaborative project launched in 2011 by Google, Microsoft, Yahoo, and Yandex.

The reason structured data matters is rich results. When a page has valid structured data and Google decides the query and content quality justify it, the SERP shows enhanced features alongside or instead of the regular snippet. Star ratings appear under product results. FAQ accordions appear under articles. Breadcrumb trails replace the URL line. Recipe cards show cook time and calorie count. Event listings show date and location. Each of these enhancements occupies more vertical space, visually distinguishes the result, and lifts click-through rate substantially. A position-three result with a rich snippet routinely beats a position-one result with a plain blue link.

Beyond the SERP, structured data feeds the broader semantic web. Voice assistants like Google Assistant and Alexa read schema to answer questions. The Google Knowledge Graph uses schema to build entity profiles. Aggregators like Google Shopping, Google Travel, and Google Jobs rely on structured data to populate their verticals. Without schema, your content is text that has to be inferred; with schema, it is data that can be quoted directly.

Google's processing hierarchy matters when you have a choice of formats. The team has stated since 2015 that JSON-LD is the preferred format, and a 2020 confirmation made clear that JSON-LD is parsed faster and more reliably than inline alternatives. The order of preference is JSON-LD first, Microdata second, RDFa third. Mixing formats on the same page produces inconsistent results — Google may pick one, may merge them, or may flag the conflict — so commit to JSON-LD and avoid mixing. JSON-LD also has the practical advantage of living in a <script type="application/ld+json"> tag in the head, separate from the rendered HTML, which makes it easier to maintain and version-control.

How to use this generator

The form is grouped by schema type, and you only fill the fields that apply to your page.

Step 1 — Pick the schema type. Choose Article, Product, Organization, LocalBusiness, FAQPage, or BreadcrumbList based on what the page actually represents. The generator only emits markup for types that match real page content; it does not let you fabricate FAQ entries or product reviews to game rich results.

Step 2 — Fill the required fields. Each schema type has a required field set defined by Google's structured data documentation. The generator highlights required fields in red and flags missing values before generating output. Optional fields are visible but collapsible to keep the form short.

Step 3 — Copy the JSON-LD and paste into your <head>. The output is a single <script type="application/ld+json"> block. Paste it into the head of the page that the schema describes. Validate immediately afterward in the Rich Results Test — if Google's tool reports errors, no rich result will ever render in production.

Schema types and when to use each

The Schema.org vocabulary contains hundreds of types, but a small set covers the majority of real-world pages.

Article, NewsArticle, BlogPosting

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to write a meta description",
  "datePublished": "2026-04-27T10:00:00+00:00",
  "dateModified": "2026-04-27T12:00:00+00:00",
  "author": { "@type": "Person", "name": "Jane Smith" },
  "publisher": {
    "@type": "Organization",
    "name": "Example",
    "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
  },
  "mainEntityOfPage": "https://example.com/blog/meta-description"
}

Article is the generic parent type. NewsArticle is for journalistic, editorial content — news reports, investigative pieces, anything with a publication date and an editorial process. BlogPosting is for blog-format content — opinion pieces, how-tos, personal posts. Use the most specific subtype that genuinely applies. Google rewards specificity in schema by surfacing the right rich results: NewsArticle is eligible for the Top Stories carousel, while plain Article is not. The required fields are headline, datePublished, author, and an image for rich result eligibility.

Product

Product schema gives you star ratings, price displays, and availability badges in search. The required fields are name, image, and either offers (with price and currency) or review and aggregateRating. Aggregate rating is the field that produces the gold stars under the result, but Google has tightened rules since 2019: the rating must be derived from real first-party reviews on the page itself, not pulled from third-party sources. Faking ratings or reusing third-party ratings as if they were yours is a manual action waiting to happen.

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Inc.",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://twitter.com/example",
    "https://linkedin.com/company/example",
    "https://en.wikipedia.org/wiki/Example_Inc"
  ]
}

Organization schema goes on the homepage and About page. It tells search engines who is publishing the site, which feeds into the Knowledge Graph entity profile that appears in the right rail for branded searches. The sameAs field is the most important and most often skipped — it lists external authoritative profiles that confirm the organization's identity. Without sameAs, Google has to infer the entity from context; with sameAs, the link is explicit.

LocalBusiness

LocalBusiness extends Organization with location-specific fields: address, geo (latitude and longitude), openingHoursSpecification, telephone, and priceRange. It is required for the Knowledge Panel that appears in local search and Google Maps. Use the most specific subtype: Restaurant, Dentist, AutoRepair, LegalService, and so on, each of which has its own subtype. The full list lives in the LocalBusiness section of Schema.org. Including the wrong subtype — Restaurant for a coffee shop, Store for a service business — confuses local search and reduces visibility for the right queries.

FAQPage

FAQPage schema marks up questions and answers in a Q-and-A format. The format is straightforward — a mainEntity array of Question objects, each with an acceptedAnswer — but the rich result eligibility has narrowed sharply since 2023. Google now restricts FAQ rich results to authoritative government and health sites, and most marketing pages no longer see the accordion in search even with valid markup. The schema is still worth including because it helps Google understand the page structure, but do not expect rich results outside the eligible verticals.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Current Article"
    }
  ]
}

BreadcrumbList replaces the URL line in the SERP with a clickable breadcrumb trail, which is one of the most reliably-rendered rich results on Google. The current page (the last item) does not need an item URL — its absence tells Google this is the final position. Always include BreadcrumbList on every page deeper than the homepage; it costs nothing and consistently lifts CTR.

Linking entities with @id and sameAs

Most real pages contain multiple entities — an Article with an author, a publisher, and a breadcrumb trail. Without coordination, you end up declaring the same Organization three times in three different schema blocks, with no way for search engines to know they are the same entity. The @id pattern solves this.

Assign every entity a stable, unique @id that looks like a URL — typically the canonical page URL with a fragment identifier like #organization, #article, or #author. Once an entity is declared with an @id, every subsequent reference can be a { "@id": "..." } object instead of a full duplicate.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/article#article",
      "headline": "Title",
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

The @graph wrapper lets you declare multiple top-level entities in a single JSON-LD block, with @id linking establishing the relationships. This is the modern best practice for any page with more than one entity, and it is how SEO plugins like Yoast and Rank Math structure their output.

sameAs is the partner property to @id. Where @id links entities within the site, sameAs links entities to their canonical representations elsewhere — the Wikipedia page, the Wikidata entry, the official Twitter and LinkedIn profiles. Search engines use sameAs to perform entity reconciliation, confirming that your Organization is the one users mean when they search for the brand. Always include sameAs on Organization, Person, and high-value entity schema.

Common mistakes that hurt SEO

Schema for content that does not appear on the page. FAQ schema for questions that are not actually rendered, Product schema with reviews that do not exist, Recipe schema on a page that does not contain a recipe — all of these violate Google's structured data guidelines and can trigger manual actions. Schema must describe content that is visibly present on the page.

Wrong schema type. Using Article for a product page, Organization for a personal blog, LocalBusiness for an online-only service. The wrong type confuses search engines and prevents the right rich results from rendering. Pick the most specific type that genuinely fits, and check the Schema.org type tree if in doubt.

Mixing JSON-LD with Microdata or RDFa. When the same page declares the same entity in two formats, Google's behavior is undefined — it may merge, may pick one, may flag the conflict in Search Console. Commit to JSON-LD and remove inline structured data from the rendered HTML.

Ignoring required fields. Each rich result type has required fields documented at developers.google.com/search. Article requires headline, datePublished, author, and an image. Product requires name, image, and either offers or rating data. Missing any required field means no rich result will render, even if the rest of the markup is perfect. The Rich Results Test highlights what is missing.

Stale dateModified. Article schema with a dateModified value that never changes signals to Google that the page is stagnant. Conversely, updating dateModified on every page regeneration without an actual content change is also a signal — Google detects the pattern and discounts the field. Set dateModified to the real last-edit time of the content.

Duplicate or recursive @id values. Two entities sharing the same @id, or an entity referencing its own @id, breaks the graph. Each @id must be unique within the JSON-LD block. The pattern of using fragment identifiers like #organization, #author, #article keeps the IDs predictable and unique.

Validating once and never again. Schema markup that worked at launch can break in any number of ways: a CMS update changes how dates are formatted, a translation removes a required field, a template refactor strips the JSON-LD entirely. Run the Rich Results Test on at least one page per schema type after every significant deploy.

Edge cases nobody mentions

JSON-LD is not visible to humans, but it is visible to attackers and competitors who view your page source. Schema that lists internal employees by name, exposes business email addresses, or details pricing not shown on the page can leak information you would prefer to keep private. The recommendation is to put only data that is already public elsewhere on the page into the JSON-LD. The other edge case is rendering: schema injected client-side by JavaScript may be missed by Googlebot's first crawl pass, since the rendering queue is separate from the indexing queue and runs later. For schema that affects rich results, server-side rendering or static generation is the safe path.

Free Schema.org JSON-LD Generator