Como adicionar um blog ao seu app SaaS (sem construir um CMS)

Toda empresa de SaaS uma hora precisa de um blog: para anúncios do produto, guias e a cauda longa de tráfego de busca que se acumula ao longo dos anos. O erro da maioria das equipes de engenharia é tratar “adicionar um blog” ou como uma instalação de WordPress num fim de semana, ou como um projeto de CMS interno que ocupa um trimestre. Existe um terceiro caminho, que coloca um blog de produção no seu próprio domínio em uma tarde.

Decida onde o blog vai ficar: subdomínio ou subdiretório

Antes de escrever qualquer código, defina a URL. Você tem três opções:

• blog.yourapp.com — um subdomínio, geralmente apontando para uma plataforma hospedada à parte.

• yourapp.com/blog — um subdiretório do seu site principal, renderizado pelo seu próprio frontend.

• Um domínio de terceiros — publicar no Medium ou em algo parecido.

O subdiretório é a opção mais forte para SEO: cada artigo constrói autoridade para o domínio onde o seu produto está, os links internos circulam naturalmente entre as páginas de marketing e os posts, e o analytics fica em uma única propriedade. Um subdomínio funciona; um domínio de terceiros significa que a autoridade vai inteira para outra empresa.

Escolher o subdiretório traz uma restrição de arquitetura: a sua própria aplicação precisa renderizar os posts. Isso descarta as plataformas acopladas, que insistem em servir as páginas elas mesmas, e aponta para uma configuração API-first: conteúdo escrito em um painel, buscado como JSON e renderizado pelo seu frontend.

A arquitetura de três camadas

Um blog de SaaS precisa de exatamente três camadas, e só uma delas é código seu:

1. Autoria — um painel onde os posts são escritos: editor de texto rico, tags, categorias, rascunhos, metadados de SEO (título, descrição, imagem Open Graph) e publicação agendada.

2. Entrega — uma API que serve os posts publicados como JSON, com paginação, filtro por tag e busca.

3. Renderização — duas rotas no seu app: uma página de lista e uma página de post.

É ao construir as camadas 1 e 2 por conta própria que os projetos internos de blog morrem: só o editor leva semanas, e depois vêm o upload de imagens, os rascunhos, as permissões e os slugs. Um backend de conteúdo entrega essas duas camadas como serviço, e o seu projeto inteiro passa a ser a camada 3.

Renderização: duas rotas e uma requisição

Com um SDK tipado, a camada de renderização é pequena. A página de lista busca uma página de posts:

const { data: posts } = await kookee.blog.list({ page: 1, limit: 10 });

A página do post busca pelo slug:

const post = await kookee.blog.getBySlug(params.slug);

Renderize o corpo com os seus próprios componentes e o design system que você já tem. No React dá para gastar ainda menos esforço: hooks como useBlogPosts e useBlogPost cuidam dos estados de carregamento e da paginação, e um componente de conteúdo renderiza o HTML do corpo do post para você. Ou pule a marcação de vez: componentes renderizados no servidor desenham a lista de posts, o filtro de tags, a paginação e a página do post a partir dos dados que você busca; veja Crie um blog com os componentes React.

Duas regras mantêm a qualidade alta:

• Renderize no servidor. Use SSR ou geração estática para que crawlers e leitores recebam HTML pronto. A renderização só no cliente funciona, mas você abre mão do SEO que motivou a escolha do subdiretório.

• Devolva 404 de verdade. Quando um slug não existe, responda com status 404, e não com uma página estilizada de “não encontrado” e status 200. Esses soft 404 poluem o índice.

O checklist de metadados

Cada página de post deve emitir, a partir de dados que o CMS já guarda:

• <title> e meta description vindos dos campos de SEO do post.

• Uma URL canônica apontando para o próprio caminho do post.

• Tags Open Graph e Twitter Card, incluindo a imagem do post.

• article:published_time e article:modified_time.

• Dados estruturados JSON-LD do tipo Article.

Como tudo isso sai de uma única resposta da API, cabe em uma única função auxiliar. Adicione um feed RSS e uma entrada no sitemap para cada post; os dois são simples de gerar a partir do mesmo endpoint list que a página do blog já chama.

Tags, busca e os recursos que vêm de graça

Quando os posts são dados estruturados, recursos que seriam projetos inteiros em um sistema caseiro viram parâmetros de consulta:

• Páginas de tag: kookee.blog.list({ tags: ['engineering'] }) por trás de uma rota /blog/tags/:tag.

• Busca: kookee.blog.list({ search: query }) por trás de uma caixa de busca.

• Comentários e reações: servidos pela mesma API, se você quiser engajamento nos posts.

• Traduções: busque as versões de um post em outros idiomas quando expandir para outros países.

Nada disso exige mudanças de schema ou migrações do seu lado: o backend já modela tudo isso.

Quanto isso custa

A conta honesta do caminho API-first:

• Seu código: duas rotas, uma função de metadados, um feed. Um dia de trabalho na maioria dos frameworks, menos se você partir dos templates de página que já tem.

• Custo recorrente: a assinatura de uma plataforma de conteúdo. Com planos gratuitos baseados em uso (o do Kookee inclui 100.000 requisições de API por mês), um blog típico roda no plano gratuito por muito tempo.

• O que você evita: construir e manter um editor, o armazenamento de mídia, um fluxo de publicação e uma segunda aplicação em produção.

Compare com o caminho auto-hospedado: uma construção inicial medida em semanas e, depois, a responsabilidade permanente por patches de segurança e atualizações de dependências de um sistema que não é o seu produto.

Uma ordem concreta de construção

1. Crie um projeto no seu backend de conteúdo e escreva um post de teste.

2. Adicione as rotas /blog e /blog/:slug, que buscam esse post e o renderizam no servidor.

3. Monte a função de metadados: título, descrição, URL canônica, tags OG, JSON-LD.

4. Adicione o filtro por tag e o feed RSS.

5. Apresente o painel à sua equipe e apague “construir um blog” do backlog de engenharia.

O blog em si nunca é a parte difícil. A parte difícil é garantir que o esforço de engenharia vá para o seu produto enquanto o marketing ganha uma publicação rápida, com a cara da marca e no seu domínio, e é exatamente isso que a divisão entre um backend de conteúdo e uma camada fina de renderização traz.