Turning a legacy wiki into a 5.35M-visit traffic engine
A market leader in the CS2 asset economy had a wiki that held the business back. We rebuilt it as a fast, headless knowledge platform on its own domain, and it now sends organic traffic back to the core product.
A $5B market with no reliable reference
The CS2 digital asset economy is worth more than $5 billion, yet the information about those assets was spread across half a dozen sources. None was definitive, and most were slow or visually inconsistent.
The client, a market leader inside that economy, ran a legacy wiki that had started to constrain the business. The admin interface was rigid, and a crowded UI pulled attention away from the content people came for.
The brief: a structured catalogue of 24,000+ assets on its own domain, built to win organic search traffic and route it back into the core ecosystem.
No one owned the reference
No authoritative record existed for high-tier asset metadata. The market was visibly waiting for one, and whoever built it would own the search traffic.
The interface drove people away
Monetisation-driven layouts distracted from the content, and default game images were low resolution and often covered in user stickers. Bounce rates reflected it.
The admin layer could not scale
The old admin panel was built for a smaller catalogue and team. Growing to 24,000+ entries and editors in 29+ locales meant rewriting it.
Four decisions that made content pay for itself
Give the wiki its own domain
A separate domain lets the catalogue rank in search on its own, and SSO keeps logged-in users inside the core product. SEO was part of the architecture from the first sprint, so the platform could become a traffic source instead of a maintenance cost.
Build our own image pipeline
Official game APIs return low-resolution images, often defaced by stickers. Our pipeline filters for sticker-free items and converts them to 2K/4K WebP. Pages look authoritative and load fast, which both feed search rankings.
Trust no single data feed
In a volatile market every feed has anomalies, downtime and stale data. A backend engine combines pricing, volume and metadata streams in real time and flags outliers, and a separate service parses game files directly so new assets appear before third-party feeds catch up.
Separate editing from delivery
A headless setup lets editors and translators work in their own admin with role-based access while readers get sub-100ms pages. It is more to operate, and we would not choose it by default. Here, read speed and editor velocity both mattered.
Weeks 1–4 · Discovery and prototyping
UI/UX design, blueprint, ADRs.
Weeks 5–12 · MVP build
Backend engine, headless CMS, SSO.
Weeks 13–20 · Global scaling
Multilingual search and 4K media migration.
After launch · Handover
The client's team takes over its evolution.
The client's team now runs the traffic engine
The platform runs as an autonomous traffic engine for the core ecosystem. It built an SEO authority score of 48 from a standing start within the engagement window, and readers stay for eight minutes on average.
After launch the platform was handed over to the client's team, which now leads its continuous evolution: new interactive tools, SEO coverage for emerging markets and ongoing refinement of content delivery.
5.35M
monthly visits
909.82K
monthly organic search visitors
08:03
average session duration
48
SEO authority score, built from zero
5.35M
monthly visits, 80% ecosystem referral
909.82K
monthly organic search visitors
< 100ms
global API latency
24,000+
unique asset entries
29+
languages supported
10–15%
cloud footprint vs comparable platforms
A headless wiki catalogue with custom multilingual search, a role-based CMS for admins, editors and translators, a 2K/4K image pipeline, multi-source data aggregation and SSO into the core platform.
Next.js + TypeScript · NestJS · Node.js · Tailwind CSS · AWS EC2 + S3 · PostgreSQL 17.5 (RDS) · Valkey 8.0.1 (ElastiCache) · Terraform · GitLab CI/CD · Playwright · JMeter · Grafana
Questions about this project
Why headless for a content platform at this scale?
Headless architecture (in this case Next.js on the frontend, Nest.js on the backend) decouples content management from delivery, which is what lets the platform serve sub-100ms responses to millions of users while editors work in a separate, optimised admin interface. The trade-off is operational complexity (two systems to run, not one), and we don't recommend headless by default. For content-first platforms where read performance and editor velocity both matter, the trade-off is worth it.
How long does building a platform like this take?
The deployment cycle here was 20 weeks: 4 weeks of discovery and prototyping, 8 weeks of MVP engineering, 8 weeks of global scaling. That timeline reflects a defined scope: 24,000+ entries, 29+ locales, sub-100ms global latency. Projects with materially different scope or constraints land in different windows.
How does automated media processing affect SEO?
In two ways. First, asset quality directly affects user signals (bounce rate, dwell time, perceived authority), which Google has used as ranking inputs for years. High-fidelity, sticker-free 2K/4K assets read as authoritative. Second, optimised WebP delivery reduces page weight, which improves Core Web Vitals scores. The combination of both is what generated the organic traffic curve.
Can a wiki catalogue be cleanly integrated with an existing product ecosystem?
Yes, if it's designed for it from the start. The pattern that worked here was a separate domain, so the wiki could rank independently in search, combined with SSO and ecosystem integration on the user side. This let the platform operate as an autonomous traffic source while staying part of the core product experience for logged-in users.
How do you maintain data integrity across 24,000+ entries in a volatile market?
By treating no single data source as authoritative. The backend engine aggregates and normalises feeds across three stream types (pricing, volume, metadata) in real time, and surfaces anomalies rather than passing them through. When market data disagrees across sources, the platform has explicit logic for resolution rather than silently inheriting one feed's noise.
Can you share the client name?
The client name is withheld under NDA. Get in touch if you'd like to discuss the engagement in more detail under a mutual NDA. We can walk through the architecture and operational decisions at a level not appropriate for public material.
See more cases
Could your content be bringing in customers?
Tell us what you are building. We will come back with an honest view of how we would approach it.