Tailored JSON-LD for e-commerce entities, including merchant trust signals, VAT data, and return policies.
Everything you need to know about implementing Organization schema correctly, from choosing the right type to fine-tuning your return policy markup.
Organization schema is a block of structured data that acts as a definitive profile for your business in the eyes of search engines. It tells Google who you are, what you do, where you're based, and how to verify you across the web. While structured data isn't a direct ranking factor, it makes it significantly easier for Google to surface your business information accurately and confidently.
In practice, this can unlock Knowledge Panels (the business cards that appear on the right of desktop search results), rich results with images and links, and better visibility in local and branded queries. For e-commerce sites in particular, it's also the foundation that your product, offer, and return policy markup relies on — so getting it right at organisation level pays dividends across the whole site.
No. Google doesn't guarantee any specific rich result treatment from structured data, and Knowledge Panels are algorithmically generated based on a wider set of signals including your presence in the Knowledge Graph, external mentions, and search volume around your brand. That said, providing complete, accurate Organization schema is one of the clearest ways to feed Google the data it needs to build that picture.
Think of it less as a switch and more as building a dossier. The more consistent and connected your structured data is across your site, the stronger your entity definition becomes over time.
Organization, OnlineStore, or something else?Google recommends using the most specific subtype that accurately describes your organisation. The more precise the type, the more useful the signal. Here's a quick reference:
| Schema Type | Best for |
|---|---|
| Organization | Generic fallback; use only when no subtype fits |
| OnlineBusiness | Online-only businesses without a physical presence |
| OnlineStore | E-commerce sites selling products online — recommended over OnlineBusiness |
| LocalBusiness | Businesses with a physical location; use the most specific subtype (e.g. Restaurant, Store) |
| Corporation / NGO / etc. | Non-retail organisations — check the full schema.org hierarchy |
For example: if you run a UK-based fashion retailer that sells online, OnlineStore is the correct type — not the generic Organization. If you also have a physical location, you'd want to look at combining with LocalBusiness subtypes and following Google's Local Business structured data guidelines separately.
This generator outputs Organization as a safe general-purpose type. If you're running a dedicated e-commerce site, swap the "@type" value to "OnlineStore" in the output before deploying.
Google recommends placing Organization schema on your homepage, or a single page that clearly describes your organisation (such as an About Us page). You do not need to include it on every page of your site. One well-defined instance is enough.
For pages across the rest of your site — products, blog posts, service pages — you reference your organization using the @id property rather than repeating the whole block. For example, a BlogPosting schema on a blog post would include "publisher": { "@id": "https://yoursite.com/#organization" } to link back to the entity you defined on the homepage. This creates a connected data web without code bloat.
Google supports three formats for structured data: JSON-LD, Microdata, and RDFa. Google (and this tool) recommends JSON-LD because it keeps your structured data entirely separate from the HTML content. This means it's easy to update, easy to validate, and much less risky to maintain — you're editing a script block rather than weaving attributes through your actual page markup.
Place the generated <script type="application/ld+json"> block in the <head> section of your page. While it technically works in the body too, placing it in the head is the standard practice and ensures crawlers encounter it as early as possible.
Yes, and for sites on a CMS this is often the more practical option. The most widely used plugins for adding Organization schema are:
The trade-off with plugins is reduced customisation — particularly for e-commerce-specific fields like VAT IDs, return policies, and fine-grained merchant data. If you need full control over the output, or if you're on a custom-built site, writing JSON-LD manually (and validating with the buttons above) will give you the cleanest result.
For online retailers, basic contact information isn't enough to establish authority. Google expects merchant-specific signals to verify that you're a legitimate, transparent business. The key additions for e-commerce are:
These fields directly support Google's E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) evaluation framework. Merchants who are transparent about their policies and registration details are treated as more trustworthy than those who aren't.
The hasMerchantReturnPolicy property supports more fields than this generator currently outputs. If you're editing JSON-LD manually, here are the key fields available:
["GB", "IE"]MerchantReturnFiniteReturnWindow, MerchantReturnUnlimitedWindow, or MerchantReturnNotPermittedFiniteReturnWindowReturnByMail, ReturnInStore, or ReturnAtKioskFreeReturn, ReturnShippingFees, or ReturnFeesCustomerResponsibilityFullRefund, StoreCreditRefund, or ExchangeRefundNewConditionSee the full Google MerchantReturnPolicy documentation for a complete reference and additional examples.
No. Define it once on the homepage using the full block, then reference it everywhere else using the @id. For example, a product page schema would include "seller": { "@id": "https://yoursite.com/#organization" } rather than repeating all the fields. This keeps your code clean and avoids conflicting signals if you ever need to update your details.
OnlineStore beats OnlineBusiness beats Organization)sameAs links as possible — LinkedIn, Facebook, Companies House, Wikipedia, Wikidata if applicable. Each verified link strengthens your Knowledge Graph entryUse the two buttons above the code output to run your schema through Google's Rich Results Test (checks eligibility for enhanced search features) and the Schema.org Validator (checks technical correctness against the schema.org specification). It's worth running both — they catch different categories of issue.
Once deployed, you can also check coverage and errors in Google Search Console under Enhancements — this will show you how many pages have been picked up and whether any warnings have been logged.