Strumenti di Web Downloader a confronto: cosa salvano e cosa rompono

Un provider di hosting è sparito nel weekend lasciando a piedi un cliente. Nessun backup, ovviamente. Il lunedì mattina il sito rispondeva ancora, a malapena, e la prima cosa che ho fatto è stata puntarci un web downloader per scaricare ogni pagina raggiungibile prima che la corrente si staccasse per sempre. Ecco a cosa servono questi strumenti: prendere ciò che un server ti concede ancora, in fretta, prima che smetta di concedere.

Un web downloader non fa magie, però, e i quattro strumenti a cui la gente ricorre davvero, HTTrack, SiteSucker, wget e il pulsante Salva del browser, differiscono nettamente in ciò che conservano. Ecco cosa salva ciascuno, cosa rompe silenziosamente e come scegliere tra loro.

Cosa salva davvero un web downloader

Ogni web downloader funziona allo stesso modo, sotto il cofano. Richiede un URL, analizza l'HTML che torna, trova le risorse collegate e i link interni, li scarica, riscrive i link perché funzionino dal tuo disco e continua finché la coda non è vuota. Un crawler con un pulsante Salva.

Cosa arriva sul tuo disco:

• Pagine HTML, di solito rinominate per aprirsi in locale senza un server
• CSS, JavaScript e font richiamati da quelle pagine
• Immagini, video, PDF e qualsiasi altra cosa a cui le pagine linkano direttamente
• Una struttura di cartelle che rispecchia la disposizione degli URL originali

Cosa non arriva: tutto ciò che il server genera al volo. Il downloader riceve lo stesso HTML renderizzato che riceve un visitatore anonimo. Il PHP, il database, il pannello di amministrazione, lo storico degli ordini, niente di tutto ciò viaggia sulla rete, quindi niente di tutto ciò torna a casa. Un sito WordPress scaricato è una statua del sito, non il sito.

Due dettagli di perimetro decidono il risultato finale. Primo, la scoperta: un crawler trova solo gli URL linkati dalle pagine che ha già, più la sitemap se gliela fornisci, le pagine orfane senza link in ingresso restano invisibili. Secondo, la cortesia: la maggior parte degli strumenti rispetta robots.txt di default, e sebbene HTTrack ti permetta di sovrascriverlo, dovresti farlo solo su siti di tua proprietà.

HTTrack e SiteSucker: le opzioni con interfaccia grafica

HTTrack (WinHTTrack su Windows) è il nonno della categoria: gratuito, open source e in giro dal 1998. Incolli un URL, scegli una cartella di progetto e lui crea il mirror del sito. Il vero valore sta nelle opzioni, limiti di profondità di crawling, filtri per tipo di file, tetti di banda e regole di scansione che includono o escludono pattern di URL. Ho creato il mirror di un portfolio da 400 pagine di un fotografo in circa venti minuti, immagini comprese.

Impostazioni che effettivamente cambio rispetto ai default:

• Profondità massima di mirroring: lasciala illimitata per siti piccoli, limitata a 3 o 4 per quelli grandi
• Regole di scansione: aggiungi un pattern di inclusione per il dominio target così il crawl non può andarsene in giro
• Controllo di flusso: due o quattro connessioni e un limite di banda su tutto ciò che non è il tuo server
• Tipi MIME: escludi i video nei primi passaggi, una cartella di webinar dimenticata può pesare 40 GB

Le insidie: l'interfaccia mostra la sua età, l'ultima release significativa risale a anni fa, ed è cieco a JavaScript. Se una pagina costruisce il suo contenuto nel browser, HTTrack salva l'impalcatura vuota.

SiteSucker è la risposta per Mac, pochi dollari sull'App Store. Incolli un URL, premi go e scarica in background con default sensati, pausa e ripresa inclusi. Meno manopole di HTTrack e la stessa cecità per JavaScript, ma per un mirror rapido e pulito su macOS è l'opzione meno dolorosa.

wget per chi ama il terminale

wget è l'opzione scriptabile, installato su quasi ogni box Linux e a un brew install di distanza su Mac. La classica ricetta per il mirror completo:

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

Cosa ti offre ciascun flag:

• --mirror attiva la ricorsione e il timestamping, così le esecuzioni successive scaricano solo ciò che è cambiato
• --convert-links riscrive i link dopo il download così le pagine funzionano offline
• --adjust-extension salva le pagine generate dal server come file.html veri e propri
• --page-requisites prende CSS, JS e immagini necessari a renderizzare ogni pagina
• --no-parent mantiene il crawl sotto il percorso di partenza invece di divorarsi l'intero dominio

