In this article
My hreflang build for three language versions of this site went live this week. Below is the exact markup running in production right now, pulled straight from the page source, not a mockup.
You're weighing the same call I made: translate the site, or skip it and stay English-only.
This is the framework I used to decide, plus the live tags I actually shipped. It's not a six-month case study with a results graph.
I'll cover which languages actually earn a version, how hreflang holds up on a JavaScript-heavy stack, and what to measure once it's live. My guide to web3 SEO covers the rest of the cluster.
Why Web3 Search Demand Is Multilingual by Default
Web3 search demand is multilingual because crypto adoption itself is multilingual, and English-only content opts out of most of it by default, not by decision.
Chainalysis's 2025 Global Crypto Adoption Index ranks India first, for the third year running. The US is second.
Pakistan, Vietnam, and Brazil round out the top five. Latin America's on-chain transaction value grew 63% year over year in that same report, one of the fastest rates of any region tracked.
None of those five markets run primarily on English-language search. A protocol shipping English-only content isn't ignoring a niche audience. It's ignoring most of its own addressable demand.
Nigeria ranks sixth on the same index, extending the same pattern into Africa. Adoption concentrates in LATAM, South Asia, Southeast Asia, and Africa, not in English-first markets.
That's the case for going multilingual at all. It says nothing yet about which languages, and that's where most projects guess.
Which Languages Actually Earn a Site Version
A language earns a site version when search demand and a real, maintainable presence both point at it. Adoption looking big on a chart isn't enough on its own.
I use three questions before adding a language, not one.
| Signal | Question to ask | What it rules out |
|---|---|---|
| Search demand | Does keyword volume in that language exist for your actual topics? | A market with high adoption but zero search volume for your niche |
| Community location | Is your audience active in that language, not just statistically present? | Translating for a market you don't actually operate in yet |
| Maintainable presence | Do you or your team have a real, verifiable connection to that market? | Vanity translation nobody keeps current after launch |
Here's how that played out on my own site. I picked pt-BR because I'm based in Florianópolis, Brazil, and Brazil sits at #5 on the same Chainalysis index above.
I picked es because one build covers a wide Spanish-speaking LATAM footprint at once. I skipped Hindi and Urdu, even though India and Pakistan both outrank Brazil on that index.
I have no team or community presence in either market yet. Translating into a language I can't maintain isn't international SEO. It's vanity translation with extra steps.
Key Insight
The market-picking test isn't "where's the biggest opportunity." It's "where do I have search demand and a real presence to back it up." Adoption rank alone answers neither half.
hreflang on a Crypto Site: What Actually Ships in Production
hreflang tags tell search engines which URL to serve for which language and region. On mangabeira.net, every article carries four: English, Portuguese for Brazil, Spanish, and an x-default fallback pointing to English.
This is the exact pattern, pulled from a live article's rendered page head:
<link rel="alternate" hreflang="en" href="https://mangabeira.net/publications/[slug]" />
<link rel="alternate" hreflang="pt-BR" href="https://mangabeira.net/br/artigos/[slug-pt]" />
<link rel="alternate" hreflang="es" href="https://mangabeira.net/es/articulos/[slug-es]" />
<link rel="alternate" hreflang="x-default" href="https://mangabeira.net/publications/[slug]" />Four tags, one per language plus the fallback. Each of the three language URLs carries all four tags, pointing at itself and at the other two.
Watch Out For
Tags alone don't help if the crawler can't render the page behind them. That's a rendering problem, not a translation problem. Web3 Technical SEO covers it in full.
Best Practice
Every alternate needs a return link, including a self-reference. Google's own documentation on localized versions states this plainly: miss one return link, and Google can disregard the whole set for that URL, not just log a warning.
That reciprocity rule is why I generate all four tags from one source list per article, never by hand-editing three separate files.
Each language URL also carries its own self-referencing canonical tag. Canonical and hreflang do different jobs.
Canonical says "this exact URL is the version to index." hreflang says "here's who else in the set to consider." Mixing the two up is a common source of the exact errors the reciprocity rule punishes.
Beyond Translation: Localized Keyword Intent
A translated page and a localized page are not the same asset. Translation changes the words. Localization changes which question the page answers.
Take a crypto tax guide. The literal Portuguese translation of "how to file crypto taxes" reads awkwardly and matches almost nothing people actually type.
Brazilians search around declarar criptomoeda no imposto de renda, tied to their specific tax authority's filing process. That's a different query shape, not just a different language.
On-ramp content has the same problem. "How to buy [token] with cash" needs different instructions per country, because the local payment rail people actually use isn't the same everywhere.
| Topic | Translated version | Localized version |
|---|---|---|
| Crypto tax guide | Word-for-word translation of the English page | Built around the country's own filing process and terms |
| On-ramp guide | Same steps, different language | Built around the payment rail that market actually uses |
A translated page ships faster. A localized page is the one that actually ranks for what people in that country type.
What I Don't Localize: Docs, the App, and Programmatic Pages
Editorial content and marketing pages get translated on mangabeira.net. Docs, the app interface, and programmatic pages generally don't.
Docs serve one audience: builders reading API references. That audience reads English technical docs by convention. Maintaining three versions of a docs site that changes weekly is a maintenance tax I haven't seen pay off.
The dApp interface is a separate localization problem: wallet-gated screens, per-address routes, session-dependent state. SEO for dApps covers that surface on its own.
Programmatic pool and pair pages, generated at scale from live data, are a third case. DeFi Protocol SEO covers what to do with those.
Watch Out For
Translating everything by default multiplies maintenance without multiplying qualified traffic. Scope the decision per content type, not per site.
What to Measure Once Multilingual Content Is Live
Segment Search Console by country and page path per language, not just aggregate impressions. Aggregate numbers hide whether a language version is working at all.
International SEO Measurement Checklist
That reciprocity check matters most: skip it, and the return-link rule covered above kicks in for the whole set, not just the missing link.
Search-appearance segments matter too, not just clicks. Whether a language version shows up in an AI Overview or a rich result is a separate signal from ranking position. GSC reports it per URL.
The rebuilt hreflang stack behind my BR and ES versions is days old as I write this. That's not enough time to claim a result.
What I can show is the setup, not a graph yet. I'll revisit this piece once there's real GSC history to segment.
FAQ
What is international SEO for web3 projects?
International SEO for web3 projects means building language- and region-specific versions of a crypto site's content, backed by hreflang markup. Languages get chosen by search demand and real community presence, not by translating everything by default.
Which languages should a web3 project translate into first?
Whichever languages pass three checks. Real search demand for your specific topics, an audience actually active in that language, and a team that can maintain the content after launch. Adoption rankings like Chainalysis's index help identify candidates, but they don't answer any of the three checks alone.
Does hreflang work on a JavaScript-heavy web3 site?
hreflang tags themselves work the same regardless of stack. The risk is that a client-side-rendered site hides those tags, and the content behind them, from crawlers that don't execute JavaScript. That's a rendering problem separate from the hreflang markup itself.
What's the difference between translating a page and localizing it?
Translation changes the words on a page. Localization changes which question the page answers. It's built around how people in that country actually search: their tax terms, their payment rails, their regulatory process.
How long does it take to see results from a new language version?
Long enough that days or weeks aren't a fair test. New language versions need a real crawl and indexing window before Search Console data means anything. Results also depend on whether the language passed the demand and presence checks in the first place.
Analyst in the Arena · Gabriel Mangabeira
Find out if your protocol's international SEO is costing you real search demand
Thinking about a second language version of your site?
I've built and measured this exact setup. My Web3 Growth Audit covers the market-picking and hreflang review from this article, applied to your project.
Learn About the Web3 Growth Audit →For the deeper cluster context, the full web3 SEO guide connects this piece back to keyword research, technical SEO, and getting cited in AI Overviews.
---