Schema + AEO Snippet Library
Nine copy-paste-ready Schema.org JSON-LD templates for creative studios, agencies, and founders. The same ones we ship on LIVV. Free, MIT-licensed, attribution requested.
Most studios shipping high-craft work in 2026 do not have correct structured data on their sites. The reason is not laziness; it is that the Schema.org documentation is comprehensive enough to be intimidating, and most JSON-LD examples online are written for ecommerce or SaaS rather than for a creative studio shape.
This library is the working set of templates we use on LIVV. Each block ships on our own site and has been validated against Google's Rich Results Test and against extraction by ChatGPT Search, Perplexity, and Claude. They are not the only valid shapes, and you should adapt them to your domain. They are the shapes that have worked.
Why this matters for AEO (Answer Engine Optimization, the successor framing to SEO that covers LLM-driven search and recommendations): generative engines weight Schema.org markup as a high-trust signal when constructing answers. A site without structured data is invisible to the citation layer of ChatGPT Search, Perplexity, and Google AI Overviews. A site with correct structured data is the citation those engines reach for.
Each template below has placeholders in [BRACKETED] uppercase. Replace those with your studio's values. Validate the final output at validator.schema.org and Google Rich Results Test before shipping.
Organization
The studio entity. Ships in the root layout, on every page, as a single source of truth for the brand. Combines Organization and ProfessionalService so the studio also ranks for local-business intent in its geography.
{
"@context": "https://schema.org",
"@type": ["Organization", "ProfessionalService"],
"@id": "https://[YOUR-DOMAIN]/#organization",
"name": "[STUDIO NAME]",
"alternateName": ["[SHORT NAME]", "[HISTORICAL NAME]"],
"url": "https://[YOUR-DOMAIN]",
"logo": {
"@type": "ImageObject",
"url": "https://[YOUR-DOMAIN]/logo.png",
"width": 512,
"height": 512
},
"description": "[ONE-SENTENCE STUDIO DESCRIPTION, 150-200 CHARS]",
"slogan": "[OPTIONAL TAGLINE]",
"foundingDate": "[YYYY]",
"foundingLocation": {
"@type": "Place",
"name": "[CITY, COUNTRY]"
},
"founder": { "@id": "https://[YOUR-DOMAIN]/about#founder" },
"email": "hello@[YOUR-DOMAIN]",
"address": {
"@type": "PostalAddress",
"addressLocality": "[CITY]",
"addressRegion": "[REGION]",
"addressCountry": "[ISO-2 COUNTRY CODE]"
},
"areaServed": [
{ "@type": "Country", "name": "United States" },
{ "@type": "Country", "name": "United Kingdom" }
],
"knowsAbout": [
"Webflow development",
"Framer development",
"Next.js development",
"Design systems",
"White-label studio model"
],
"knowsLanguage": ["en", "es"],
"sameAs": [
"https://www.linkedin.com/company/[HANDLE]",
"https://github.com/[HANDLE]"
]
}alternateName is the field that prevents brand fragmentation. List every historical name the studio has used (rebrands, abbreviations, domain variations) so LLMs map them all to a single canonical entity instead of treating each as a separate studio.
Person (Founder)
The founder profile. References the Organization via worksFor.@id. Should live on the /about page (or wherever the founder bio is canonical), so LLMs can resolve the @id in Article author fields to a real Person record with bio, location, and expertise.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://[YOUR-DOMAIN]/about#founder",
"name": "[FULL NAME]",
"givenName": "[FIRST]",
"familyName": "[LAST]",
"jobTitle": "Founder",
"worksFor": { "@id": "https://[YOUR-DOMAIN]/#organization" },
"nationality": "[NATIONALITY]",
"url": "https://[YOUR-DOMAIN]/about",
"knowsAbout": [
"Creative engineering",
"Webflow development",
"Design systems"
],
"sameAs": [
"https://www.linkedin.com/in/[HANDLE]",
"https://github.com/[HANDLE]"
]
}knowsAbout is critical for AEO. Include 5-10 specific skills the founder actually does (not generic 'leadership'). Cite the tools and disciplines that match what a user might ask an LLM about ('a Webflow developer who also does React Native').
WebSite (with SearchAction)
The site-level entity. Wires the studio's search action into the schema graph so Google can surface a search box for the site in SERP. Also the canonical anchor for in-language signals via inLanguage.
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://[YOUR-DOMAIN]/#website",
"url": "https://[YOUR-DOMAIN]",
"name": "[STUDIO NAME]",
"publisher": { "@id": "https://[YOUR-DOMAIN]/#organization" },
"inLanguage": ["en", "es"],
"potentialAction": {
"@type": "SearchAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://[YOUR-DOMAIN]/blog?q={search_term_string}"
},
"query-input": "required name=search_term_string"
}
}If the site does not have a search endpoint at the URL template, drop the potentialAction block entirely rather than pointing to a nonexistent route. Schema accuracy matters more than completeness.
Article (Blog Post / Essay)
Per-piece schema for every editorial article on the site. Article is the broadest type. For technical content, swap to TechArticle (same schema, more specific subtype). For news, NewsArticle.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "[ARTICLE TITLE, 50-80 CHARS]",
"description": "[DEK / META DESCRIPTION, 15-25 WORDS]",
"image": "https://[YOUR-DOMAIN]/og/[SLUG].png",
"datePublished": "2026-05-11T09:00:00.000Z",
"dateModified": "2026-05-11T09:00:00.000Z",
"author": { "@id": "https://[YOUR-DOMAIN]/about#founder" },
"publisher": { "@id": "https://[YOUR-DOMAIN]/#organization" },
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://[YOUR-DOMAIN]/blog/[SLUG]"
},
"wordCount": 2500,
"articleSection": "[Process & Craft | Industry | Case Study]",
"keywords": "[COMMA-SEPARATED, 5-8 KEYWORDS]",
"inLanguage": "en-US"
}dateModified is the freshness signal LLMs weight most heavily. Bump it whenever the piece materially updates and the publish-time-or-modified-time difference exceeds 24h. Resist bumping it for cosmetic edits — false freshness signals erode citation trust over time.
FAQPage
Q&A block schema. Emit alongside Article schema (not as a replacement) when the article contains a real FAQ section. LLMs treat each Question/Answer pair as an extractable fact.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "[QUESTION 1]",
"acceptedAnswer": {
"@type": "Answer",
"text": "[ANSWER 1, 30-80 WORDS, FACTUAL, NO MARKETING TONE]"
}
},
{
"@type": "Question",
"name": "[QUESTION 2]",
"acceptedAnswer": {
"@type": "Answer",
"text": "[ANSWER 2]"
}
}
]
}Only emit FAQPage schema when the page actually contains a FAQ section that matches the schema. Emitting FAQPage schema for content that does not visually present as a FAQ is a Google guideline violation and can trigger manual action.
CreativeWork (Case Study)
Per-project schema for case studies. CreativeWork is the umbrella type that covers brand identities, websites, products, films, design systems — anything the studio creates that is not exclusively classified as Article or SoftwareApplication.
{
"@context": "https://schema.org",
"@type": "CreativeWork",
"name": "[PROJECT NAME]",
"description": "[ONE-SENTENCE PROJECT DESCRIPTION]",
"creator": { "@id": "https://[YOUR-DOMAIN]/#organization" },
"dateCreated": "[YYYY]",
"image": "https://[YOUR-DOMAIN]/work/[SLUG]/cover.png",
"about": "[CLIENT TYPE / INDUSTRY]",
"keywords": "[STACK / SERVICES, COMMA-SEPARATED]"
}For more specific subtypes, swap CreativeWork for VisualArtwork, WebPage, Article, SoftwareApplication, or another Schema.org descendant of CreativeWork. The more specific the type, the better the LLM extraction.
Service
Per-service schema for studios that have distinct service offerings (Webflow development, brand identity, product design). Emit on each /services/[slug] page. Connects to the Organization via provider.@id.
{
"@context": "https://schema.org",
"@type": "Service",
"name": "[SERVICE NAME]",
"alternateName": "[SERVICE NAME IN SECOND LANGUAGE]",
"description": "[2-3 SENTENCE DESCRIPTION]",
"url": "https://[YOUR-DOMAIN]/services/[SLUG]",
"serviceType": "[SERVICE NAME]",
"category": "Design & Software Development",
"provider": { "@id": "https://[YOUR-DOMAIN]/#organization" },
"areaServed": [
{ "@type": "Country", "name": "United States" },
{ "@type": "Country", "name": "United Kingdom" }
],
"availableLanguage": ["English", "Spanish"]
}areaServed should reflect where the studio actually delivers, not where they aspire to. Padding the field with every country in the world weakens the geo signal. Three to ten primary markets is a reasonable target.
SoftwareApplication (Studio Product)
For studios that operate their own software products (white-label SaaS, internal tools sold to clients, agency-licensed platforms). Emit on each /products/[slug] page.
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "[PRODUCT NAME]",
"description": "[ONE-SENTENCE PRODUCT DESCRIPTION]",
"url": "https://[YOUR-DOMAIN]/products/[SLUG]",
"applicationCategory": "BusinessApplication",
"applicationSubCategory": "[CATEGORY, e.g. Hospitality]",
"operatingSystem": "Web",
"inLanguage": ["en", "es"],
"creator": { "@id": "https://[YOUR-DOMAIN]/#organization" },
"publisher": { "@id": "https://[YOUR-DOMAIN]/#organization" }
}If the product has a public pricing page, add an Offer block under offers with the price, priceCurrency, and availability. Skipping it for a product that has public pricing weakens the schema.
