Estávamos na onda da Copa. Figurinhas, álbum, troca. Eu demorei a entrar e me arrependi do timing. Ainda assim, em poucas horas de trabalho — na prática o dia inteiro mandando correção e função nova — subiu um site com 980 figurinhas em português, inglês, espanhol, francês, italiano, japonês, coreano e alemão. No Search Console eu enviei o sitemap e a conta foi 8.656 páginas encontradas. O site tinha menos de 24 horas.
O volume saiu de dado estruturado, não de texto repetido. Cada figurinha virou ficha de jogador, raridade, código, afiliado e um álbum digital. Eu não usei banco: Astro estático na Cloudflare, imagens baixadas com extensão de navegador, placeholder onde faltou foto. Codex no plano do GPT, pedido explícito de Workers + Astro sem Next.js e sem biblioteca extra.
- Catálogo
- 980 figurinhas × 8 idiomas + jogos e álbum
- Sitemap
- 8.656 URLs no Search Console, site com menos de um dia
- Stack
- Astro na Cloudflare, sem banco, deploy pelo Codex
Ficha da figurinha, álbum compartilhado e dois jogos no subdomínio
A página da figurinha não é um título com a foto. Tem detalhe do jogador, nascimento, altura, clube, código da figurinha, raridade, história. Tem atalho de compra em afiliado — Amazon e o que eu fosse ligando. Tem o botão de guardar no álbum. O álbum é um checklist digital: você marca o que tem, gera um link e manda para outra pessoa ver o que falta. O estado fica no localStorage. Não é cache. Fecha o navegador, abre de novo, a coleção continua naquela máquina.
No subdomínio de jogos, o domínio principal já era focado em estilo DLE. Trouxe uma versão Copa: você tenta o nome do jogador do dia e o jogo devolve altura, clube, ano de nascimento, maior ou menor, até fechar. Outro modo mostra a imagem e dá cinco palpites. Sem essas peças, o site seria só um diretório. Com elas, a pessoa volta.
Também subi uma vitrine de produto afiliado: capa, sleeve, o que guarda figurinha. Tudo isso nasceu no mesmo dia de iteração. As ideias chegaram depois do primeiro pedido. O Codex atualizou salário, contrato, marca. Eu pedi esses campos porque termo de marca e dinheiro costuma puxar o valor do clique na rede de anúncios. Não tenho número de receita deste projeto para colocar aqui. Tenho a intenção: ficha rica, não página oca.
O loading dos anúncios só na segunda página, de propósito
O site em JavaScript abre rápido. Eu coloquei um loading mesmo assim. Motivo: esperar o anúncio renderizar e melhorar viewability. Muita gente recusa isso porque o laboratório de velocidade pune. O recorte que eu usei: na primeira entrada a página aparece na hora. O loading entra quando a pessoa já está no site e navega de uma URL para outra, como um app client-side. Não é bloquear o HTML dos robôs. Não é segurar a primeira pintura para o anúncio. É a navegação interna.
Isso também segura CLS: o anúncio não empurra o layout depois que a pessoa já está lendo, no caminho entre fichas. A rede de anúncios tem regra sobre atraso artificial. O que eu descrevi no vídeo é esperar o slot na troca de página do visitante humano, não esconder conteúdo do crawler. Se você copiar o truque, leia a política da sua rede. Eu não estou ensinando a trapacear métrica de laboratório.
Álbum no localStorage e link compartilhável fecham o loop social. Quem recebe o link vê a coleção da outra pessoa. Nada disso precisa de conta, e-mail ou banco. Por isso o projeto inteiro pôde ficar estático.
Astro desta vez, 31 Workers, e o pedido que segura a fatura
Eu não sou fã de Astro. Na verdade eu não conhecia bem e achava dependência demais. O dia a dia era Hono. Neste site fui de Astro, leve, sem biblioteca empilhada, feito para Cloudflare Workers. No painel eu mostrei 31 sites na conta: domínio, subdomínio, ferramenta, API, desenvolvimento. Inteligência artificial da própria Cloudflare também está no menu. O deploy deste álbum saiu do Codex. Eu pago o plano do GPT. Claude Code eu queria testar; na gravação ainda não era o caminho.
Workers começa de graça. Com 5 dólares entram milhões de requests no mês e 25 bilhões de linhas lidas no D1. Sem saber pedir, o código lê essas bilhões rápido e a fatura aparece. Neste álbum eu zerei o risco de banco: zero query. Markdown, MDX, arquivo estático — para blog isso basta. Figurinhas foram dados no build. Sem D1, a cota de linha lida nem entra na conversa.
Se você não trava a stack, a IA puxa Next.js e um saco de pacotes. O site fica pesado. O pedido que eu uso na maioria dos projetos pede Workers, HTML semântico, SSR de ponta a ponta, schema, meta social, OG. TypeScript ou JavaScript na hora de escrever quase tanto faz: o que o isolate executa é o bundle. Dá para entregar HTML sem mandar um arquivo .js para o visitante. Quem vem de PHP precisa dessa frase: JavaScript no servidor não é o scriptzinho no rodapé do tema.
- Reúna o ativo (imagem, código, atributo) antes de pedir o site. Eu não achava as 980 fotos.
- Baixe em lote o que a loja expuser; eu usei extensão de navegador e fiquei com umas 750.
- Peça Workers + Astro ou Hono, sem Next, sem lib extra, SSR completo.
- Complete o catálogo depois; o Codex preencheu até 980 e inventou placeholder decente onde faltou foto.
- Envie o sitemap no Search Console no mesmo dia. Indexação não é instantânea.
De 750 fotos a 980 fichas, e o que 8.656 URLs ainda não provam
Sem imagem não existe site de figurinha. Vasculhei loja até achar um catálogo com mais de 750. Não eram as 980. Baixei tudo de uma vez com extensão. Passei o lote ao Codex: diretório da Copa, oito idiomas, Cloudflare, sem dependência. O primeiro corte saiu com 750. Depois pedi as 980. Onde não havia foto, ele montou um placeholder organizado, um por recorte da página. Feio seria um quadrado quebrado. Aquilo era uma ficha de verdade esperando o PNG.
Pedir tudo de uma vez gasta menos token do que ir soltando ideia. Eu não fiz isso. As funções nasceram no caminho: jogo, álbum, afiliado, marca, salário. Ele atualizou bem. Ainda assim, cada ida extra é correção, regressão, arquivo a mais.
8.656 páginas no sitemap não são 8.656 páginas úteis no índice. Eu mandei indexar. Não sabia o que o Google ia pegar. O vídeo não tem ranqueamento, não tem receita, não tem “ganhei X”. Tem um site estruturado no ar, em oito idiomas, com dado de jogador, jogo e álbum, construído em menos de um dia porque a entidade (a figurinha) já existia no mundo. Sem essa entidade, milhares de URLs são só milhares de URLs.
Na sequência
- Modele a entidade (figurinha, jogador, código, raridade) antes de gerar rota.
- Trave a stack: Workers, Astro ou Hono, SSR, sem pacote de moda.
- Separe primeira visita (HTML na hora) de navegação interna (se for usar loading de anúncio).
- Use localStorage só para estado do visitante; não finja que isso é conta no servidor.
- Confira o sitemap no Search Console e aceite que índice não nasce no mesmo dia do deploy.
Onde isso quebra
Deixar a IA escolher Next.js “porque é o padrão” e herdar o peso no Workers.
Criar oito idiomas de uma página que só troca o nome, sem dado novo.
Segurar o HTML do robô para o anúncio pintar — isso não é o que eu fiz.
Medir sucesso por número no sitemap no primeiro dia.
Perguntas frequentes
Precisa de banco para milhares de páginas?
Neste álbum, não. Figurinhas e idiomas foram build estático em Astro. Banco entra quando a página muda por usuário ou por escrita o tempo todo. Álbum no localStorage não é banco.
Por que Astro se você prefere Hono?
Neste projeto eu quis um gerador estático leve na Cloudflare. Hono continua o caminho da maior parte dos meus sites. Astro foi experiência, com pedido explícito de não puxar biblioteca.
Quanto tempo até o Google indexar 8.656 URLs?
Eu não tinha 24 horas de site quando enviei o sitemap. O vídeo termina aí. Enviar o arquivo não é o mesmo que ter a ficha no índice.
E as fotos que faltaram?
Placeholder gerado no mesmo layout da figurinha. Melhor que quebrar a grade. Depois se troca o arquivo sem redesenhar a página.