How OVR Rebuilt Schema Architecture and Quadrupled Organic Traffic
AR/VR + NFT platform with 200+ pages running default Article schema. Most marketing pages were CSR React, invisible to crawlers. The fix was structural across schema, rendering and content depth.
Client context
OVR is an augmented and virtual reality platform that maps the world into NFT-owned hexagonal cells. Users buy, sell and build experiences on these cells through the OVR marketplace. The team came in with a real product, real users and real revenue but a website that Google couldn't fully see.
The site was built on a React SPA with client-side rendering. Marketing pages, NFT collection pages and ecosystem listings all rendered after JavaScript executed. Google's crawler can render JS but does so on a delayed budget; for a content-heavy site this meant most pages weren't getting indexed reliably.
On top of that, every content page emitted Article schema by default. NFT collection pages (which describe digital products with floor prices) were marked as articles. Protocol-level explainer pages were marked as articles. The schema was wrong by design across hundreds of URLs.
The team had been getting solid branded traffic but losing on every comparison and category query in their space. Searches like "AR NFT platform", "virtual real estate NFTs" and "metaverse land marketplace" were going to competitors with weaker products but stronger SEO foundations.
The problem
Three structural issues compounded each other.
First, the rendering model. About 70% of marketing and content pages were CSR React. Google's crawl budget for delayed JS rendering meant freshly-published pages took weeks to get indexed. Update cycles also broke: editing an NFT collection description required a re-crawl that often didn't happen for the next major Googlebot pass. Competitor sites running SSR or SSG were getting indexed in days while OVR was getting indexed in weeks.
Second, the schema problem. Yoast was installed and emitting Article schema on every post type by default. Across the inventory we found:
- NFT collection pages: marked as Article (should be ItemList + Product)
- Per-cell pages: marked as Article (should be Place + Cryptocurrency)
- Marketplace pages: marked as Article (should be Service + Offer)
- Token information page: marked as Article (should be Cryptocurrency + FinancialProduct)
- Build/develop pages: marked as Article (should be Service)
Third, the NFT collection pages were thin. Most listed under 500 words of generic copy with the floor price hardcoded as static text. Floor prices change hourly. Stale data on schema-incorrect pages told Google the content was both unstructured and stale. Bad combination.
The combined impact: organic traffic was a fraction of what the product's actual user base and brand recognition should have been driving. The team knew something was off but the multi-layered nature of the problem made it hard to point at one thing.
The audit
The TG3 audit took two weeks and produced a prioritized list of 47 issues across schema, rendering, content depth and internal linking.
Highest-impact findings:
The schema migration was the biggest single opportunity. Templates in WordPress were emitting Article by default. Replacing those templates with type-appropriate schemas (FinancialProduct for token pages, Service for marketplace, Place + Cryptocurrency for cell pages, ItemList + Product for collections) would enable rich result eligibility across hundreds of pages without touching a single piece of content.
The CSR rendering issue had two viable paths: full SSR rebuild or migrate marketing/content pages to SSG while keeping the actual application (the marketplace, the cell viewer) as CSR. We recommended the second path because it preserved all the interactive product surface while fixing the SEO-critical pages.
NFT collection pages needed expansion. We recommended a target of 1,500-2,000 words per major collection with live floor prices pulled from the OVR marketplace API and re-rendered hourly via SSG with ISR (incremental static regeneration). The static fallback would always have a recent floor price; the dynamic update would keep it fresh.
Internal linking was thin. Marketing pages didn't link to ecosystem listings. Ecosystem pages didn't link back. There was no /ecosystem/ index. Building one with categorized sub-pages (creators, collections, locations) would capture long-tail queries that the existing architecture missed.
FREE WEB3 AUDIT
Get the same audit type for your site.
Run the same Crawlux audit on your crypto domain. Free first audit, full PDF report.
Free first audit · No signup · 60 seconds · Full PDF report
The work
Schema migration across 200+ pages
Built a schema mapping document covering every URL pattern on the site. Each pattern got assigned a target schema type (FinancialProduct, Service, Place, Cryptocurrency, ItemList) and the migration ran template-by-template through the WordPress backend.
Yoast's default Article emission was overridden via the wpseo_schema_graph_pieces filter for each affected post type. Custom JSON-LD injection replaced it with the correct type. The @graph wrapper let us stack BreadcrumbList and FAQPage on every page cleanly. We built one PHP filter per affected template rather than a blanket override because some legitimate Article pages (the actual blog posts) needed to keep emitting Article schema.
The mapping document had four columns: URL pattern, current schema, target schema, complications. Most rows were straightforward. Collection pages → ItemList + Product. Token information → FinancialProduct + Cryptocurrency. The complications column captured the edge cases: collection pages where some items were physical-world location-tied (cells) and others were purely virtual (avatars), per-cell pages where cells had no associated NFT yet, archived collections that had been retired but kept indexed for SEO history.
Before migration: only a small minority of pages had schema appropriate to their content type. After migration: the majority of pages did. The validation pass caught about a dozen edge cases which got bespoke handling rather than blanket treatment. Schema.org Validator, Google Rich Results Test and Bing Markup Validator all passed clean within the second iteration.
CSR React → Next.js SSG migration
We didn't rebuild the entire site. The marketplace application stayed as CSR because that's where users interact with their wallets and live data. We migrated only the marketing pages, the NFT collection pages, the ecosystem directory and the help/docs sections to Next.js with static generation plus ISR for the floor-price-dependent collection pages.
This kept the dev team's actual product surface untouched while moving the SEO-critical content to a rendering model crawlers could parse on first request. ISR with a one-hour revalidation gave us static-fast initial loads with hourly floor price updates.
Crawlable content went from approximately 30% of pages to effectively all of them. First-pass indexation latency dropped from weeks to days.
NFT collection page expansion
Each major collection got a content rewrite. Target was 1,500-2,000 words covering: collection origin and creator, themes and aesthetic, notable cells included, secondary market activity, links to creator's other work and how to acquire.
The live floor price block became a structured data feature. Pulled from the OVR marketplace API at build time, displayed prominently with a "last updated" timestamp. Schema-tagged the floor price as a Product offer with priceValidUntil set to the next ISR window.
This single change caused the biggest individual ranking shift. Collection pages that had been struggling to rank for their own collection name started ranking for category-level queries ("virtual real estate NFTs", "AR cell collections").
Ecosystem directory build
Built /ecosystem/ as a categorized index of everything happening on OVR. Categories: creators, locations, experiences, collections, infrastructure. Each category got its own page with editorial commentary plus a filtered grid. Per-creator and per-collection pages stacked on top.
The ItemList + Service schema across the directory captured a substantial volume of long-tail queries that the previous architecture missed entirely. Things like "AR experiences in Milan", "OVR creators to follow", "virtual events Berlin" all started ranking within the first 90 days.
We also built the /ecosystem/submit/ flow so new creators could apply for inclusion. Manual review kept quality high while signaling to Google that the directory was active and growing.
Results
Within 90 days of the full migration going live, the headline outcomes:
Organic traffic more than quadrupled. The lift wasn't evenly distributed. Marketing pages saw modest gains. NFT collection pages and ecosystem directory pages drove most of the new volume.
Indexation became reliable. Pages published after the migration got indexed within a few days rather than weeks. The Search Console "Discovered, not indexed" queue shrank dramatically.
Schema-eligible pages went from a small minority to the majority. Rich result enhancements (FAQ, Sitelinks Search Box, BreadcrumbList) showed up across the new architecture.
Long-tail capture grew substantially. Hundreds of new query patterns started driving traffic, mostly from the ecosystem directory and expanded collection pages.
The migration paid for itself within the first quarter on traffic value alone. Conversion to product signups (the metric that mattered to the OVR team) lifted alongside the traffic but with a lag because the buying funnel takes weeks for high-consideration NFT purchases.
5 tactical lessons you can apply
Schema migrations beat content rewrites for ROI
Across 200+ pages, switching schema templates took two weeks of dev work. The same dev capacity spent on content rewrites would have touched maybe 30 pages. Schema migrations scale; content rewrites don't. When you're schema-broken at architectural scale, fix the schema first.
Hybrid rendering beats pure SSR for Web3 platforms
Pure SSR would have created new problems with wallet integrations and live data display. Pure CSR was the original problem. SSG for content + CSR for application is the right architecture for almost every Web3 platform with a meaningful product surface.
ISR plus live API beats fully dynamic rendering
Floor prices change hourly. Updating them via ISR with a 60-minute revalidation gave us static-fast initial loads with hourly freshness. Crawlers see static HTML. Users see current prices. The dual-purpose pattern works for any time-sensitive data on a static site.
Ecosystem directories should be category-deep not just project-listed
An ecosystem directory with 200 projects in a flat list captures less long-tail traffic than the same 200 projects across 5 categorized sub-pages with editorial commentary. Categorization captures category queries; per-project pages capture branded queries. Build both.
Capture an AEO baseline before you start work
We measured AEO citations after the migration and saw clear improvement but couldn't cleanly attribute it to specific changes because the pre-migration baseline was missing. Always capture baseline citation rates on your top 10-20 queries before starting any major SEO project.
AB's takeaway
The OVR engagement reinforced something we already believed: schema is the highest-ROI lever in Web3 SEO. Most other SEO work is incremental. Schema migration is structural. When you go from wrong to right across hundreds of pages, the lift compounds across every query type touching those pages.
The CSR-to-SSG decision was contentious. Some on the OVR team wanted a full SSR rebuild for "cleaner" architecture. We pushed back hard because the marketplace application genuinely needed CSR for wallet interactions and live data. Hybrid rendering (SSG for content, CSR for application) is the right pattern for most Web3 platforms. Going pure SSR would have created new problems while solving old ones.
If we'd had to pick one thing to do first with limited budget, it would have been schema. The CSR-to-SSG migration accelerated indexation but the schema migration drove rankings. Order matters.
What we'd do differently
Two things in hindsight.
First, we'd have run a baseline AEO citation rate test before starting. We measured AEO citations after the migration and they had clearly improved but we couldn't cleanly attribute the improvement to specific changes because we didn't have a pre-migration baseline. AEO measurement was newer back then; now we always capture it before any project starts.
Second, we'd have built the ecosystem directory before the schema migration rather than alongside it. The directory generated dozens of new internal links to product pages. Doing it first would have meant the schema migration went live with stronger internal link signals already pointing at the migrated pages. We did them in parallel which worked but sequencing them differently might have accelerated the ranking impact.
TG3 came in with a clear thesis and executed against it. The schema migration alone was worth the engagement; the ecosystem directory has been driving qualified discovery traffic ever since. They understand crypto SEO at a level most agencies don't.
Run a free Crawlux audit on your site
The audit identifies which schema, technical and AEO issues are blocking your rankings. Same diagnostic framework we used at OVR.
Run free audit →Related playbooks
Pillar guides
RUN YOUR OWN AUDIT
See what Crawlux finds on your site.
These results came from the same audit you can run for free on your own domain. 60-second turnaround.
Free first audit · No signup · 60 seconds · Full PDF report