ESTUDO DE CASO / ENGENHARIA DE PLATAFORMA + CRESCIMENTO

Uma plataforma de conteúdo para cliente, com o motor orgânico por cima

Uma empresa brasileira de contabilidade digital, online desde 2018, precisava de uma plataforma em que seus editores conseguissem publicar e de um motivo para os buscadores a encontrarem. Construí a plataforma e conduzi SEO, estratégia de conteúdo e produção de conteúdo por cima dela, sozinho.

Ver o caso do produto de eventos
  1. Base
  2. Componentes
  3. Variantes
  4. Páginas
CONTENT PLATFORMDIAGRAMA CONCEITUAL
ANATOMIA DO CASO
Função
Product engineer solo, responsável por SEO e conteúdo (cliente)
Período
2025 a janeiro de 2026

Contexto e escopo

Uma empresa brasileira de contabilidade digital, online desde 2018, tinha quase nenhum tráfego orgânico não-marca. O site não sustentava os formatos de conteúdo que uma categoria competitiva exige, e o editor não conseguia publicar uma página rica sem trabalho de engenharia.

O trabalho cobriu as duas metades do problema em um só lugar. Construí a plataforma em PayloadCMS e Next.js 15 com um page builder próprio, e depois conduzi a consultoria de SEO, a estratégia de conteúdo e a produção de conteúdo por cima dela. Sozinho, como solopreneur, com um estagiário ou freelancer ajudando no conteúdo.

Este é o registro que mostra a combinação de forma direta: a plataforma é a razão de o conteúdo poder ser produzido em volume, e o conteúdo é a razão de a plataforma ter movido os números.

O problema

  • O tráfego orgânico não-marca estava na casa das dezenas de visitas por mês, e quase todo o tráfego existente era de marca.
  • Os editores não conseguiam compor os formatos de página que a categoria exigia sem um desenvolvedor a cada vez.
  • O modelo de conteúdo e a estrutura de SEO não eram a mesma coisa, então cada tipo de página era uma decisão nova.
  • Um conjunto de palavras-chave acima de quarenta mil termos era bagunça, não plano.
  • A produção de conteúdo era um gargalo, não só a publicação.
  • As necessidades de múltiplos idiomas (pt, en, es) estavam chegando, e o site não foi construído para elas.
Mapa do sistema
SuperfícieMódulos compostos
Hotéis
  • Busca
  • Resultado
  • Detalhe do hotel
  • Reserva
Pacotes
  • Montagem
  • Preço
  • Detalhe do pacote
  • Checkout
Transfers
  • Trajeto
  • Opções
  • Agendamento
  • Confirmação
Passeios e ingressos
  • Catálogo
  • Disponibilidade
  • Compra
  • Confirmação
VISÃO CONCEITUAL / ESCOPO PÚBLICO

Restrições

  • Um trabalho solo, então plataforma, SEO e conteúdo precisavam dividir a mesma agenda e o mesmo responsável.
  • Uma data de go-live em janeiro de 2026, com conteúdo real já no plano.
  • O stack do cliente vivia na AWS, então a plataforma precisava se encaixar nele em vez de substituí-lo.
  • Performance no lançamento importava, porque a categoria é competitiva em experiência de página.
  • Os detalhes do cliente permanecem privados, então o registro é escrito a partir do escopo do trabalho e dos resultados medidos.

O que construí

  • Uma plataforma de conteúdo em PayloadCMS 3, Next.js 15 e React 19, com 18 collections e cerca de 25 blocos modulares em um page builder próprio.
  • Uma biblioteca de componentes grande e cheia de variações, para que um bloco renderizasse muitos layouts sem código novo.
  • Uma camada de resiliência de blocos, para que um bloco quebrado ou vazio degradasse de forma limpa em vez de derrubar a página.
  • Controle de acesso por papel, preview ao vivo e localização em pt, en e es.
  • Trabalho de cloud e mídia em AWS S3 e CloudFront, com Mux para vídeo, e uma migração posterior para Amplify.
  • SEO tratado como problema de engenharia: arquitetura de informação, dados estruturados, links internos e estrutura programática de páginas.
  • Um programa de palavras-chave que reduziu mais de quarenta mil termos a 40 alvos principais e 400 complementares.
  • Um motor de conteúdo produzindo cerca de 30 artigos densos por mês, na faixa de 2.000 a 5.000 palavras.

Decisões e trade-offs

01

Construir a plataforma antes de escalar o conteúdo

O custo da escolha: Um primeiro mês mais lento, compensado todo mês depois, porque publicar deixou de esperar pela engenharia.

02

Escolher um page builder em vez de templates por página

O custo da escolha: Mais trabalho nos contratos de bloco no início, o que barateou cada tipo de página nova.

03

Priorizar 40 termos principais e 400 complementares em vez do conjunto completo

O custo da escolha: Deixar deliberadamente uma cauda longa de fora e concentrar o conteúdo nos termos que podiam mover.

04

Medir orgânico não-marca em vez do orgânico total

O custo da escolha: Um número mais difícil e menos lisonjeiro, e o que mostra se o trabalho causou algo.

Resultado

O orgânico não-marca saiu de 50 a 200 visitas por mês para 10.000 por mês em seis meses, e para mais de 20.000 por mês em nove meses. A plataforma foi ao ar com PageSpeed entre 82 e 92, e essa performance é parte da razão de o conteúdo ter ranqueado. Scripts de marketing adicionados depois do lançamento derrubaram a nota; carregá-los corretamente é a vitória mais rápida disponível no site.

50 a 200 visitas orgânicas não-marca por mês antes do trabalho
10 mil/mês orgânico não-marca aos seis meses
20 mil+/mês orgânico não-marca aos nove meses
82 a 92 PageSpeed no lançamento, antes de scripts de terceiros

Stack

  • PayloadCMS 3, Next.js 15, React 19 e TypeScript.
  • MongoDB na AWS, com S3, CloudFront e Amplify para entrega, e Mux para vídeo.
  • GA4 e Google Tag Manager para medição, além de ferramenta de palavras-chave de terceiros.

Próximos passos

  • Carregar os scripts de terceiros adicionados depois para que o PageSpeed volte à faixa do lançamento.
  • Ampliar o page builder para cobrir mais padrões de conteúdo sem blocos específicos.
  • Empacotar a plataforma e o playbook de conteúdo como um trabalho de cliente reutilizável.
Voltar para todos os projetos