01 · O que o Bonn App é
Uma rede social de restaurantes. O usuário abre o app, acha o prato, marca presença, compartilha. Pros donos de restaurante, é cardápio digital + agenda de eventos + integração com stories do Instagram num lugar só.
Posicionamento público: "a primeira rede social de restaurantes do Brasil — totalmente gratuita e sem publicidade". A promessa exige escala — e escala na web passa por SEO.
02 · Por que isso é um problema de SEO difícil
Quando alguém digita "onde comer em Pouso Alegre", o Google tem uma decisão fácil: TripAdvisor, Kekanto, iFood Descubra. Marca nova não entra nessa disputa por autoridade de domínio — entra por template replicável com conteúdo único o suficiente pra merecer um lugar.
Template mal feito = penalização. Foi o que aconteceu com outro projeto da casa anos atrás (o site antigo huioswebmarketing.com.br — centenas de páginas quase-idênticas, Google desindexou em massa). Usamos essa cicatriz como manual do que não fazer no Bonn App.
03 · O que fizemos diferente
- Cada página de cidade tem conteúdo único de verdade. Não é "X é uma cidade brasileira e tem muitos restaurantes". É trecho autoral sobre o que caracteriza a cena gastronômica local, sugestões específicas extraídas da base de pratos cadastrados no app, e indicações por momento ("almoço executivo", "jantar romântico", "pós-trilha").
- Threshold mínimo de 600 palavras únicas por página indexável. Abaixo disso,
noindexautomático — melhor não existir no sitemap do que arriscar a confiança do domínio inteiro. - Fingerprint de similaridade entre páginas do mesmo template. Se duas landings tiverem Jaccard 3-grams acima de 0.8, uma vira canônica e a outra sai do índice. Isso roda como lint em CI antes de
next build. - JSON-LD
ItemListem cada landing, com os pratos reais cadastrados pra aquela cidade no app. Schema.org dá sinal de que a página tem dado estruturado, não só texto. - Interlink manual entre cidades vizinhas. "Onde comer em Águas de Lindoia" linka pra Socorro, Serra Negra, Lindóia, Monte Sião. Google lê o cluster semântico, não a página isolada.
- Imagens com
altdescritivo por prato, não "foto1.jpg". Parece óbvio. 80% dos sites de restaurante competindo nessas SERPs não faz.
04 · Resultado medido (DataForSEO Labs, Brazil, abril/2026)
- 1.248 keywords ranqueadas no Google Brasil.
- ~9.670 visitas orgânicas/mês estimadas (ETV do domínio).
- 357 keywords novas no último ciclo de crawl — o domínio ainda está em rampa, não platô.
- 524 keywords subiram de posição no mesmo período contra 294 que desceram.
- Top 3 em keywords competitivas:
- "restaurantes pouso alegre" — posição 3, volume 6.600/mês
- "restaurantes em itaquera" — posição 2, volume 2.400/mês (subiu de #5 pra #2 no último ciclo)
- "aguas de lindoia restaurantes" — posição 3, volume 3.600/mês (subiu de #14 pra #3)
05 · Stack
Next.js 16 App Router · Prisma + Postgres (Neon) · ISR com revalidateTag · Vercel · JSON-LD ItemList + LocalBusiness por rota · sitemap.ts como whitelist (só entra a landing que passou no lint de guardrail, nunca como blacklist).
06 · O que o Bonn App ganhou com isso
Tráfego qualificado que chega buscando "restaurantes em [cidade]" — exatamente o match de intenção da proposta do produto. CPA de lead tende a zero (tráfego é orgânico puro) e um floor de aquisição que independe de campanha de Ads rodando.
Mais importante que o número hoje: o método está documentado. Quando o produto quiser abrir mais 40 cidades, o template já roda com guardrail. Não é corrida — é esteira.