Automatizar blog n8n parece complicado até você dividir o problema em cinco blocos: entrada de pauta, deduplicação, reescrita com IA, imagem de capa e publicação. É a arquitetura que mantenho rodando há mais de dois anos e que me permite cuidar de três blogs sozinho. Neste guia, mostro cada bloco com os nodes envolvidos, as decisões que tomo em cada etapa e o que vigiar quando a coisa vai para produção.
O fluxo descrito aqui roda na linha estável mais recente, a n8n 2.43.7, lançada em 2026-10-16 conforme a página de releases. Os requisitos são enxutos: uma instância do n8n, acesso a um modelo de IA (por API ou local) e um blog para receber os posts. Se o seu n8n estiver muito atrás, vale atualizar antes de montar o pipeline, porque alguns recursos citados dependem de versões recentes.
A arquitetura em 5 blocos para automatizar blog n8n de ponta a ponta
O pipeline funciona como uma linha de produção. O RSS Feed Trigger vigia as fontes de pauta, um controle de deduplicação garante que nada seja processado duas vezes, a IA reescreve o material na voz do blog, a capa é gerada em seguida e o post sai no WordPress, com auditoria antes de ir ao ar. Na tabela a seguir, o papel de cada bloco e as opções principais:
| Bloco | O que faz | Opções principais |
|---|---|---|
| Entrada de pauta | Monitora as fontes e dispara o workflow | RSS Feed Trigger |
| Deduplicação | Impede o processamento repetido de itens | Remove Duplicates, Data table, Redis |
| Reescrita | Transforma a pauta em texto na voz do blog | Modelo via API ou modelo local |
| Imagem de capa | Gera a arte do post | API de imagem ou modelo local |
| Publicação | Envia ao blog e controla a qualidade | Integração com WordPress, auditoria |
Entrada de pauta: RSS Feed Trigger monitorando as fontes
O RSS Feed Trigger é um trigger de polling: o n8n checa o feed periodicamente e inicia o workflow quando detecta itens novos, conforme a documentação oficial do node. O node de leitura de RSS (RSS Read) trabalha com um único parâmetro de URL e tem a opção Ignore SSL Issues, útil para fontes com certificado problemático. O Feed Trigger é justamente a variante que dispara o fluxo sozinha, então é ele que abre o pipeline.
Duas práticas evitam dor de cabeça: configure o intervalo de polling de acordo com a frequência de publicação de cada fonte e não exagere na quantidade de feeds por trigger. Para fontes sem RSS, a linha 2.43 do n8n, que chegou em 2026-10-06, liberou o node Browser Use para todos os usuários, abrindo caminho para monitorar páginas por navegação.
Deduplicação: Remove Duplicates nativo vs Redis com SET NX e TTL
Trigger de polling e conteúdo sindicado geram sobreposição: o mesmo item volta no feed várias vezes. Sem deduplicação confiável, você publica o post repetido, e o leitor percebe isso rápido.
O caminho nativo é o node Remove Duplicates com a operação Remove Items Processed in Previous Executions, que compara os itens novos contra os vistos em execuções anteriores. A documentação do node recomenda encadear dois Remove Duplicates: um para duplicatas no input atual e outro para o histórico de execuções anteriores. O node também tem a operação Clear Deduplication History, que limpa o histórico sem afetar os itens do input atual, algo útil na manutenção.
Para não processar nada antigo, o método getWorkflowStaticData salva o timestamp do último item processado do feed entre execuções do workflow. Cada item novo é comparado contra essa marca, e o que já passou é descartado.
Uma terceira opção é o Data table node, disponível a partir do n8n 2.17.0, que armazena dados entre execuções e pode servir como histórico de posts publicados, funcionando como alternativa ao Redis dentro do próprio n8n.
O Redis entra quando a operação cresce: múltiplos workflows, múltiplas instâncias ou volume alto de itens. O padrão SET NX grava a chave só se ela ainda não existir, o que resolve a corrida entre execuções, e o TTL define a expiração para o histórico não crescer para sempre. Como chave, o link do artigo é o mais seguro, e combinar link e título cobre o caso de a fonte alterar o endereço. Para a sintaxe exata dos comandos, confira a documentação oficial do Redis.
Reescrita com IA: escolha do modelo, prompt e voz do blog
O critério número um na escolha, no meu caso, é desempenho em língua portuguesa. Modelo ruim em português entrega artigos com mistura de línguas e erros gramaticais e verbais, e o leitor percebe na primeira linha.
Se você consegue rodar localmente um modelo bom de português, opte pelo local: aconselho o gemma4 ou o qwen a partir da versão 3.5 em diante. Sem hardware para isso, use modelos baratos e bons de português, como Haiku5.5, Gpt-Luna e gemini2.5-flash-lite, sempre pesando o custo-benefício. Vale ainda explorar o catálogo de chat models do n8n: o MiniMax, por exemplo, foi adicionado no n8n 2.18 (2026-04-21) como sub-node compatível com API OpenAI, com a opção Hide Thinking para respostas limpas.
No prompt, três regras seguram a qualidade: definir a voz do blog em poucas frases, exigir estrutura fixa de texto e proibir o modelo de inventar informação que não está no material de origem. Guarde o prompt em um ponto único do workflow, porque você vai ajustá-lo muitas vezes nos primeiros meses. Registre também a fonte original junto do post gerado, já que rastrear a origem é metade do trabalho quando a auditoria acusa um erro.
Imagem de capa: geração via API ou modelo local no seu servidor
A capa entra depois da reescrita e antes da publicação, com duas rotas possíveis. A API externa entrega qualidade estável e não consome sua máquina, mas cada imagem tem custo e você fica sujeito aos limites e à disponibilidade do serviço. O modelo local no seu servidor zera o custo por imagem e mantém tudo em casa, com a contrapartida de exigir hardware e tempo de geração.
Para consistência visual, use um padrão de prompt por blog, com estilo, paleta e formato fixos, em vez de prompt solto a cada post. Os detalhes da chamada da API e do envio do arquivo dependem do serviço escolhido, então confira na documentação oficial em docs.n8n.io como montar a requisição e o upload no seu caso.
Publicação no WordPress e controle de qualidade antes de ir ao ar
Do lado do blog, o n8n conta com integração com WordPress para criar os posts. A prática que recomendo é o workflow publicar como rascunho, nunca direto no ar, deixando a etapa de auditoria decidir o que sobe. Os detalhes de configuração do node, incluindo autenticação, estão na documentação oficial em docs.n8n.io.
O controle de qualidade tem duas camadas. A automática roda dentro do workflow e pega os erros mais simples, com checagens que você define. A humana é o editor revisando o texto antes de liberar, e é aí que a arquitetura precisa facilitar a sua vida, não atrapalhar.
Na prática: como rodo isso aqui
Hoje rodo automações de blogs há mais de dois anos, são três blogs no total, com modelos locais que ajudam nas automações e diminuem os custos: uso o gemma4 12B e o qwen3.5 9B na reescrita e em outras tarefas do fluxo. Meu n8n está atualizado e funcionando bem. Na migração do 1.x para o 2.x eu já tinha estudado as mudanças antes, e por isso não tive problemas com nenhum workflow.
Na deduplicação, uso o Redis salvando link e título para evitar a repetição de artigos, com outros meios ajudando como rede de segurança. E a auditoria é o diferencial que me permite operar sozinho: além da checagem automática dos erros mais simples, recebo no WhatsApp o texto com o erro ou os erros apontados, de onde estiver e a qualquer hora. Respondo corrige 1 quando é uma correção só, ou corrige 1 2 quando são duas, e o agente de correção já manda o ajuste para o blog ou blogs que precisarem.
O resultado é que uma pessoa só dá conta de três blogs e ainda sobra espaço para meus serviços extras. A arquitetura não elimina o humano do processo: ela reposiciona o humano na parte que importa, que é decidir e corrigir.
Custos, limites e o que monitorar em produção
O custo por post é a conta que decide a viabilidade do projeto. Modelo local concentra o gasto em hardware e energia; modelo via API cobra por chamada, e volume alto de posts amplifica qualquer diferença de preço. Faça a conta com o número real de posts por mês antes de fechar a escolha do modelo.
Em produção, fique na linha estável: a n8n 2.43.7 é a versão estável mais recente, lançada em 2026-10-16, enquanto a build 2.44.3 segue como pre-release beta no mesmo dia. O changelog oficial avisa que sai um novo minor quase toda semana e recomenda a linha stable para produção, então atualize com planejamento, não no impulso.
Monitore três pontos com atenção: execuções com falha no trigger e na publicação, crescimento do histórico de deduplicação (lembre da operação Clear Deduplication History) e limites de requisição da API do modelo de reescrita. Um blog que falha em silêncio publica menos, e o pior cenário é descobrir isso dias depois, pelo leitor. Com esses cuidados no lugar, o pipeline roda sozinho e você cuida só das decisões.
Perguntas frequentes
Qual versão do n8n devo usar nesse pipeline?
A estável, hoje a n8n 2.43.7, lançada em 2026-10-16. A build 2.44.3 é pre-release beta, e o changelog oficial recomenda a linha stable para produção.
Preciso de Redis para não duplicar posts?
Não necessariamente. O Remove Duplicates, na operação Remove Items Processed in Previous Executions, cobre a maior parte dos casos, e a própria documentação sugere encadear dois nodes. O Redis entra quando há múltiplas instâncias ou volume grande de itens.
Como guardar o último item processado do feed sem banco externo?
Com o método getWorkflowStaticData, que salva o timestamp do último item processado entre execuções do workflow. O Data table node, a partir do n8n 2.17.0, é outra alternativa interna para manter histórico.
