Conteúdo automatizado em WordPress significa ligar dados estruturados, sistemas editoriais e redação assistida por IA, para que as pessoas gastem o seu tempo a decidir, e não a copiar, formatar e agendar. O princípio que separa uma configuração útil de uma fábrica de conteúdo é curto: automatize o processo, não a decisão sobre a qualidade.
Este guia explica o que a Google diz de facto sobre conteúdo gerado por IA e conteúdo automatizado, que interfaces do WordPress tratam da publicação (a REST API, o WP-CLI e o AI Client que chegou com o WordPress 7.0) e que controlos mantêm os rascunhos gerados fora do índice até que uma pessoa os verifique.
Se quiser primeiro a versão prática: automatize as partes repetitivas do fluxo de trabalho (briefs, rascunhos, modelos, enriquecimento, agendamento) e deixe a decisão final de publicar com um editor. Publicar sem controlo editorial é precisamente a parte que não escala.
Leia mais sobre SEO e conteúdo otimizado na WPPoland.
O que diz a Google sobre conteúdo gerado por IA
A posição da Google mantém-se estável desde a publicação no blogue do Search Central de 8 de fevereiro de 2023. As perguntas frequentes dessa publicação respondem diretamente à primeira dúvida:
“O uso adequado de IA ou de automação não viola as nossas diretrizes.”
Google Search Central, Google Search’s guidance about AI-generated content (tradução própria)
A mesma publicação define o que torna esse uso inadequado. Usar automação, incluindo IA, para gerar conteúdo “com o objetivo principal de manipular a classificação nos resultados de pesquisa constitui uma violação das nossas políticas de spam”. Responde também à pergunta que a maioria dos projetos de automação gostaria, em silêncio, de ver respondida ao contrário: “Usar IA não dá ao conteúdo qualquer vantagem especial. É apenas conteúdo.” Uma página gerada é avaliada como qualquer outra página: pela utilidade, pela originalidade e pelas qualidades que a Google agrupa sob E-E-A-T.
A página de documentação da Google sobre o uso de conteúdo de IA generativa, atualizada pela última vez a 1 de outubro de 2026, acrescenta a parte operacional. A IA generativa é descrita como útil “ao pesquisar um tema e para dar estrutura a conteúdo original”. Segue-se o aviso que conta para qualquer pipeline:
“É fundamental verificar manualmente os factos e rever todo o conteúdo gerado por IA quanto à exatidão e à fiabilidade antes de o publicar.”
Google Search Central, Google Search’s guidance on using generative AI content on your website (tradução própria)
A razão apresentada é técnica: os modelos generativos não vão buscar factos, preveem uma sequência provável de palavras, por isso o que produzem pode conter alucinações. Nada disto garante que o conteúdo de IA fique bem classificado ou que seja seguro. Diz apenas que o método de produção não é o critério. O critério é o valor para o leitor.
O que conta como abuso de conteúdo em escala
A política de spam com que os sites WordPress automatizados se cruzam é a do abuso de conteúdo em escala (scaled content abuse). A página das políticas de spam da Google (atualizada pela última vez a 28 de agosto de 2026) define-a assim:
“Abuso de conteúdo em escala é quando muitas páginas são geradas com o objetivo principal de manipular as classificações de pesquisa e não de ajudar os utilizadores.”
Google Search Central, Spam policies for Google web search (tradução própria)
A política acrescenta que este conteúdo é tipicamente pouco original e oferece pouco ou nenhum valor aos utilizadores, “independentemente da forma como é criado”. Os exemplos parecem uma lista dos atalhos que as ferramentas de automação tornam fáceis:
- usar IA generativa ou ferramentas semelhantes para gerar muitas páginas sem acrescentar valor para os utilizadores,
- recolher feeds, resultados de pesquisa ou outro conteúdo para gerar muitas páginas, incluindo através de transformações automáticas como sinónimos, tradução ou outra ofuscação,
- coser ou combinar conteúdo de diferentes páginas web sem acrescentar valor,
- criar vários sites para esconder a natureza massificada do conteúdo,
- criar muitas páginas que fazem pouco ou nenhum sentido para um leitor, mas contêm palavras-chave de pesquisa.
Há duas consequências relevantes para projetos WordPress. A tradução automática usada apenas para multiplicar páginas é referida de forma explícita, por isso um pipeline multilingue precisa da mesma revisão que um pipeline numa só língua. E a política termina com uma instrução: se alojar este tipo de conteúdo no seu site, exclua-o da Pesquisa. Na prática, isto significa um noindex nas páginas geradas que ainda não passaram pela revisão, e não a esperança de que ninguém repare.
A página da Google “Criar conteúdo útil, fiável e focado nas pessoas” enumera os sinais de alerta correspondentes, entre eles “usar automação extensiva para produzir conteúdo sobre muitos temas” e produzir muito conteúdo sobre muitos temas diferentes na esperança de que parte dele fique bem classificado.
Níveis de automação de conteúdo em WordPress
Nem toda a automação de conteúdo é igual. Vai da assistência mínima à publicação totalmente automática, e cada degrau traz um nível de risco diferente.
Nível 1: assistência de IA (risco baixo)
A IA ajuda em partes específicas de um fluxo de trabalho humano:
- Pesquisa de temas: a IA agrupa consultas de pesquisa, encontra lacunas face aos artigos existentes e sugere ângulos.
- Geração de briefs: a IA transforma dados de SEO e notas editoriais num brief estruturado.
- Verificações depois da escrita: a IA sugere melhorias de legibilidade, estrutura e cobertura temática num rascunho escrito por uma pessoa.
Quem escreve continua a ser o autor. É o uso que a Google descreve como pesquisar um tema e dar-lhe estrutura.
Nível 2: rascunhos assistidos por IA (risco médio)
A IA produz rascunhos que as pessoas reveem e enriquecem:
- Primeiro rascunho completo: a IA escreve um rascunho a partir de um brief detalhado.
- Revisão editorial: um editor verifica a exatidão, acrescenta experiência própria e ajusta o tom da marca.
- Enriquecimento: a equipa acrescenta os seus próprios dados, capturas de ecrã e exemplos reais que o modelo não consegue fornecer.
O tempo poupado depende da profundidade da revisão. Um rascunho em que é preciso voltar a verificar cada afirmação poupa menos do que parece.
Nível 3: conteúdo programático (risco alto)
Páginas geradas em escala a partir de dados e modelos:
- Páginas por localidade: “[Serviço] em [Cidade]” para muitas cidades.
- Páginas de comparação: “[Produto A] vs [Produto B]” construídas a partir de uma base de dados de produtos.
- Páginas de perguntas frequentes: construídas a partir de pedidos de suporte e dados de pesquisa.
É neste nível que a política de abuso de conteúdo em escala se aplica mais diretamente. Só funciona quando cada página traz dados que o leitor não obtém apenas a partir do modelo.
Nível 4: publicação totalmente automática (risco muito alto)
A IA gera, revê e publica sem nenhuma pessoa no circuito. Os riscos são concretos:
- informação factualmente errada publicada sem verificação,
- texto genérico que não acrescenta nada de novo,
- páginas pobres ou quase duplicadas que caem na política de spam,
- danos à marca quando uma afirmação errada sai em seu nome.
Desaconselhamo-la em quase todos os casos. Só é viável para atualizações de dados de risco muito baixo, como um nível de stock ou um horário de funcionamento lidos de um sistema de referência.
Como os fluxos de IA multiagente dividem o trabalho
Algumas equipas já não enviam um único prompt a um único modelo. Dividem o trabalho em papéis, cada um com um prompt ou agente próprio e instruções próprias:
- Investigador: reúne fontes para o brief, como documentação, notas de lançamento e os dados da própria equipa.
- Estruturador: constrói um esquema a partir do brief, da intenção de pesquisa e das diretrizes de tom da marca.
- Redator: escreve o rascunho e inclui os dados técnicos específicos indicados no brief.
- Editor: verifica o tom, assinala cada afirmação sem fonte e compara o rascunho com as orientações de E-E-A-T.
Dividir o trabalho torna cada passo mais fácil de testar, mas não torna os factos mais fiáveis. Um agente “editor” continua a ser um modelo de linguagem. A verificação de factos que a Google considera fundamental tem de ser feita por uma pessoa, contra a fonte, e o pipeline deve entregar a essa pessoa uma lista de afirmações e fontes em vez de um artigo acabado.
Como criar rascunhos no WordPress através da REST API
A REST API do WordPress é o ponto de entrada habitual para um pipeline externo. Um novo artigo é criado com POST /wp/v2/posts. Segundo a referência de Posts, o argumento status aceita publish, future, draft, pending e private, e date é a data de publicação no fuso horário do site (com date_gmt como variante em GMT). O mesmo endpoint aceita title, content, excerpt, categories, tags, author e meta.
No conteúdo automatizado, o estado é o ponto de controlo. Um pipeline que escreve pending coloca cada rascunho na fila Pending review (revisão pendente) que os editores já conhecem, e um pipeline que nunca escreve publish não consegue publicar por engano.
A autenticação de scripts passa normalmente pelas Application Passwords, adicionadas ao núcleo no WordPress 5.6. O guia de integração em make.wordpress.org explica que as credenciais são enviadas com autenticação HTTP Basic sobre HTTPS, que a funcionalidade só está disponível por omissão em sites servidos por HTTPS e que os utilizadores geram e revogam estas palavras-passe no ecrã de edição do utilizador. Crie para o pipeline um utilizador dedicado com o papel de Colaborador (Contributor), para que a conta não consiga publicar mesmo que o script o peça.
curl -X POST https://example.com/wp-json/wp/v2/posts \
-u "content-pipeline:$APPLICATION_PASSWORD" \
-H "Content-Type: application/json" \
-d '{"title":"Rascunho do pipeline","content":"<p>Body</p>","status":"pending"}'Uma conta de Colaborador pode submeter para revisão, mas não pode publicar, o que corresponde ao fluxo descrito acima. Revogue a palavra-passe de aplicação quando o pipeline for desativado.
Como criar artigos no WordPress com o WP-CLI
Quando o pipeline corre no próprio servidor, o WP-CLI é mais simples do que o HTTP. A referência de wp post create lista as opções que interessam para a automação:
--post_statususadraftpor omissão, por isso uma flag esquecida falha do lado seguro.- Um caminho de ficheiro como primeiro argumento lê o conteúdo desse ficheiro, e
-lê-o da entrada padrão, o que serve um gerador que escreve para stdout. --meta_inputaceita um objeto JSON com chaves e valores de meta, útil para registar como o rascunho foi produzido.--porcelainimprime apenas o ID do novo artigo, para que o passo seguinte do script o possa usar.--post_status=futurecom--post_dateagenda um artigo.
POST_ID=$(wp post create ./draft.html \
--post_title='Rascunho do pipeline' \
--post_status=pending \
--meta_input='{"_generated_by":"pipeline","_review_status":"pending"}' \
--porcelain)
echo "Rascunho criado $POST_ID"A referência nota ainda que --tax_input ignora a verificação de permissões do utilizador que o núcleo normalmente aplica. Um script WP-CLI corre com mais poderes do que um cliente REST, por isso mantenha-o fora do alcance de tudo o que aceite dados vindos de fora.
Como o AI Client do WordPress 7.0 gera texto
O WordPress 7.0 “Armstrong”, lançado a 20 de maio de 2026, acrescentou um AI Client ao núcleo. A nota de desenvolvimento Introducing the AI Client in WordPress 7.0 descreve como funciona:
- O ponto de entrada é
wp_ai_client_prompt(), que devolve umWP_AI_Client_Prompt_Builder. - Os métodos de configuração incluem
using_system_instruction(),using_temperature(),using_max_tokens()eusing_model_preference(). Uma preferência de modelo é uma lista de prioridades, não um requisito: é usado o primeiro modelo disponível. as_json_response( $schema )pede uma resposta em JSON estruturado, que serve melhor briefs e metadados do que texto livre.generate_text()e os restantes métodosgenerate_*()devolvem umWP_Errorem caso de falha, por isso aplica-se a habitual verificação comis_wp_error().- O núcleo não inclui nenhum fornecedor. Os administradores ligam um no ecrã de definições
Connectors, usando plugins de fornecedor como os oficiais para Anthropic, Google e OpenAI. O código dos plugins nunca lida com chaves de API. is_supported_for_text_generation()e os métodos irmãos verificam a disponibilidade sem fazer nenhuma chamada à API.
$builder = wp_ai_client_prompt( $brief )
->using_system_instruction( 'Escreve um primeiro rascunho. Marca com [SOURCE] cada afirmação que precise de fonte.' )
->using_temperature( 0.4 );
if ( ! $builder->is_supported_for_text_generation() ) {
return;
}
$text = $builder->generate_text();
if ( is_wp_error( $text ) ) {
return $text;
}
wp_insert_post( [
'post_title' => $title,
'post_content' => wp_kses_post( $text ),
'post_status' => 'pending',
], true );A nota documenta também o filtro wp_ai_client_prevent_prompt. Quando devolve true, não é feita nenhuma chamada, as verificações is_supported_*() devolvem false e generate_*() devolve um WP_Error. Isto dá ao dono do site um único interruptor para parar a geração, por exemplo fora de um papel aprovado ou durante uma auditoria. Para funcionalidades expostas no painel de administração, a nota recomenda um endpoint REST dedicado no servidor para cada funcionalidade, com as suas próprias verificações de permissões.
O AI Client facilita a geração dentro do WordPress. Não altera nada nas orientações da Google descritas acima: o que produz continua a precisar de revisão antes de ir para o ar.
Verificações automáticas de qualidade para rascunhos de IA
Antes de um editor abrir um rascunho, verificações automáticas baratas podem apanhar as falhas óbvias. Este exemplo regista os resultados em post meta, para que o editor os veja na lista de artigos pendentes:
// Verificações automáticas de qualidade para rascunhos gerados
function automated_quality_checks( $post_id ) {
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}
if ( ! get_post_meta( $post_id, '_generated_by', true ) ) {
return;
}
$content = get_post_field( 'post_content', $post_id );
$issues = [];
// Comprimento mínimo
$word_count = str_word_count( wp_strip_all_tags( $content ) );
if ( $word_count < 800 ) {
$issues[] = "Demasiado curto: {$word_count} palavras (mínimo 800)";
}
// Links internos
$internal_links = preg_match_all( '/href=["\']\/pt-pt\//', $content );
if ( $internal_links < 2 ) {
$issues[] = "Poucos links internos: {$internal_links} (mínimo 2)";
}
// Subtítulos
$headings = preg_match_all( '/<h[2-3]/', $content );
if ( $headings < 3 ) {
$issues[] = "Poucos subtítulos: {$headings} (mínimo 3)";
}
// Marcadores de fonte por resolver deixados pelo modelo
if ( false !== strpos( $content, '[SOURCE]' ) ) {
$issues[] = 'Afirmações ainda marcadas com [SOURCE] sem citação';
}
// Verificação básica de duplicados
$first_paragraph = wp_strip_all_tags( substr( $content, 0, 500 ) );
$similar_posts = new WP_Query( [
's' => $first_paragraph,
'posts_per_page' => 1,
'post__not_in' => [ $post_id ],
] );
if ( $similar_posts->have_posts() ) {
$issues[] = 'Possível conteúdo duplicado';
}
update_post_meta( $post_id, '_quality_issues', $issues );
update_post_meta( $post_id, '_quality_score', empty( $issues ) ? 'pass' : 'needs_review' );
}
add_action( 'save_post', 'automated_quality_checks' );Os limiares são exemplos para as suas próprias regras editoriais, não números da Google. Passar na verificação significa apenas que o rascunho merece o tempo de uma pessoa. Não diz nada sobre se os factos estão certos.
SEO programático em WordPress em escala
O SEO programático é a forma mais ambiciosa de automação: centenas ou milhares de páginas construídas a partir de dados estruturados e modelos. O WordPress trata bem do armazenamento. Os tipos de conteúdo personalizados e os campos personalizados (por exemplo com ACF) guardam o modelo de dados, e a REST API ou o WP-CLI importam entradas de uma base de dados externa.
A questão não é se o WordPress consegue guardar as páginas, mas se cada página merece existir. Os exemplos de abuso de conteúdo em escala descrevem exatamente o que corre mal: um modelo em que só muda o nome da cidade não acrescenta valor para o leitor.
Exemplos típicos que podem funcionar:
- Páginas de serviço por localidade: para uma empresa que oferece manutenção de WordPress em várias cidades, cada página precisa de dados verdadeiros para essa cidade: projetos reais, testemunhos reais, o contacto local, condições locais que alteram o serviço.
- Páginas de integração: para um produto SaaS, as páginas “WordPress + [Ferramenta]” precisam dos passos reais de configuração, dos limites dessa integração e de perguntas de suporte vindas de utilizadores dessa ferramenta.
Regras que aplicamos antes de gerar um conjunto destes:
- Cada página precisa de dados únicos. Se não consegue dizer o que é diferente na página 214 em relação à página 213, não publique a página 214.
- Verifique a intenção de pesquisa por variante. Confirme que as pessoas procuram a variante antes de a construir.
- Mantenha as páginas não revistas fora do índice. Use
noindexaté a página passar a revisão, que é também o que a política de spam pede. - Acompanhe a indexação. O Search Console mostra que páginas geradas a Google indexa e quais ignora.
- Consolide as páginas pobres. Uma página sem tráfego e sem dados únicos é fundida numa página mais forte ou removida.
Como atualizar artigos do WordPress com dados de API em direto
Algum conteúdo só está correto quando acompanha um sistema de referência. É aqui que a automação mais ajuda, porque o trabalho é sincronizar e não escrever:
- Preços e disponibilidade: uma página de produto ou de plano lê o preço e o stock da loja ou do sistema de faturação, em vez de uma cópia no corpo do artigo.
- Dados de referência que mudam: um artigo sobre segurança pode mostrar a lista de alertas recentes a partir de um feed que uma tarefa agendada atualiza.
- Webhooks: um evento externo (uma atualização de produto, uma nova versão) aciona a atualização dos artigos afetados através da REST API.
- WordPress headless: o WordPress serve o conteúdo através da sua API a vários frontends, por isso uma única atualização chega a todos os canais.
Mantenha as partes geradas em blocos ou campos que o modelo renderiza, e não no texto editorial. Assim, um feed que falhe mostra um valor antigo num só sítio, em vez de estragar o artigo.
Como divulgar o uso de IA e rever os metadados
As orientações da Google indicam duas tarefas que os pipelines costumam saltar.
A primeira são os metadados. A exigência de verificação de factos “aplica-se também a metadados como elementos <title>, elementos de meta description, dados estruturados e textos alternativos de imagens”, porque estes aparecem diretamente nos resultados de pesquisa. Uma meta description gerada com uma afirmação errada é tão visível como uma frase errada no corpo do texto. Para os dados estruturados, a Google pede também que siga as diretrizes gerais e as políticas específicas de cada funcionalidade e que valide a marcação.
A segunda é o contexto. A Google sugere que os editores que geram conteúdo de forma automática ponderem “acrescentar informação sobre a forma como o conteúdo foi criado”, por exemplo um enquadramento sobre como a automação foi usada e metadados de imagem. A página sobre conteúdo útil apresenta isto como a pergunta “Como”: se o uso de automação é evidente para os visitantes, através de divulgações ou de outras formas. As perguntas frequentes de 2023 acrescentam que estas divulgações são úteis quando alguém se pode perguntar “Como foi isto criado?”, e que indicar a IA como autora provavelmente não é a melhor forma de o fazer.
Para lojas, o Google Merchant Center tem regras próprias: as imagens geradas por IA têm de levar o valor IPTC DigitalSourceType TrainedAlgorithmicMedia, e os títulos e descrições de produto gerados por IA têm de ser indicados em separado e assinalados como gerados por IA.
Em termos de WordPress, guarde os detalhes da geração em post meta (os campos --meta_input e meta referidos acima), mostre uma nota curta sobre como o artigo foi produzido onde os leitores a esperariam e reserve a assinatura para a pessoa que o reviu e responde por ele.
Ferramentas para automatizar conteúdo em WordPress
Ferramentas de IA para rascunhos
- AI Client do WordPress 7.0: geração dentro do WordPress através de um fornecedor ligado.
- APIs de fornecedores (Anthropic, OpenAI, Google): rascunhos em escala a partir de um pipeline externo.
- DeepL API: tradução automática, que continua a precisar de revisão, porque a política de spam refere a tradução usada para multiplicar páginas.
Ferramentas de publicação
- WP-CLI: cria artigos a partir da linha de comandos ou de uma tarefa cron no servidor.
- REST API do WordPress: liga pipelines externos através de Application Passwords.
- n8n, Make, Zapier: orquestram fluxos de trabalho sem código personalizado.
Ferramentas de monitorização
- Google Search Console: indexação e desempenho das páginas geradas.
- Query Monitor: problemas de base de dados e de desempenho quando o número de artigos cresce.
- Relatórios próprios: alertas de qualidade a partir de post meta, tempos de revisão e motivos de rejeição.
Riscos do conteúdo gerado por IA e como reduzi-los
Conteúdo pobre. Defina mínimos editoriais (dados únicos, fontes, links internos), mantenha as páginas não revistas em noindex e audite regularmente os conjuntos gerados.
Desinformação. Torne obrigatória a verificação humana de factos no conteúdo factual e peça ao modelo que marque as afirmações que precisam de fonte, para que o editor verifique uma lista em vez de reler tudo.
Ações manuais por spam. Siga a política de abuso de conteúdo em escala e as orientações sobre conteúdo útil. O volume não é um objetivo.
Incoerência da marca. Escreva um guia de estilo que a instrução de sistema possa citar e verifique a terminologia de forma automática.
Dependência de um único fornecedor. As preferências de modelo do AI Client e o ecrã Connectors facilitam a troca de fornecedor. Mantenha os prompts e as verificações no seu próprio código, para que acompanhem a mudança.
Perda de competência editorial. Mantenha pessoas que saibam escrever e editar. A IA multiplica o trabalho de uma equipa; não substitui o juízo que a Google pede.
O que medir no conteúdo automatizado
A tabela mostra o que acompanhamos e onde ler cada valor. As metas pertencem a cada projeto e saem da sua própria linha de base, por isso não as indicamos aqui.
| Métrica | Porque importa | Onde ler |
|---|---|---|
| Rascunhos produzidos por mês | Mostra se a automação acrescenta capacidade | Contagem de artigos no WordPress pela meta _generated_by |
| Taxa de aprovação à primeira | Mostra quanto retrabalho os rascunhos exigem | Estado de revisão em post meta |
| Motivos de rejeição mais comuns | Mostra o que corrigir nos prompts e nas verificações | Notas do editor, _quality_issues |
| Parte indexada das páginas geradas | Mostra se a Google vê valor no conjunto | Relatório de indexação de páginas do Search Console |
| Cliques e impressões por página gerada | Separa as páginas com procura das páginas sem procura | Relatório de desempenho do Search Console |
| Correções depois da publicação | Mede o custo dos erros que passaram a revisão | Histórico de revisões |
Por onde começar a automação de conteúdo em WordPress
A automação de conteúdo em WordPress funciona quando é conduzida com disciplina. Automatize a pesquisa, os rascunhos, os modelos, o enriquecimento e o agendamento. Deixe os factos, a decisão de publicar e a responsabilidade pela página com pessoas. As orientações da Google traçam a linha com clareza: a automação é permitida, páginas em massa sem valor caem na política de abuso de conteúdo em escala e o conteúdo de IA não recebe tratamento especial, nem num sentido nem no outro.
Um primeiro passo prático é listar os seus tipos de página, as fontes de dados por trás de cada um e as regras de aprovação humana, e depois ligar apenas um fluxo delimitado, como briefs ou meta descriptions, com pending como único estado que o pipeline pode escrever.
Se precisar de ajuda com fluxos de conteúdo automatizado em WordPress, contacte a WPPoland. Trabalhamos também em desenvolvimento WordPress e SEO programático.







