Make reforça o SSL no WordPress: o que revisar nas automações

A integração do Make com WordPress passou a validar rigorosamente certificados SSL. A mudança aparece no changelog de 12 de outubro de 2026. Certificados inválidos ou vencidos causam erro; ambientes internos também ganham suporte a certificado próprio. Veja o anúncio oficial.

O que mudou na conexão Make com WordPress

Segundo o Make, erros de certificado anteriormente ignorados podem interromper a conexão. A nota não detalha uma versão mínima de WordPress. Veja a seção WordPress das atualizações.

SSL é o nome ainda usado no mercado; a proteção atual da conexão HTTPS é feita por TLS. Esse protocolo protege o transporte e permite verificar a identidade do servidor. Ele não certifica a qualidade do conteúdo nem substitui a autenticação da integração. A documentação da Mozilla sobre TLS explica essa separação.

Quem precisa revisar as automações

A prioridade são equipes que usam módulos WordPress do Make em rotinas de conteúdo ou atualização de dados. A documentação do aplicativo lista operações de posts, categorias, mídia e outras entidades, com conexão pela API do WordPress.

Como critério operacional, comece pelo fluxo que tem consequência comercial: um formulário que alimenta outro sistema, uma atualização de catálogo ou a criação de rascunhos para revisão. Faça um inventário com cenário, conexão, domínio e responsável. Assim, um erro pode ser localizado sem mexer em todas as integrações de uma vez.

O anúncio não informa restrição para o Brasil, cobrança adicional ou cronograma regional. Também não detalha formatos e limites do certificado enviado. Esses pontos devem ser conferidos na conta; ausência de restrição publicada não comprova disponibilidade em cada organização.

Como identificar se o problema é realmente SSL

Não classifique qualquer falha como certificado. Registre a mensagem completa, o módulo afetado e o horário da execução. Depois, separe a etapa de transporte da resposta recebida da API:

A tabela é uma triagem, não um diagnóstico definitivo. Em especial, o Make documenta que cache na rota /wp-json/ pode devolver respostas desatualizadas ou impedir a confirmação do ID de um post. Veja o guia de troubleshooting do aplicativo antes de repetir uma criação e produzir duplicatas.

Certificado válido: o que conferir na hospedagem

1. Domínio exato da conexão. Compare o endereço configurado no Make com o nome coberto pelo certificado. A validação de identidade associa o certificado ao domínio, como explica a Mozilla.
2. Prazo de validade. Verifique o certificado servido, não apenas se o painel mostra renovação automática habilitada. Peça à hospedagem a confirmação da renovação quando houver divergência.
3. Cadeia de certificados. O Let’s Encrypt aponta a cadeia incorreta como causa comum de falhas em plataformas modernas e recomenda teste do servidor. Confira a orientação oficial de compatibilidade.
4. Camada que atende o HTTPS. Se houver CDN ou proxy, identifique onde a conexão segura termina e como ela chega ao WordPress. O manual do WordPress sobre HTTPS explica que configurações de proxy também interferem nos redirecionamentos.

Com essas evidências, abra um chamado específico: domínio, erro, horário e teste realizado. Esse registro ajuda a distinguir renovação, cadeia incompleta e configuração de proxy. Evite enviar chaves de API ou senhas no chamado.

E se o WordPress usa certificado autoassinado?

O Make anunciou suporte para enviar um certificado próprio na configuração da conexão. Isso atende ambientes de desenvolvimento ou internos, segundo a nota de atualização. Não há instruções detalhadas de instalação nessa nota.

Autoassinado não significa que outros clientes confiarão no certificado automaticamente. O Let’s Encrypt explica que essa confiança precisa ser estabelecida no ambiente de desenvolvimento. Para um site público, avalie um certificado emitido por uma autoridade reconhecida e a renovação administrada pela hospedagem.

Não envie a chave privada no lugar do certificado público e não desative a verificação TLS para “fazer funcionar”. Uma conexão aceita sem verificar identidade reduz uma proteção que a mudança pretende reforçar. O ajuste deve preservar a comunicação autenticada com o servidor.

Exemplo prático: verificar rascunhos antes de repetir a criação

Imagine um cenário que recebe uma pauta aprovada, cria um rascunho e registra o ID em uma planilha. Se a execução parar no módulo WordPress, guarde o identificador da pauta e verifique se o rascunho já existe antes de repetir. Esse é um exemplo de desenho de fluxo, não um teste feito por Josué.

Após resolver o problema identificado, comece por uma operação de leitura. Depois crie um único rascunho de teste, confira título, status e ID no WordPress e só então retome o processamento normal. Se a chamada retornar conteúdo antigo, investigue o cache da API; se retornar bloqueio de acesso, revise permissões.

O resultado esperado desse procedimento é evidência de cada etapa: conexão aceita, resposta coerente e registro persistido. Uma tela de conexão salva, sozinha, não comprova que o fluxo inteiro voltou a funcionar.

O que fazer agora, conforme seu cenário

Se a integração continua funcionando: registre quais conexões usam WordPress e quem acompanha a renovação dos certificados. Não há motivo para recriar todas as conexões apenas pelo anúncio.

Se apareceu erro de certificado: reúna as evidências de domínio, validade e cadeia antes de alterar o cenário. Se o problema está em desenvolvimento interno: confira o suporte ao certificado próprio e seus requisitos na conta Make.

Para quem gerencia sites de clientes, a implicação prática é incluir a conexão da automação na revisão técnica do site. HTTPS funcionando na página, autenticação da API e persistência de dados são verificações relacionadas, mas cada uma precisa de evidência própria. Veja também os projetos de sites e integrações da Josué Sites e acompanhe a categoria Novidades.