Schema.org for B2B agencies: a 2026 implementation guide

If you're a B2B agency in 2026, schema.org markup is the single highest-leverage technical SEO/AEO investment you can make. The cost is one engineer-week of upfront work plus maintenance on each new content type. The return is consistent AI engine citation eligibility on the queries your buyers actually ask.

This piece is the agency-specific implementation guide. It walks through the nine schema types every agency site needs in 2026, the agency-specific patterns (ProfessionalService, OfferCatalog, Service tiers), the centralization pattern that prevents drift, and the validation discipline that keeps the schema healthy as the site grows.

#Why agencies in particular

B2B agencies have specific schema needs that B2C SaaS doesn't. Three reasons:

Service-shaped queries. Most agency queries are "best [service] agency for [vertical]," "fixed-price [service]," "[service] agency under $X." These map cleanly to Service + OfferCatalog schema. AI engines extract from these schemas to answer the queries.

Tier-based pricing. Productized agencies sell at specific tiers ($4,800 sprint, $14,800 build, $25,000 plus). Tier structure expressed as OfferCatalog.itemListElement with Offer.price is what lets ChatGPT cite "Acme Agency offers a $14,800 fixed-price MVP build" instead of "Acme Agency offers MVP builds at various price points."

No PII issue. Agencies that publish founder names + photos + bios get strong E-E-A-T citation lift via Person schema. Agencies that don't (privacy-first agencies like SolvSpot) lean heavier on Organization + ProfessionalService schema. Either way, agencies have more identity surface than typical B2C SaaS, and that surface is where the citation lift comes from.

#The nine schema types

In implementation order:

If you ship these nine, you've covered ~90% of the AEO citation surface available to a B2B agency. The remaining 10% is content quality and external signals (Reddit, HN, citations from other authoritative sites).

#1. Organization

The base schema. Every page should include this in the @graph.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yoursite.com#organization",
  "name": "Acme Agency",
  "legalName": "Acme Agency, LLC",
  "url": "https://yoursite.com",
  "description": "Productized B2B SaaS development and AI automation agency.",
  "email": "hello@yoursite.com",
  "foundingDate": "2023",
  "sameAs": [
    "https://twitter.com/acmeagency",
    "https://linkedin.com/company/acmeagency",
    "https://github.com/acmeagency"
  ]
}

For brand-only agencies (no founder identity disclosed), keep sameAs to the agency's own profiles. For named-operator agencies, also include Person schema with full sameAs to LinkedIn, GitHub, X, prior work.

For the underlying schema reference, see Organization on schema.org.

#2. ProfessionalService

The agency-specific layer. Tells AI engines you provide professional services in a defined category. Goes on the homepage in the same @graph as Organization.

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://yoursite.com#professionalservice",
  "name": "Acme Agency",
  "description": "Productized B2B SaaS development and AI automation.",
  "url": "https://yoursite.com",
  "provider": { "@id": "https://yoursite.com#organization" },
  "areaServed": { "@type": "Place", "name": "Worldwide" },
  "serviceType": ["SaaS development", "AI automation", "AEO/SEO consulting"]
}

The serviceType array is what AI engines match against query categories. Be specific ("SaaS MVP development" is better than "software development").

ProfessionalService schema is a subtype of LocalBusiness, but for an agency without a public-facing physical storefront, the location-specific LocalBusiness fields (address, geo) can be omitted.

#3. WebSite

Goes on the homepage only. Tells AI engines this is a website with a name, optionally with site search.

{
  "@type": "WebSite",
  "@id": "https://yoursite.com#website",
  "url": "https://yoursite.com",
  "name": "Acme Agency",
  "publisher": { "@id": "https://yoursite.com#organization" },
  "potentialAction": {
    "@type": "SearchAction",
    "target": "https://yoursite.com/blog?q={search_term_string}",
    "query-input": "required name=search_term_string"
  }
}

If you don't have site search, omit the entire potentialAction block. Don't fake it; both Google and AI engines penalize fake SearchAction.

#4. BreadcrumbList

