Digite o nome de um protocolo no Google. O primeiro resultado é o site de marketing, nunca o app.
Não é acaso. Wallet gates e renderização client-side mantêm o produto invisível para os crawlers.
Você poliu o texto de marketing. O app, o produto de verdade, continua sem rankear para nada.
Trate o app e o site de marketing como um único sistema de indexação, e os dois começam a rankear. Uniswap, Aave e Curve já rodam essa divisão.
Este texto cobre o que pertence ao app.* versus ao www.*, conteúdo atrás de wallet gate, e por que as páginas de pool e par são o ponto de entrada real. Também cobre a bagunça de URLs de deep link que as páginas programáticas criam.
É a camada de app-frontend do guia definitivo de SEO e AEO para Web3. Não cobre o pipeline de renderização do site inteiro. o texto de SEO Técnico para Web3.
Por que dApps são invisíveis para a busca por padrão
Um dApp é invisível para a busca por padrão porque sua interface principal renderiza depois que uma wallet conecta, e os crawlers de busca não conectam wallet.
A maioria dos frontends de dApp são single-page apps. O payload de HTML inicial é uma casca. Tudo que importa para o usuário carrega depois que o JavaScript executa, e muitas vezes depois que uma wallet assina uma requisição.
!O sistema de indexação do dApp: app vs www vs docs
O Googlebot não segura uma wallet nem espera uma chamada RPC lenta. Ele vê o que renderiza no estado desconectado, e nada além disso. O Web3 piora isso de três formas:
- O wallet gate fica mais cedo do que um muro de autenticação típico, muitas vezes já na própria tela de entrada do app.
- O dado é o conteúdo. O APY de uma pool, o TVL de um vault, uma funding rate são exatamente o que os buscadores querem, e exatamente o que fica trancado atrás de chamadas client-side amarradas à wallet.
- As equipes não separam o produto do discurso de venda. O site de marketing fica genérico ("o futuro do X descentralizado") porque a equipe assume que o app vai ser encontrado eventualmente. Não vai, sem arquitetura deliberada.
Insight-chave
A casca do dApp nunca vai rankear. A tarefa não é tornar o app indexável, é tornar fatias específicas dos seus dados indexáveis em algum lugar que o crawler consiga alcançar.
A divisão app/marketing: o que pertence a cada um, e como a autoridade flui
Todo protocolo com tração de verdade acaba rodando duas propriedades: app.projeto.xyz (o produto) e www.projeto.xyz (o site de marketing). Tratá-los como um único sistema de indexação significa ser explícito sobre quem é dono de quê.
O www.* deve ser dono de: a homepage e o posicionamento, páginas de feature para quem ainda não conectou uma wallet, e o conteúdo de docs e blog. Também é dono de qualquer página programática que exponha dados do produto para usuários deslogados.
O app.* deve ser dono de: a interface de transação, tudo que só faz sentido com uma wallet, e o estado em tempo real rápido demais para indexar.
O erro que a maioria das equipes comete é colocar tudo no app.*, ou deixar o www.* só com adjetivos, assumindo que o app vai falar por si. Os dois deixam o site de marketing sem nada específico o suficiente para rankear numa busca real.
A Uniswap roda marketing e docs em uniswap.org, com a interface de swap em app.uniswap.org. A Aave faz o mesmo: aave.com carrega posicionamento e conteúdo de governança, enquanto a interface de transação fica em app.aave.com.
A Curve mantém seu site principal em curve.fi, com a interface do app acessível por caminhos próprios. Observações estruturais, não afirmações de ranking.
A autoridade flui do www.* para o app.* por meio de links internos e, mais importante, de backlinks que caem no site de marketing. É essa propriedade que as pessoas citam e sobre a qual escrevem. Uma homepage genérica, sem nada que valha a pena linkar, deixa essa autoridade na mesa.
Atenção
Uma divisão em subdomínio não compartilha os sinais de ranking automaticamente como subpastas compartilhariam. Links internos deliberados entre `app.*` e `www.*` importam mais, não menos.
Conteúdo atrás de wallet gate: o que os crawlers realmente veem
O muro de conectar wallet não é o problema. Não saber o que existe dos dois lados dele é.
Abra o app numa aba anônima sem conectar uma wallet, e veja o que renderiza. É isso que o Googlebot vê: para muitos dApps, um botão de conectar wallet e mais nada. Não há motivo para um crawler associar a URL a qualquer busca.
A correção não é desbloquear o app para os crawlers. É pré-renderizar o estado deslogado com conteúdo de verdade em vez de um muro.
A correção de pré-renderização, não a de desbloqueio
Nada disso compromete o wallet gate. Ninguém está defendendo que o app deixe um crawler anônimo executar um swap. O dado que descreve o que está disponível não deveria ficar invisível até depois da conexão, porque é exatamente isso que as pessoas buscam.
Superfícies programáticas: páginas de pool, par e vault como o ponto de entrada real
Para a maioria dos protocolos de DeFi e DEX, o tráfego orgânico não chega na homepage. Chega numa página de pool específica, num par de negociação ou num vault. É isso que as pessoas de fato digitam no Google: um par de tokens, o nome de uma chain, uma taxa de rendimento.
Essas páginas programáticas, uma por pool, par, vault ou mercado, são o ponto de entrada orgânico real do dApp, não a homepage. Um protocolo com 400 pools tem 400 páginas de destino potenciais, cada uma mirando uma busca de cauda longa que poucos concorrentes constroem.
Construir isso bem significa resolver o problema de conteúdo duplicado que todo conjunto grande de páginas programáticas enfrenta. As páginas compartilham um template e diferem só nos dados, com risco de leitura como conteúdo raso.
A mecânica de um conjunto de páginas seguro contra conteúdo duplicado é coberta no texto de SEO para protocolos DeFi deste cluster. o texto de SEO para Protocolos DeFi.
O que importa aqui é mais simples: decida cedo se essas páginas vivem em app.* ou www.*, e pré-renderize independentemente de qual vencer. Uma página de pool que só resolve depois que uma wallet conecta tem zero chance de rankear para a busca para a qual foi construída.
Deep links para o estado do app: tratamento canônico para o caos de parâmetros
O estado do app acessível por deep link é uma vantagem para os usuários e um problema de canonicalização para a busca. Uma URL como app.projeto.xyz/swap?chain=arbitrum&pool=usdc-eth&ref=abc123 deixa alguém compartilhar uma configuração específica. Mas o mesmo conteúdo, a pool USDC/ETH na Arbitrum, fica acessível por dezenas de permutações de parâmetro: ordem de chain, tags de indicação, parâmetros de UTM, estados de ordenação.
Sem tratamento, um crawler pode dividir o sinal de ranking entre duplicatas, ou descartar o cluster inteiro como de baixo valor.
Três correções cobrem a maior parte disso:
Canonicalizando o caos de deep link
Isso é uma fatia de uma questão maior de renderização e schema. Pertence ao lado de SEO técnico deste cluster, não ao texto de app-frontend. o texto de SEO Técnico para Web3.
O que medir: quais segmentos do GSC realmente refletem a descoberta do dApp
Depois que a divisão está construída e as páginas pré-renderizadas, a pergunta vira se está funcionando. O GSC é a ferramenta principal, e a armadilha é olhar para o segmento errado.
Cliques e impressões agregados misturam homepage, blog, docs e cada página de pool num único número, que não vai dizer se a descoberta do dApp está funcionando. Dois segmentos importam mais:
Os dois segmentos do GSC que realmente contam
Um protocolo que só olha o tráfego da homepage vai concluir que o esforço não está funcionando, quando o sinal real está num segmento que ninguém filtrou.
O caso de lançamento: por que isso importa antes do TGE também
Tudo acima assume um protocolo já ativo, com pools existentes. As mesmas decisões, app.* versus www.*, pré-renderizar o estado deslogado, importam do mesmo jeito pré-TGE. A única diferença: uma interface de testnet e uma lista de espera em vez de pools ativos.
Insight-chave
Acertar a divisão app/marketing antes do lançamento significa que o site de marketing já carrega a autoridade de que precisa no momento em que as páginas de pool reais entram no ar.
Perguntas frequentes
A interface de um dApp pode rankear no Google?
Raramente, e não é o objetivo certo. O alvo realista são as superfícies deslogadas e pré-renderizadas ao redor dela: páginas de pool, páginas de mercado e o site de marketing.
O app e o site de marketing devem ficar no mesmo domínio ou em subdomínios separados?
Os dois funcionam, mas subdomínios são mais comuns, já que as equipes conseguem lançar atualizações do app sem mexer no código do site de marketing. O trade-off: a autoridade não flui tão livremente entre subdomínios quanto entre subpastas, então os links internos precisam ser deliberados.
Por que páginas atrás de wallet gate prejudicam o SEO especificamente?
Crawlers de busca não conectam wallet. Se o conteúdo relevante, preços, taxas, dados de pool, só aparece depois da conexão, o crawler indexa uma casca vazia em vez do conteúdo que alguém de fato buscou.
Quantas páginas programáticas de pool ou par são demais?
Não há um teto fixo, mas o risco sobe quando o número de páginas ultrapassa o dado real. Uma pool com volume e dados de taxa genuínos se lê como conteúdo distinto. Uma pool com atividade quase zero e só um template compartilhado se lê como conteúdo raso e duplicado.
Qual é a primeira coisa que uma equipe deve checar se o SEO do dApp não está funcionando?
Abra o app numa aba anônima sem conectar uma wallet, e veja o que renderiza. Se for um aviso de conectar wallet e mais nada, é isso que todo crawler vê também, e é a causa raiz por trás da maioria dos problemas de descoberta de dApps.
Onde isso deixa a lacuna de descoberta
Um dApp não precisa se tornar rastreável para ser encontrável. Precisa que a equipe pare de tratar o app e o site de marketing como problemas separados. Posicionamento e dados programáticos pertencem ao www.*, a interface de transação ao app.*, e views deslogadas e pré-renderizadas onde as buscas reais apontam.
Leia o framework completo em que este satélite se encaixa. O guia definitivo de SEO e AEO para Web3 cobre como essa camada de app-frontend se encaixa junto com o stack técnico e a estratégia de conteúdo por tipo de protocolo.
A auditoria de 6 pilares cobre o pilar de dApp junto com Website, Social, Comunidade, SEO e PR. É uma leitura assíncrona e escopada sobre onde está a lacuna de descoberta da sua equipe: Web3 Growth Audit.