O site está fora do ar, e quem fez ele já não está mais aqui.
Veja como estancar o sangramento primeiro.

Triagem primeiro, diagnóstico depois

Quando um site está fora do ar e não traz venda nenhuma, o instinto de corrigir tudo de uma vez é compreensível. Em geral, é o movimento errado. A primeira hora deveria descartar as causas simples, porque elas são comuns e rápidas de corrigir. Um domínio vencido. Uma conta de hospedagem sem pagar. Um certificado SSL que venceu em silêncio. Uma atualização de plugin que quebrou no próprio calendário. Uma parte surpreendente dos casos de “o desenvolvedor desapareceu e agora o site está fora do ar” acaba sendo exatamente uma dessas, não um problema profundo de código.

O que uma auditoria real procura

Com as causas simples descartadas, o próximo passo é ler o código e o próprio servidor. O que mudou pouco antes da queda. O que os registros de erro de fato dizem. Se o problema está no código do aplicativo, num banco de dados, numa integração externa, ou na configuração do servidor. Para um site de tamanho normal, isso costuma levar dias, não semanas. Termina com uma lista escrita do que está quebrado, ordenada pelo que de fato custa dinheiro contra o que é só desorganizado.

Corrigindo sem recomeçar do zero

A maioria dos sites que quebram depois que um desenvolvedor sai não precisa de reescrita. Precisa que a parte quebrada específica seja corrigida, e o resto do sistema deixado em paz. Uma reescrita joga fora tudo que já funcionava, e troca uma queda conhecida por meses de risco novo. Reconstruir só faz sentido onde a auditoria mostra de fato que é mais barato. É uma decisão com números reais, não uma resposta padrão.

Por que “ninguém entende o código” se resolve

Um site sem documentação parece impossível de salvar, mas o código em si quase sempre explica o que faz, para quem o lê com atenção. A estrutura do banco de dados. Como as páginas são geradas. Para que serve cada integração. Tudo isso se descobre sem o desenvolvedor original, só mais lento do que com as notas dele. Resolvida a queda, a solução real é anotar o que foi encontrado, para a próxima pessoa não começar do zero de novo.

Saindo do modo “uma pessoa da próxima queda”

Com o site de volta no ar, vale corrigir o que permitiu que o desaparecimento de uma pessoa tirasse todo o negócio do ar. Acesso de hospedagem e domínio que o negócio controla direto. Uma segunda pessoa que pelo menos consiga checar se o site está vivo. Documentação de como o sistema é construído. Nada disso evita cada problema futuro. Mas transforma a próxima queda numa hora de incômodo, em vez de uma crise onde ninguém consegue entrar.