Baixe um site inteiro do Wayback Machine

Salvar uma página do Wayback Machine leva dois minutos. Salvar o site inteiro é um trabalho completamente diferente, do tipo que consome um fim de semana se você for sem preparo. O arquivo não guarda seu site como um pacote organizado. Ele guarda milhares de capturas separadas, cada uma congelada em seu próprio momento de crawl, e remontá-las em um site coerente é onde a maioria trava. Este guia mostra as armadilhas que realmente quebram downloads de sites inteiros, e o ponto em que a automação deixa de ser opcional.

Por que baixar um site do Wayback Machine é mais difícil do que baixar uma página

Uma página é uma captura. Um site é cada URL que o crawler já encontrou, cada uma arquivada em seu próprio cronograma. Sua homepage pode ter 9.000 capturas. Sua página de trocas e devoluções pode ter três, e a mais recente pode ser de 2017. Quando você baixa um site do Wayback Machine, está montando um mosaico a partir de peças que nunca foram feitas para se encaixar.

Os assets pioram tudo. O logo é uma captura. A folha de estilo é outra, possivelmente de um ano diferente. O arquivo serve cada uma com URLs reescritas que só funcionam dentro de web.archive.org, então uma cópia ingênua do site quebra no momento em que você abre localmente. Uma página perdoa esses pecados. Quinhentas páginas os multiplicam.

Mapeie o site antes de baixar qualquer coisa

Não comece com wget. Comece com a CDX API e puxe o inventário completo do que o arquivo realmente guarda:

web.archive.org/cdx/search/cdx?url=example.com/*&matchType=prefix&output=json&collapse=urlkey&filter=statuscode:200

Essa única requisição mostra quantas URLs únicas existem, quais seções o crawler cobriu e onde estão os buracos. Em um trabalho recente, um fórum phpBB de 2009, o inventário mostrou 22.000 URLs únicas. Talvez 1.400 daquelas fossem conteúdo real. O resto eram IDs de sessão, duplicatas de visualização de impressão e páginas de calendário que ninguém nunca leu.

Leia o inventário como um empreiteiro

• Conte URLs por diretório. Uma seção /images gorda significa que os assets sobreviveram; uma magra significa dor depois.
• Verifique a dispersão de datas por seção. Se seu blog para em 2016 mas a homepage vai até 2023, o blog foi deslinkado ou bloqueado, não deletado.
• Procure padrões de lixo cedo: parâmetros de sessão, formulários de resposta, ordens de classificação. Elesinflam o total e seu tempo de download.
• Anote os tipos MIME. Muito text/html sem entradas de imagem significa que o arquivo guardou o esqueleto e perdeu a pele.

Se você quer o inventário sem escrever uma única requisição, o orçamento gratuito da Restorix mostra a contagem exata de arquivos arquivados e o tamanho total de um domínio antes de você gastar qualquer coisa. Esse número muda o plano. Trezentos arquivos é uma tarde DIY. Trinta mil não é.

As armadilhas que quebram um download de site do Wayback Machine

Cada item desta lista já me queimou pelo menos uma vez. Nenhum deles é óbvio até que você esteja três horas dentro de um download e o resultado não faça sentido.

• Histórico de robots.txt. Por anos, o arquivo se recusou a rastrear ou servir páginas bloqueadas pelo robots.txt. Se um dono anterior o configurou errado, diretórios inteiros simplesmente não existem no arquivo, e nenhuma ferramenta pode conjurá-los.
• Dispersão de hosts. www.example.com, example.com, blog.example.com e o antigo host de CDN são conjuntos de capturas diferentes. Uma consulta de prefixo em um host perde silenciosamente os outros, e um script de crawler também.
• http versus https. A mesma página sob ambos os esquemas é arquivada duas vezes, às vezes com assets diferentes. Escolha a variante com melhor cobertura, não a que você lembra.
• Páginas renderizadas em JavaScript. O crawler armazenou o que conseguiu executar no momento do crawl. Um site React de 2019 pode voltar como uma casca de divs vazias com o conteúdo real perdido.
• Deriva de timestamp. Arquivos capturados em 2014, 2017 e 2021 costurados em um site produzem layouts quebrados e navegação incompatível. Ancore tudo em uma data-alvo.
• O chrome do Wayback. Snapshots servidos normalmente incluem a barra de ferramentas do arquivo e links reescritos. Busque com o sufixo id_ no timestamp, ou planeje remover o chrome de cada arquivo que você salvar.

Query strings, paginação e outras armadilhas de URL

Query strings são onde downloads de sites inteiros falham silenciosamente. Para o arquivo, /shop?cat=shoes e /shop?cat=hats são URLs diferentes com capturas diferentes. Assim como ?page=2 e ?page=200. Uma loja WooCommerce de um cliente em que trabalhei tinha 4.000 URLs arquivadas e apenas 90 produtos reais. O resto eram combinações de filtros, ordens de classificação e parâmetros de rastreamento.

A estratégia é mecânica. Puxe a lista do CDX, agrupe URLs pelo caminho antes do ponto de interrogação e decida quais parâmetros carregam conteúdo. IDs de produto e paginação: mantenha. IDs de sessão, tags UTM e permutações de filtro: descarte. Errar isso em uma direção e você perde páginas reais. Errar na outra e você baixa dez vezes mais lixo e paga por isso em horas.

Quando o download do seu site do Wayback Machine volta com buracos

Assets ausentes são a regra, não a exceção. Espere lacunas em:

• Imagens com lazy load e injetadas via JavaScript que o crawler nunca disparou
• Imagens de fundo de CSS e web fonts referenciadas de dentro das folhas de estilo
• Arquivos de vídeo e áudio, que o arquivo captura de forma inconsistente quando muito
• Fontes e ícones carregados através de kits de terceiros que precisavam de uma chave de API ativa
• Qualquer coisa servida a partir de um domínio de terceiros, uma rede de anúncios ou atrás de um login

Para cada buraco, suas opções são limitadas: tente timestamps adjacentes, tente as variantes www e não-www ou http e https, ou aceite a perda e regenere o asset. É aqui que um manifesto vale seu preço. A Restorix entrega um manifesto de arquivos em JSON ou SQLite com cada restauração, então descobrir quais arquivos estão faltando vira uma consulta de filtro em vez de uma tarde clicando em páginas.

Quando parar de fazer scripts e automatizar

Faça a conta honestamente. Um script de download sólido para um site bagunçado é um fim de semana para construir e depurar, mais horas de reexecuções quando o archive.org limita você no arquivo 8.000 de 9.000. Depois, um segundo projeto inteiro começa: remover reescritas do Wayback, corrigir links internos, escolher um host canônico, fazer deploy e testar.

A automação faz sentido no momento em que o site precisa voltar a funcionar, em vez de apenas existir no seu disco. A plataforma Restorix cuida do download, da limpeza e do deploy em um único trabalho: pague por arquivo restaurado, primeiro arquivo grátis, preço travado no momento do orçamento e reembolso automático para seu saldo se algo falhar. O caminho DIY ainda faz sentido para sites pequenos, coletas de pesquisa e pessoas que genuinamente curtem o quebra-cabeça. Já fiz os dois caminhos mais vezes do que consigo contar, e o ponto de equilíbrio chega mais rápido do que as pessoas esperam, geralmente por volta da segunda reexecução.

De arquivos baixados a um site funcionando

1. Remova a barra de ferramentas do Wayback e reescreva cada URL de archive.org de volta para um caminho relativo.
2. Escolha um host canônico, www ou não-www, e redirecione o outro.
3. Converta links internos para HTTPS antes de fazer deploy em qualquer lugar moderno.
4. Remova scripts de terceiros mortos: analytics antigos, tags de anúncios e widgets sociais que ligam para casa.
5. Faça deploy, depois clique pelas 50 principais páginas com a aba network do navegador aberta para pegar o que ainda retorna 404.

Duas coisas sempre falham nesta etapa: formulários de contato e busca. Ambos dependiam de código de servidor que o arquivo nunca capturou. Substitua formulários por um serviço de formulário hospedado ou um simples link mailto, e troque a busca do site por um índice estático ou uma caixa de busca com escopo de mecanismo de pesquisa.

A Restorix engloba tudo isso em opções de restauração: links internos relativos, conversão para HTTPS, remoção de analytics, deploy com um clique para SSH, FTP ou S3, e um pequeno CMS incluído para que o site restaurado continue editável. Faça à mão ou deixe o serviço fazer; o checklist é o mesmo nos dois casos. Só as horas mudam.