Token Page Structured Data: The Complete Schema Reference

Why FinancialProduct is the right base type

The single most common schema mistake on crypto sites is using Product when the page describes a token. Product is for physical goods or generic merchandise. FinancialProduct is for monetary instruments. To Google and to AI extraction models, these two types signal completely different things.

A page marked Product gets categorized as e-commerce. The AI extracts price, availability, ratings and seller. None of those map cleanly onto a token. A page marked FinancialProduct gets categorized as a financial instrument. The AI extracts the right properties: ticker symbol, exchange listings, holder count, supply metrics, audit history.

The fix is binary. Either your token page exposes FinancialProduct schema or it does not. The difference in AI citation rate between sites that get this right and sites that get it wrong is often 30 to 40 percentage points.

The base FinancialProduct template for any token

This is the minimal viable schema for a token landing page. Every property serves AEO extraction; do not omit any of them. Below the JSON, we walk through what each property does.

{
  "@context": "https://schema.org",
  "@type": "FinancialProduct",
  "name": "Example Token",
  "alternateName": "EXMP",
  "description": "Layer-1 utility token powering the Example Network. Used for staking, governance and transaction fees.",
  "url": "https://example.com/token/",
  "category": "Cryptocurrency",
  "feesAndCommissionsSpecification": "Network transaction fees vary by chain congestion. No protocol-level fees on transfers.",
  "interestRate": {
    "@type": "QuantitativeValue",
    "value": 4.2,
    "unitText": "% APY for staked tokens"
  },
  "provider": {
    "@type": "Organization",
    "name": "Example Foundation",
    "url": "https://example.org/"
  }
}}

name and alternateName. The full token name and the ticker symbol. Both are needed because AI engines extract both. Queries about "EXMP token" route to the alternateName; queries about "Example Token" route to the name.

description. One paragraph. State the layer (Layer-1, Layer-2, Layer-2 rollup), the network and the primary use cases. Use plain language. Marketing-speak does not survive AI extraction.

category. "Cryptocurrency" is correct for fungible tokens. "Non-Fungible Token" or "NFT Collection" for ERC-721 and ERC-1155. The AI uses this to route the page into the right citation category.

provider. Organization schema for the issuer. Critical for E-E-A-T and authority signals. AI engines weight provider authority heavily for YMYL crypto content.

Extending with AggregateRating and Review

Ratings and reviews are extension properties. They make the page eligible for star ratings in Google rich results and provide direct signal to AI extraction. Add them when the underlying review data is real; never fabricate.

{
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 124,
    "bestRating": 5,
    "worstRating": 1
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Independent reviewer name" },
      "reviewRating": { "@type": "Rating", "ratingValue": 5 },
      "reviewBody": "Real review text quoted directly from the source."
    }
  ]}

Where do ratings come from. CoinGecko has community ratings for major tokens. Audit firms publish numerical scores. Token analytics platforms publish trust ratings. Pull from real sources, attribute correctly, link to the original.

Common mistake: aggregating internal reviews and presenting them as a community rating. Google's review guidelines specifically prohibit self-serving aggregation. AI extraction models are also trained to deprioritize self-aggregated reviews because they correlate with low-quality content.

Adding exchange rate and price metadata

Token pages routinely show price data. Exposing that price data via schema lets AI engines cite it directly when answering questions about the token's value or trading pairs.

{
  "exchangeRateSpecification": {
    "@type": "ExchangeRateSpecification",
    "currency": "USD",
    "currentExchangeRate": {
      "@type": "UnitPriceSpecification",
      "price": 1.247,
      "priceCurrency": "USD"
    },
    "exchangeRateSpread": {
      "@type": "MonetaryAmount",
      "value": 0.002,
      "currency": "USD"
    }
  },
  "offers": [
    {
      "@type": "Offer",
      "price": 1.247,
      "priceCurrency": "USD",
      "seller": { "@type": "Organization", "name": "Coinbase" },
      "url": "https://www.coinbase.com/price/example-token"
    },
    {
      "@type": "Offer",
      "price": 1.249,
      "priceCurrency": "USD",
      "seller": { "@type": "Organization", "name": "Binance" }
    }
  ]}

Two things to know. First, price data goes stale fast. Either update the schema in real-time (server-side render with current price) or omit the price node and use a separate live ticker. Stale schema prices hurt more than missing prices.

Second, offers should reflect actual exchange listings. Listing exchanges where the token is not actually tradeable is misleading and gets caught by manual review. Pull the live listing data from your token's CoinGecko or CoinMarketCap entry.

Schema for ERC-721 collections and NFT marketplaces

NFT collection pages need a different shape than fungible token pages. The base type is still FinancialProduct, but the extensions diverge. Floor price, total supply, holder count and trait distribution are the properties that matter.

{
  "@context": "https://schema.org",
  "@type": "FinancialProduct",
  "name": "Example Collection",
  "alternateName": "EXC",
  "description": "10,000 unique generative art pieces on Ethereum mainnet. Each NFT grants membership access to the Example DAO.",
  "category": "NFT Collection",
  "image": "https://example.com/collection-cover.png",
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Total supply", "value": "10000" },
    { "@type": "PropertyValue", "name": "Unique holders", "value": "4283" },
    { "@type": "PropertyValue", "name": "Floor price", "value": "1.24 ETH" },
    { "@type": "PropertyValue", "name": "Contract standard", "value": "ERC-721" },
    { "@type": "PropertyValue", "name": "Chain", "value": "Ethereum" }
  ]}

Use additionalProperty for collection-specific metadata. PropertyValue is flexible and AI extraction handles it well. Avoid stuffing properties; pick the five that buyers actually ask about. Total supply, holders, floor price, standard, chain. That is the set.

For individual NFT pages within the collection, switch to a Product schema with offers reflecting the listed price. The collection page is FinancialProduct (a financial instrument); the individual NFT page is Product (a unique listed item).

The schema validation chain that actually works

Schema that does not validate is schema that does not work. Run every page through three validators before shipping. They catch different errors and you need all three to pass.

Validator 1: Google Rich Results Test. Tests SERP eligibility. If your schema does not pass this, you are not eligible for rich snippets in Google search. Common failures: missing required properties, wrong type, malformed dates.

Validator 2: Schema.org validator. Tests spec conformance. Catches errors the Google tool misses, especially around extension properties and nested types. More strict than Google.

Validator 3: Crawlux Token Schema Tester. Tests crypto-specific patterns. Catches things the generic validators do not: missing FinancialProduct extensions, stale exchange rate data, mismatched ticker symbols. The free tester covers FinancialProduct, CryptoExchange and NFT collection variants.

All three pass means the schema is ready to ship. Two out of three is not good enough; ship only after all three pass. The cost of a re-deploy is much lower than the cost of getting cited incorrectly or not at all.

Continue exploring

More tactical pieces from the Crawlux blog. Picked because they relate to the topic above.