Segurança & performance WordPress, guia técnico do administrador 2025

Gerir um site WordPress profissional é mais do que escrever conteúdo. É trabalho contínuo em três pilares: Segurança, Visibilidade (Analytics/SEO) e Performance. Este artigo desenvolve uma apresentação de formação e confronta cada recomendação com a documentação oficial: o WordPress Advanced Administration Handbook, a página de segurança do WordPress.org, os requisitos de servidor, a OWASP e a documentação da Google. Cada secção dá passos que pode aplicar hoje.

#Como reforçar a segurança do WordPress sem plugins

Muitos pensam que são necessários plugins “Security Pro” caros para proteger WordPress. É um mito. As proteções mais sólidas funcionam a nível de servidor, antes de um pedido chegar a executar PHP. Uma abordagem por camadas, que começa na infraestrutura e sobe até à aplicação, é mais fiável do que depender apenas de plugins.

#Atualizações, plugins não usados e temas nulled

Atualizações: Segundo a página de segurança do WordPress.org, só a versão mais recente do WordPress tem suporte oficial; a equipa de segurança (mais de 50 especialistas, segundo a mesma página) aplica correções a versões antigas apenas por cortesia. O guia de reforço acrescenta dois factos: as atualizações automáticas existem desde o WordPress 3.7, e os detalhes das vulnerabilidades corrigidas costumam tornar-se públicos. Uma versão antiga fica, por isso, mais fácil de atacar a cada semana sem atualização.

PHP: Os requisitos oficiais recomendam PHP 8.3 ou superior, MySQL 8.0 ou superior (ou MariaDB 10.11 ou superior) e suporte HTTPS. O WordPress ainda funciona com PHP 7.4 e MySQL 5.5.5, mas ambas as versões chegaram ao fim de vida e a própria página avisa que podem expor o site a vulnerabilidades. Se o seu servidor ainda está em PHP 7.x, atualizar é a primeira tarefa.

Temas e plugins: Apague (não apenas desative) tudo o que não usa. Cada ficheiro no servidor é um potencial vetor de ataque. Os plugins desativados continuam executáveis se um atacante pedir diretamente os seus ficheiros, por isso a remoção completa é a única opção segura.

Fonte: Nunca descarregue plugins “Premium grátis” de torrents (Nulled). Uma cópia nulled é código alterado por um terceiro desconhecido, que não pode auditar e que não recebe atualizações. O guia oficial pede que o WordPress seja descarregado apenas do WordPress.org; para plugins e temas, o equivalente é o diretório oficial ou o site do autor.

#Que definições do wp-config.php aumentam a segurança

Acrescente estas linhas ao ficheiro de configuração para bloquear ataques típicos:

// Bloquear edição de ficheiros do admin
define( 'DISALLOW_FILE_EDIT', true );

// Forçar SSL para login e painel
define( 'FORCE_SSL_ADMIN', true );

// Mudar prefixo da base de dados (faça isto SÓ durante a instalação!)
$table_prefix = 'wp_a1b2_'; // Em vez do padrão wp_

DISALLOW_FILE_EDIT retira a todos os utilizadores as capacidades edit_themes, edit_plugins e edit_files. O guia de reforço é claro sobre o limite: a constante não impede o carregamento de ficheiros maliciosos, mas fecha um caminho habitual depois do roubo de uma conta de administrador. Quanto ao prefixo, o mesmo guia explica que muitos ataques de injeção SQL publicados assumem wp_, pelo que mudá-lo bloqueia pelo menos parte deles. Não substitui consultas preparadas no código.

#Como desativar o XML-RPC e limitar revisões

// No wp-config.php: limitar revisões
define( 'WP_POST_REVISIONS', 5 );

// Num mu-plugin, não no wp-config.php
add_filter( 'xmlrpc_enabled', '__return_false' );
remove_action( 'wp_head', 'wp_generator' );

Duas correções a excertos que circulam na internet. Primeiro, não existe uma constante XMLRPC_ENABLED no WordPress; o que existe é o filtro xmlrpc_enabled (desde a versão 3.5), que só desativa os métodos que exigem autenticação. Os pingbacks continuam a responder. Se não usa XML-RPC, bloqueie xmlrpc.php no servidor, como faz a regra abaixo. Segundo, remove_action() não funciona no wp-config.php, porque nesse ponto as funções do WordPress ainda não foram carregadas; a chamada pertence a um plugin ou a wp-content/mu-plugins/.

