Ferramentas de Web Downloader Comparadas: O Que Salvam e Quebram

Uma hospedagem simplesmente sumiu com o cliente durante um fim de semana. Sem backups, claro. O site ainda respondia na segunda de manhã, mal, e a primeira coisa que fiz foi apontar um web downloader para ele e puxar cada página alcançável antes que as luzes se apagassem de vez. É para isso que essas ferramentas existem: pegar o que o servidor ainda dá, rápido, antes que pare de dar.

Um web downloader não é mágica, porém, e as quatro ferramentas que as pessoas realmente usam, HTTrack, SiteSucker, wget e o botão de salvar do próprio navegador, diferem bastante no que preservam. Veja o que cada uma salva, o que cada uma quebra silenciosamente e como escolher entre elas.

O que um web downloader realmente salva

Todo web downloader funciona da mesma forma por baixo dos panos. Ele faz uma requisição para uma URL, analisa o HTML que volta, encontra os assets e links internos apontados, baixa esses itens, reescreve os links para que funcionem a partir do seu disco e segue em frente até a fila esvaziar. Um crawler com botão de salvar.

O que chega no seu disco:

• Páginas HTML, geralmente renomeadas para abrir localmente sem precisar de servidor
• CSS, JavaScript e fontes referenciados por essas páginas
• Imagens, vídeos, PDFs e qualquer outro item para o qual as páginas apontem diretamente
• Uma estrutura de pastas que espelha o layout original de URLs

O que não chega: tudo o que o servidor monta na hora. O downloader recebe o mesmo HTML renderizado que qualquer visitante anônimo recebe. O PHP, o banco de dados, o painel administrativo, o histórico de pedidos, nada disso trafega pela rede, então nada disso chega em casa. Um site WordPress baixado é uma estátua do site, não o site.

Dois detalhes de escopo decidem com o que você vai ficar. Primeiro, descoberta: um crawler só encontra URLs linkadas em páginas que ele já tem, mais o sitemap se você fornecer um, páginas órfãs sem links de entrada continuam invisíveis. Segundo, cortesia: a maioria das ferramentas respeita robots.txt por padrão, e embora o HTTrack permita desativar isso, você só deve fazer isso em sites que você é dono.

HTTrack e SiteSucker: as opções com interface gráfica

HTTrack (WinHTTrack no Windows) é o avô da categoria: gratuito, open source e por aí desde 1998. Cole uma URL, escolha uma pasta de projeto e ele espelha o site. O valor real está nas opções, limites de profundidade de crawl, filtros por tipo de arquivo, limites de banda e regras de varredura que incluem ou excluem padrões de URL. Eu espelhei o portfólio de um fotógrafo com 400 páginas em cerca de vinte minutos, imagens e tudo.

Configurações que eu realmente mexo em relação aos padrões:

• Profundidade máxima de espelhamento: deixe sem limite para sites pequenos, limite em 3 ou 4 para os grandes
• Regras de varredura: adicione um padrão de inclusão para o domínio alvo, para que o crawl não escape do site
• Controle de fluxo: duas a quatro conexões e um limite de banda em qualquer coisa que não seja seu próprio servidor
• Tipos MIME: exclua vídeo nas primeiras passadas, uma pasta de webinar esquecida pode ter 40 GB

As pegadinhas: a interface mostra a idade, o último lançamento relevante foi há anos e ele é cego para JavaScript. Se uma página monta o conteúdo no navegador, o HTTrack salva só a estrutura vazia.

SiteSucker é a resposta para Mac, alguns dólares na App Store. Cole uma URL, aperte go, e ele baixa em segundo plano com padrões sensatos, com pausa e retomada inclusas. Menos ajustes que o HTTrack e a mesma cegueira para JavaScript, mas para um espelho limpo e rápido no macOS é a opção menos dolorida.

wget para quem gosta de terminal

wget é a opção scriptável, instalado em praticamente toda máquina Linux e a um brew install de distância no Mac. A receita clássica de espelho completo:

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent https://example.com

O que cada flag te entrega:

• --mirror ativa recursão e timestamping, então reexecuções só baixam o que mudou
• --convert-links reescreve os links depois do download para que as páginas funcionem offline
• --adjust-extension salva páginas geradas pelo servidor como arquivos.html de verdade
• --page-requisites baixa o CSS, JS e imagens que cada página precisa para renderizar
• --no-parent mantém o crawl abaixo do caminho inicial em vez de devorar o domínio inteiro

