The schema brief: what to give your developer before your next drop
Almost every brand I've worked with hits the same wall. The Head of Ecommerce reads one of my earlier pieces on entity trust and AI shopping agents, forwards it to their developer, and gets back a version of the same question: "Okay, but what should it actually look like?"
Fair question. The strategic case for structured data is one conversation. The implementation brief is a different one. This article is the second conversation. What the JSON-LD should look like for a fashion drop brand, why each field matters, and what you're likely to find when you go looking at what's already on your site.
I've written this so you can forward it directly to your developer or technical lead. The context sits in the earlier pieces in this series. This one is just the brief.
Product schema
This is the one that matters most and the one most brands have done partially or badly.
Here's what I typically find when I crawl a fashion brand's PDPs — a minimal block that's technically present but functionally useless:
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Essential Tee - Black",
"image": "https://brandname.com/images/tee-black.jpg",
"offers": {
"@type": "Offer",
"price": "65.00",
"priceCurrency": "GBP"
}
}
A product name and a price. No brand entity, no GTIN, no seller identity, no availability. From an AI agent's perspective, this product has no verified relationship to any organisation and no provenance chain. It's a product floating in the data with nothing connecting it to a legitimate source.
Here's what it should look like:
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Essential Tee - Black",
"description": "Heavyweight 320gsm cotton tee, garment-dyed.",
"image": "https://brandname.com/images/tee-black.jpg",
"sku": "ESS-TEE-BLK-M",
"gtin13": "5901234123457",
"brand": {
"@type": "Brand",
"name": "Brand Name"
},
"manufacturer": {
"@type": "Organization",
"name": "Brand Name Ltd",
"url": "https://brandname.com"
},
"offers": {
"@type": "Offer",
"url": "https://brandname.com/products/essential-tee-black",
"priceCurrency": "GBP",
"price": "65.00",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition",
"seller": {
"@type": "Organization",
"name": "Brand Name Ltd"
}
}
}
The fields that matter most in this block are gtin13, brand, manufacturer, and seller. The GTIN creates the provenance chain. It’s the identifier an AI shopping agent can cross-reference against product registries to verify the product belongs to you. The brand, manufacturer, and seller fields declare the relationship between the product and your organisation. Without them, the product has no declared owner in the data.
One note on GTINs: the field name depends on the number of digits in your GTIN. Use gtin8 for 8-digit GTINs, gtin12 for 12-digit, gtin13 for 13-digit. Most fashion brands will be using gtin13. If you're not sure what GTINs you have or whether they're correctly registered to your brand, check them against GS1's Verified by GS1 tool before adding them to your schema.
Organisation schema
This one should be on every page of your site. Ideally in the global header or footer so it renders across the entire domain, not just the homepage.
What I usually find:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Brand Name",
"url": "https://brandname.com"
}
A name and a URL. No legal name, no verified external profiles, no contact information, nothing that a system trying to verify your identity can cross-reference.
What it should look like:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Brand Name",
"legalName": "Brand Name Ltd",
"url": "https://brandname.com",
"logo": {
"@type": "ImageObject",
"url": "https://brandname.com/logo.png"
},
"sameAs": [
"https://www.instagram.com/brandname",
"https://www.linkedin.com/company/brandname",
"https://twitter.com/brandname",
"https://www.facebook.com/brandname"
],
"vatID": "GB123456789",
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"email": "hello@brandname.com"
}
}
A few things to flag to your developer here.
The legalName field should match exactly how your business is registered — the same string that appears in Google Merchant Center and on any official business registration. Not approximately the same. Exactly the same. Discrepancies between these are the kind of thing that creates an ambiguous entity.
The sameAs array is only useful if the URLs in it are current and active. Before adding any URL to this array, open it and verify it resolves to a profile that matches your brand name. An Instagram handle you changed two years ago, a LinkedIn page that 404s, a Twitter profile that's been suspended. These are worse than no sameAs entries at all because they actively signal an entity with contradictory data.
The vatID field is worth including if you have one. It's a verifiable legal identifier that ties your schema entity to a real, registered business. Counterfeit operations won't have it.
Person schema
In my experience this is the field that gets the most resistance when I raise it with ecommerce teams, because it feels like it belongs to HR or the marketing team rather than the technical brief. It doesn't. It's a data layer, and it's one of the hardest things for a counterfeit operation to replicate.
The brief is straightforward. For each key person with a public-facing role — Founder, Creative Director, Head of Design — create a Person schema block on your site. A dedicated team page with individual profiles is the right home for this, but even a single /about page with the markup present is better than nothing.
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Chen",
"jobTitle": "Creative Director",
"worksFor": {
"@type": "Organization",
"name": "Brand Name",
"url": "https://brandname.com"
},
"sameAs": "https://www.linkedin.com/in/alexchen"
}
The worksFor property is the link between the person and your organisation entity. Without it, the Person schema exists in isolation and doesn't contribute to your brand's entity structure. With it, you're creating a declared relationship that an AI agent can follow: this person works for this organisation, and this organisation sells these products.
The sameAs URL here should be their LinkedIn profile. Make sure the profile is public, up to date, and lists the correct current role and company name. A LinkedIn profile where someone's job title says "Senior Designer" and your schema says "Creative Director" is another discrepancy that creates ambiguity.
For any editorial content on your site such as collection stories, brand notes, drop retrospectives, etc add Article or BlogPosting schema with an author field linking back to the relevant Person entity:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "The Thinking Behind Spring Drop",
"datePublished": "2025-03-10",
"author": {
"@type": "Person",
"name": "Alex Chen",
"url": "https://brandname.com/team/alex-chen"
},
"publisher": {
"@type": "Organization",
"name": "Brand Name",
"url": "https://brandname.com"
}
}
This creates an authorship trail that connects your content to a real person, that real person to your organisation, and your organisation to your products. A ghost-run counterfeit operation has none of this and can't manufacture it.
Validation
Three tools, each with a different job. Don't rely on just one.
validator.schema.org This is where to start for everything. Paste the URL of any page and it'll render all schema it finds, regardless of type. This is the right tool for checking your Organisation and Person schema because the Rich Results Test won't show you those at all. They don't generate rich results, so Google's tool ignores them. A homepage that passes the Rich Results Test can still have completely broken Organisation schema. Use validator.schema.org to check your homepage, a sample of PDPs, and any editorial content pages with Author markup.
Google's Rich Results Test (search.google.com/test/rich-results) Use this specifically for your Product schema. It shows whether your product markup is structured correctly to be eligible for a rich result in Google Search, and it renders the parsed data so you can see exactly what Google is reading. Worth running on a sample of PDPs and at least one new drop SKU before launch.
Screaming Frog The two tools above only check one URL at a time. For checking that schema is actually present across your full catalogue, crawl the site and extract all structured data. Filter for Product schema and check GTIN coverage at scale. This is the only practical way to find pages where schema has been missed, broken by a template change, or dropped during a platform migration.
After deployment, check Search Console's "Enhancements" section a couple of weeks later for any structured data errors surfacing at scale. Individual page testing catches most issues but occasionally something only breaks across certain product templates or dynamic price fields.
That's the brief. The strategic case for why this matters is in the earlier pieces in this series. This is just what to build and what to check when it's done.
Summary of article;
- Product schema: add gtin13, brand, manufacturer, and seller to every PDP. The GTIN is the provenance chain. Without it the product has no verified owner in the data.
- Organisation schema: place it in the global header or footer so it renders on every page. Include legalName (exactly as registered), sameAs links to active social profiles, and vatID if you have one. Check every sameAs URL resolves before adding it.
- Person schema: create it for founders and public-facing roles with worksFor linking back to the Organisation entity. Add Author markup to any editorial content. This is the layer a counterfeit operation cannot replicate.
- Validate with three tools: validator.schema.org for Organisation and Person schema, Google's Rich Results Test for Product schema, Screaming Frog for catalogue-wide coverage. The Rich Results Test will not surface Organisation or Person schema — use validator.schema.org for those.
- Check before launch: run the Rich Results Test on at least one new drop SKU before the window opens. A product that fails schema validation enters the drop as an unverified entity.
What schema markup does a fashion brand need before a product drop?
Three schema types are essential before a drop. Product schema on every PDP including gtin13, brand, manufacturer, seller, availability, and itemCondition fields. Organisation schema in the global header or footer on every page including legalName, sameAs links to active social profiles, and vatID where available. Person schema for founders and key public-facing roles, with a worksFor property linking each person back to the Organisation entity. All three together create a connected entity structure that AI shopping agents can verify.
Why is the GTIN the most important field in product schema?
The GTIN is the primary identifier AI shopping agents use to verify product ownership and provenance. It can be cross-referenced against GS1's global registry to confirm the product belongs to the brand claiming to sell it. Without a valid, GS1-registered GTIN in the product schema, the product has no verified relationship to any organisation. Use gtin13 for 13-digit GTINs, which covers most fashion brands. Check GTINs against GS1's Verified by GS1 tool before adding them to schema to confirm they resolve to your brand entity and not a third party.
What tools should I use to validate schema markup?
Three tools each do a different job. Use validator.schema.org to check all schema types including Organisation and Person schema — the Rich Results Test will not show these as they do not generate rich results. Use Google's Rich Results Test at search.google.com/test/rich-results specifically for Product schema to confirm it is eligible for rich results in Google Search. Use Screaming Frog to crawl the full site and check schema is present at scale across the entire catalogue — the other two tools only check one page at a time. After deployment, check Search Console Enhancements for structured data errors appearing across product templates.
Why does Organisation schema need to be on every page, not just the homepage?
Organisation schema establishes the brand as a verified legal entity across the entire domain. If it only appears on the homepage, AI shopping agents and search crawlers may not associate it with product pages, editorial content, or other parts of the site. Adding it to the global header or footer ensures it renders on every page and creates a consistent entity signal across all URL paths. The legalName field should match exactly how the business is registered — the same string used in Google Merchant Center and on official business registration documents.