#Como bloquear ficheiros sensíveis com .htaccess

O ficheiro .htaccess (em servidores Apache/LiteSpeed) é o seu primeiro guarda. Defina regras que bloqueiem o acesso a ficheiros sensíveis antes de qualquer código PHP ser executado.

Bloquear o acesso a ficheiros sensíveis (sintaxe do Apache 2.4, a usada no guia oficial):

<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php)">
Require all denied
</FilesMatch>

As diretivas Order deny,allow e Deny from all pertencem ao Apache 2.2; no Apache 2.4 só funcionam através do módulo de compatibilidade mod_access_compat. Bloqueie xmlrpc.php apenas se nenhum serviço o usar: a aplicação móvel do WordPress ou o Jetpack podem depender dele.

Restringir o wp-login.php por IP, se trabalha a partir de endereços fixos. É o exemplo do guia oficial contra força bruta, com endereços de documentação que deve trocar pelos seus:

<Files "wp-login.php">
Require ip 203.0.113.15 203.0.113.16
</Files>

#Que permissões de ficheiros o WordPress precisa

O guia de reforço dá valores concretos: diretórios em 755 e ficheiros em 644, que é também o que as atualizações automáticas aplicam. A raiz, wp-admin/, wp-includes/ e wp-content/plugins/ devem ser graváveis apenas pela sua conta de utilizador; wp-content/ também pelo servidor web. Para o wp-config.php recomenda 440 ou 400, para que só o proprietário e o servidor web o possam ler, e menciona a hipótese de o mover um diretório acima da instalação, com a ressalva de que alguns especialistas consideram o benefício mínimo.

find /caminho/para/wordpress/ -type d -exec chmod 755 {} \;
find /caminho/para/wordpress/ -type f -exec chmod 644 {} \;
chmod 440 /caminho/para/wordpress/wp-config.php

Na base de dados aplica-se o mesmo princípio: o funcionamento normal só precisa de SELECT, INSERT, UPDATE e DELETE, mas o guia desaconselha retirar ALTER ou DROP, porque as atualizações e alguns plugins alteram o esquema. Um utilizador de base de dados diferente por site, pelo contrário, não custa nada.

#Cabeçalhos de segurança HTTP no .htaccess

Adicione cabeçalhos que protejam contra ataques comuns como clickjacking e MIME sniffing. Os valores seguem a folha de referência de cabeçalhos HTTP da OWASP:

# Cabeçalhos de segurança
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header set X-XSS-Protection "0"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header unset X-Powered-By

Muitos guias antigos recomendam X-XSS-Protection: 1; mode=block. A OWASP diz o contrário: não enviar o cabeçalho ou defini-lo como 0, porque o filtro do navegador que ele ativava podia criar falhas XSS em sites que eram seguros. A proteção real contra XSS é uma Content Security Policy que não permita JavaScript inline. A OWASP prefere DENY ou a diretiva CSP frame-ancestors a X-Frame-Options; SAMEORIGIN é o compromisso habitual no WordPress porque o personalizador carrega o site dentro de um iframe do mesmo domínio. Cuidado com o HSTS: um certificado expirado bloqueia os visitantes durante todo o max-age, por isso ative-o só quando o HTTPS funcionar em todos os subdomínios.

#Autenticação de dois fatores (2FA) no WordPress

Ative a 2FA em todas as contas de administrador. O guia oficial contra força bruta di-lo sem rodeios: o núcleo do WordPress não inclui 2FA, por isso precisa de um plugin de confiança ou de um fornecedor de identidade. Plugins como Two Factor (mantido por colaboradores do WordPress), WP 2FA ou Google Authenticator oferecem esta função. O mesmo guia acrescenta três medidas: não usar o nome de utilizador admin, usar palavras-passe longas e únicas com um gestor de palavras-passe, e limitar a frequência de pedidos a wp-login.php e xmlrpc.php na periferia da rede (WAF ou CDN) ou no servidor web, porque um plugin de segurança continua a consumir PHP durante um ataque em grande escala.

#Como fazer cópias de segurança do WordPress