Goes on every non-home page. Tells AI engines the navigation path.

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://yoursite.com/" },
    { "@type": "ListItem", "position": 2, "name": "Services", "item": "https://yoursite.com/services" },
    { "@type": "ListItem", "position": 3, "name": "AI Automation Sprints", "item": "https://yoursite.com/services/ai-automation-sprints" }
  ]
}

Position integers must be 1-indexed and consecutive. URLs must be absolute. The last breadcrumb should match the page you're on.

#5. Service + 6. OfferCatalog

The agency-specific high-leverage pair. Every service page ships these together.

{
  "@type": "Service",
  "@id": "https://yoursite.com/services/saas-mvp#service",
  "name": "SaaS MVP in 6 Weeks",
  "description": "Fixed-price productized B2B SaaS MVP build. Auth, billing, six core flows, custom design system, admin panel, production deploy.",
  "provider": { "@id": "https://yoursite.com#organization" },
  "serviceType": "SaaS MVP development",
  "areaServed": { "@type": "Place", "name": "Worldwide" },
  "url": "https://yoursite.com/services/saas-mvp",
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "SaaS MVP Pricing",
    "itemListElement": [
      {
        "@type": "Offer",
        "name": "Lite",
        "price": 9800,
        "priceCurrency": "USD",
        "description": "3 core flows, auth, billing, basic admin (4 weeks)",
        "availability": "https://schema.org/InStock"
      },
      {
        "@type": "Offer",
        "name": "Standard",
        "price": 14800,
        "priceCurrency": "USD",
        "description": "6 core flows, custom design, full admin, analytics (6 weeks)",
        "availability": "https://schema.org/InStock"
      },
      {
        "@type": "Offer",
        "name": "Plus",
        "price": 22800,
        "priceCurrency": "USD",
        "description": "Standard + AI feature + extended support (8 weeks)",
        "availability": "https://schema.org/InStock"
      }
    ]
  }
}

Critical fields:

• provider references Organization @id. Entity graph link.
• Offer.price must be a number (not a string), with priceCurrency separately.
• Offer.description is what the AI engine uses to disambiguate tiers. Be specific.
• Offer.availability uses schema.org enum URLs (InStock, OutOfStock, LimitedAvailability).

For a deeper dive into the schema mechanics, see The minimum schema markup every SaaS homepage needs in 2026.

#7. FAQPage

The highest-leverage schema for AEO. Goes on homepage, every service page, every pillar blog post.

{
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How much does a fixed-price SaaS MVP cost in 2026?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Productized agency SaaS MVPs in 2026 cost $9,000 to $25,000 depending on scope. The standard tier (auth, Stripe billing, six core flows, custom design, admin panel, analytics) lands at $14,800 for a 6-week build."
      }
    }
  ]
}

The Q&A phrasing matters. Write the questions the way real users type them into ChatGPT, not the way SEO keyword tools phrase them. Answer in 2 to 4 complete sentences with concrete facts.

#8. Article (or BlogPosting)

Every blog post and case study. Use BlogPosting for blog content; Article for editorial content (definitive guides, methodology pages, case studies).

{
  "@type": "BlogPosting",
  "@id": "https://yoursite.com/blog/post-slug#article",
  "headline": "How to write llms.txt for a SaaS site",
  "description": "Practical guide to llms.txt and llms-full.txt for B2B SaaS sites...",
  "datePublished": "2026-04-28",
  "dateModified": "2026-04-30",
  "author": { "@id": "https://yoursite.com#organization" },
  "publisher": { "@id": "https://yoursite.com#organization" },
  "wordCount": 2400,
  "articleSection": "AEO",
  "citation": [
    { "@type": "CreativeWork", "url": "https://llmstxt.org/" },
    { "@type": "CreativeWork", "url": "https://schema.org/" }
  ],
  "inLanguage": "en"
}

The citation array is the Princeton GEO finding playing out in schema: pages that cite primary sources get cited more by AI engines. Auto-extract outbound markdown links from your post body and emit them as citation entries; the lift is real.

For brand-only agencies, author references Organization. For named-author agencies, author references a Person schema.

#9. HowTo

Goes on process pages, methodology pages, step-by-step guides. Highest-leverage when the page genuinely teaches a procedure.

