
SEO para Web3 é a prática de otimizar protocolos blockchain, dApps e conteúdo relacionado a tokens para rankear nos mecanismos de busca tradicionais e ser citado em respostas geradas por IA.
Eu acompanho o próprio histórico de citações desta página. Em setembro de 2026, ela empata como a URL mais citada em uma bateria de oito prompts que rodei no Perplexity sobre SEO Web3. Isso não é vaidade. É a base que estou afiando nesta reescrita, não um ponto de partida do zero.
A maioria dos times de protocolo ou pula o SEO por completo ou copia um playbook de Web2 que quebra no primeiro contato com conteúdo protegido por wallet e times pseudônimos. Nenhuma das duas abordagens funciona.
O que vem a seguir é a versão construída de dentro do problema: pesquisa de palavras-chave para termos de protocolo com volume zero, correções técnicas para dApps em React, e a economia real de link building.
Também inclui uma tabela de padrões de query por vertical. E inclui dois trechos de código executável, uma query DuneSQL de atribuição de wallet e um schema de evento GA4, que nada mais nessa categoria publica.
Verifiquei as páginas mais bem posicionadas para "web3 seo", "seo for web3" e "crypto seo" antes de escrever esta reescrita. Dez das treze são propriedades de agências ou consultores. Duas são agregadores de plataforma, Medium e dev.to.
Nenhuma pertence a um protocolo, e nenhuma é blog de ferramenta SaaS. Não existe um incumbente de domínio forte sentado nessa categoria. Dá para vencer isso só com qualidade de conteúdo.
Este guia cobre o que SEO Web3 realmente é e por que o Google trata cripto de forma diferente. Ele mapeia sua superfície indexável real entre site de marketing, docs, dApp e fórum.
Depois percorre estratégia de palavras-chave e de vertical, correções técnicas e link building. Termina com GEO e medição de citação por IA, atribuição on-chain, custo e prazo, erros comuns, e um plano de ação por estágio.
Principais pontos
- SEO Web3 difere do SEO padrão em três eixos: confiança (times pseudônimos não têm o E-E-A-T convencional), stack técnico (SPAs em React e portões de wallet bloqueiam crawlers) e intenção de busca (queries de protocolo misturam pesquisa, especulação de preço e avaliação técnica).
- Ninguém entre as 13 páginas mais bem posicionadas hoje para "web3 seo" publica uma receita executável de atribuição on-chain. Um schema de evento GA4 nomeado mais uma query DuneSQL copiável é o ativo mais linkável disponível nessa categoria agora.
- Arquitetura multi-superfície, site de marketing, docs, dApp, fórum de governança, GitHub, é a pergunta real mais frequente que um líder de crescimento de protocolo faz. Quase ninguém publica uma resposta direta para ela.
- Identidade on-chain (ENS, endereço de wallet, links sameAs) é um sinal de consistência de verificação, não um fator de ranking do Google. Trate qualquer alegação contrária como marketing, não como evidência.
- Para as suas próprias queries de marca e ticker, o resultado que de fato aparece no topo costuma ser CoinGecko, CoinMarketCap ou DefiLlama, não o seu próprio site. Reconquistar essa SERP tem um playbook específico, coberto adiante.
Neste artigo
O que é SEO para Web3?
SEO para Web3 é a prática de otimizar protocolos blockchain, dApps e conteúdo relacionado a tokens para rankear nos mecanismos de busca tradicionais e ser citado em respostas geradas por IA. Ele aplica frameworks padrão de otimização aos desafios únicos de confiança, técnica e palavras-chave de projetos on-chain.
Essa única frase já faz trabalho pesado. É a definição que esta página carrega desde 2025, e é parte do motivo pelo qual o Perplexity continua citando esta URL. Não estou substituindo essa base. Estou afiando o que está ao redor dela.
Três coisas separam o SEO Web3 da versão padrão. Primeiro, o ambiente de confiança: times anônimos ou pseudônimos não têm os sinais convencionais de E-E-A-T que os avaliadores de qualidade do Google procuram, especialmente em tudo que toca instrumentos financeiros.
Segundo, o stack técnico. SPAs em React com portões de entrada via wallet-connect frequentemente devolvem páginas quase vazias aos crawlers. Terceiro, a intenção de busca. Queries de protocolo misturam pesquisa, especulação de preço e avaliação técnica de formas que os frameworks padrão de palavras-chave nunca foram feitos para organizar.
Você também vai ver isso chamado de "crypto SEO". Os dois termos se sobrepõem, mas não são idênticos. Crypto SEO pende mais para conteúdo de exchange e venda de token. SEO Web3 cobre como protocolos DeFi, redes DePIN, wallets e plataformas RWA constroem visibilidade de busca, uma superfície de conteúdo diferente com exigências de confiança diferentes.
A oportunidade é maior do que a maioria dos times percebe assim que olha além do próprio blog. Um protocolo de lending DeFi explicando mecânicas de liquidação. Uma rede DePIN publicando mapas de cobertura de nós e guias de configuração de hardware.
Uma plataforma RWA escrevendo sobre a estrutura legal por trás de treasuries tokenizadas. Um time de stablecoin documentando dados de estabilidade de peg com números reais anexados. Essas são as superfícies de conteúdo que rankeiam, persistem e compõem em cada vertical da Web3. Uma compra pontual de anúncio não faz isso, e nem um único press release de semana de lançamento.
O anel de satélites ao redor desta página aprofunda cada frente. Veja SEO de protocolo DeFi por tipo de protocolo, ser citado com precisão por engines de IA, e o stack técnico que quebra em silêncio. Veja também tornar encontrável um dApp atrás de wallet, transformar prova on-chain em E-E-A-T rastreável, e levar tudo isso para o multilíngue.
SEO Web3 vs SEO tradicional: o que muda de verdade
Os playbooks de SEO padrão assumem identidades verificadas, HTML estático e eventos de conversão que deixam rastros de dados first-party. Projetos Web3 quebram as três premissas de uma vez.
| Fator | SEO tradicional | SEO Web3 |
|---|---|---|
| Sinais de confiança | Bylines de autor, histórico de marca, credenciais nomeadas | Reputação on-chain, relatórios de auditoria, listagens no CMC/CoinGecko, histórico de segurança |
| Formato de conteúdo | Posts de blog, landing pages, estudos de caso | Whitepapers, páginas de tokenomics, docs de protocolo, dashboards no Dune |
| Link building | Guest posts, PR digital, listagens em diretórios | Diretórios de protocolo, backlinks de auditorias, citações no Dune, mídia cripto |
| Analytics | GA4, GSC, dados de conversão first-party | GA4 mais atribuição on-chain via Dune, eventos de wallet connect |
| Risco do stack técnico | Baixo. A maioria dos CMS renderiza no servidor por padrão. | Alto. SPAs em React e portões de wallet-connect frequentemente bloqueiam crawlers. |
| SERP de marca | Seu próprio domínio costuma rankear em #1 para o nome da sua marca | CoinGecko, CMC ou DefiLlama frequentemente superam o seu próprio site para o seu ticker |
Por que o Google trata cripto de forma diferente: YMYL, E-E-A-T e a barra de confiança
As diretrizes dos avaliadores de qualidade do Google dão peso alto a Experiência, Expertise, Autoridade e Confiabilidade para conteúdo YMYL, "Your Money or Your Life". Qualquer coisa que toque instrumentos financeiros se qualifica. A maior parte do conteúdo Web3 se qualifica.
Um time pseudônimo sem página de autor, sem histórico verificável e sem colaboradores nomeados começa em desvantagem estrutural nesse eixo.
Isso não torna o ranking impossível. Significa substituir credenciais pessoais por autoridade institucional: auditorias de segurança publicadas, histórico de commits no GitHub, participação em governança e citações de terceiros confiáveis. O histórico do protocolo faz o papel do currículo do fundador.
A mecânica de time pseudônimo que quase ninguém de fato resolve
A maioria do conteúdo de SEO Web3 nomeia esse problema e para por aí. Aqui está o que fazer de fato a respeito.
Use uma entidade, não uma pessoa, como autor quando o time é pseudônimo. Estruture o schema de Organization em torno do próprio protocolo, com links sameAs para o seu repositório auditado no GitHub, suas listagens no CMC e no CoinGecko, e seu fórum de governança. O grafo de entidades do Google consegue verificar uma organização consistente mesmo quando não consegue verificar um indivíduo.
Deixe a trilha de auditoria fazer o trabalho de E-E-A-T. Uma auditoria de segurança de uma firma nomeada como CertiK ou Hacken, publicada com destaque e linkada diretamente, funciona como validação de terceiro. Esse é o padrão mais forte disponível: verificação independente vence alegação autopublicada, sempre.
Empilhe participação em governança como sinal de confiança. Histórico público de votação no Snapshot ou no Tally, atrelado a um endereço consistente, é auditável por qualquer pessoa. Não é um fator de ranking do Google por si só, mas é o tipo de atividade consistente e verificável que sustenta o caso de autoridade institucional.
A documentação da Compound Finance é uma referência útil aqui. A página de parâmetros de risco dela rankeia para queries técnicas como "Compound Finance collateral factor". Não porque alguém na Compound tem um byline pessoal de autor.
Rankeia porque a página é HTML estruturado com títulos claros, apoiada por um protocolo com um histórico on-chain e de auditoria longo e verificável. A trilha institucional carrega o peso que uma bio pessoal carregaria em outro lugar.
Um exemplo real: minha própria identidade on-chain, com honestidade
Quero mostrar como isso funciona na prática, então aqui está minha própria configuração. Meu nome ENS, mangabeira.eth, resolve para 0xc2268753E724bcE4A20B413ADD6359abF14D5154.
Ele está cruzado via web3.bio com o mangabeira.net, meu GitHub e meu perfil no X. Também tenho o nome equivalente mangabeira.lens no Lens Protocol, apontando para o mesmo endereço e o mesmo site.
Ainda não tenho uma atestação EAS (Ethereum Attestation Service). Checei o EASScan diretamente antes de escrever esta seção e confirmei que não há nada lá. Considerei construir uma eu mesmo e decidi não fazer isso: a própria documentação do EAS é clara que o valor de uma atestação vem da reputação de quem atesta, não de quem é atestado. Uma autoatestação sobre mim mesmo seria só uma alegação autopublicada com embalagem criptográfica, exatamente o padrão que esta seção inteira alerta contra.
Eu tenho uma credencial real, sem relação com a configuração on-chain: uma certificação em Marketing Engineering da Profound University, concluída em setembro de 2026, com um registro público de diploma cujo texto eu não controlo. Essa é a barra honesta para a propriedade hasCredential do schema.org: verificação que vive em outro lugar, não no meu próprio site. Aqui está o schema completo, as duas partes:
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Gabriel Mangabeira",
"url": "https://mangabeira.net",
"sameAs": [
"https://x.com/manga82",
"https://github.com/gmangabeira",
"https://web3.bio/mangabeira.eth"
],
"identifier": [
{
"@type": "PropertyValue",
"propertyID": "ens_domain",
"value": "mangabeira.eth"
},
{
"@type": "PropertyValue",
"propertyID": "ethereum_address",
"value": "0xc2268753E724bcE4A20B413ADD6359abF14D5154"
}
],
"hasCredential": [
{
"@type": "EducationalOccupationalCredential",
"name": "Marketing Engineering",
"recognizedBy": { "@type": "Organization", "name": "Profound University" },
"url": "https://university.tryprofound.com/diplomas/344379c2-41f7-4829-a136-1d38e90837fe"
}
]
}
Note para onde hasCredential aponta, e para onde não aponta. Ele aponta para o diploma da Profound, verificável no site da própria Profound, não no meu. Ele não aponta para o nome ENS nem para o endereço da carteira. Esses ficam em identifier, uma âncora secundária ao lado do meu nome e URL, não uma credencial. Misturar os dois, tratar um endereço de carteira como se fosse uma credencial, é o mesmo erro de categoria que a alegação retratada de "85% de Knowledge Panel" cometeu, mencionada abaixo.
Fique atento
Um desenvolvedor construiu uma integração de ENS com schema.org e alegou publicamente que ela produzia uma "probabilidade de 85% de Knowledge Panel". Depois retratou o número, afirmando que ele não tinha embasamento empírico. Reputação on-chain não é um fator de ranking confirmado do Google, e nenhuma evidência mostra que ela toca o grafo de verificação de entidades do Google. Trate esta seção como uma jogada de consistência de verificação para engines de resposta de IA, nunca como uma alavanca de SEO.
O pitch honesto: uma alegação verificável e à prova de adulteração é um sinal de confiança real em um mundo onde texto é quase de graça para gerar. Isso vale independente de algum algoritmo recompensar isso hoje ou não. Essa é uma posição defensável. "Isso vai melhorar seu ranking" não é. Leia a mecânica completa no satélite de sinais de confiança on-chain.
Sua superfície de SEO real: site de marketing, docs, dApp, fórum, GitHub
Pergunte a qualquer líder de crescimento de protocolo qual é a superfície indexável real dele, e a maioria não consegue responder de forma limpa. Um protocolo típico se espalha por um site de marketing, um subdomínio de docs, um dApp renderizado no cliente, um fórum de governança e uma organização no GitHub. Quase todo guia de SEO Web3 nomeia essa fragmentação e segue em frente sem resolvê-la. Aqui está a política que eu aplico.
Isso importa porque o Google aloca um orçamento de crawl por site. Uma superfície fragmentada espalha esse orçamento entre domínios que o Google trata como entidades separadas.
Um estudo de caso de link interno em site grande descobriu que uma revisão de linkagem interna levou um site de 40% para 70% de cobertura de crawl do Googlebot. Páginas que recebem mais links internos apontando para elas são priorizadas para crawl.
Um protocolo que consolida sua superfície, e linka suas páginas mais importantes a partir das páginas de maior tráfego, consegue rastrear mais conteúdo de fato.
| Superfície | Subdomínio ou subpasta | Política de indexação |
|---|---|---|
| Site de marketing | Domínio raiz | Totalmente indexado, SSR ou SSG obrigatório |
| Docs | Subpasta (/docs), não docs.protocolo.xyz | Totalmente indexado. Consolida autoridade no domínio raiz em vez de dividi-la. |
| dApp (app.protocolo.xyz) | Subdomínio, mantido separado | Noindex em views atrás de wallet. Indexe só os estados estáticos, pré-conexão, se carregam conteúdo real. |
| Fórum de governança | Subdomínio (gov.protocolo.xyz) ou hospedado (Discourse/Commonwealth) | Indexe se hospedado por você mesmo com tags canônicas. Fóruns hospedados por terceiros raramente devolvem patrimônio de link. |
| Organização no GitHub | github.com/protocolo (externo) | Já indexado diretamente pelo Google. Garanta que o README linke de volta para o domínio raiz, dofollow. |
A ação de maior alavancagem aqui: consolide os docs no domínio raiz como subpasta em vez de subdomínio separado. Subdomínios são tratados como entidades distintas para a maioria dos sinais de autoridade.
Um protocolo rodando docs.protocolo.xyz e blog.protocolo.xyz está construindo dois domínios fracos em vez de um forte. Migre para protocolo.xyz/docs e protocolo.xyz/blog, e os links de entrada que seus docs conquistam passam a fluir para o site inteiro.
Regra canônica para o dApp: se uma rota exige conexão de wallet para renderizar qualquer conteúdo, aplique noindex nela explicitamente. Uma página em branco ou atrás de auth que acaba sendo indexada só acumula sinal de conteúdo raso contra o domínio.
Mantenha os estados estáticos de entrada do dApp (uma landing page, um dashboard de estatísticas que não exige conexão) indexáveis, e bloqueie o resto. Isso é coberto com mais profundidade no satélite seo-for-dapps e no satélite web3-technical-seo.
Pesquisa de palavras-chave quando os termos do seu protocolo têm volume zero
Ferramentas de palavras-chave cripto retornam volumes baixos para a maioria dos termos específicos de Web3. A tentação é descartar essas queries como pequenas demais para sustentar uma estratégia. Esse é o enquadramento errado.
Um fundador buscando "Aave vs Compound" está comparando ativamente parâmetros de risco e escolhendo onde alocar capital. Volume baixo pelo padrão de consumo, valor de conversão alto por qualquer padrão.
Aqui está o processo, passo a passo:
- Comece pelo GSC, não por uma ferramenta de palavras-chave. Puxe os dados do Search Console ordenados por impressões. Filtre as posições 5 a 20. Essas são páginas que o Google já está avaliando para queries relevantes, onde você ainda não conquistou o clique. Esse é o caminho mais rápido para movimento de ranking.
- Mapeie primeiro as queries de comparação. Queries no estilo "Aave vs Compound" definem o posicionamento de um protocolo na busca. Uma página de comparação bem estruturada, com dados atuais de TVL do DefiLlama para os dois lados, rankeia para a query e constrói credibilidade ao mesmo tempo.
- Use as páginas de categoria do DefiLlama como sinal de palavra-chave. Se o seu protocolo aparece na categoria "lending" ou "liquid staking", esses termos de categoria são seus alvos de meio de funil. As próprias páginas de protocolo do DefiLlama aparecem para termos como "[protocolo] TVL" porque a página tem estrutura de dados explícita. Seus docs e blog podem competir pelos mesmos termos com contexto específico do protocolo.
- Separe "price prediction" das queries de pesquisa. Elas atraem especuladores, não usuários do protocolo, e geram tráfego que rejeita antes de um wallet connect. Mapeie-as separadamente se você as atender de alguma forma.
- Use o padrão de query de confiança. "Is [protocolo] safe", "is [token] a rug" e "[protocolo] hack" carregam volume de busca real, embora nada glamouroso. Uma página que responde a isso com honestidade, com seu histórico de auditoria e registro de incidentes se houver, rankeia justamente porque quase ninguém quer escrever isso.
- Puxe os termos de categoria do CoinGecko. Rótulos padronizados como "real-world assets" ou "decentralized derivatives" mapeiam diretamente para queries de busca e tipicamente têm menos concorrência do que termos de marca em nível de protocolo.
- Inclua variantes de grafia britânica. "Web3 search engine optimisation" carrega impressões mensuráveis no GSC vindas de públicos fora dos EUA. Inclua a variante uma vez no corpo do texto para um ganho de alcance global.
Uma ressalva sobre ferramentas: a maioria das ferramentas de palavras-chave populares, incluindo Ahrefs e Semrush, subestima o volume de busca específico de Web3. As fontes de dados delas pendem para padrões de busca de consumo mais amplos.
Uma leitura de "0" de volume em uma ferramenta padrão não significa zero buscadores. Geralmente significa que a amostra da ferramenta não capturou esse nicho específico. Trate os dados de impressão do próprio GSC como mais confiáveis do que a estimativa de volume de qualquer ferramenta terceira para termos específicos de protocolo.
Padrões de query por vertical: DeFi, CEX/DEX, wallets, stablecoins, DePIN, RWA
Todo guia de SEO Web3 que já li trata "Web3" como uma audiência única com um padrão de query único. Não é.
Um protocolo DeFi, uma CEX, uma wallet, uma emissora de stablecoin, uma rede DePIN e uma plataforma RWA enfrentam formatos de query diferentes. Cada uma enfrenta um incumbente de SERP diferente e um sinal de confiança diferente que de fato move a agulha.
Essa é a seção mais defensável e original de toda essa peça. A cobertura em satélite para a mais aprofundada delas vive em SEO de protocolo DeFi.
Tratar essas seis verticais com um único playbook indiferenciado é o motivo pelo qual tanto conteúdo Web3 tem baixo desempenho. Um time DePIN escrevendo conteúdo de "melhores práticas" mirando especuladores de token perde a audiência de comprador de hardware e operador de nó que de fato converte.
Uma emissora de stablecoin publicando conteúdo DeFi genérico perde as queries de risco de peg e transparência de reserva que dominam a demanda de busca real dela. A tabela abaixo é o mapa de partida. Cada vertical merece seu próprio universo de palavras-chave construído a partir dele, não uma lista única compartilhada.
| Vertical | Padrão de query dominante | Incumbente típico na SERP | Sinal de confiança decisivo |
|---|---|---|---|
| Protocolos DeFi | Queries de comparação e métrica ("[protocolo] vs [protocolo]", "[protocolo] TVL") | DefiLlama, páginas de protocolo de agregadores | Auditoria de segurança publicada, atualidade do TVL |
| CEX/DEX | "Is [exchange] safe", comparação de taxas, queries de listagem | Rankings de exchange do CoinGecko, agregadores de review | Prova de reservas, páginas de licenciamento regulatório |
| Wallets | "[Wallet] vs [wallet]", chains suportadas, guias de recuperação | Listagens de app store, sites de review | Status de auditoria open-source, clareza sobre self-custody |
| Stablecoins | Queries de mecanismo e risco de peg ("USDC vs DAI", "is [stablecoin] backed") | Páginas de transparência do emissor, rastreadores de peg de agregadores | Atestações de reserva, histórico de resgate |
| DePIN | Queries geográficas, de hardware e de operador ("how to run a [network] node") | Dashboards de mapa de cobertura de rede, fóruns de review de hardware | Dados reais de mapa de cobertura, histórico de pagamento a operadores |
| RWA | Queries de classe de ativo e compliance ("tokenized treasury yield", "RWA token regulation") | Conteúdo legal/compliance, firmas de pesquisa institucional | Divulgação de estrutura legal, cadeia de custódia e auditoria |
Reconquistando a SERP da sua própria marca do CoinGecko, CMC e DefiLlama
Busque o nome do seu próprio protocolo agora. Existe uma chance real de que o primeiro resultado não seja o seu site. É uma listagem no CoinGecko, uma página no CoinMarketCap, ou um perfil no DefiLlama.
Nenhuma das 13 páginas que revisei ao construir esta reescrita menciona esse problema, muito menos oferece uma solução. Isso torna essa a seção mais incontestada de todo este guia.
Isso acontece porque páginas de agregador carregam mais autoridade de domínio bruta do que a maioria dos sites jovens de protocolo, e são construídas com estrutura de dados explícita que o Google recompensa. A correção não é brigar com o agregador. É fazer o seu próprio site ser a resposta mais completa e mais atual.
| Agregador | Por que ele te supera | Tática de reconquista |
|---|---|---|
| CoinGecko | Autoridade de domínio alta, dados de preço/TVL estruturados | Complete a listagem por inteiro, linke para seus próprios docs e tokenomics a partir dela, depois publique com mais frequência que ele, com contexto atual que ele não carrega |
| CoinMarketCap | Mesmo padrão, mais domínio de query de marca vindo de tráfego de checagem de preço | Mesmo que o CoinGecko. Mantenha a descrição no CMC atualizada toda vez que sua mensagem mudar |
| DefiLlama | Quem busca focado em TVL cai aqui primeiro, especialmente em queries de comparação | Construa sua própria página de TVL com os mesmos dados ao vivo (veja a seção de atribuição on-chain) mais explicação de mecanismo que o DefiLlama não oferece |
| Páginas de listagem de exchange | Domínios de exchange com DA alto rankeiam para "[token] price" e termos parecidos | Não compita nas páginas de preço. Domine as queries de mecanismo e comparação que a página da exchange não consegue responder |
A meta realista não é superar o CoinGecko para "[token] price". É dominar as queries que o agregador não consegue responder: mecanismo, roadmap, governança e comparação. Essas são exatamente as páginas que o seu próprio site deveria estar estruturado para vencer.
SEO técnico para dApps: renderização, Core Web Vitals e conteúdo atrás de wallet
A maioria dos protocolos perde mais terreno aqui, e a maior parte disso é corrigível sem uma reconstrução.
Renderização de JavaScript. Se o seu dApp é uma SPA em React servida inteiramente no cliente, o Google precisa renderizá-la antes de indexar. Isso acontece em uma fila com atrasos que podem chegar a dias.
Se o ponto de entrada da homepage é um modal de wallet-connect, o Googlebot muitas vezes recebe conteúdo vazio na primeira passada. A correção é SSR ou SSG para todas as páginas de marketing e conteúdo, mesmo enquanto o próprio dApp continua no cliente.
O Next.js resolve isso com renderização híbrida. O dApp mantém a arquitetura dele, e as landing pages, docs e blog recebem geração estática.
Já auditei sites de protocolo onde a homepage devolvia menos de 500 bytes de conteúdo aos crawlers. A página inteira era renderizada no cliente atrás de um fluxo de autenticação de wallet. Isso não é uma lacuna pequena.
Significa que o Google efetivamente via uma página em branco onde um visitante humano via um site de marketing completo. A correção também nem sempre exige uma migração completa de framework.
Um modo de falha de site de página única é uma versão mais severa do mesmo problema. Isso acontece quando o domínio inteiro é uma única rota com tudo carregado via JavaScript. Verifique se o seu site tem URLs reais e separadamente roteáveis para docs, blog e cada seção de conteúdo, não só links âncora dentro de uma única página.
Core Web Vitals para dApps
| Métrica | Meta | Causa comum em Web3 quando falha |
|---|---|---|
| LCP (Largest Contentful Paint) | Abaixo de 2,5 segundos | Bundles pesados de JS, bibliotecas de wallet-connect sem otimização carregadas em toda página |
| CLS (Cumulative Layout Shift) | Abaixo de 0,1 | Widgets dinâmicos de preço/TVL carregando sem espaço reservado |
| INP (Interaction to Next Paint) | Abaixo de 200ms | Handlers de interação de wallet rodando na thread principal |
Configuração do robots.txt. Um padrão que vejo constantemente em auditorias de protocolo: um robots.txt copiado de um template Web2 SaaS que bloqueia caminhos de staging e rotas internas. Às vezes ele também bloqueia /whitepaper, /docs ou /token por acidente. Audite seu robots.txt contra a estrutura pública real do seu site antes de assumir que tudo está indexável.
Teste a renderização diretamente em vez de assumir que ela funciona. A ferramenta de Inspeção de URL do Google Search Console mostra exatamente o que o Googlebot vê ao renderizar uma página, incluindo uma captura de tela do DOM renderizado.
Rode isso na sua homepage, no índice dos docs e na página de tokenomics especificamente. Se a captura mostrar uma página em branco ou um modal de wallet-connect sem nada por trás, essa é a página falhando exatamente no ponto que importa.
É uma checagem de cinco minutos. Ela pega um problema que a maioria dos times só descobre meses depois em um relatório de cobertura do GSC.
Acesso de crawlers de IA. O Google é um crawler. Perplexity, ChatGPT e Gemini enviam seus próprios bots: PerplexityBot, GPTBot, ClaudeBot. Se um robots.txt herdado de template bloqueia esses bots, seu protocolo não será citado em respostas geradas por IA para a sua categoria, não importa quão bom seja o conteúdo. Verifique isso explicitamente.
Conteúdo atrás de wallet. Aplique noindex em qualquer rota que exija conexão de wallet para renderizar conteúdo relevante, seguindo a regra canônica da seção de superfície de SEO acima. A árvore de decisão SSR vs CSR para cada tipo de rota está no satélite seo-for-dapps.
Schema markup para projetos Web3
Schema é uma das vitórias de AEO mais baratas dessa categoria, e a maioria das páginas mais bem posicionadas nessa SERP ainda erra nisso.
Oito das treze páginas concorrentes que revisei mostram um bloco de FAQ visível. Onze das treze não emitem schema de FAQPage algum. A maioria das páginas com FAQ visível ainda falha em marcá-lo.
| Tipo de schema | O que ele faz | Observação específica de Web3 |
|---|---|---|
| Article | Marca páginas de blog e docs | Use em docs e blog de protocolo, nunca nas views do app atrás de wallet |
| Organization | Estabelece o protocolo como entidade | sameAs para CMC, CoinGecko, GitHub e fórum de governança, os quatro se existirem |
| Person | Estabelece um autor ou colaborador nomeado | Só para membros nomeados do time. Use Organization, não Person, quando o time é pseudônimo |
| FAQPage | Marca conteúdo de FAQ para extração direta | Verifique se de fato renderiza. Um FAQ visível sem schema correspondente é a lacuna mais comum dessa categoria |
| BreadcrumbList | Sinal de hierarquia do site | Útil assim que os docs estiverem consolidados no domínio raiz como subpastas |
| HowTo | Marcação de processo passo a passo | Se encaixa bem em guias de configuração para operador de nó e tutoriais de staking |
Valide todo bloco de schema no Rich Results Test do Google antes de publicar. Um bloco que falha ao renderizar é pior do que nenhum bloco, porque sinaliza uma lacuna técnica sem conquistar nenhum dos benefícios.
Teste depois de cada deploy, não só no lançamento. Uma migração de CMS ou mudança de template pode remover o schema em silêncio sem quebrar a página visível, e ninguém percebe até que a taxa de citação caia silenciosamente meses depois.
SEO on-page para páginas de protocolo, docs e blog
SEO on-page para Web3 significa otimizar páginas que não existem em um stack Web2 padrão. Para um protocolo DeFi, isso é o whitepaper, a página de tokenomics e a landing page do TGE. Para DePIN, são mapas de cobertura de nós e guias de hardware. Para RWA, são explicações por classe de ativo e páginas de estrutura legal.
SEO do whitepaper. Publicar o whitepaper apenas como PDF é uma penalidade de indexação que você escolhe assumir. O Google indexa PDFs pior do que HTML, e não consegue seguir estrutura de âncora interna dentro de um.
Uma versão em HTML, estruturada com H2s para mecânicas, tokenomics, segurança e governança, vira uma página de alta autoridade. Ela rankeia para queries técnicas e conquista links de entrada de pesquisadores.
Estrutura da página de tokenomics. Essas páginas rankeiam consistentemente para queries de "[token] tokenomics" e "[token] vesting schedule" de pesquisadores em due diligence.
O erro comum: renderizar toda a divisão de alocação como um gráfico em JavaScript sem nenhum fallback de texto estático. Se o gráfico quebra ou falha ao renderizar, o conteúdo rastreável some por completo.
Cada categoria de alocação e termo de vesting deveria existir como texto HTML puro, com qualquer gráfico sobreposto visualmente por cima.
Páginas de TGE e lançamento de token. Uma página viva e indexada mirando "[protocolo] token launch" e "[token] airdrop eligibility" acumula impressões antes do lançamento se for colocada no ar cedo. A maioria dos times constrói isso duas semanas antes. Construir três meses antes captura o pico de intenção de busca que acontece no próprio dia do lançamento.
Dois satélites relacionados aprofundam isso: estrutura de página de tokenomics e o checklist completo de SEO pré-lançamento.
SEO programático para páginas de token, chain e par
Apenas duas das treze páginas concorrentes que revisei cobrem SEO programático para Web3, e nenhuma vai além de um parágrafo. É uma alavanca real para qualquer protocolo que abrange múltiplas chains, pares ou ativos.
O padrão: construa um template que gera uma página por token, chain ou par de negociação. Popule a partir da mesma fonte de dados que alimenta o seu app.
Um agregador de DEX com 400 pares suportados pode gerar programaticamente 400 páginas, cada uma mirando "[token A] to [token B] swap" ou "[token] price on [chain]". Os dados específicos do par vêm ao vivo da mesma API que o app já chama.
Três regras evitam que isso vire spam de conteúdo raso que o Google descarta. Primeiro, cada página precisa de dados genuinamente distintos, não uma casca de template com o nome do token trocado. Segundo, limite o template aos dados que o seu app de fato mostra, não invente campos para preencher espaço.
Terceiro, aplique noindex em qualquer página gerada abaixo de um limite mínimo de dados. Um par com volume quase zero não merece uma página indexada. Protocolos multi-chain e agregadores de DEX são o encaixe mais claro para esse padrão. Um protocolo de lending de uma única chain com cinco mercados tem menos a ganhar com ele.
Construindo autoridade sem guest posting: a economia real de link building
Link building tradicional, guest posts e trocas de links, não mapeia bem para como protocolos Web3 conquistam autoridade. O ecossistema cripto produz fontes de link de alta autoridade naturalmente, como subprodutos da operação normal do protocolo. A maioria dos times não as coleta de forma sistemática.
| Fonte de link | Impacto de autoridade | Esforço |
|---|---|---|
| Listagens em diretórios de protocolo (CMC, CoinGecko, DefiLlama) | Alto. Entre as fontes de maior DA disponíveis para qualquer projeto Web3 | Baixo. Configuração única, atualidade de descrição contínua |
| Publicação de auditoria de segurança | Alto. Backlink de terceiro confiável mais sinal institucional de E-E-A-T | Baixo se a auditoria já existe. Basta publicar e linkar com destaque |
| Citações de dashboard no Dune | Médio a alto, compõe com o tempo conforme pesquisadores citam o dashboard | Médio. Construa uma vez, mantenha atualizado |
| Cobertura de mídia cripto (CoinDesk, Decrypt, The Block) | Alto, mais volume de query de marca | Médio a alto. Exige uma história genuína guiada por dados, não um press release |
| Referências de repositório no GitHub | Compõe organicamente com a adoção do ecossistema | Baixo, majoritariamente conquistado de forma passiva se o repositório é genuinamente útil |
| Participações em podcast | Médio. Um link mais uma audiência que pode buscar por você depois | Médio. Mídia conquistada, uma participação por vez |
O sinal de autoridade mais durável para um protocolo DeFi não é um guest post em um blog de blockchain. É uma listagem completa no CMC, uma auditoria de segurança publicada, um dashboard público no Dune, e um repositório ativo no GitHub, juntos.
Essas são as fontes que pesquisadores citam, jornalistas linkam e engines de IA tratam como referências autoritativas ao formar respostas sobre a sua categoria. Nada disso é conteúdo construído para aquisição de link. São os artefatos que o seu protocolo já produz, estruturados para transferir autoridade em vez de ficarem sem uso.
Sobre custo: não tenho um número verificado e com fonte sobre o quanto links cripto custam a mais em relação a links SaaS padrão. Uma agência desse espaço publicou uma alegação: posicionamentos tier-1 em cripto custam entre US$ 5.000 e US$ 15.000, de três a cinco vezes um link SaaS comparável.
Não consigo verificar esse número de forma independente, então estou sinalizando isso como uma alegação da indústria publicada, não um fato que estou afirmando. Faça o orçamento de forma conservadora e negocie por posicionamento em vez de ancorar em um único número que você leu.
Um pitch guiado por dados vence um press release sempre, especificamente com mídia cripto. Em vez de anunciar um lançamento, apresente a um jornalista um achado que o seu próprio dashboard no Dune mostra. Uma mudança em participação de volume de DEX, um ponto de inflexão de TVL, algo que os seus dados on-chain mostram que não é visível de fora do seu protocolo.
Jornalistas de veículos como CoinDesk e The Block citam dados originais porque isso torna a própria cobertura deles mais crível. Um press release compete com uma centena de outros press releases naquela semana. Um achado de dados genuíno geralmente não compete.
GEO: sendo citado em AI Overviews, ChatGPT e Perplexity
GEO, Generative Engine Optimization, é a prática de estruturar conteúdo para ser citado dentro de respostas geradas por IA, não apenas rankeado abaixo delas. Para queries de Web3, isso está ficando mais urgente do que o ranking tradicional. Queries informacionais cada vez mais acionam um AI Overview antes mesmo do primeiro resultado orgânico carregar.
Quando quem busca recebe a resposta direto da síntese do Google, o clique nunca acontece. Rankear na primeira página não garante mais visibilidade. A pergunta real não é "onde a gente rankeia". É "a gente é citado dentro da resposta".
Quatro coisas impulsionam citação em AI Overviews e em chats de IA para conteúdo de protocolo:
Definições diretas no topo das seções relevantes. Engines de IA extraem de seções que respondem diretamente a uma pergunta. Abra cada H2 principal com uma resposta direta de 40 a 60 palavras, e depois expanda. Esta página segue essa estrutura deliberadamente, e é parte do motivo pelo qual ela já é citada.
Dados estruturados. Schema de FAQPage, Article e Organization com links sameAs verificáveis dão aos sistemas de IA clareza de entidade nomeada sobre o que o seu protocolo é.
Sinais de E-E-A-T para times pseudônimos. Coberto por completo acima: auditorias, histórico no GitHub e proxies institucionais substituem credenciais pessoais.
Densidade de entidades nomeadas. Conteúdo referenciando Aave, Uniswap, Compound, Dune, DefiLlama e CoinGecko pelo nome sinaliza expertise específica do domínio de um jeito que conteúdo cripto genérico não sinaliza. Construa isso deliberadamente como evidência, não como keyword stuffing.
Precisão, não só presença. Ser citado é só metade da equação. Um teste ao vivo que rodei em agosto de 2026 checou o que os principais modelos de IA diziam sobre TVL de protocolo contra os números on-chain no momento da consulta.
O TVL da Pendle apareceu superestimado entre 244% e 320% nos modelos testados. O da Lido, entre 80% e 96%.
Um usuário que confere o número real e encontra um valor três vezes menor perde confiança tanto no modelo quanto no protocolo. O protocolo não fez nada de errado além de não controlar a narrativa.
A correção não é mais conteúdo. São números que se atualizam sozinhos. Incorpore um widget de TVL ao vivo puxando do DefiLlama ou do seu próprio subgraph em vez de um número estático. Marque cada dado numérico com a data explícita, "em [data]", para que crawlers e leitores possam avaliar a atualidade.
Atualidade importa além da precisão. Toda página mais citada que verifiquei ao pesquisar esta reescrita carrega um carimbo de atualização visível e recente, a maioria dentro dos últimos quatro meses da data em que verifiquei.
Um post de blog sobre a sua estrutura de taxas pode ficar sem mudança por dois anos sem te prejudicar. Uma página da qual engines de IA puxam alegações numéricas não pode. Se uma página carrega um número que muda com o tempo, TVL, APY, contagem de holders, trate a cadência de atualização dela como manutenção de SEO, não como um detalhe secundário.
Medindo citações de IA: uma bateria de prompts e uma linha de base de share of voice
Todo guia dessa categoria diz "seja citado pelo ChatGPT". Quase nenhum dá um método para medir se isso está de fato acontecendo. Aqui está o método que usei para produzir a alegação de citação no parágrafo de abertura deste artigo, para que você mesmo possa rodar.
Construa uma bateria de oito a vinte prompts. Misture prompts definicionais ("what is web3 seo") com prompts específicos de vertical ("how do I do SEO for a DeFi protocol"). Adicione um prompt de caso extremo sobre um tópico com pouca oferta competitiva, como hreflang para sites cripto. Mantenha o texto exato fixo para que os resultados sejam comparáveis ao longo do tempo.
Rode a bateria por uma API que retorna citações estruturadas. A API da Perplexity retorna anotações explícitas de url_citation por resposta, não só prosa que você tem que interpretar manualmente. Esse é um sinal confiável de como aquela engine específica mostra fontes, embora seja uma engine, não um consenso entre engines.
Contabilize por domínio e por URL exata. Conte instâncias distintas de citação por prompt, depois consolide por domínio e por página específica. Um domínio pode aparecer mais de uma vez por prompt se tiver múltiplas páginas rankeadas sobre o tópico.
Rode de novo todo mês. A participação em citações se move com atualidade de conteúdo e atividade de publicação de concorrentes. Um único snapshot mostra onde você está hoje. Uma cadência mensal mostra se você está ganhando ou perdendo terreno.
Quando rodei esse processo exato em setembro de 2026 em oito prompts de SEO Web3, esta página empatou como a URL mais citada. Ela apareceu no prompt definicional, no prompt de protocolo DeFi, no prompt de melhores práticas, e no prompt de SEO técnico.
Esse é um resultado verificável e repetível, não uma alegação sem fonte. Rode os mesmos oito prompts você mesmo e pode checar.
Atribuição on-chain: da sessão ao wallet connect
Essa é a seção que ninguém mais nessa categoria construiu. Todo guia concorrente tem um título que diz "rastreamento de conversão on-chain". Zero contêm uma query ou schema de evento de fato, ou um método para cruzar uma sessão com um endereço de wallet. Aqui estão as duas peças, prontas para adaptar.
Sessão de busca orgânica
Visita à landing page
Wallet Connect
evento GA4, endereço hashado
Join no Dune
Atividade on-chain da wallet
Passo 1: instrumente o wallet connect como um evento customizado do GA4
Dispare esse evento na conexão de wallet, com o endereço bruto hashado, nunca enviado como texto plano:
{
"name": "wallet_connect",
"params": {
"wallet_provider": "metamask",
"wallet_address_hash": "sha256_hashed_address",
"chain_id": "1",
"connect_source": "docs_page",
"utm_source": "{{utm_source}}",
"utm_campaign": "{{utm_campaign}}"
}
}
Isso conecta a camada de analytics web com a primeira ação on-chain. Você não vai ter atribuição on-chain completa só com o GA4, mas vai ver quais queries orgânicas e landing pages produzem wallet connects na maior taxa. Para a maioria dos protocolos, esse é o sinal de atribuição mais útil disponível sem um pipeline customizado no Dune.
Passo 2: cruze os connects com atividade on-chain no Dune
A query abaixo assume que você está exportando seus eventos de wallet connect do GA4 para uma tabela que o Dune consegue consultar. Um padrão comum é uma exportação agendada para um data warehouse, depois uma fonte de dados no Dune apontando para ele. Ela cruza esse registro de connect com transações on-chain contra o contrato do seu protocolo:
-- Atribuição de wallet: cruza wallet connects do site de marketing com atividade on-chain
-- Assume uma tabela `wallet_connects` populada a partir da sua exportação do GA4
-- (wallet_address, utm_source, utm_campaign, connect_timestamp)
with connects as (
select
wallet_address,
utm_source,
utm_campaign,
connect_timestamp
from dune.your_project.dataset_wallet_connects
),
first_tx as (
select
"from" as wallet_address,
min(block_time) as first_tx_time
from ethereum.transactions
where "to" = 0xYOUR_PROTOCOL_CONTRACT
group by 1
)
select
c.utm_source,
c.utm_campaign,
count(distinct c.wallet_address) as wallets_connected,
count(distinct t.wallet_address) as wallets_transacted,
round(100.0 * count(distinct t.wallet_address) / count(distinct c.wallet_address), 1) as connect_to_tx_rate_pct
from connects c
left join first_tx t
on c.wallet_address = t.wallet_address
and t.first_tx_time >= c.connect_timestamp
group by 1, 2
order by wallets_connected desc
O resultado é uma taxa de conexão para transação dividida por fonte e campanha de UTM, exatamente a cadeia que justifica o investimento em conteúdo para um board.
Isso exige um engenheiro de dados e algum trabalho de exportação server-side para colocar de pé. É viável para qualquer protocolo com time técnico. É a única forma confiável de ver se o tráfego orgânico de fato converte em atividade on-chain, não só em page views.
Faça o hash do endereço de wallet antes que ele chegue ao GA4. Os próprios termos do Google proíbem o envio de dados pessoalmente identificáveis. Um endereço Ethereum bruto atrelado a uma sessão identificável pode cruzar essa linha, mesmo que seja dado on-chain público.
Um hash unidirecional (SHA-256 serve) mantém o evento utilizável para atribuição. Também mantém o endereço bruto fora de uma plataforma terceira que você não controla por completo. Faça o cruzamento de fato entre wallet e transação dentro do Dune, contra seus próprios dados exportados, não dentro do próprio GA4.
Quanto custa SEO Web3 e quanto tempo leva
| Tarefa | Prazo típico |
|---|---|
| Correções técnicas (crawl, robots.txt, Core Web Vitals) | 2 a 4 semanas depois que o Google refaz o crawl |
| Listagens em diretórios de protocolo (CMC, CoinGecko) | 2 a 8 semanas para revisão e indexação |
| Conteúdo mirando novos clusters de palavras-chave | 3 a 6 meses até a primeira página, dependendo da autoridade de domínio e da concorrência |
| Citações em AI Overview / chats de IA | Podem aparecer em dias em conteúdo recém-indexado se o formato bater com o que a engine extrai |
Custos variam bastante por escopo e por quem executa: agência, consultor solo ou time interno. Não vou publicar uma faixa de valor específica aqui. Não tenho dados de mercado verificados para embasar um número, e um número inventado falharia o padrão que estou aplicando neste artigo.
O que posso afirmar com confiança: correções técnicas e listagens em diretório são as vitórias mais baratas e mais rápidas disponíveis. Elas deveriam acontecer antes de qualquer gasto pago com conteúdo ou link building.
Ao avaliar uma proposta, seja de agência ou consultor solo, pergunte o que exatamente é corrigido nos primeiros 30 dias. Pergunte como você vai saber que funcionou.
Um fornecedor que não consegue nomear um resultado concreto e checável no primeiro mês está vendendo um retainer, não um diagnóstico. As vitórias mais rápidas dessa categoria são baratas e rápidas justamente porque não exigem conteúdo novo, só corrigir o que já está quebrado.
Os 10 erros que queimam orçamento de SEO Web3
| # | Erro | Por que queima orçamento |
|---|---|---|
| 1 | Whitepaper só como PDF | O Google não consegue rastrear a estrutura de âncora dentro de um PDF. Você perde uma página de alta autoridade de graça |
| 2 | docs. e blog. como subdomínios separados | Divide o orçamento de crawl e a autoridade de entrada entre dois domínios separados que nunca se combinam em um só |
| 3 | Tokenomics renderizada só como gráfico JS, sem fallback de texto | Se o gráfico falha ao renderizar, o conteúdo rastreável desaparece por completo |
| 4 | robots.txt herdado bloqueando /docs ou /whitepaper | Crawlers não conseguem acessar conteúdo desautorizado, não importa quão bom seja |
| 5 | Bloquear crawlers de IA por acidente | GPTBot, ClaudeBot e PerplexityBot bloqueados significa zero citação em IA, não importa a qualidade do conteúdo |
| 6 | Perseguir picos de query de marca durante volatilidade de preço | Parece progresso de SEO no GSC. É pânico de preço, não patrimônio de busca |
| 7 | Fazer todo o trabalho de conteúdo dentro de Discord e Telegram | Profundidade real, zero patrimônio indexável. Os dois esforços não compõem juntos |
| 8 | Números estáticos de TVL ou preço em conteúdo de blog | Perde precisão em semanas e é propagado adiante por todo modelo que faz scraping dele |
| 9 | Ignorar o problema de SERP de marca dominada por agregador | CoinGecko ou CMC continua superando o seu próprio site para o seu próprio ticker, indefinidamente, se ninguém resolve |
| 10 | Construir um arquivo llms.txt esperando que ele gere citações | Análise de log de 137 mil domínios encontrou 97% dos arquivos llms.txt sem nenhuma requisição em um mês inteiro. É um arquivo de cortesia para agente de código, não uma tática de AEO |
Conteúdo multi-região e com bloqueio por jurisdição
Audiências cripto são globais e fragmentadas por jurisdição, e quase ninguém nessa categoria escreve sobre isso.
Hreflang é a tag que diz ao Google qual versão de idioma e região de uma página servir para qual audiência. Ela é mencionada exatamente uma vez nas 13 páginas que revisei para esta reescrita, como uma palavra solta sem nenhuma explicação.
Se o seu protocolo atende regiões distintas com exigências de compliance distintas, faça o gate de conteúdo por jurisdição deliberadamente em vez de geo-bloquear em silêncio.
Uma página invisível em uma região por motivos legais deveria continuar indexável onde é legal mostrá-la. Tags hreflang corretas deveriam apontar entre as variantes regionais. Geo-bloqueio silencioso sem hreflang confunde crawlers, que passam a achar que o conteúdo simplesmente não existe em lugar nenhum.
Este site roda um exemplo ao vivo desse padrão. O mesmo artigo existe em inglês, português brasileiro e espanhol. Cada um tem seu próprio slug traduzido, não uma cópia traduzida automaticamente da URL em inglês, cruzados com tags hreflang.
Um protocolo com uma base relevante de usuários na América Latina ou na Europa enfrenta a mesma decisão, e quase nenhum a toma de forma deliberada. A maioria ou publica só em inglês e perde o buscador não-anglófono, ou traduz automaticamente sem hreflang e acaba com sinais de conteúdo duplicado trabalhando contra ela.
A mecânica completa de rodar isso em três idiomas, o padrão de slug traduzido e tag canônica que uso neste site, está no satélite de SEO internacional.
Plano de ação de SEO Web3 por estágio
Pré-lançamento
3-6 meses antes do TGE
- Site no ar com SSR/SSG
- Auditoria agendada cedo
- Schema Organization + sameAs
Semana de lançamento
- Publicar relatório de auditoria
- Enviar URLs ao GSC
- Corrigir páginas em branco/modal de wallet
Pós-lançamento
meses 1-3
- Conteúdo de comparação + dashboard no Dune
- Varredura GSC posições 5-20
- Escopar programático (se multi-chain)
Crescimento
meses 3-12
- Pitches de mídia com dados do Dune
- Checagem de reclame de brand-SERP
- Publicar páginas programáticas
Escala
- Auditar páginas com impressões sem clique
- hreflang se houver parcela não-anglófona
- Conteúdo de ecossistema
As prioridades de SEO mudam conforme o protocolo amadurece, e o caminho mais rápido não é o mesmo para todo time. Autoidentifique-se pelo estágio primeiro. Passado o pré-lançamento, autoidentifique-se também pela estrutura do time ou pela pegada de chains, onde isso muda o caminho concreto. Cada trilha abaixo assume as bases de confiança e técnicas já cobertas neste guia.
Pré-lançamento (3 a 6 meses antes do TGE)
Confirme primeiro seu modelo de identidade de time. Isso muda um passo em uma trilha por lo demais idêntica.
Se seu time é pseudônimo ou anônimo →
- Coloque o site de marketing no ar no domínio raiz com SSR ou SSG, e consolide os docs em uma subpasta (
protocolo.xyz/docs) em vez de um subdomínio separado. - Configure o robots.txt para permitir todos os crawlers, incluindo GPTBot, ClaudeBot e PerplexityBot. Envie seu sitemap ao GSC imediatamente.
- Estruture o schema Organization em torno da entidade do protocolo, não de uma pessoa, com links
sameAspara seu repositório no GitHub, suas listagens no CMC e CoinGecko, e seu fórum de governança. O grafo de entidades do Google consegue verificar uma organização consistente mesmo quando não consegue verificar um indivíduo. - Publique o whitepaper em HTML junto com o PDF, e construa a página de tokenomics com texto HTML puro para cada categoria de alocação, nunca um gráfico só em JS.
- Agende sua auditoria de segurança agora, não depois do lançamento. É o primeiro substituto de autoridade institucional que um time sem credenciais precisa, e as auditorias fecham a agenda com semanas de antecedência.
- Inicie o processo de listagem no CMC e no CoinGecko cedo. Ambos têm períodos de revisão que levam semanas.
Se seu time é nomeado ou público →
Rode os mesmos seis passos. Dois ajustes: o schema Organization ainda ancora o protocolo, mas o schema Person é seguro de adicionar para contribuidores nomeados com credenciais reais e verificáveis. E a auditoria ainda importa exatamente igual. Um time nomeado não isenta conteúdo YMYL de escrutínio, só dá mais um sinal de confiança para empilhar junto da auditoria, não um substituto para ela.
Semana de lançamento
Mesma trilha independente da estrutura do time ou da pegada de chains.
- Publique o relatório de auditoria e linke com destaque da sua página de segurança.
- Envie novas URLs via solicitação de indexação manual do GSC.
- Monitore o GSC para erros de crawl especificamente em páginas renderizadas em JS, não só o relatório agregado de cobertura.
- Rode a ferramenta de Inspeção de URL na sua homepage, no índice de docs e na página de lançamento do token. Se o screenshot renderizado mostrar uma página em branco ou um modal nu de conexão de wallet, corrija isso antes de qualquer outra coisa nesta semana.
- Atualize suas listagens no CMC e CoinGecko com dados de exchange ao vivo imediatamente.
Pós-lançamento, meses 1 a 3
Autoidentifique-se pela pegada de chains aqui. É isso que determina se uma tática inteira já se aplica a você.
Se você é um protocolo de chain única e produto único →
- Comece a produzir conteúdo de comparação e "alternativas a" construído em torno dos seus concorrentes reais.
- Publique seu primeiro dashboard público no Dune com o nome do seu protocolo no título.
- Rode uma análise no GSC: ordene por impressões, filtre nas posições 5 a 20, e atualize essas páginas existentes para mirar a query de forma mais direta. Esse é o ganho de ranking mais rápido disponível neste estágio.
| Query | Página | Posição | Impressões |
|---|---|---|---|
| avici tokenomics | /publications/case-study-defi-avici | 6.2 | 43 |
| marketing analytics for defi growth teams | /publications/defi-growth-experiments-marketing-team | 7.6 | 27 |
| defilaunch | /publications/defi-launch-frameworks | 18.2 | 15 |
| hyperliquid team size | /publications/hyperliquid-analysis | 10.2 | 5 |
Dados reais de query do GSC para mangabeira.net, ordenados por impressões, filtrados nas posições 5 a 20, 2026-06-08 a 2026-09-05. A linha destacada é a query com mais impressões que está atualmente nessa faixa, exatamente o filtro que este estágio do plano manda rodar.
- Pule o SEO programático por enquanto. Um protocolo de chain única com um punhado de mercados não tem dados genuinamente distintos o suficiente para escapar do padrão de conteúdo raso que o Google desconta.
Se você é um protocolo multi-chain, uma DEX multi-par, ou um agregador →
- Rode os mesmos três primeiros passos: conteúdo de comparação, um dashboard público no Dune, e a varredura GSC de posições 5 a 20.
- Comece a escopar seu template de página programática agora, mesmo que você só vá publicá-lo no estágio de crescimento. Confirme qual campo, por token, por chain, ou por par, seu app já expõe, e construa o template contra essa fonte de dados ao vivo, não um dataset estático que fica desatualizado.
- Defina agora seu limite de noindex. Decida qual volume mínimo de dados, um par, um mercado, uma chain, uma página precisa antes de valer a pena indexá-la. Decidir isso antes de gerar centenas de páginas é o que impede o padrão de virar o spam de conteúdo raso no qual ele facilmente se transforma.
Estágio de crescimento (3 a 12 meses pós-lançamento)
Autoidentifique-se pela estrutura do time de novo aqui. As táticas convergem, mas o sequenciamento e uma alavanca diferem.
Se seu time é pseudônimo ou anônimo →
- Continue construindo o stack de autoridade institucional: rode ou atualize a auditoria de novo após qualquer mudança material de contrato, e mantenha a participação em governança (histórico de votos no Snapshot ou Tally) atrelada a um endereço consistente.
- Mire a mídia cripto com pitches guiados por dados construídos a partir dos achados do seu dashboard no Dune. Um número verificável que um jornalista pode checar vale mais que um press release, e não precisa de um porta-voz nomeado para funcionar.
- Rode a checagem de SERP de marca vista antes neste guia. Se o CoinGecko, o CMC, ou o DefiLlama ainda rankeiam acima de você para o nome do seu próprio protocolo, esse é o estágio para corrigir isso.
- Monitore citações em AI Overview e chats de IA mensalmente usando o método de bateria de prompts descrito acima.
- Se você é multi-chain ou multi-par, publique as páginas programáticas que você escopou nos meses 1 a 3.
Se seu time é nomeado ou público →
Rode os mesmos cinco passos. O stack de auditoria e governança ainda importa com fundadores nomeados. Você tem uma alavanca a mais que a trilha pseudônima não tem: fazer pitch para aparições em podcast e comentário com assinatura nomeada sob suas próprias credenciais. Um jornalista ou apresentador de podcast consegue verificar uma pessoa real mais rápido que uma entidade de protocolo, o que encurta o ciclo de outreach sem substituir os sinais institucionais acima.
Estágio de escala
Autoidentifique-se pela pegada de audiência. É isso que decide se conteúdo internacional é o próximo investimento ou um posterior.
Se uma parcela relevante da sua atividade é não-anglófona →
- Audite toda a biblioteca de conteúdo contra os dados atuais do GSC. Encontre páginas com impressões mas cliques quase zero e rode atualizações direcionadas primeiro, antes de adicionar conteúdo novo.
- Construa conteúdo internacional usando o padrão de slug traduzido e hreflang coberto na seção de multi-região acima, não cópias traduzidas por máquina da URL em inglês.
- Restrinja qualquer conteúdo específico de jurisdição deliberadamente, com tags hreflang corretas, em vez de geo-bloqueio silencioso.
Se sua atividade é só em inglês ou de mercado único →
- Rode a mesma auditoria do GSC primeiro: encontre páginas com impressões mas sem cliques e corrija essas antes de escrever qualquer coisa nova.
- Construa conteúdo de ecossistema cobrindo protocolos adjacentes na sua categoria. Autoridade de categoria é o que converte quem busca comparações em avaliadores do seu produto específico.
- Revisite a pergunta internacional a cada dois trimestres. Uma fatia de mercado que você não tem hoje pode aparecer assim que um protocolo for integrado a uma chain, wallet, ou exchange com uma base de usuários regional diferente.
Quer uma leitura estruturada de toda a presença de busca do seu protocolo?
O Web3 Growth Audit cobre lacunas de palavras-chave, problemas técnicos de crawl, oportunidades de conteúdo, autoridade de links e um plano de 90 dias ajustado ao estágio e à vertical do seu protocolo. Totalmente assíncrono, escopo fixo, sem call de descoberta.
Veja o Web3 Growth AuditAgência vs time interno: quando cada um faz sentido
| Fator | Agência | Contratação interna | Especialista assíncrono |
|---|---|---|---|
| Estrutura de custo | Retainer mensal, muitas vezes com entrega concentrada em juniores | Salário integral mais benefícios, custo fixo mesmo em períodos parados | Escopo fixo, único ou por engajamento |
| Velocidade de início | Lenta. Onboarding, camadas de gestão de conta | Mais lenta ainda. Ciclo de contratação, tempo de ramp-up | Rápida. Escopo definido e entregue de forma assíncrona em dias |
| Profundidade vertical | Varia muito, muitas agências generalizam cripto em um único playbook | Depende inteiramente de quem você contrata | Alta, se o especialista já atua em múltiplas verticais |
| Melhor encaixe | Times grandes e bem financiados que precisam de capacidade de execução contínua | Protocolos com necessidade sustentada e de longo prazo de volume de conteúdo | Times pós-PMF que precisam de diagnóstico e roadmap, não de headcount |
Não existe uma resposta universalmente certa aqui. Um protocolo com uma operação de conteúdo grande e sustentada se beneficia de uma contratação interna que vive dentro do roadmap diariamente. Um time que precisa de um diagnóstico estruturado, um plano priorizado e decisões de julgamento sem aumentar o headcount é melhor atendido por um engajamento assíncrono e com escopo definido.
O erro que vejo com mais frequência: um time parte direto para um retainer de agência antes de fazer as correções técnicas baratas e rápidas cobertas antes neste guia.
Pagar por conteúdo contínuo enquanto o seu robots.txt bloqueia silenciosamente a sua pasta de docs é gastar no lado errado do problema. Corrija o que está quebrado primeiro, não importa quem faz isso, depois decida como a capacidade contínua deveria de fato funcionar.
Perguntas frequentes
O que é SEO Web3?
SEO Web3 é a prática de otimizar protocolos blockchain, dApps e conteúdo relacionado a tokens para rankear nos mecanismos de busca tradicionais e ser citado em respostas geradas por IA. Ele aplica frameworks padrão de SEO aos desafios específicos de confiança, técnica e palavra-chave da Web3.
Como o SEO Web3 é diferente do SEO comum?
Três eixos: confiança (times pseudônimos não têm o E-E-A-T convencional) e stack técnico (SPAs em React e portões de wallet muitas vezes bloqueiam crawlers). O terceiro é intenção de busca, já que queries de protocolo misturam pesquisa, especulação de preço e avaliação técnica juntas.
Quanto tempo o SEO Web3 leva para mostrar resultado?
Correções técnicas mostram resultado em 2 a 4 semanas depois que o Google refaz o crawl. Listagens em diretório levam de 2 a 8 semanas para revisão. Conteúdo novo em cluster de palavras-chave tipicamente leva de 3 a 6 meses para chegar à primeira página. Citações em IA podem aparecer em dias se o formato bater com o que a engine extrai.
Quanto custa SEO Web3 em 2026?
Custos variam bastante por escopo, agência versus time interno versus especialista assíncrono, e quanta correção técnica é necessária de início. Não tenho dados de preço de mercado verificados para publicar uma faixa específica aqui. Faça o orçamento de forma conservadora e defina o escopo por entregável, não por tamanho de retainer.
Links cripto são mais caros que links de SEO comum?
Algumas agências desse espaço publicam alegações de que links cripto custam várias vezes um link SaaS comparável. Não verifiquei de forma independente um multiplicador específico. Trate qualquer número que você vir, incluindo os desta peça, como uma alegação direcional da indústria, não como um fato definitivo.
Como eu meço o ROI do SEO Web3?
Acompanhe eventos de wallet connect no GA4 junto com impressões e cliques por categoria de query no GSC. Para atribuição completa, cruze os logs de wallet connect com dados de transação on-chain no Dune, o padrão de query está coberto na seção de atribuição on-chain acima.
Dá para fazer SEO para um projeto cripto sem volume de busca?
Sim. Volume baixo reportado em termos específicos de protocolo não significa valor baixo. Um fundador buscando "[protocolo] vs [protocolo]" está avaliando ativamente onde alocar capital, independente do que a estimativa de volume de uma ferramenta de palavras-chave mostra.
Quais palavras-chave um projeto cripto deveria mirar primeiro?
Comece pelos dados do GSC nas posições 5 a 20, esses são os seus ganhos mais rápidos. Depois construa queries de comparação ("[protocolo] vs [protocolo]"), termos de categoria do DefiLlama ou CoinGecko, e queries de confiança ("is [protocolo] safe").
Projetos cripto deveriam otimizar para busca por IA (ChatGPT, Perplexity)?
Sim. Queries informacionais de protocolo cada vez mais acionam uma resposta gerada por IA antes de qualquer resultado orgânico carregar. Estruture o conteúdo com definições diretas de 40 a 60 palavras no topo de cada seção, e verifique se o seu robots.txt não bloqueia GPTBot, ClaudeBot ou PerplexityBot.
Projetos cripto novos ou pequenos conseguem rankear contra grandes exchanges?
Sim, nas queries que as exchanges não disputam. Exchanges dominam queries de preço e listagem. Protocolos pequenos vencem em queries de mecanismo, comparação e confiança que o time de conteúdo de uma exchange grande não tem motivo para escrever.
Qual o papel dos dados on-chain no SEO Web3?
Dados on-chain não alimentam o Google diretamente, o Google não lê a blockchain. Mas a atividade on-chain gera a cobertura de imprensa, as citações no Dune e a discussão de comunidade em plataformas indexáveis que de fato constroem autoridade de busca. A ligação é real, mas indireta.
Quais ferramentas funcionam melhor para pesquisa de palavras-chave Web3?
Google Search Console para impressões existentes, páginas de categoria do DefiLlama e CoinGecko para mapeamento de tópico, e padrões de query de dashboard no Dune para o que a sua comunidade de fato acompanha.
Dá para construir SEO em um projeto cripto sem blog?
Parcialmente. Docs, uma página de tokenomics e um whitepaper em HTML podem rankear por conta própria. Mas um blog é onde vivem conteúdo de comparação, respostas a queries de confiança e comentário oportuno, e essas coisas são difíceis de substituir.
Quais são os erros de SEO Web3 mais comuns?
Whitepapers só em PDF, dividir docs e blog em subdomínios separados, gráficos de tokenomics só em JS sem fallback de texto, e bloquear crawlers de IA por acidente no robots.txt. A lista completa de 10 está acima.
Os docs do protocolo deveriam viver em um subdomínio ou em uma subpasta?
Uma subpasta no domínio raiz (protocolo.xyz/docs), não um subdomínio (docs.protocolo.xyz). Subdomínios dividem sinais de autoridade entre dois domínios mais fracos. Subpastas os consolidam em um só.
Como eu acompanho wallet connects como uma conversão de SEO no GA4?
Dispare um evento customizado do GA4 na conexão de wallet, com o endereço hashado em vez de enviado como texto plano, e parâmetros de UTM anexados. O schema completo do evento está na seção de atribuição on-chain acima.
Como um time pseudônimo satisfaz o E-E-A-T?
Substituindo credenciais pessoais por autoridade institucional: auditorias de segurança publicadas, histórico de commits no GitHub, participação em governança e citações de terceiros confiáveis. Estruture o schema de Organization em torno da entidade do protocolo em vez de um indivíduo.
Por que o CoinGecko supera o meu protocolo para o nome do meu próprio token?
Páginas de agregador carregam autoridade de domínio alta e dados estruturados explícitos que o Google recompensa. A correção não é competir nas queries de preço, é dominar as queries de mecanismo, roadmap e comparação que a página do agregador não consegue responder.
Como eu sei se o ChatGPT ou o Perplexity está citando o meu projeto?
Rode uma bateria fixa de 8 a 20 prompts por uma API que retorna citações estruturadas, como a da Perplexity. Contabilize os resultados por domínio e URL mensalmente. O método completo está na seção de medição de citações de IA acima.
Os protocolos que constroem patrimônio de busca agora pagam uma fração do que os retardatários vão pagar depois. Retardatários adquirem usuários equivalentes via canais pagos e acordos com KOLs mais tarde. Essa matemática vale na Web3 do mesmo jeito que vale em qualquer outro lugar. Demora mais para começar e compõe indefinidamente depois que começa.
Quer um diagnóstico estruturado de onde está a presença orgânica do seu protocolo de verdade? O Web3 Growth Audit cobre SEO como parte de uma revisão completa do sistema de distribuição.
Escrito por Gabriel Mangabeira, estrategista de crescimento Web3 no mangabeira.net. Análise de SERP e teste de citação de IA conduzidos em setembro de 2026. Dados de GSC do mangabeira.net dos últimos 12 meses. Dados de volume de palavras-chave via YepAPI. Identidade on-chain verificada via ENS e web3.bio, setembro de 2026.