Recuperação de Sites Antigos: Colocando um Site de Volta no Ar Após Anos Offline

Uma cliente me ligou na primavera passada com um problema familiar. A empresa de paisagismo dela havia funcionado por anos em um site construído em 2013, um site institucional caprichado, uma galeria de jardins finalizados e um formulário de orçamento que trazia a maior parte dos clientes. O domínio venceu em 2019. A conta de hospedagem tinha sido cancelada muito antes disso. O designer tinha se aposentado em Portugal e parou de responder e-mails. Ela fez a pergunta que todo mundo faz nesse momento: será que a recuperação de site antigo é realmente possível, ou vou ter que começar do zero?

A resposta honesta: provavelmente sim, e provavelmente mais do que você imagina. Quase tudo que um site público já mostrou para visitantes foi copiado em algum lugar, por rastreadores de arquivos, por mecanismos de busca, pelo script de backup de alguém. O trabalho é saber o que sobrevive onde, e ser honesto sobre as lacunas. Este é o fluxo de trabalho que uso em jobs como o dela, e as expectativas que defino antes que alguém gaste um centavo.

O que recuperação de site antigo realmente significa

Recuperação de site antigo não é um redesign, e não é 'construa um site novo que pareça com o antigo'. Significa encontrar cópias existentes do site, HTML arquivado, imagens, folhas de estilo, documentos, e remontá-las em um site funcional que você volte a possuir. Um site que você possa colocar em um domínio, editar e gerar leads. A distinção importa porque muda o preço em uma ordem de grandeza: a recuperação reaproveita o que já existe, enquanto uma reconstrução paga alguém para recriar tudo a partir de capturas de tela e memória.

Três tipos de fontes fazem o trabalho pesado. Arquivos da web, acima de tudo o Wayback Machine, guardam cópias rastreadas de páginas públicas que vão décadas atrás. Os caches de mecanismos de busca costumavam ser a segunda opção, mas o Google aposentou seu cache em 2024, então esse poço está praticamente seco. E backups reais, da sua hospedagem antiga, do seu desenvolvedor antigo, ou de um HD numa gaveta, são o único lugar onde as peças dos bastidores às vezes sobrevivem. Cada fonte te entrega uma fatia diferente do site antigo.

Onde as cópias do seu site realmente ficam

Antes de restaurar qualquer coisa, faça o inventário das fontes. Veja o que cada uma realisticamente guarda para um site que está fora do ar há anos:

Leia essa tabela e um padrão salta aos olhos: a camada de apresentação sobrevive, a camada de aplicação não. HTML, CSS e imagens eram públicos, então os rastreadores os copiaram. Scripts PHP, bancos de dados e painéis administrativos ficavam atrás do servidor web, onde nenhum rastreador podia ver. Para um site institucional ou blog, a camada de apresentação é quase todo o site. Para uma loja ou fórum, você recupera o catálogo e o conteúdo, não os pedidos, contas ou mensagens privadas.

Expectativas realistas para recuperação de sites antigos

Eu defino expectativas com números antes de tocar no site de qualquer pessoa, porque esperança não é plano. Com base em jobs de recuperação dos últimos anos, é assim que um bom resultado se parece:

• Páginas estáticas e posts de blog: 90–100% recuperáveis se o site permitia rastreamento.
• Imagens: geralmente 70–95%, dependendo da profundidade do rastreamento do arquivo e se estavam em um domínio CDN separado.
• PDFs e downloads: uma moeda no ar. Rastreadores frequentemente pulavam arquivos acima de certo tamanho.
• Vídeo: considere como perdido a menos que estivesse no YouTube ou no Vimeo, nesse caso, nunca se perdeu.
• Bancos de dados, produtos, usuários, comentários, pedidos: perdidos a menos que exista um backup real. Arquivos só viram páginas renderizadas.
• Posições no Google: parcialmente recuperáveis. Mantenha as URLs originais quando possível, faça 301 nas demais, e o Google reaprende o site mais rápido do que você imagina.

Dois jobs reais. Um fórum phpBB de 2009 voltou como cerca de 400 tópicos de HTML estático, cada post legível, zero contas de usuário. A loja WooCommerce de um cliente voltou com o catálogo completo, cada descrição de produto e a maioria das fotos, mas sem histórico de pedidos e sem lista de clientes. Os dois donos ficaram satisfeitos, porque os dois sabiam o formato do resultado antes do trabalho começar.

O que sobrevive, e o que se perde de vez

Um inventário rápido poupa as pessoas de um fim de semana perdido caçando coisas que nunca tiveram cópia:

• Geralmente sobrevive: páginas HTML públicas e posts de blog, além das imagens que essas páginas referenciavam.
• Geralmente sobrevive: folhas de estilo, arquivos JavaScript, fontes, robots.txt, favicon, às vezes sitemap.xml.
• Geralmente sobrevive: alguns PDFs e downloads menores, se páginas rastreadas tinham link para eles.
• Se perde sem backup: código do servidor, PHP, Python, plugins, lógica de template do tema.
• Se perde sem backup: o banco de dados, produtos, metadados de posts, usuários, comentários, pedidos.
• Se perde sem backup: tudo que ficava atrás de um login, e cada formulário funcional, caixa de busca e carrinho, os arquivos guardaram a aparência, não a engrenagem.
• Se perde sem backup: contas de e-mail, configuração do servidor, regras do.htaccess.

