Type a protocol's name into Google. The top result is the marketing site, never the app.
That's not a fluke. Wallet gates and client-side rendering keep the product invisible to crawlers.
You've polished the marketing copy. The app, the actual product, still ranks for nothing.
Treat the app and the marketing site as one indexation system, and both start ranking. Uniswap, Aave, and Curve already run this split.
This piece covers what belongs on app.* versus www.*, wallet-gated content, and why pool and pair pages are the real entry point. It also covers the deep-link URL mess programmatic pages create.
It's the app-frontend layer of the definitive guide to Web3 SEO and AEO. It doesn't cover the site-wide rendering pipeline. the Web3 Technical SEO piece.
Why dApps are invisible to search by default
A dApp is invisible to search by default because its core interface renders after a wallet connects, and search crawlers don't connect wallets.
Most dApp frontends are single-page apps. The initial HTML payload is a shell. Everything a user cares about loads after JavaScript executes, and often after a wallet signs a request.
!The dApp indexation system: app vs www vs docs
Googlebot doesn't hold a wallet or wait on a slow RPC call. It sees whatever renders in the disconnected state, and nothing past that. Web3 makes this worse in three ways:
- The wallet gate sits earlier than a typical auth wall, often on the app's landing view itself.
- The data is the content. A pool's APY, a vault's TVL, a funding rate are exactly what search engines want, and exactly what's locked behind wallet-tied client-side fetches.
- Teams don't separate the product from the pitch. The marketing site stays generic ("the future of decentralized X") because the team assumes the app will eventually be found. It won't be, without deliberate architecture.
Key Insight
The dApp shell will never rank. The job isn't to make the app indexable, it's to make specific slices of its data indexable somewhere the crawler can actually reach.
The app/marketing split: what belongs where, and how authority flows
Every protocol with real traction ends up running two properties: app.project.xyz (the product) and www.project.xyz (the marketing site). Treating them as one indexation system means being explicit about which owns what.
www.* should own: the homepage and positioning, feature pages for someone who hasn't connected a wallet, and docs and blog content. It also owns any programmatic pages surfacing product data for logged-out users.
app.* should own: the transacting interface, anything requiring a wallet to be meaningful, and real-time state too fast-moving to index.
The mistake most teams make is putting everything on app.*, or leaving www.* with nothing but adjectives, assuming the app will speak for itself. Both leave the marketing site with nothing specific enough to rank for a real query.
Uniswap runs marketing and docs on uniswap.org, with the swap interface on app.uniswap.org. Aave does the same: aave.com carries positioning and governance content, while the transacting interface sits at app.aave.com.
Curve keeps its main site at curve.fi with the app UI reachable through its own paths. Structural observations, not ranking claims.
Authority flows from www.* to app.* through internal linking and, more importantly, backlinks that land on the marketing site. That's the property people write about and cite. A generic homepage with nothing worth linking to leaves that authority on the table.
Watch out for
A subdomain split doesn't automatically share ranking signals the way subfolders would. Deliberate internal linking between `app.*` and `www.*` matters more, not less.
Wallet-gated content: what crawlers actually see
The connect-wallet wall isn't the problem. Not knowing what's on either side of it is.
Pull up the app in an incognito tab without connecting a wallet, and look at what renders. That's what Googlebot sees: for a lot of dApps, a connect-wallet button and nothing else. There's no reason for a crawler to associate the URL with any query.
The fix isn't unlocking the app for crawlers. It's pre-rendering the logged-out state with real content instead of a wall.
The pre-render fix, not the unlock fix
None of this compromises the wallet gate. Nobody is arguing the app should let an anonymous crawler execute a swap. The data describing what's available shouldn't be invisible until after connection, because that's exactly what people search for.
Programmatic surfaces: pool, pair, and vault pages as the real entry point
For most DeFi and DEX protocols, organic traffic doesn't arrive at the homepage. It arrives at a specific pool page, trading pair, or vault. That's what people actually type into Google: a token pair, a chain name, a yield figure.
These programmatic pages, one per pool, pair, vault, or market, are the dApp's real organic entry point, not the homepage. A protocol with 400 pools has 400 potential landing pages, each targeting a long-tail query few competitors are building for.
Building these well means solving the duplicate-content problem any large programmatic page set runs into. Pages share a template and differ only in the data, risking a thin-content read.
The mechanics of a duplicate-content-safe page set are covered in the DeFi protocol SEO piece in this cluster. the DeFi Protocol SEO piece.
What matters here is simpler: decide early whether these pages live on app.* or www.*, and pre-render them regardless of which wins. A pool page that only resolves after a wallet connects has zero chance of ranking for the query it was built for.
Deep links into app state: canonical handling for parameter chaos
Deep-linkable app state is a feature for users and a canonicalization problem for search. A URL like app.project.xyz/swap?chain=arbitrum&pool=usdc-eth&ref=abc123 lets someone share a specific setup. But the same content, the USDC/ETH pool on Arbitrum, becomes reachable through dozens of parameter permutations: chain order, referral tags, UTM parameters, sort states.
Left alone, a crawler can split ranking signal across duplicates, or write off the whole cluster as low-value.
Three fixes cover most of this:
Canonicalizing deep-link chaos
This is one slice of a larger rendering and schema question. It belongs to the technical SEO side of this cluster, not the app-frontend piece. the Web3 Technical SEO piece.
What to measure: which GSC segments actually reflect dApp discovery
Once the split is built and pages are pre-rendered, the question becomes whether it's working. GSC is the primary tool, and the trap is looking at the wrong segment.
Aggregate clicks and impressions blend the homepage, blog, docs, and every pool page into one number, which won't say whether dApp discovery is working. Two segments matter more:
The two GSC segments that actually tell you
A protocol that only looks at homepage traffic will conclude the effort isn't working, when the real signal sits in a segment nobody filtered for.
The launch case: why this matters before TGE too
Everything above assumes a live protocol with existing pools. The same decisions, app.* versus www.*, pre-rendering the logged-out state, matter just as much pre-TGE. The only difference: a testnet interface and a waitlist instead of live pools.
Key Insight
Getting the app/marketing split right before launch means the marketing site already carries the authority it needs the moment real pool pages go live.
FAQ
Can a dApp interface itself ever rank in Google?
Rarely, and it's not the right goal. The realistic target is the logged-out, pre-rendered surfaces around it: pool pages, market pages, and the marketing site.
Should the app and marketing site be on the same domain or separate subdomains?
Either works, but subdomains are more common, since teams can ship app updates without touching the marketing codebase. The trade-off: authority doesn't flow as freely between subdomains as subfolders, so internal linking has to be deliberate.
Why do wallet-gated pages hurt SEO specifically?
Search crawlers don't connect wallets. If the meaningful content, prices, rates, pool data, only appears post-connection, the crawler indexes an empty shell instead of the content someone actually searched for.
How many programmatic pool or pair pages is too many?
No fixed ceiling, but risk rises when page count outpaces real data. A pool with genuine volume and rate data reads as distinct content. A pool with near-zero activity and only a shared template reads as thin, duplicate content.
What's the first thing a team should check if dApp SEO isn't working?
Open the app in an incognito tab without connecting a wallet, and look at what renders. If it's a connect-wallet prompt and nothing else, that's what every crawler sees too, and it's the root cause behind most dApp discovery problems.
Where this leaves the discovery gap
A dApp doesn't need to become crawlable to be findable. It needs its team to stop treating the app and marketing site as separate problems. Positioning and programmatic data belong on www.*, the transacting interface on app.*, and pre-rendered logged-out views wherever real search queries are pointed.
Read the full framework this satellite sits inside. The definitive guide to Web3 SEO and AEO covers how this app-frontend layer fits alongside the technical stack and protocol-type content strategy.
The 6-pillar audit covers the dApp pillar alongside Website, Social, Community, SEO, and PR. It's a scoped, async read on where a team's own discovery gap sits: Web3 Growth Audit.