Checklist de segurança WordPress: 15 pontos para proteger seu site sem ser especialista

Um checklist de segurança WordPress começa com perguntas simples: você consegue restaurar o site? Há atualizações pendentes? Quem tem acesso de administrador? A lista abaixo reúne 15 verificações práticas, com o que fazer e como registrar o resultado. Ela reduz riscos e ajuda na recuperação, mas não garante proteção absoluta. Para aprofundar as camadas técnicas, consulte nosso guia de segurança WordPress.

Antes de começar: acesso, backup e registro

Use um acesso autorizado ao painel e peça ajuda à hospedagem quando o item depender do servidor. Em hospedagem gerenciada, multisite ou site com SSO e loja, alguns controles podem estar em outro painel ou sob responsabilidade de outra equipe.

Antes de atualizar, remover plugins, trocar PHP ou tema, configurar HTTPS, firewall, XML-RPC, login ou permissões, tenha backup recente dos arquivos e do banco de dados, cópia fora da hospedagem e plano de retorno. Teste mudanças que possam interromper o site em staging, se disponível. Nosso guia de backup do WordPress na nuvem ajuda a planejar a cópia e a restauração.

Para cada ponto, marque OK, pendente ou depende da hospedagem; registre evidência, responsável e data. Não inclua senhas, códigos de recuperação nem logs sensíveis na planilha.

Recuperação e manutenção: pontos 1 a 5

1. O backup inclui arquivos e banco de dados e pode ser restaurado?

Faça: confira a última execução, frequência, retenção e cópia protegida fora da mesma hospedagem. Planeje um teste de restauração em ambiente separado; existir um arquivo não prova que a recuperação funciona. Confirme: anote data, escopo (uploads, plugins, temas e banco), localização da cópia e resultado do teste. Em lojas, avalie a perda de pedidos e dados desde a última cópia antes de restaurar.

2. WordPress, plugins e temas têm atualizações pendentes?

Faça: consulte Painel > Atualizações, além das telas de plugins e temas. Planeje correções após backup; em sites críticos, teste fluxos essenciais em staging e valide novamente na produção. Mesmo com atualização automática, acompanhe o resultado. Confirme: não há pendências sem responsável ou há plano documentado; login, formulários e checkout, se houver, continuam funcionando.

3. Há plugins sem manutenção conhecida ou sem função?

Faça: em Plugins, relacione os ativos e inativos e consulte origem, finalidade, suporte e histórico de atualizações. A data da última atualização, isoladamente, não comprova vulnerabilidade; investigue compatibilidade e avisos de segurança. Antes de desativar ou remover, verifique dados, shortcodes e integrações. Confirme: cada plugin instalado tem motivo e responsável; substituições ou remoções foram testadas após backup, sem perda inesperada de dados.

4. O tema é confiável e continua mantido?

Faça: em Aparência > Temas, se disponível, identifique o tema ativo, seu tema pai quando houver e os inativos. Confira origem, atualizações e compatibilidade; evite versões de procedência duvidosa. Não remova o tema pai de um tema filho nem troque o tema ativo sem teste. Confirme: as dependências estão registradas e os temas extras têm destino planejado com segurança.

5. O PHP da hospedagem está em versão mantida e compatível?

Faça: consulte a versão em Ferramentas > Saúde do site > Informações > Servidor (os rótulos variam) e os alertas na aba Status. Se houver aviso de versão obsoleta, planeje com a hospedagem uma versão mantida que funcione com WordPress, tema e plugins. Confirme: depois da mudança no painel da hospedagem, páginas, editor, formulários e transações funcionam. A Saúde do site mostra diagnósticos; ela não altera a versão do PHP.

Contas e conexões: pontos 6 a 10

6. Cada administrador ainda precisa desse privilégio?

Faça: em Usuários > Todos os usuários, revise responsáveis e funções; conceda somente a função necessária. Antes de excluir ou rebaixar uma conta, avalie autoria de conteúdo, integrações e o caminho legítimo de recuperação. Confirme: os administradores correspondem à equipe autorizada e, sempre que possível, cada pessoa usa sua própria conta. Multisite e plugins podem apresentar funções diferentes.

7. As senhas de acesso são exclusivas e bem guardadas?

Faça: oriente quem tem acesso privilegiado a usar senhas longas e exclusivas, preferencialmente geradas e guardadas em gerenciador. Inclua contas de e-mail administrativo e hospedagem. Diante de suspeita de vazamento, use os canais legítimos para trocar credenciais. Confirme: cada responsável atesta que revisou sua senha e o método de armazenamento; não peça a senha, não tente verificá-la por compartilhamento e não registre credenciais na auditoria.

8. O segundo fator protege as contas privilegiadas?

Faça: no WordPress auto-hospedado, avalie um plugin mantido de 2FA ou o provedor de identidade do site: o core não oferece 2FA por padrão. Guarde códigos de recuperação fora da planilha e teste uma nova sessão antes de encerrar a atual. Confirme: cada administrador consegue entrar com o segundo fator e existe recuperação testada para perda do dispositivo. Nosso guia mostra como ativar 2FA no WordPress sem perder o acesso. Avalie SSO, clientes da loja e acessos de serviço antes de impor uma regra global.

