Schema markup on crypto sites in 2026 is in a strange middle place. Most agencies still treat schema as a Google ranking signal — implement Article and BreadcrumbList, validate, ship. The work is roughly correct but radically underused.

The bigger lever is AI-search citation extraction. ChatGPT search, Perplexity, Gemini and Google AI Overviews all rely on schema to identify what’s quotable, who said it, and which entities the page is about. A crypto site with a properly designed schema graph gets cited 1.5–3× more often than an equivalent site with default WordPress schema, on the same content.

Here’s what actually moves the citation rate, in priority order.

Why does Person schema move AI citations so much in YMYL?

YMYL niches — finance, legal, medical, crypto — have algorithmic preference for content authored by named experts with verifiable credentials. Schema.org Person is the markup language for declaring those credentials in a machine-readable format.

The properties that materially move the needle:

{
  "@type": "Person",
  "name": "Maksym Drobotenko",
  "jobTitle": "Founder & Lead Strategist",
  "worksFor": {
    "@type": "ProfessionalService",
    "name": "CryptoRank Labs",
    "url": "https://cryptoseoagency.net"
  },
  "knowsAbout": ["Crypto SEO", "AEO", "Crypto licensing", "AI search"],
  "alumniOf": "KNEU",
  "yearsOfExperience": 12,
  "sameAs": [
    "https://www.linkedin.com/in/[username]",
    "https://cryptolawindex.com/about"
  ]
}

Two properties carry most of the weight: sameAs (verifiability) and knowsAbout (topical authority). LinkedIn alone is enough for sameAs; ideally there’s a second independent profile (a conference talk page, a regulator submission record, an interview, an authored publication). Two or more linked profiles cross-validate the person’s identity and let AI tools confidently pull citations attributed to that name.

The author’s name on the byline alone is not enough. The byline plus full Person schema with sameAs is what triggers the citation-extraction confidence boost.

What’s the right top-level type for crypto licensing firms?

The choice between Organization, Service, ProfessionalService, LegalService, and FinancialService matters more than it looks. Each conveys different signals to indexers about what the entity does and who is authoritative for what topic.

For crypto licensing firms (Fast Offshore Licenses-style entities), ProfessionalService is the right choice. It’s the schema.org parent type for advisory and consultancy services that don’t fit LegalService cleanly. The hierarchy:

  • Organization (too generic; gives AI tools no useful signal about what kind of org)
  • LocalBusiness (wrong; suggests a physical-storefront operation)
  • Service (too generic; describes a single service offering, not a firm)
  • ProfessionalService (right for advisory + consultancy + B2B services)
  • LegalService (only if the firm is a registered law firm with bar-admitted lawyers)
  • FinancialService (only for licensed CASPs, banks, EMIs, etc.)

For ourselves, we use ProfessionalService because we’re a marketing agency, not a financial services firm. For our licensing-firm clients, we typically use ProfessionalService plus a structured description that names the regulatory specialisation. For client CASPs we use FinancialService and reference their licence number directly.

What does ItemList do that other types can’t?

For ranking and comparison pages — CryptoLawIndex-style sites, “best X for Y” articles, comparative review pages — ItemList is the type that AI tools handle correctly without entity confusion.

Naive implementations declare each ranked item as a separate Organization schema on the same page. This causes entity confusion: AI tools see multiple top-level org claims and weight them inconsistently. The correct pattern is a single page-level ItemList that contains references to each ranked entity:

{
  "@type": "ItemList",
  "name": "Top crypto licensing law firms 2026",
  "itemListOrder": "Descending",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "ProfessionalService",
        "name": "Firm A",
        "url": "https://firma.example"
      }
    },
    ...
  ]
}

The page itself is the publication entity (Article or similar), and the list is its primary content. Each ranked firm is referenced by name and URL, which lets AI tools resolve them against their own entity graph rather than treating the ranking page as the canonical source for each firm.

We rebuilt CryptoLawIndex’s structured data along these lines in early 2025. The change correlated with a measurable AI-citation lift over the following 60 days.

When does FAQPage actually earn rich results?

FAQPage schema is widely deployed and often misused. The criteria for rich-result eligibility are stricter than the basic markup validation:

  • The questions and answers have to be visible to users (not hidden behind accordions that load JS-only)
  • The content has to actually be Q-and-A format (not promotional text dressed up)
  • The page can’t be classified by Google as “low-quality” or “promotional” overall
  • The same Q&A content can’t appear elsewhere as separate FAQPage markup

