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 and getting found in AI search.
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.
Yes. Well-structured Organization markup improves your visibility in AI-powered search surfaces — including Google's AI Overviews, Bing Copilot, and voice assistants. When your entity is clearly defined with a consistent @id, name, URL, and verified sameAs links, AI systems can confidently surface your brand as a source of answers rather than attributing information to competitors or third-party sites.
For e-commerce sites, this is increasingly important: AI shopping tools pull structured merchant data (VAT IDs, return policies, contact points) directly from schema when deciding which retailers to recommend.
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.
| 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 |
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.
LocalBusiness is a subtype of Organization, so it inherits all the same properties but adds location-specific fields like opening hours, geo-coordinates, and service areas. Use LocalBusiness (or a more specific subtype like Store or Restaurant) when you have a physical premises customers can visit. Use Organization or OnlineStore when you operate purely online.
If you run both a physical shop and an online store, you can combine types in a single schema block: "@type": ["LocalBusiness", "OnlineStore"]. Google supports this multi-type approach.
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.
@id property and why does it matter? The @id is a unique identifier — essentially a permanent URL that represents your organisation as an entity in the Knowledge Graph. By convention it's your homepage URL with a fragment like #organization (e.g. https://yoursite.com/#organization).
Once you've defined your entity with a full Organization block on your homepage, every other schema block on your site can reference it via @id rather than duplicating all the fields. This creates a connected data web that makes your entity much more legible to search engines and AI systems, and means a single update to your homepage schema propagates correctly everywhere it's referenced.
Copy the generated <script type="application/ld+json">…</script> block and paste it according to your platform:
theme.liquid → paste before the closing </head> tag. Or use the XO Insert Code app for a no-code route.</body> → paste and publish.<head>…</head> in your template file.Whichever method you use, validate after deployment using the buttons above the code output.
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 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.
Probably not for the basics — both Yoast and Rank Math output Organization schema automatically based on your site settings. However, plugin-generated schema rarely includes e-commerce-specific fields like VAT IDs, Tax IDs, and full MerchantReturnPolicy blocks. If you need that granularity, you have two options: inject a custom block alongside the plugin's output (ensuring there's no conflicting duplicate), or disable the plugin's Organization output and manage it yourself entirely.
Check Google Search Console → Enhancements to see what schema your site is currently serving before deciding.
Yes — and you should. A single page can contain multiple schema blocks. On your homepage, it's perfectly valid to have your Organization block alongside a WebSite block (which enables Sitelinks Search Box) and a BreadcrumbList block. On product pages, your Product schema should reference back to your Organization entity via the brand or seller property.
Keep each block logically separate and make sure your @id values are consistent across all of them.
There's no fixed timeline — it depends on how frequently Google crawls your site. For most sites, changes are typically reflected in Google Search Console within a few days to a few weeks after Googlebot recrawls the page. You can speed this up by submitting the URL for indexing via the URL Inspection tool in Search Console.
Knowledge Panel updates can take considerably longer, as they depend on Google building sufficient confidence in the entity data from multiple signals — not just your schema alone.
No, not meaningfully. JSON-LD schema is a small block of text — typically under 2KB — and doesn't render-block anything. It has no measurable impact on LCP, CLS, or INP. You can safely add it to your <head> without worrying about performance implications.
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 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.
Absolutely — Organization schema is valuable for any website, not just retailers. Service businesses, SaaS companies, charities, publishers, and personal brands all benefit from a well-defined entity. The e-commerce-specific fields (VAT ID, return policy, merchant contact) are simply additional properties you can add if they apply; they're not required for basic Organization schema to function correctly.
If you're not a retailer, use the Organization type (or a relevant subtype like Corporation, NGO, or ProfessionalService) and focus on the core fields: name, url, logo, contactPoint, and sameAs.
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 entry@id consistent across all schema blocks on your site so Google can build a coherent entity graphUse 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.