Aggiunte da conoscere: --wait=1 --random-wait ti tiene cortese sui server piccoli, -c riprende un mirror interrotto senza riscaricare i file finiti, e --load-cookies con un file di cookie esportato può tirare giù pagine protette dal tuo login. E non confondere wget con curl, curl recupera un URL in modo splendido, wget crea il mirror di interi siti. La gente li confonde di continuo.

Salvataggio del browser: l'opzione integrata

Ctrl+S, Pagina Web Completa, il downloader che hai già. Salva una pagina più una cartella di risorse. Per una ricevuta, un articolo o una pagina dei contatti che ti servono subito, va bene. Ha anche un vero superpotere: il browser salva la pagina dopo che JavaScript è stato eseguito, quindi una pagina piena di React che a wget restituisce un guscio vuoto arriva completamente renderizzata.

I limiti emergono subito. Le immagini di sfondo CSS e le catene @import spesso mancano, i link puntano di nuovo al sito live invece che tra loro, e non c'è ricorsione, un sito da 300 pagine significa 300 salvataggi manuali. Un trucco correlato da conoscere: l'estensione SingleFile incorpora ogni risorsa in un unico file HTML autosufficiente, dopo l'esecuzione di JavaScript. Per archiviare singole pagine ricche di JS batte nettamente il semplice Ctrl+S. Salva come PDF è un'altra bestia: cattura l'aspetto, non la pagina, e niente al suo interno funziona.

Una sessione di web downloader, dall'inizio alla fine

Il primo mirror di un sito sconosciuto fila meglio con una routine. La mia:

1. Controlla robots.txt e i termini del sito prima di fare crawling, e usa un flag di attesa sui server piccoli comunque.
2. Scegli il perimetro: intero dominio o una sezione. Una regola no-parent o una regola di scansione HTTrack impedisce al crawl di un blog di inghiottire il negozio accanto.
3. Lancia il mirror e osserva il log. 403 ripetuti indicano rilevamento bot; una marea di pagine calendario o tag significa che il perimetro perde colpi.
4. Controlla a campione dieci pagine casuali offline, inclusa una con un modulo di contatto e una galleria pesante. Rotto ora significa rotto per sempre.
5. Confronta il numero di file locali con la sitemap del sito. Un divario grande indica contenuto renderizzato da JavaScript o regole di perimetro che divorano pagine.

Cosa rompe ogni web downloader

Scegli uno qualsiasi degli strumenti sopra e le stesse cose vanno in pezzi, perché i problemi stanno nel mezzo, non nel software:

Occhio anche alle risorse cross-domain. La maggior parte dei crawler rimane sull'host di partenza di default, quindi le immagini servite da un sottodominio CDN o i font provenienti da un host esterno vengono saltati a meno che non allarghi il perimetro, e allora le pagine salvate tornano a casa piene di riferimenti rotti. C'è anche il residuo SEO: tag canonical, URL Open Graph e link interni assoluti che puntano ancora al vecchio dominio. Innocuo in un archivio personale, un problema vero se il mirror torna online.

Un sito scaricato è una statua: sembra esattamente giusto, e niente dentro si muove.

Quando un web downloader è lo strumento sbagliato

Il caso ovvio: il sito è già offline. Un downloader ha bisogno di un server attivo che risponda alle richieste, e un dominio scaduto o un host morto non gli danno nulla da crawlare. La copia sopravvissuta sta nella Wayback Machine invece, e puntare wget su web.archive.org è un calvario: richieste rallentate, URL riscritti dall'archivio, una toolbar iniettata in ogni pagina e snapshot sparsi lungo anni.

È il lavoro per cui esiste il nostro servizio di ripristino. Ripristina siti da snapshot d'archivio con selezione dell'intervallo di date, elimina il materiale di scarto dell'archivio e le vecchie analytics, e mostra il conteggio esatto dei file archiviati, la dimensione totale e un prezzo bloccato prima di qualsiasi pagamento.

Secondo caso di strumento sbagliato: vuoi il contenuto, non i pixel, articoli in un foglio di calcolo, prodotti in un database. Quella è estrazione, non download. E terzo: se il sito deve riavere le sue funzionalità basate su database, un negozio, un forum, un mirror statico ti dà l'aspetto, non la macchina. Ti serve il ripristino più un backend nuovo.

Da file di nuovo a un sito live

Una cartella di mirror non è un sito web. Rimetterlo online significa ospitarlo da qualche parte, correggere i link assoluti, rimuovere gli script di tracking morti e sistemare HTTPS. Fattibile a mano, oppure salta la fatica: Restorix distribuisce i siti ripristinati direttamente su SSH/SFTP, FTP/FTPS o S3, con un CMS leggero incluso così il sito torna modificabile, non solo visualizzabile. In entrambi i casi, testa il risultato su un telefono prima di dichiararlo finito.