When all four are met, rich-result eligibility typically lands in 30–60 days. For pages that already rank top-3 on the target query, the FAQPage rich result captures additional SERP real estate and lifts CTR by 15–40%.

The speakable property is an extension worth adding for voice-search surfaces. It marks specific sentences as “appropriate for audio response”, which is what voice assistants and AI voice modes look for when deciding what to read aloud:

{
  "@type": "FAQPage",
  "mainEntity": [...],
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".direct-answer"]
  }
}

The CSS selector tells the speakable extractor which DOM elements contain the audio-friendly answers. We use .direct-answer as a class on every direct-answer block in our content — same class is used by the AEO direct-answer styling, so the markup tracks the visual structure.

What’s the schema graph design for an exchange?

For a crypto exchange (CASP under MiCA), the schema graph at minimum includes:

  • FinancialService (top-level for the firm), with licence number, regulatory authority, and country of registration
  • Person for each named compliance officer and product lead, with sameAs to LinkedIn and substantive knowsAbout properties
  • Service for each product offering (spot trading, futures, staking, lending), each with appropriate risk warnings in description
  • WebSite with SearchAction to enable the search-box rich result
  • BreadcrumbList per page
  • FAQPage on cost, fees, KYC, supported jurisdictions
  • Article per blog post or guide, with dateModified, author (Person reference), publisher (FinancialService reference)

The graph elements cross-reference each other through @id properties. A Person who authored an Article references the FinancialService through worksFor, and the FinancialService is referenced from the global WebSite. AI tools that traverse the graph have a coherent picture of who said what under whose authority.

For a crypto licensing firm, the graph is similar but rooted in ProfessionalService instead of FinancialService, and the Service types describe advisory offerings (jurisdictional analysis, structuring services, ongoing compliance support) rather than financial products.

For a tokenization platform serving institutional buyers, SoftwareApplication plus ProfessionalService is the typical pairing — the platform itself is software, and the team that delivers integration is a professional service.

What schema mistakes break the most?

Three failure patterns we see most often when auditing client sites.

Mismatched between schema and visible content. Schema declares the article was authored by Person X; the visible byline says “Editorial Team”. Schema declares the firm is a LegalService; the firm is actually a marketing agency. AI tools that catch the mismatch treat the schema as untrustworthy and downweight the entire page.

Missing or stale dateModified. The Article schema’s dateModified should update whenever the content is meaningfully edited. Many CMS implementations only update the visible “last updated” date but not the schema, or vice versa. The mismatch confuses freshness signals.

Validation errors on edge cases. Schema validates fine for the primary case but breaks on edge cases: missing required properties in a sub-entity, type mismatch (string where date is expected), broken sameAs URLs. Schema validators flag these but a lot of CMS-implemented schemas never get validated post-deployment.

We run schema validation as part of every page rewrite under the GS Playbook. The validation has to pass 100% on Schema.org Validator and Google Rich Results Test before the page ships. Anything less is technical debt that will eventually need to be paid back.

How long does a full schema rebuild take?

For a typical mid-market crypto site with 30–80 indexed pages, the initial schema rebuild takes 3–6 weeks of senior technical SEO time. The breakdown:

  • Discovery + schema graph design: 1 week
  • Implementation per page template: 1–3 weeks (varies by CMS)
  • Validation + fixes: 1 week
  • Production deployment + monitoring: 1 week

Per-page implementation is faster after the templates are in place — usually under 1 hour per page for new content thereafter. The capital cost is the design and template work; the marginal cost per piece is small.

For sites running on a custom CMS or a complex multi-locale setup, double the timelines and budget. We’ve seen 8–12 week rebuilds on enterprise tokenization platforms with deep product-catalog complexity.

The work is technical SEO, not content work. We staff for it specifically (Inna leads, with a junior or contractor depending on volume) because the implementation requires JSON-LD fluency, JS-rendering awareness, and willingness to work with the client’s dev team. Outsourcing schema work to a generalist content writer produces validation errors and missed opportunities. We’ve inherited too many half-implemented schemas to recommend that path.

If schema is the bottleneck on your AI-citation rate, the discovery call covers what we’d ship and on what timeline. Free, 30 minutes, named lead — Inna is on the call when schema is the agenda.