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
Separar site público, gestão e loja
Compare URL representativos com dispositivo, sessão e condições iguais. Cache pública rápida não descreve editor ou carrinho. Repita medições e registe a referência inicial.
02
Distinguir servidor e apresentação
Esperar pelo primeiro byte difere de imagens tardias ou scripts bloqueantes. Consulte a cascata de rede e PageSpeed Insights. Distinga testes de laboratório e dados reais disponíveis.
03
Ajustar imagens e scripts
Verifique imagens iniciais, resolução, compressão e espaço reservado. Não atrase a imagem principal com carregamento diferido. Analise scripts externos e mantenha ganhos comprovados sem falhas funcionais.
04
Adaptar cache às funções
Verifique caches existentes antes de adicionar outra. Plugins semelhantes complicam o diagnóstico. Carrinho, pagamento, contas e conteúdo pessoal precisam de exceções. Teste sessões, preços e formulários.
05
Examinar aplicação e alojamento
O trabalho das extensões importa mais que a quantidade. Verifique consultas lentas, ligações externas e tarefas simultâneas. Faça profiling em staging; não elimine tabelas ou desligue tarefas sem evidência.
Core Web Vitals: objetivos para visitas reais
LCP refere-se ao maior conteúdo visível, INP à resposta às interações e CLS às deslocações visuais. Os objetivos aplicam-se ao percentil 75 de visitas reais, separando móvel e computador. Laboratório não substitui esses dados.
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.