The Token Schema Guide for crypto sites.
Schema selection is the highest-leverage SEO and AEO fix because it is binary, fast and rarely done correctly on crypto sites. This guide covers every JSON-LD type relevant for crypto with copy-paste examples, the decision tree for picking the right type per page and the multi-chain canonical handling pattern.
Why schema correctness matters for crypto
Schema.org is the structured data vocabulary search engines and AI extractors use to understand what a page describes. Wrong schema means the engine misclassifies the page; the page either ranks lower or gets ignored entirely for the queries it should serve.
For crypto specifically, schema correctness compounds across three citation paths.
What correct schema enables
Three compounding wins
- Google rich results for crypto categories (where supported)
- AI extraction databases (ChatGPT, Perplexity, Claude)
- Knowledge graph entities for project recognition
- Schema.org Person resolution for E-E-A-T
- FinancialProduct or CryptoExchange categorization
What wrong schema costs
Three compounding losses
- Generic Product schema gets categorized as merchandise
- AI extractors skip the page or misclassify it
- YMYL trust signals get rejected without Person + sameAs
- Multi-chain duplicate schema reduces confidence scores
- Missing recommended properties downgrade rich results
The single highest-leverage fix
Audit token pages for FinancialProduct (not generic Product), exchange pages for CryptoExchange (not generic Organization), wallet pages for SoftwareApplication (not generic Product). Three template fixes typically improve schema correctness across the entire site.
The schema decision tree by page type
Picking the right schema type is straightforward once you know the rules. Every page on a crypto site falls into one of seven categories. Each category has one correct primary schema type.
Token information pages → FinancialProduct
Pages describing a specific token: tokenomics, supply, market cap, contract address. The page describes a financial instrument, not a product.
Exchange platform pages → CryptoExchange
Homepage and pricing pages of CEX or DEX platforms. The page describes a trading platform with supported assets and trading fees.
Wallet apps → SoftwareApplication
Pages describing wallet apps: features, supported chains, download links. applicationCategory should be FinanceApplication for wallets.
SDKs and APIs → SoftwareApplication
Developer tools, libraries, API documentation. applicationCategory should be DeveloperApplication. Include operatingSystem and codeRepository properties.
Company about pages → Organization
About page, team page (parent), company history. Include foundingDate, founders array, address, sameAs links to social profiles.
Team and founder pages → Person
Individual team member pages or sections within team page. Always include sameAs linking to LinkedIn, GitHub, Twitter for E-E-A-T verification.
Articles and guides → Article or TechArticle
Blog posts, documentation, guides like this one. TechArticle for technical content; Article for general posts. Include author, datePublished, dateModified.
Composite pages combine multiple schema types using @graph. A token information page often includes FinancialProduct (the token), Organization (the project) and FAQPage (the FAQ section). The @graph wrapper handles this cleanly.
FinancialProduct in depth
FinancialProduct is the right type for token information pages. Required properties are name and description. The recommended additions below significantly improve AI extraction quality.
{ "@context": "https://schema.org", "@type": "FinancialProduct", "@id": "https://protocol.com/token#prtc", "name": "PROTOCOL Token", "alternateName": "PRTC", "description": "Native governance token of the PROTOCOL DeFi protocol. Used for voting on protocol upgrades, fee distribution and staking rewards.", "category": "Cryptocurrency", "feesAndCommissionsSpecification": "https://protocol.com/fees", "interestRate": { "@type": "QuantitativeValue", "value": "4.2", "unitText": "PERCENT" }, "provider": { "@type": "Organization", "@id": "https://protocol.com/#org", "name": "PROTOCOL Foundation", "url": "https://protocol.com" }, "identifier": [ { "@type": "PropertyValue", "propertyID": "contractAddress", "value": "0x1234...5678" }, { "@type": "PropertyValue", "propertyID": "chain", "value": "Ethereum" } ] }
Three patterns make this example work. First, identifier array uses PropertyValue to expose contract address and chain as structured facts. Second, provider links the token to its Organization entity using @id reference. Third, interestRate exposes APY as a QuantitativeValue (not free text), which AI extractors parse cleanly.
Property recommendations
Required: name, description. Strongly recommended: category, provider, identifier (contract address). Optional but high-value: feesAndCommissionsSpecification, interestRate, alternateName (ticker).
CryptoExchange in depth
CryptoExchange describes the trading platform itself. Use it on the homepage, pricing pages and platform description pages. For individual token landing pages on the exchange, use FinancialProduct instead.
{ "@context": "https://schema.org", "@type": "CryptoExchange", "@id": "https://exchange.com/#org", "name": "EXCHANGE", "url": "https://exchange.com", "description": "Centralized crypto exchange supporting 380+ trading pairs across BTC, ETH and major altcoins. Operating since 2019, regulated as MSB in the United States.", "foundingDate": "2019-03-15", "address": { "@type": "PostalAddress", "addressCountry": "US", "addressRegion": "NY" }, "hasOfferCatalog": { "@type": "OfferCatalog", "name": "Supported trading pairs", "itemListElement": [ { "@type": "Offer", "itemOffered": { "@type": "FinancialProduct", "name": "BTC/USD" } }, { "@type": "Offer", "itemOffered": { "@type": "FinancialProduct", "name": "ETH/USD" } } ] }, "sameAs": [ "https://twitter.com/exchange", "https://www.linkedin.com/company/exchange" ] }
The hasOfferCatalog pattern lets you expose supported assets directly in schema. Each Offer wraps a FinancialProduct. AI extractors use this to answer "does EXCHANGE support TOKEN" prompts directly without needing to crawl individual pages.
Regulatory disclosure in schema
Mention regulatory status in the description (MSB, MiCAR, BitLicense, FCA registered). This signals to AI extractors that the platform is regulated and to YMYL trust models that the entity is legitimate.
SoftwareApplication for wallets and SDKs
SoftwareApplication is the right type for any installable or hosted software. For crypto specifically, it covers wallets, SDKs, protocol clients, browser extensions and APIs. The applicationCategory property differentiates use cases.
{ "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://wallet.com/#app", "name": "WALLET", "applicationCategory": "FinanceApplication", "operatingSystem": "iOS, Android, Chrome, Firefox, Edge", "description": "Self-custody crypto wallet supporting 50+ chains. Audited by Trail of Bits in October 2024.", "offers": { "@type": "Offer", "price": "0", "priceCurrency": "USD" }, "aggregateRating": { "@type": "AggregateRating", "ratingValue": "4.7", "reviewCount": "12500" }, "downloadUrl": [ "https://apps.apple.com/app/wallet", "https://play.google.com/store/apps/details?id=com.wallet" ] }
For SDKs, switch applicationCategory to DeveloperApplication and add codeRepository pointing to the GitHub repo. The repository link doubles as a freshness signal because AI engines weight active GitHub activity heavily for crypto trust signals.
{ "@context": "https://schema.org", "@type": "SoftwareApplication", "name": "PROTOCOL SDK", "applicationCategory": "DeveloperApplication", "operatingSystem": "Node.js, Python, Rust", "codeRepository": "https://github.com/protocol/sdk", "programmingLanguage": ["TypeScript", "Python", "Rust"], "softwareVersion": "3.2.0", "datePublished": "2026-04-01" }
Browser extension specifics
For browser extension wallets and tools, list operatingSystem as the browsers supported (Chrome, Firefox, Edge, Brave). Avoid the common mistake of listing only "Web" or "Browser". The specific browser names work better for AI extraction.
Organization and Person for E-E-A-T
Organization schema describes the project entity itself. Person schema describes individual team members. Both matter for E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness), which Google weights heavily on YMYL pages.
{ "@context": "https://schema.org", "@type": "Organization", "@id": "https://protocol.com/#org", "name": "PROTOCOL Foundation", "url": "https://protocol.com", "foundingDate": "2022-08-15", "founders": [ { "@type": "Person", "name": "Jane Doe", "sameAs": [ "https://twitter.com/janedoe", "https://github.com/janedoe", "https://www.linkedin.com/in/janedoe" ] } ], "sameAs": [ "https://twitter.com/protocol", "https://github.com/protocol", "https://www.linkedin.com/company/protocol" ] }
Person schema goes on team pages with one Person entity per team member. The sameAs array is the most important property: links to LinkedIn, GitHub, Twitter verify the person is real and active in the crypto community.
{ "@context": "https://schema.org", "@type": "Person", "name": "Jane Doe", "jobTitle": "Co-Founder, CTO", "worksFor": { "@type": "Organization", "@id": "https://protocol.com/#org" }, "alumniOf": [ { "@type": "Organization", "name": "MIT" }, { "@type": "Organization", "name": "ConsenSys" } ], "sameAs": [ "https://twitter.com/janedoe", "https://github.com/janedoe", "https://www.linkedin.com/in/janedoe" ] }
Why sameAs matters for crypto
Anonymous-founder projects struggle to score E-E-A-T regardless of technical SEO. Person schema with sameAs links to LinkedIn, GitHub and Twitter is the technical implementation of E-E-A-T author signals. If a founder is doxxed and verifiable, the schema should reflect that.
Multi-chain canonical handling
Multi-chain documentation is where most crypto sites lose schema correctness. The pattern that works: keep schema canonical to the chain-agnostic primary version. Per-chain subdomains use the same schema with the same canonical URL.
The wrong pattern
Duplicate schema per chain
- docs.protocol.com has SoftwareApplication schema
- docs-bnb.protocol.com has duplicate schema with different chain
- docs-arbitrum.protocol.com has third copy
- AI extractors see 3 conflicting facts about the same product
- Confidence score reduced for all 3
The right pattern
One canonical, parameterized chain views
- docs.protocol.com is canonical with full schema
- docs-bnb.protocol.com points canonical to docs.protocol.com
- Per-chain pages reuse same @id reference
- Chain-specific facts go in identifier array, not separate schema
- AI extractors see one product with chain-specific deployments
{ "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://protocol.com/#sdk", "name": "PROTOCOL SDK", "applicationCategory": "DeveloperApplication", "identifier": [ { "@type": "PropertyValue", "propertyID": "deployment-ethereum", "value": "0xETH...ADDR" }, { "@type": "PropertyValue", "propertyID": "deployment-bsc", "value": "0xBSC...ADDR" }, { "@type": "PropertyValue", "propertyID": "deployment-arbitrum", "value": "0xARB...ADDR" } ] }
When implementations truly differ
If the SDK genuinely differs across chains (different methods, different gas behavior, different security model), separate canonical with hreflang-style chain attribute is acceptable. For most multi-chain products, the implementation is the same and one canonical wins.
Validation tools and testing
Schema validation is a three-step process. Each tool catches different classes of issues. All three should pass before deploying schema changes to production.
Google Rich Results Test
Catches Google-specific issues: missing required properties for rich results eligibility, deprecated property usage, structured data warnings. Free at search.google.com/test/rich-results. Use for live URLs and code snippets.
Schema.org validator
Catches generic schema correctness: invalid type usage, missing required properties, malformed @id references, JSON-LD parsing errors. Free at validator.schema.org. Use as the cross-check after Google passes.
Crawlux Token Schema Tester
Catches crypto-specific issues: wrong type for token pages (Product instead of FinancialProduct), missing recommended properties for FinancialProduct and CryptoExchange, inconsistent schema across templates. Free at the tester page.
The validation workflow
Generate schema in code, paste into Google Rich Results Test, fix any errors. Cross-check in Schema.org validator, fix any warnings. Test the live URL through Crawlux Token Schema Tester for crypto-specific checks. All three pass means the schema works.
Common schema mistakes
Five schema mistakes appear in nearly every crypto site audit. Each has a specific fix; collectively they account for most schema-related citation failures.
Mistake 01 · Generic Product on token pages
The most common crypto SEO error
- Token info pages with Product schema
- AI extractors classify as merchandise, not financial instrument
- Lost rich results eligibility for crypto categories
Fix
FinancialProduct with category Cryptocurrency
- Switch @type to FinancialProduct
- Add category Cryptocurrency
- Include identifier array with contract address and chain
Mistake 02 · Missing sameAs on Person
Anonymous-looking team pages
- Person schema without LinkedIn, GitHub, Twitter
- YMYL trust signals fail to verify identity
- E-E-A-T author signals get rejected
Fix
Add sameAs array on every Person
- LinkedIn URL (most weighted by Google)
- GitHub URL (crypto trust signal)
- Twitter or Mastodon URL
Mistake 03 · Schema in JS render only
JSON-LD inserted by JavaScript
- Schema generated client-side via React or Vue
- 69% of AI crawlers cannot execute JS
- Schema invisible to most AI extractors
Fix
Server-render schema in initial HTML
- Next.js getStaticProps or getServerSideProps
- Vue: ssrContext or Nuxt static
- Output JSON-LD in initial HTML response
Mistake 04 · Duplicate schema across templates
Inconsistent type usage
- Token page A uses FinancialProduct
- Token page B uses Product (older template)
- AI extractors see inconsistency, lower confidence
Fix
Centralize schema generation
- One getSchema utility per page type
- Used across all templates of that type
- Audit existing templates for inconsistencies
Mistake 05 · Missing @id references
Disconnected entities
- FinancialProduct mentions provider Organization
- No @id reference linking to actual Organization entity
- AI extractors cannot resolve entity relationships
Fix
Use @id consistently across entities
- Each Organization gets stable @id
- Each Person gets stable @id
- Reference @id from related entities
The companion Crypto SEO Guide covers schema in the broader audit context. The AI Visibility Guide covers how AI extractors specifically use schema for citation decisions.
Common questions
Eight schema selection and validation questions that come up most often.
Which schema type should I use for a token information page?
FinancialProduct is the right schema type for token information pages. It tells search engines and AI extractors that this page describes a financial instrument, not a generic product. Required properties: name, description, category. Recommended additions: tickerSymbol, marketCapitalization (numeric), priceCurrency, feesAndCommissionsSpecification, provider (Organization). Avoid generic Product schema on token pages; it is the most common crypto SEO mistake.
When should I use CryptoExchange vs FinancialProduct?
CryptoExchange describes the platform itself; FinancialProduct describes individual assets. Exchange homepage and pricing pages: CryptoExchange. Specific token landing pages on the exchange: FinancialProduct. Trading pair pages: ItemList containing FinancialProduct entries. The two schemas can co-exist on a site, applied to different page templates.
What is the right schema for a wallet app page?
SoftwareApplication with applicationCategory FinanceApplication is the right type for wallet pages. Include operatingSystem (iOS, Android, Chrome Extension), offers (Free with priceCurrency USD), aggregateRating if you have store reviews, downloadUrl pointing to the App Store and Play Store. The same SoftwareApplication type with applicationCategory DeveloperApplication works for SDK and API documentation pages.
Do I need both Organization and Person schema?
Yes for E-E-A-T signals. Organization schema goes on the homepage and About page describing the project entity itself. Person schema goes on team pages with sameAs linking to LinkedIn, GitHub, Twitter for each named team member. Crypto YMYL signals weight founder identity heavily; anonymous-founder projects struggle to score E-E-A-T regardless of technical SEO. Person schema with verified sameAs links is the technical implementation of E-E-A-T author signals.
How do I handle multi-chain documentation in schema?
Keep schema canonical to the chain-agnostic primary version. Per-chain subdomains (docs-bnb, docs-arbitrum) should use the same SoftwareApplication schema with the same name and the same canonical URL pointing to the primary version. Avoid duplicating schema across chain-specific URLs; that creates conflicting facts AI extractors will weight as low confidence. Same canonical, same schema, parameterized chain views.
Which schema validators should I use?
Use three validators sequentially. Google Rich Results Test catches Google-specific issues. Schema.org validator catches generic schema correctness. The Crawlux Token Schema Tester catches crypto-specific issues like wrong type for token pages, missing recommended properties for FinancialProduct and inconsistent schema across templates. All three should pass before deploying schema changes.
Does schema work for AI search if Google does not index the page?
Yes. Google indexation and AI search citation are independent paths. ChatGPT, Perplexity and Claude crawl independently of Google. Schema parsed at crawl time gets added to AI extraction databases regardless of Google indexation status. A page blocked from Google but crawlable by AI bots still benefits from correct schema. Allow both Google and AI bots in robots.txt for full coverage.
Can I use multiple schema types on one page?
Yes, common pattern. A token information page might use FinancialProduct (the token itself) plus Organization (the project) plus FAQPage (the FAQ section) plus BreadcrumbList. Use @graph to wrap multiple entities in a single JSON-LD block. Each entity gets its own @type and @id. AI extractors handle multiple entities cleanly when wrapped in @graph; they get confused when entities are duplicated across separate JSON-LD blocks.
RUN YOUR FIRST AUDIT FREE
See Crawlux on your own crypto site.
No signup, no credit card. Full Web3-tuned audit report in 60 seconds.
Free first audit · No signup · 60 seconds · Full PDF report