O guia oficial de cópias de segurança separa duas partes que devem ser guardadas juntas: a base de dados (artigos, comentários, definições) e os ficheiros (núcleo, plugins, temas, carregamentos). Uma cópia só da base de dados não restaura o site. Frequência recomendada: semanal para sites pequenos, diária para sites com muita atividade e sempre antes de uma atualização. Guarde entre 3 e 5 cópias recentes em locais e suportes diferentes. Para restaurar, reponha primeiro os ficheiros e depois importe a base de dados; se as credenciais mudaram, ajuste o wp-config.php. O guia de reforço acrescenta que as cópias devem ser cifradas, com hashes independentes guardados para provar que ninguém as alterou.

#Que riscos do OWASP Top 10 2025 afetam o WordPress

A página de segurança do WordPress.org indica que a equipa de segurança trabalha para reforçar o núcleo contra ameaças como o OWASP Top Ten. A edição de 2025 serve como lista de verificação para um administrador, porque várias categorias correspondem a decisões tomadas no painel ou no servidor, e não no código do núcleo:

Sobre os registos, o guia de reforço explica que os logs do servidor mostram IP, hora e ação, e revelam tentativas de XSS, inclusão de ficheiros, travessia de diretórios e força bruta. Recomenda ferramentas como o OSSEC e filtrar o ruído para que os alertas importantes não se percam.

#Como configurar o Google Search Console e o GA4 no WordPress

Não pode gerir o que não mede. O Google Search Console (GSC) e o Google Analytics 4 (GA4) são os olhos e ouvidos do seu negócio.

#O que verificar no Google Search Console todas as semanas

O único lugar onde o Google “fala” consigo sobre o seu site. Para qualquer administrador WordPress que se preocupe com a visibilidade na pesquisa, é a ferramenta mais importante.

1. Sitemap: Certifique-se de que enviou o seu sitemap (normalmente dominio.pt/sitemap_index.xml, gerado pelo plugin de SEO). Confirme que todos os URLs importantes estão incluídos e que não há erros de processamento.
2. Erros de Indexação: Verifique a secção “Páginas” semanalmente. Procure erros 404 e 5xx. Um 404 num URL que recebe ligações ou tráfego é uma visita perdida; um 5xx repetido aponta para um problema de servidor.
3. Core Web Vitals: O GSC vai dizer-lhe diretamente se o site carrega com rapidez suficiente (LCP), se responde a tempo às interações (INP) e se é visualmente estável (CLS). Dê atenção aos dados de campo de utilizadores reais, que são os que o relatório conta.

#Que limiares de Core Web Vitals uma página tem de cumprir

Segundo a documentação do web.dev, uma página tem bons Core Web Vitals quando cumpre os três limiares no percentil 75 dos carregamentos, medidos separadamente em dispositivos móveis e em computador:

O percentil 75 significa que a maioria das visitas tem de cumprir o limiar, não apenas a média. Por isso, um teste de laboratório rápido feito no seu escritório não garante um relatório verde no GSC.

#Como configurar eventos principais no GA4

O GA4 é diferente do antigo UA. Foca-se em eventos em vez de visualizações de página, o que muda a forma de medir o sucesso de um site.

• Não meça apenas “visitas”. Configure eventos principais: submissão de formulário, clique no telefone, download de PDF. A Google mudou o nome: o que antes eram conversões no GA4 chama-se agora eventos principais, e “conversão” fica reservado para a medição ligada ao Google Ads.
• Lembre-se do RGPD. O Consent Mode v2 transmite às etiquetas da Google a decisão de consentimento do visitante. Segundo a documentação da Google, a versão 2 acrescenta os parâmetros ad_user_data e ad_personalization aos já existentes ad_storage e analytics_storage. O Consent Mode não substitui o banner de consentimento nem a base legal: apenas faz com que as etiquetas respeitem a escolha do utilizador.
• Crie eventos personalizados que reflitam os objetivos do seu negócio: pedidos de orçamento, subscrições da newsletter, cliques no WhatsApp, marcações.

#Como otimizar a performance do WordPress (WPO)

Um site rápido melhora a experiência de utilização e os Core Web Vitals, que a Google mede no relatório do GSC descrito acima.

#Que alojamento precisa um WordPress rápido