{
  "@type": "HowTo",
  "name": "How a 6-Week SaaS MVP Build Runs Week-by-Week",
  "description": "A realistic week-by-week build plan for a productized B2B SaaS MVP.",
  "totalTime": "PT6W",
  "step": [
    {
      "@type": "HowToStep",
      "name": "Week 1: Foundation",
      "text": "Auth working, Stripe sandbox connected, schema deployed, staging URL live."
    },
    {
      "@type": "HowToStep",
      "name": "Week 2: Design system",
      "text": "Component library built, 3 of 6 flows in design, navigation skeleton in code."
    }
  ]
}

HowTo schema is heavily extracted by Google AI Overviews specifically. If you have a process page, ship HowTo. If you don't have one, consider whether your scoping or methodology content would be better surfaced as a HowTo page.

#The centralization pattern

Authoring schema by hand on each page is the canonical drift trap. Six months in, your Organization schema on the about page disagrees with the about page on the homepage, your prices in the OfferCatalog disagree with the prices on the pricing page, and your FAQ schema disagrees with the visible FAQ content.

The fix: centralize schema generation in a typed builder. Every page composes from typed builder functions; the underlying data lives in one place.

// src/lib/schema.ts (sketch)
export function organizationSchema() { /* ... */ }
export function professionalServiceSchema() { /* ... */ }
export function websiteSchema() { /* ... */ }
export function serviceSchema(input: ServiceInput) { /* ... */ }
export function articleSchema(input: ArticleInput) { /* ... */ }
export function faqPageSchema(faqs: FAQ[]) { /* ... */ }
export function breadcrumbSchema(crumbs: Crumb[]) { /* ... */ }
export function howToSchema(input: HowToInput) { /* ... */ }

Each function takes typed input, returns the JSON-LD object. The page composes:

// src/app/services/[slug]/page.tsx
const schemaGraph = {
  "@context": "https://schema.org",
  "@graph": [
    organizationSchema(),
    serviceSchema({ ... }),
    faqPageSchema(service.faqs),
    breadcrumbSchema([...]),
  ],
}

When pricing changes or a new sameAs URL is added, you update one constant and every page's schema updates automatically. This is the discipline that makes schema sustainable past the first ship.

#Validation discipline

Before pushing schema to production, validate it. Three tools worth running:

1. Google Rich Results Test. Tells you which schemas validate and which are eligible for rich results.
2. Schema.org Validator. Stricter than Google's; catches errors Google may silently ignore.
3. Manual JSON parse: curl https://yoursite.com/services/x | grep -A 200 'application/ld+json' | jq to verify the JSON parses cleanly.

Run all three on every page type when you ship. Run them again after every schema change. Add validation to CI if you can; some teams ship a custom test that fetches every page and validates the JSON-LD against a Zod schema.

Quarterly: pick 5 random pages, run them through both validators. Catch drift before it compounds.

#What changes the calculus

Two schema-related shifts to watch in 2026:

• Schema.org's AI-specific types. Google has been iterating on schema types specific to AI Overviews (Speakable, AskQuestion). New types could change what's worth marking up.
• Native AI-engine schemas. Both OpenAI and Anthropic have hinted at first-party schema-like declarations. If they ship, the multi-vendor schema landscape gets more complex.

For now, the nine types above are the durable baseline. The marginal types (Speakable, EducationalOccupationalProgram, etc.) are worth adding only when you have a specific reason and the validation infrastructure to maintain them.

#Bottom line

Every B2B agency site in 2026 needs nine schema.org types: Organization, ProfessionalService, WebSite, BreadcrumbList, Service, OfferCatalog, FAQPage, Article, HowTo. Centralize generation in a typed builder. Validate every page type before shipping. Revalidate quarterly.

The implementation is one engineer-week. The compounding citation benefit shows up over 4 to 8 weeks for the technical baseline and 3 to 6 months for the content-and-distribution layer above it.

For the broader AEO playbook context, see AEO vs SEO: what changed in 2026. For the productized AEO Audit that ships this implementation as a one-week engagement, see our AEO + SEO for SaaS service.