Logs de erros WordPress: como ler e usar para diagnosticar problemas

Quando um site WordPress tem um problema que não se manifesta com uma mensagem de erro visível, os logs são o próximo passo. Saber onde encontrar os logs, como activá-los, e como interpretar o que está escrito reduz o tempo de diagnóstico de horas para minutos. Este guia cobre todos os tipos de log relevantes para WordPress.

Os três tipos de log que importam em WordPress

1. WordPress debug.log

O log nativo do WordPress — regista erros PHP, warnings e notices gerados durante a execução do WordPress e dos plugins. É o ponto de partida para qualquer diagnóstico.

2. PHP error_log do servidor

O log do servidor PHP — regista erros PHP que ocorrem antes ou independentemente do WordPress estar carregado. Erros fatais que impedem o WordPress de iniciar aparecem aqui mas não no debug.log.

3. Access log e error log do servidor web

Logs do Apache ou Nginx — registam todos os pedidos HTTP ao servidor e erros de servidor (500, 404, etc.). Úteis para diagnosticar problemas de .htaccess, permissões de ficheiros, e timeouts.

Activar o debug.log do WordPress

Por defeito, o WordPress não regista erros em ficheiro. Activar adicionando ao wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);

Com esta configuração:

• WP_DEBUG: activa o modo debug do WordPress
• WP_DEBUG_LOG: escreve erros para /wp-content/debug.log
• WP_DEBUG_DISPLAY false: não mostra erros no ecrã (para utilizadores do site)
• SCRIPT_DEBUG: força versões não-minificadas de JS e CSS do core

Atenção: em produção, nunca activar WP_DEBUG_DISPLAY true — expõe informação técnica sensível a visitantes. Usar sempre WP_DEBUG_LOG true + WP_DEBUG_DISPLAY false.

Como ler o debug.log

O debug.log fica em /wp-content/debug.log. Aceder via FTP ou gestor de ficheiros do hosting. Cada entrada tem o formato:

[02-Feb-2026 14:23:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function xyz() in /wp-content/plugins/meu-plugin/includes/functions.php on line 47

O que extrair de cada entrada:

• Timestamp: quando ocorreu o erro
• Tipo: Fatal error (bloqueia execução), Warning (problema não fatal), Notice (informativo), Deprecated (funcionalidade obsoleta)
• Ficheiro e linha: onde no código está o problema — o ficheiro indica qual plugin ou tema é o responsável
• Mensagem: o que causou o erro

Erros frequentes e o que significam

• Fatal error: Allowed memory size exhausted — limite de memória PHP esgotado. Aumentar WP_MEMORY_LIMIT ou identificar o plugin que consome memória excessiva.
• Fatal error: Call to undefined function — uma função chamada não existe. Frequentemente um plugin que depende de outro plugin não activo.
• Warning: Cannot modify header information — algo a tentar enviar headers HTTP depois de output já ter sido enviado. Frequentemente um ficheiro com espaços antes de <?php ou após ?>.
• Deprecated: Creation of dynamic property — em PHP 8.2+, criação de propriedades de objecto dinâmicas foi depreciada. Indica plugin não actualizado para PHP 8.2.

Encontrar os logs do servidor

A localização dos logs do servidor varia por hosting:

• cPanel: Logs > Error Log no painel de controlo, ou ~/public_html/error_log via FTP
• Plesk: Logs > Apache Error Log na secção do domínio
• VPS com Apache: tipicamente em /var/log/apache2/error.log ou /var/log/httpd/error_log
• VPS com Nginx: tipicamente em /var/log/nginx/error.log

Ferramentas para monitorização contínua de logs

Para portfólios grandes, verificar logs manualmente em cada site é impraticável. Alternativas:

• Query Monitor (plugin WordPress) — mostra erros PHP, queries à base de dados e HTTP requests na barra de admin. Ideal para diagnóstico interactivo.
• WP Log Viewer — interface no painel WordPress para ler o debug.log sem acesso FTP.
• Sentry ou Raygun — plataformas de error tracking que agregam erros de múltiplos sites com alertas automáticos. Para agências que gerem muitos sites, o investimento justifica-se.

Quando desactivar o debug mode

Em produção, o debug mode deve estar activo apenas enquanto se diagnostica um problema específico. Um debug.log a crescer indefinidamente pode ocupar espaço significativo em disco. Após resolver o problema, definir WP_DEBUG a false ou remover as entradas do wp-config.php.