Duas armadilhas merecem menção especial. Se o site antigo tinha um robots.txt que bloqueava rastreadores, os arquivos podem ter quase nada, verifique antes de planejar qualquer coisa. E snapshots tirados depois que o domínio venceu geralmente mostram uma página de parking ou um site porta de entrada golpista. Sempre restaure a partir de um snapshot tirado enquanto o site estava genuinamente no ar; a captura mais nova raramente é a melhor.

Um fluxo de trabalho passo a passo para recuperar sites antigos

1. Liste as URLs. Extraia o inventário de URLs do site pelo índice CDX do Wayback Machine ou pela visualização de calendário, e pegue o sitemap.xml de um snapshot saudável, se existir.
2. Escolha o ano certo. Examine o calendário de snapshots para encontrar o último período em que as capturas mostram o site verdadeiro, não uma página de parking ou um site hackeado.
3. Preencha lacunas com o archive.today. Páginas que o Wayback pulou às vezes existem lá, verifique suas URLs mais importantes uma a uma.
4. Restaure os arquivos. Para algumas páginas, salvar manualmente funciona. Para um site inteiro, faça uma restauração automatizada: o serviço de restauração mostra uma estimativa grátis com a contagem exata de arquivos arquivados, tamanho total e preço fixo antes de você pagar qualquer coisa, e depois restaura o site com os links internos reescritos e o analytics antigo removido, se você quiser.
5. Faça a limpeza. Remova tags de anúncios e scripts de rastreamento arquivados, canonize www ou não-www, e converta os links internos para relativos, para que o site funcione em qualquer domínio.
6. Mapeie as URLs. Mantenha os caminhos originais sempre que possível e faça 301 em tudo que você decidir descartar.
7. Faça o deploy e verifique. Rastreie o site restaurado, corrija os 404s e envie um sitemap novo para o Search Console.

A limpeza é onde os trabalhos de faça-você-mesmo travam. Copiar e colar manualmente do archive.org deixa você com links absolutos apontando de volta para web.archive.org e um beacon de analytics de uma década disparando em cada página. As opções de restauração existem exatamente para isso: remover iframes e código de anúncios, minificar assets e tornar os links independentes de domínio são caixas de marcação, não tardes inteiras de localizar e substituir.

Erros que afundam uma recuperação de site antigo

• Restaurar do snapshot mais recente em vez do mais saudável. O último ano de um site moribundo frequentemente é de páginas de parking e redirecionamentos de malware.
• Deixar o domínio parado enquanto você decide. Compre o domínio de volta primeiro, recuperar conteúdo para um endereço que um especulador possui é trabalho desperdiçado.
• Misturar anos de snapshots. A navegação de 2016 aponta para páginas que sua cópia de 2014 não tem, e todo menu vira uma fábrica de 404.
• Esquecer o subdomínio da CDN. Se as imagens ficavam em cdn.seusite.com, verifique esse hostname no arquivo separadamente, ele tem seu próprio histórico de snapshots.
• Pular a questão dos direitos. Restaurar seu próprio site é prática padrão; republicar o conteúdo de outra pessoa em massa é um problema de direitos autorais.
• Reconstruir em uma plataforma fechada antes de exportar. Primeiro obtenha arquivos limpos, a exportação estruturada de artigos para XML, CSV ou JSON existe por um motivo, depois decida onde eles vão morar.

Custos, prazos e fazer sozinho ou contratar

Faça você mesmo com copiar e colar: grátis, e funciona até umas vinte páginas. Reserve um fim de semana e muita paciência. Scripts gratuitos de download do Wayback lidam com volume, mas deixam você com links internos quebrados e assets faltando, o imposto da limpeza de novo. Restaurações pagas cobram por arquivo; o Restorix cobra por arquivo restaurado com uma pequena taxa fixa por restauração, o primeiro arquivo é grátis, o preço é fixado no momento da estimativa e nada é recorrente. Algumas centenas de arquivos geralmente custam algumas dezenas de dólares, e reembolsos automáticos voltam para o seu saldo se uma restauração falhar.

O prazo se divide da mesma forma em todo job: a restauração em si é a parte rápida, centenas de páginas em menos de uma hora, e o trabalho humano depois é a parte lenta. O site de paisagismo da minha cliente voltou como 86 páginas e cerca de 300 imagens. A estimativa levou um minuto. O fim de semana dela foi para montar um formulário de orçamento funcional e regravar duas fotos de jardim que ela nunca tinha gostado de qualquer forma. O site recuperado ficou melhor que o original em uma semana, o que é a parte que ninguém espera.

Colocando o site recuperado de volta no ar

Um site institucional recuperado pode viver feliz em hospedagem estática barata. Se o dono quer editar conteúdo, e eventualmente sempre quer, faça o deploy com um CMS já integrado em vez de encaixar um depois. O Restorix faz deploy em VPS SSH/SFTP, hospedagem compartilhada FTP ou S3 com um clique, e seus deploys incluem um CMS de arquivo único em /webarchive-cms.php com senha de admin por site, para que o dono edite textos e troque imagens sem mexer em código. Seja qual for sua escolha, termine com o básico chato: analytics novo em vez da tag de 2013, um sitemap XML, verificação no Search Console e 301s para cada URL que você decidiu não trazer de volta.