9. Site e painel usam HTTPS válido?

Faça: abra páginas públicas e login com https:// e confira se o navegador não mostra erro de certificado nem conteúdo misto. Pergunte à hospedagem como são feitas cobertura e renovação do certificado. Confirme: o domínio, a área administrativa e os redirecionamentos funcionam sem alertas. HTTPS protege a transmissão; não remove malware. Para migrar URLs ou configurar proxy/CDN, faça backup e siga o guia de HTTPS e certificado SSL no WordPress com testes.

10. Tentativas repetidas de login são limitadas?

Faça: pergunte à hospedagem se já há WAF ou limitação de tentativas no servidor/CDN. Se não houver, avalie uma solução mantida e adequada ao tráfego; um plugin que filtra dentro do PHP pode consumir recursos sob ataque intenso. Confirme: registre onde a proteção atua, quem recebe alertas e se usuários legítimos, API e formulários continuam funcionando. Evite sobrepor controles sem necessidade ou bloquear regiões inteiras sem medir falsos positivos.

Superfície de ataque e observação: pontos 11 a 15

11. Alguma integração ainda depende de XML-RPC?

Faça: verifique com os responsáveis por aplicativos, Jetpack ou integrações legadas se usam xmlrpc.php. Se não houver dependência, discuta restrição ou bloqueio com a hospedagem; se houver, avalie limitação de requisições e regras específicas. Confirme: a dependência e os testes posteriores estão registrados. Não bloqueie às cegas: isso pode interromper funções, e o bloqueio não substitui senhas fortes e 2FA.

12. O fluxo de login funciona e pode ser recuperado?

Faça: se um plugin muda a URL de login, documente a rota em local restrito e teste login, redefinição de senha, SSO e integrações após qualquer ajuste. Se a URL não foi alterada, não é obrigatório mudá-la: priorize 2FA e limitação de tentativas. Confirme: um administrador autorizado consegue acessar o painel e conhece um procedimento de recuperação. Ocultar o login pode reduzir ruído, mas não é uma barreira confiável por si só.

13. As permissões dos arquivos foram revisadas pela hospedagem?

Faça: em Ferramentas > Saúde do site > Informações, procure diagnósticos de sistema de arquivos, quando disponíveis. Eles indicam sobretudo se os diretórios necessários são graváveis; não certificam, sozinhos, ausência de permissões excessivas. Peça à hospedagem uma revisão do proprietário e das permissões dos arquivos de configuração e demais diretórios. Confirme: o provedor informou o resultado e uploads e atualizações continuam operando. Não use 777 nem aplique números ou alterações recursivas sem conhecer o ambiente.

14. Existe monitoramento de indisponibilidade e alterações inesperadas?

Faça: examine Ferramentas > Saúde do site > Status e, se o provedor oferecer, configure alertas de indisponibilidade e mudanças imprevistas em arquivos ou páginas. Defina quem recebe e investiga cada aviso; se usar plugin de integridade, verifique manutenção e compatibilidade. Confirme: um teste não destrutivo de notificação chega ao responsável e existe rotina para separar mudanças legítimas de suspeitas. Monitorar não limpa uma invasão.

15. Você sabe onde estão os logs e quem pode consultá-los?

Faça: pergunte à hospedagem sobre registros de acesso e erros. Se precisar de trilha de alterações no painel, avalie um plugin de auditoria mantido; o WordPress básico não fornece necessariamente um histórico completo de ações administrativas. Confirme: saiba quais eventos são registrados, quem acessa os logs e por quanto tempo ficam disponíveis. Revise a política de retenção e privacidade; não exponha IPs, caminhos ou dados pessoais em relatórios públicos.

Transforme o checklist de segurança WordPress em rotina

Registre para cada item o estado, a evidência sem segredos, a pessoa responsável e a próxima revisão. Priorize cópias restauráveis, correções pendentes e acesso privilegiado. Leve XML-RPC, login e permissões à equipe que conhece a infraestrutura. Revise a lista após mudanças importantes e periodicamente, de acordo com o risco do seu site.

Se aparecerem contas desconhecidas, redirecionamentos suspeitos ou páginas adulteradas, interrompa a auditoria preventiva: preserve evidências e acione a hospedagem. Veja os passos de contenção e recuperação de um WordPress hackeado. Instalar mais um plugin não substitui a investigação.

Perguntas frequentes

Preciso instalar um plugin de segurança para conferir os 15 pontos?

Não. Muitos itens são verificações ou serviços da hospedagem. 2FA, auditoria e certas regras de bloqueio podem exigir um plugin, um provedor de identidade ou um recurso do provedor; identifique o que já existe antes de adicionar ferramentas.

Mudar a URL de login torna o WordPress seguro?

Não. É uma medida opcional que pode reduzir ruído automatizado, mas não substitui atualizações, senha exclusiva, 2FA nem limitação de tentativas. Teste a recuperação antes de mudar.

Se a Saúde do site não apresentar alertas, a auditoria terminou?

Não. Ela ajuda a identificar algumas falhas, mas não prova que o backup é restaurável, que as permissões são adequadas em toda a hospedagem ou que não houve comprometimento.