Este guia destina-se a sites WordPress com alojamento próprio. As alterações exigem acesso adequado e um regresso seguro. Se não conhece ficheiros, bases de dados e alojamento, coordene o diagnóstico com o fornecedor.
Registar observações
Registe URL, mensagem exata, primeiro horário com fuso e última alteração. Compare início, outra página e acesso. Documente tentativas: uma falha isolada não prova indisponibilidade total.
Cópia e regresso seguro
Antes de intervir preserve ficheiros e base, quando possível, e cópias antigas. Verifique datas e capacidade de restauro. Uma cópia danificada ou infetada pode servir à investigação; proteja-a separadamente e não a considere limpa.
Altere um elemento e repita o mesmo pedido. Prefira staging para testes extensos de plugins, temas e configuração. Desativar não é eliminar: loja, formulários e segurança podem ser afetados. Documente estado inicial e reversão.
Diagnóstico dirigido
01
Isolar o pedido
Compare início, outra página, acesso e ação exata: guardar, carregar ou enviar. Antes de repetir formulário ou encomenda, confirme se já foi processado.
02
Consultar o registo correto
O código 500 não revela a causa. Forneça URL, hora, fuso e identificador do pedido. Ficheiro PHP, memória e diretiva inválida indicam pistas distintas. Sem entradas, confirme registo e serviços intermédios.
03
Rever plugins, tema e PHP
Compare o início com atualizações, código e alterações PHP. Teste o componente suspeito numa cópia. Aumentar memória não explica consumo crescente; investigue causa e limites.
04
Preservar regras do servidor
Diretivas .htaccess inválidas podem afetar Apache; Nginx puro não lê esse ficheiro. Substituir às cegas pode remover proteção e redirecionamentos. Confirme a regra específica com o fornecedor.
05
Examinar permissões e recursos
Proprietários, permissões, espaço e processamento PHP devem corresponder ao alojamento. Aplicar 777 indiscriminadamente não é reparação. Repita o pedido após corrigir e verifique outras funções.
Avaliar o restauro
Uma cópia não substitui investigar a causa. Examine-a primeiro isoladamente. Restaurar pode perder encomendas, consultas e conteúdos recentes. Combine o âmbito; após um ataque não reintroduza ficheiros atuais sem verificação.
Testar após a correção
Verifique o URL inicial, início, outras páginas e acesso. Teste formulários e loja em ambiente adequado sem encomendas reais involuntárias. Depois da correção limpe apenas as caches relevantes. Documente causa e resultado.
Quando pedir ajuda
Pare alterações se a causa continuar incerta, a reversão não for fiável ou funções críticas forem afetadas. Indícios de malware exigem investigação de segurança. Não publique registos completos, palavras-passe, chaves ou ligações de recuperação.
Combinar âmbito e custos →Manutenção após a reparação
O núcleo WordPress, os plugins e os temas são atualizados semanalmente, sem adiar tarefas necessárias por causa da rotina. Mensais, diárias ou horárias: o intervalo depende do plano. As cópias ficam em servidores na UE.
Reparações e limpeza de sites já comprometidos são serviços separados. Licenças pagas não estão incluídas.