Free schema markup generator
- No signup
- Free
- Results in ~5 seconds
Missing required fields
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"address": {
"@type": "PostalAddress"
}
}
</script>In Rank Math or Yoast, open the schema or custom code box and paste this. Or use WPCode to add a header snippet on that page only.
Want schema across the whole site, with an @graph and entity links? That is part of my technical SEO service.
Schema is a description of the page for machines. I use it so the name, the offer, and the questions on the page are unambiguous. It does not guarantee a rich result. It makes you eligible when Google still shows that result, and it gives AI systems a clean set of facts.
How to use the schema markup generator
Pick the type that matches the page. A plumber location page is a LocalBusiness subtype, not a generic WebPage and not a Product. Fill the fields you can stand behind. Empty fields are left out of the code, which is what you want. A blank price is worse than no price.
Copy the JSON-LD. Put it in a script tag with type application/ld+json, or into the SEO plugin field that accepts raw JSON-LD. Then test it. The generator checks the shape. Google and the Schema Markup Validator check it against the live page.
You can import a URL to pre-fill fields, and you can draft FAQs from a page summary. Read every drafted answer. If the sentence is not visible on the page, do not ship it. Schema that describes content you do not show is how sites get manual actions and messy AI descriptions.
Which schema type do I need?
Start with the thing the page is about. Add a breadcrumb on inner pages. Add an organization once, on the homepage or in a sitewide graph, and point other pages at it with a stable @id. Do not create a new organization on every URL.
| Page | Types I usually add |
|---|---|
| Homepage | Organization, WebSite |
| Local service or location | LocalBusiness subtype, BreadcrumbList |
| Service page | Service, BreadcrumbList |
| Blog post | Article or BlogPosting, BreadcrumbList |
| Product | Product and Offer |
| Page with visible questions | FAQPage, only for questions on the page |
| Person or author | Person, linked from Article |
Where to add schema on WordPress, Shopify, Webflow, Wix and Next.js
On WordPress, Yoast and Rank Math already print some graph. If you paste a second Organization, you now have two. Prefer the plugin field for the type it owns, and add a custom script only for a type it does not cover. Check the public HTML for duplicate @type values.
On Shopify, the theme usually prints Product. Use the generator to compare, not to paste a second Product. Extra types, such as a careful FAQ on a page that really has those questions, can go in a custom liquid block or an app you already use. Two apps writing schema is the same problem as two plugins.
On Webflow and Wix, put the script in the page head or the page custom code slot. Do not paste it into the visible rich text, or visitors will see the JSON. On Next.js, render the script from the page component so it is in the first HTML response. A script that only appears after hydration is easy for a browser to see and easy for a crawler to miss.
How to test your schema
Open the Rich Results Test for the types Google still treats as rich results, and the Schema Markup Validator for everything else. Look for errors first, then warnings. An error means the type is ineligible. A warning often means a recommended field is missing.
Then view the source of the live URL and confirm the script you copied is the script that shipped. I still find teams who tested a staging URL, deployed the page, and left the schema on the staging domain. The @id and the URL fields should use the public origin.
Does schema help SEO and AI search?
Schema makes you eligible for certain rich results. It does not move you from position eight to position three. Google has also removed some results entirely. HowTo rich results went away with the documentation on 14 September 2023. FAQ rich results stopped appearing on 7 May 2026. I still mark up real questions and answers, because the content is on the page and machines can read the pairs. I do not promise the old dropdown.
For AI answers, schema is one clean copy of the facts: the name, the URL, the sameAs profiles, the place you serve. It helps when it matches the visible page. It hurts when it contradicts the page. If the site says Leeds and the schema says Manchester, you have given the model two stories.
Common schema mistakes I see in audits
The mistakes are repetitive. They are also easy to see once you look at the HTML instead of the plugin dashboard.
- Markup for content that is not on the page, especially FAQ answers and reviews.
- Self-serving review stars on the business itself. Those are not eligible. Only mark up reviews a visitor can read.
- Two plugins printing the same type with different names or phone numbers.
- A Product offer with the wrong currency, or a price that includes a tax the page does not show.
- Relative URLs inside JSON-LD. Use absolute URLs.
- An @id that changes every release, so nothing on the site can refer to the same entity.
A graph that stays consistent
I use one @id for the organization and I reuse it. The homepage defines the organization. Articles point at the author. Products point at the seller when that link is true. If every page mints a new id, nothing on the site agrees that it is the same business.
Keep the visible page and the JSON in the same edit. When the phone number changes, change the footer, the profile, and the schema together. A generator makes the first script fast. It does not watch the site for you after that.
Test on the public URL, not only in the box on this page. I have shipped schema that was valid in a form and missing on the live page because the theme stripped script tags from the HTML field. View source. If the script is not there, the validator result does not matter.
Do not mark up a type because a checklist said every site needs it. A dentist does not need Product. A shop does not need LocalBusiness on every product URL. The table above is the set I start from. Extra types are for pages that really are that thing.
JSON-LD is the format I ship. Microdata in the HTML can describe the same facts, but it is harder to read and easier to break when the template changes. One format, in the head or just after the opening body tag, is enough. Do not output both for the same entity unless you have checked they match.
If a field is unknown, leave it out. "N/A", "null", and an empty string are not helpful to a parser. The generator already drops empty fields. Do not put them back by hand to make the script look longer.
I retest after a redesign. New themes drop custom scripts. A migration is the other moment schema disappears or starts pointing at the old domain. The generator is quick to run again. The expensive mistake is leaving the old domain in an @id for a year. Check the public origin in every URL field before you call the page done, and then you ship it.