Não consegue otimizar um site em hosting de 5€/ano. O guia oficial de otimização refere que passar para um servidor com discos SSD ou NVMe, mais CPU e mais memória pode fazer uma grande diferença. Procure hosting com:

• Discos NVMe para I/O rápido da base de dados.
• Suporte Redis/Memcached (base de dados em RAM) para object caching.
• Servidor LiteSpeed (LSCache) ou Nginx para um tratamento eficiente dos pedidos.

O mesmo guia dá dois conselhos muitas vezes esquecidos: não correr o DNS nem um servidor de correio no mesmo servidor do WordPress. Para formulários de contacto, use um plugin de formulários com um serviço de envio externo.

#Como otimizar imagens no WordPress

As imagens costumam ser os recursos mais pesados de uma página, e o elemento LCP é muitas vezes uma imagem.

• Lazy Loading: O WordPress faz isto por defeito desde a versão 5.5, mas os plugins de otimização dão mais controlo sobre iframes e vídeos. Não aplique lazy loading à imagem principal visível no carregamento, porque atrasa o LCP.
• Formatos: Use WebP ou AVIF. Segundo a Google, o WebP com perdas é 25 a 34 % mais leve do que um JPEG comparável com a mesma qualidade SSIM, e o WebP sem perdas é 26 % mais leve do que o PNG.
• Dimensões: Não carregue fotos de 4000px num blog onde a largura do texto é 800px. Redimensione antes de carregar.

#Page cache e object cache (Redis) no WordPress

O seu site não deve gerar PHP para cada visitante. Use cache em vários níveis:

• Page Cache: Guarda HTML pronto no disco do servidor para respostas imediatas. O guia oficial de otimização indica que guardar páginas como ficheiros estáticos pode acelerar várias centenas de vezes as páginas pouco dinâmicas.
• Object Cache (Redis): Guarda em memória os resultados das consultas à base de dados. Crucial para lojas WooCommerce e sites grandes, onde as mesmas consultas se repetem constantemente.
• OPcache: Guarda em memória o código PHP já compilado; o guia oficial cita-o como um acelerador que melhora todos os ficheiros PHP, não só o WordPress.
• Cache do navegador: Defina cabeçalhos de expiração para que os navegadores guardem localmente os ficheiros estáticos.

#CDN e edge computing para WordPress

Para sites com público internacional, uma CDN como a Cloudflare replica imagens e outros ficheiros estáticos em servidores próximos de cada utilizador; o guia oficial apresenta-a como a resposta à distância geográfica entre servidor e visitante. O edge computing vai mais longe e executa lógica de servidor perto do utilizador para reduzir a latência. Uma CDN com WAF é também o sítio certo para limitar os pedidos a wp-login.php.

#Como descobrir que plugin torna o WordPress lento

O guia oficial de otimização propõe um método simples: desative plugins de forma seletiva e meça a performance do servidor depois de cada alteração. Se um deles pesar muito, leia a documentação, pergunte no fórum de suporte ou procure uma alternativa com funções semelhantes. As ferramentas de programador do Firefox ou do Chrome incluem painéis de performance suficientes para uma primeira medição. Na base de dados, o mesmo guia recomenda o InnoDB, o motor por defeito do MySQL, e a conversão das tabelas MyISAM antigas.

#Monitorização contínua da performance

Configure a monitorização da performance com ferramentas como DebugBear ou SpeedCurve. Estas ferramentas detetam regressões automaticamente, para que possa agir antes de os utilizadores notarem.

#Com que frequência fazer a manutenção do WordPress

Cuidar de um site WordPress é um processo, não uma ação única. Defina um calendário firme:

• Diariamente: Verifique os backups (automáticos) em sites com muita atividade e acompanhe os alertas de segurança.
• Semanalmente: Atualize plugins, verifique o GSC, leia os registos de erros e, em sites pequenos, faça a cópia de segurança semanal.
• Mensalmente: Faça auditoria de velocidade, revisão de utilizadores (alguém sem autorização tem acesso de administrador?) e limpeza da base de dados.
• Trimestralmente: Auditoria de segurança completa, revisão dos plugins instalados, teste de restauro de uma cópia e atualização do plano de recuperação.

Segurança e performance não são projetos com data de fim, são processos contínuos.