Adições que vale a pena conhecer: --wait=1 --random-wait te mantém educado em servidores pequenos, -c retoma um espelho interrompido sem rebaixar arquivos já finalizados, e --load-cookies com um arquivo de cookies exportado consegue puxar páginas atrás do seu próprio login. E não confunda wget com curl, curl busca uma única URL com elegância, wget espelha sites inteiros. As pessoas confundem os dois o tempo todo.

Salvar pelo navegador: a opção integrada

Ctrl+S, Webpage Complete, o downloader que você já tem. Ele salva uma página mais uma pasta de assets. Para um recibo, um artigo ou uma página de contato que você precisa na hora, dá conta. Ele ainda tem um superpoder genuíno: o navegador salva a página depois que o JavaScript rodou, então uma página pesada em React que entrega ao wget uma casca vazia chega totalmente renderizada.

Os limites aparecem rápido. Imagens de fundo em CSS e cadeias de @import frequentemente somem, os links apontam de volta para o site no ar em vez de uns para os outros, e não tem recursão, um site de 300 páginas significa 300 salvamentos manuais. Um truque adjacente que vale conhecer: a extensão SingleFile incorpora todos os assets em um único arquivo HTML autocontido, depois que o JavaScript roda. Para arquivar páginas individuais pesadas em JS ela ganha do Ctrl+S simples de lavada. Salvar como PDF é outra história: captura aparência, não a página, e nada dentro funciona.

Uma sessão de web downloader, do começo ao fim

O primeiro espelho de um site desconhecido flui melhor com uma rotina. A minha:

1. Verifique robots.txt e os termos do site antes de crawlar, e use uma flag de espera em servidores pequenos independentemente
2. Defina o escopo: domínio inteiro ou uma seção. Uma regra no-parent ou uma regra de varredura do HTTrack impede que o crawl de um blog engula a loja do lado
3. Rode o espelho e acompanhe o log. 403s repetidos indicam detecção de bot; uma enxurrada de páginas de calendário ou tag significa que seu escopo está vazando
4. Verifique dez páginas aleatórias offline, incluindo uma com formulário de contato e uma galeria pesada. Quebrado agora significa quebrado para sempre
5. Compare a contagem local de arquivos com o sitemap do site. Um gap grande significa conteúdo renderizado por JavaScript ou regras de escopo engolindo páginas

O que todo web downloader quebra

Escolha qualquer ferramenta acima e as mesmas coisas se desfazem, porque os problemas estão no meio, não no software:

Fique de olho também nos assets entre domínios. A maioria dos crawlers fica no host inicial por padrão, então imagens servidas a partir de um subdomínio de CDN ou fontes vindas de um host externo são ignoradas a menos que você amplie o escopo, e aí as páginas salvas chegam cheias de referências quebradas. Tem também o resíduo de SEO: tags canonical, URLs de Open Graph e links internos absolutos ainda apontam para o domínio antigo. Inofensivo em um arquivo pessoal, um problema real se o espelho voltar ao ar.

Um site baixado é uma estátua: parece exatamente certo, e nada por dentro se move.

Quando um web downloader é a ferramenta errada

O caso óbvio: o site já está offline. Um downloader precisa de um servidor no ar respondendo requisições, e um domínio expirado ou um host morto não dá nada para crawlar. A cópia sobrevivente está no Wayback Machine, e apontar wget para web.archive.org é um suplício: requisições throttled, URLs reescritas pelo archive, uma toolbar injetada em cada página e snapshots espalhados ao longo de anos.

É para isso que o Restorix existe. Ele restaura sites a partir de snapshots do archive com seleção de intervalo de datas, remove o lixo do archive e analytics antigos, e mostra a contagem exata de arquivos arquivados, o tamanho total e um preço fixo antes de você pagar qualquer coisa.

Segundo caso de ferramenta errada: você quer o conteúdo, não os pixels, artigos em uma planilha, produtos em um banco de dados. Isso é extração, não download. E terceiro: se o site precisa ter de volta seus recursos baseados em banco de dados, uma loja, um fórum, um espelho estático te dá a aparência, não a máquina. Você precisa de restauração mais um backend novo.

De arquivos a um site no ar de novo

Uma pasta de espelho não é um site. Colocá-lo no ar de novo significa hospedá-lo em algum lugar, corrigir links absolutos, remover scripts de tracking mortos e resolver o HTTPS. Dá para fazer à mão, ou pular a parte de encanamento: o Restorix faz deploy de sites restaurados direto para SSH/SFTP, FTP/FTPS ou S3, com um CMS leve incluso para que o site volte a ser editável, não apenas visualizável. De qualquer forma, teste o resultado em um celular antes de considerar pronto.