Neste artigo
Encontrei um bug no meu próprio site que escondia 87 das 108 páginas dos mecanismos de busca. O site parecia normal no navegador o tempo todo.
Você provavelmente já publicou algo que parece funcionar e mesmo assim é ignorado pelos crawlers.
Este texto percorre essa correção, mais quatro outras falhas tiradas direto da stack em produção do mangabeira.net, não de uma auditoria genérica.
Você vai ver o bug de renderização, a allowlist de crawlers de IA e as regras de schema que evitam que dados ao vivo fiquem desatualizados. Meu guia de SEO para web3 cobre o resto do cluster.
O Que é SEO Técnico Web3
SEO técnico para Web3 torna o conteúdo de um site cripto legível, indexável e citável por mecanismos de busca e crawlers de IA. A maioria dos frontends Web3 são aplicações client-side com conexão de wallet e dados on-chain ao vivo. As ferramentas de SEO padrão nunca foram feitas para isso.
Quatro coisas importam mais. Se os crawlers conseguem renderizar suas páginas. Se seu conteúdo vive em um só lugar, ou se espalha entre um site de marketing, um app e um subdomínio de documentação.
Se seus dados carregam marcação legível por máquina. E se você já disse aos crawlers, incluindo os de IA, o que eles podem fazer com o que encontram.
O SEO técnico padrão assume um site estático com um punhado de crawlers a considerar. Web3 adiciona três pressões: renderização client-side, dados ao vivo que mudam a cada bloco, e crawlers de IA que se comportam nada como o Googlebot.
O Problema de Renderização: O Que o Googlebot Vê vs. O Que os Crawlers de IA Veem
O Googlebot renderiza JavaScript. Ele enfileira sua página, executa o JS e indexa o que vê. É mais lento que HTML estático, mas funciona.
GPTBot e ClaudeBot não fazem isso. Eles buscam o HTML bruto e não executam nenhum JavaScript.
Se seu conteúdo só existe depois de uma renderização client-side, esses crawlers veem uma casca vazia. Isso vale não importa quão boa a página pareça no navegador.
Encontrei essa falha exata no meu próprio site em 02/08/2026. Eu estava auditando uma afirmação de um post no LinkedIn sobre um bug de renderização de outro projeto. A auditoria virou um espelho.
O mangabeira.net roda um Cloudflare Worker que entrega snapshots renderizados para crawlers conhecidos, incluindo Googlebot, GPTBot, ClaudeBot e PerplexityBot. Ele dispara quando uma requisição envia um header Accept: text/html. Testado contra as 108 URLs do sitemap, toda rota passou: títulos corretos, canonicals e o JSON-LD completo.
O header da resposta confirmou: x-render-source: cf-worker-snapshot.
Onde o bug de verdade estava escondido
O Worker estava mascarando um defeito no build de origem. O vite.config.ts nunca chamava loadEnv(), então o script de prerender do lado Node lia process.env.VITE_SUPABASE_URL, sempre undefined no momento do build. A busca no Supabase falhava silenciosamente, a lista de artigos voltava vazia, e 87 das 108 rotas do sitemap caíam de volta para o shell da homepage na origem. O build passava verde o tempo todo, produzindo silenciosamente um site incompleto a cada deploy.
Uma checagem no navegador nunca vai pegar isso. O bug ficou invisível porque o Worker interceptava o tráfego de crawlers antes de chegar ao build quebrado. O build quebrado continuava sendo o ponto único de falha do sistema.
Se o Worker fosse mal configurado, ou se um novo UA de crawler passasse pela allowlist, esse crawler atingiria o build quebrado. Veria uma homepage com o título errado em 87 URLs diferentes.
A correção, publicada em 05/08/2026, foi duas linhas. Eu integrei loadEnv(mode, process.cwd(), "") em process.env antes do array de plugins do Vite ser montado. Verifiquei com um clone novo: a contagem de prerender foi de 20 das 108 páginas para 108 de 108.
Uma camada de mitigação não é a mesma coisa que uma correção. O Worker foi uma boa engenharia. Mas ele deixou um defeito real sobreviver sem ser detectado por meses, porque nunca falhava de forma visível.
Se seu site é uma single-page app, verifique duas coisas. Sua etapa de prerender roda contra as variáveis de ambiente de produção? E sua camada de fallback, se você tiver uma, falha de forma visível quando a origem que ela protege quebra?
Arquitetura do Site: Site de Marketing, App e Subdomínio de Documentação
A maioria dos projetos Web3 se divide em pelo menos três superfícies: um site de marketing (projeto.xyz), uma aplicação (app.projeto.xyz) e documentação (docs.projeto.xyz). Mecanismos de busca tratam subdomínios como propriedades relacionadas mas distintas, então autoridade de link, relevância e orçamento de crawl se dividem entre três grafos de crawl em vez de um só.
Vejo esse padrão o tempo todo em auditorias de protocolos. Um subdomínio acaba rankeando no lugar daquele que a equipe realmente queria vencer.
Fundir subdomínios nem sempre é a correção. É uma decisão grande de infraestrutura, com trade-offs reais.
A correção de verdade é uma escolha explícita. Decida qual subdomínio deve rankear para qual busca, faça cross-link de forma deliberada, e aponte as tags canonical para a superfície que você quer que vença.
Fique Atento
Um subdomínio de documentação costuma superar o site de marketing exatamente nos termos que o marketing queria dominar, porque as páginas de docs são estáticas e densas em texto enquanto o site de marketing é um app client-side mais pesado. Essa divisão precisa ser uma escolha deliberada, não um acidente.
O próprio frontend do app, atrás do fluxo de conexão de wallet, é um problema diferente: conteúdo restrito, rotas dinâmicas por endereço, estado dependente de sessão. Não entro nesse nível de detalhe aqui de propósito. Merece um recurso próprio.
Schema para Web3: Estruturando Conteúdo e Dados ao Vivo
A marcação de schema (JSON-LD) diz aos mecanismos de busca e sistemas de IA o que uma página é, não só o que ela diz. Três tipos cobrem a maior parte do que importa: Article para conteúdo editorial, FAQPage para seções de perguntas e respostas, e Organization para a entidade por trás do site.
Este artigo carrega os três. O FAQ abaixo está marcado como schema FAQPage, não é só uma lista estilizada.
A parte específica de Web3 são os dados ao vivo. Uma página mostrando o preço de um token, TVL ou número de holders só é precisa por um instante.
Sem um timestamp, um crawler ou um modelo de IA não tem como saber se os números estão atuais. Podem estar desatualizados há seis meses.
Duas regras corrigem isso. Marque toda página orientada a dados com uma data visível de "última atualização" perto do conteúdo, não escondida no rodapé. Atualize o dateModified toda vez que os dados subjacentes mudarem, não só quando você editar o texto ao redor.
Insight-chave
Para uma máquina, uma página de dados de token sem sinal de atualidade é o mesmo que uma página sem data nenhuma. A atualidade precisa ser declarada, não presumida.
Controle de Crawl e Indexação: robots.txt, Allowlists de Bots de IA e Content-Signal
O robots.txt faz dois trabalhos. Ele diz aos crawlers o que podem acessar. Cada vez mais, também diz aos crawlers de IA o que podem fazer com o que encontram.
A maioria dos projetos erra o primeiro trabalho por acidente. Herdam um template que bloqueia caminhos de staging, e acaba pegando junto /docs ou /whitepaper. Confira o seu contra as suas rotas reais em produção, e não presuma que está correto só porque veio pronto com o framework.
O segundo trabalho é mais novo, e a maioria dos sites ainda não mexeu nele. Em 31/08/2026, adicionei Content-Signal: search=yes, ai-input=yes, ai-train=yes ao robots.txt do mangabeira.net sob User-agent: *, usando o padrão emergente contentsignals.org.
ai-train=yes foi uma escolha deliberada, fora do padrão. Ela abre o site totalmente para treinamento de IA, além de input de IA e indexação de busca. Essa decisão deve seguir sua própria estratégia de citação, não ser tomada por omissão.
Duas coisas que verifiquei e deixei de lado, porque "fazer menos" às vezes é a decisão certa. Headers de resposta de link para um recurso voltado a agentes: nenhum existe ainda. Registros DNS-AID: exigem DNSSEC, que a zona não tem.
Infraestrutura para um padrão que ninguém lê não é SEO técnico. É ruído que parece diligência.
| Elemento do robots.txt | O que controla | Erro comum em Web3 |
|---|---|---|
Disallow |
Quais caminhos os crawlers podem buscar | Template herdado bloqueia /docs ou /whitepaper por acidente |
| Regras nomeadas para bots de IA (GPTBot, ClaudeBot, PerplexityBot) | Se os crawlers de IA podem acessar o site | Bloqueados sem revisão, matando a citação em respostas de IA antes mesmo de começar |
Content-Signal |
O que os crawlers podem fazer com o conteúdo coletado (busca, input de IA, treinamento de IA) | Não declarado, deixando as preferências de uso implícitas |
Performance em Frontends com Muita Wallet
Core Web Vitals é um sinal de ranking do Google. Fluxos de conexão de wallet prejudicam os três. Bundles pesados de JavaScript para SDKs de wallet atrasam o largest contentful paint.
Modais de conexão sem espaço de layout reservado causam layout shift. Handlers de eventos de wallet na thread principal bloqueiam a interação até o next paint. Não entro a fundo em corrigir isso aqui, já que é mais um problema de frontend de dApp do que algo que afeta o site inteiro.
Eis o enquadramento no nível do site inteiro. Se suas páginas de marketing compartilham o bundle de JavaScript com o seu app, o peso do SDK de wallet penaliza páginas que nunca tocam em uma wallet. A correção está abaixo.
Boa prática
Separe o bundle para que páginas de marketing e conteúdo carreguem sem dependências de wallet. Um crawler esperando por código que não precisa é uma correção de SEO técnico, não só de performance.
Perguntas Frequentes
O que é SEO técnico Web3?
SEO técnico para Web3 torna o conteúdo de um site cripto legível e indexável por mecanismos de busca e crawlers de IA. Ele considera renderização client-side, subdomínios divididos, dados on-chain ao vivo que precisam de sinais de atualidade, e permissões explícitas de crawler via robots.txt e declarações Content-Signal.
Por que os crawlers de IA não veem a mesma página que o Googlebot vê?
O Googlebot executa JavaScript antes de indexar uma página. GPTBot, ClaudeBot e a maioria dos outros crawlers de IA buscam o HTML bruto e não rodam JavaScript nenhum. Um app client-side pode parecer completo no navegador e mesmo assim estar vazio para esses crawlers, a menos que o conteúdo exista já na resposta inicial.
Preciso de um Cloudflare Worker para corrigir a renderização para crawlers de IA?
Um Worker que entrega snapshots pré-renderizados para crawlers conhecidos é um padrão que funciona, e é o que o mangabeira.net roda. Mas é uma camada de mitigação, não um substituto para um build que pré-renderiza corretamente na origem. Trate-o como defesa em profundidade, não como a correção principal, ou um defeito de build pode passar despercebido por meses.
Qual é a diferença entre SEO técnico Web3 e SEO para dApps?
SEO técnico Web3 cobre a stack inteira do site: renderização, arquitetura de subdomínios, schema, controle de crawl e performance. SEO para dApps é mais específico: a própria interface da aplicação, conteúdo restrito por wallet, rotas dinâmicas por endereço e indexação do subdomínio do app, que precisa de um tratamento próprio.
Devo abrir meu robots.txt para crawlers de IA?
Depende da sua estratégia de citação, mas deixar isso indeclarado é pior. Se você quer que seu projeto seja citado em respostas geradas por IA, GPTBot, ClaudeBot e PerplexityBot precisam de acesso explícito. Uma declaração Content-Signal (search=yes, ai-input=yes, ai-train=yes, ou uma combinação mais restrita) deixa sua preferência explícita em vez de entregá-la ao comportamento padrão de cada crawler.
Analyst in the Arena · Gabriel Mangabeira
Faça a auditoria de SEO técnico do seu protocolo antes que custe rankings
Não sabe o que um crawler realmente recebe do seu site?
Isso é a primeira coisa que eu testo. Meu Web3 Growth Audit cobre renderização, controle de crawl e as correções de schema deste artigo, rodadas contra sua stack em produção.
Conheça o Web3 Growth Audit →Essa é a lição de verdade: SEO técnico Web3 não é uma checklist que você resolve de uma vez. É um conjunto de suposições, sobre variáveis de ambiente, sobre quais crawlers executam JavaScript, sobre o que o seu robots.txt diz. Essas suposições precisam ser reverificadas toda vez que a stack muda por baixo delas.
Para o contexto mais profundo do cluster, o guia completo de SEO web3 conecta este texto de volta à pesquisa de palavras-chave, construção de links e citação em AI Overviews.