Herramientas de descarga web comparadas: lo que guardan y lo que rompen

Un proveedor de hosting dejó tirado a un cliente un fin de semana. Sin copias de seguridad, claro. El sitio seguía respondiendo el lunes por la mañana, a duras penas, y lo primero que hice fue apuntarle un descargador web para sacar todas las páginas accesibles antes de que se apagara para siempre. Para eso sirven estas herramientas: para atrapar lo que un servidor todavía te dé, rápido, antes de que deje de dártelo.

Pero un descargador web no es magia, y las cuatro herramientas que la gente suele usar de verdad, HTTrack, SiteSucker, wget y el propio botón Guardar del navegador, difieren mucho en lo que conservan. Aquí verás qué guarda cada una, qué rompe sin que lo notes y cómo elegir entre ellas.

Qué guarda realmente un descargador web

Todos los descargadores web funcionan igual por dentro. Piden una URL, analizan el HTML que vuelve, encuentran los recursos enlazados y los enlaces internos, los descargan, reescriben los enlaces para que funcionen desde tu disco y siguen hasta vaciar la cola. Un crawler con botón de guardar.

Qué acaba en tu disco:

• Páginas HTML, normalmente renombradas para que se abran en local sin servidor
• CSS, JavaScript y fuentes que referencian esas páginas
• Imágenes, vídeos, PDF y cualquier otro archivo al que las páginas enlacen directamente
• Una estructura de carpetas que refleja el esquema de URL original

Lo que no llega: todo lo que el servidor genera en el momento. El descargador recibe el mismo HTML renderizado que cualquier visitante anónimo. El PHP, la base de datos, el panel de administración, el historial de pedidos, nada de eso viaja por la red, así que nada de eso vuelve a casa. Un sitio de WordPress descargado es una estatua del sitio, no el sitio.

Dos detalles del alcance determinan lo que terminas teniendo. Primero, el descubrimiento: un crawler solo encuentra URLs enlazadas desde páginas que ya tiene, más el sitemap si se lo pasas, las páginas huérfanas sin enlaces entrantes siguen siendo invisibles. Segundo, la cortesía: la mayoría de las herramientas respetan robots.txt por defecto, y aunque HTTrack te permite saltártelo, solo deberías hacerlo en sitios que sean tuyos.

HTTrack y SiteSucker: las opciones con interfaz gráfica

HTTrack (WinHTTrack en Windows) es el abuelo de la categoría: gratis, de código abierto y con nosotros desde 1998. Pegas una URL, eliges una carpeta de proyecto y replica el sitio. El verdadero valor está en las opciones: límites de profundidad de rastreo, filtros por tipo de archivo, topes de ancho de banda y reglas de escaneo que incluyen o excluyen patrones de URL. Repliqué el portfolio de un fotógrafo de 400 páginas en unos veinte minutos, con todas las imágenes.

Ajustes que realmente cambio respecto a los valores por defecto:

• Profundidad máxima de réplica: sin límite en sitios pequeños, tope de 3 o 4 en los grandes
• Reglas de escaneo: añade un patrón de inclusión para el dominio objetivo para que el rastreo no se vaya a otros sitios
• Control de flujo: de dos a cuatro conexiones y límite de ancho de banda en cualquier servidor que no sea el tuyo
• Tipos MIME: excluye los vídeos en las primeras pasadas, una carpeta de webinars olvidada puede ocupar 40 GB

Los contras: la interfaz se nota su edad, la última versión importante salió hace años y no entiende JavaScript. Si una página construye su contenido en el navegador, HTTrack guarda el andamio vacío.

SiteSucker es la respuesta para Mac, unos pocos dólares en la App Store. Pegas una URL, le das a iniciar y descarga en segundo plano con valores por defecto razonables, pausa y reanudación incluidas. Tiene menos ajustes que HTTrack y la misma ceguera frente a JavaScript, pero para una réplica rápida y limpia en macOS es la opción menos dolorosa.

wget para quienes prefieren la terminal

wget es la opción guionizable, instalada en casi cualquier Linux y a un brew install de distancia en un Mac. La receta clásica para una réplica completa:

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

Qué te aporta cada flag:

• --mirror activa la recursión y el control de fechas, así que las reejecuciones solo traen lo que cambió
• --convert-links reescribe los enlaces después de la descarga para que las páginas funcionen sin conexión
• --adjust-extension guarda las páginas generadas por el servidor como archivos.html correctos
• --page-requisites descarga el CSS, JS e imágenes que cada página necesita para renderizarse
• --no-parent mantiene el rastreo por debajo de la ruta inicial en lugar de tragarse todo el dominio

Complementos que conviene conocer: --wait=1 --random-wait te mantiene educado en servidores pequeños, -c reanuda una réplica interrumpida sin volver a descargar los archivos terminados, y --load-cookies con un archivo de cookies exportado puede sacar páginas protegidas por tu propio login. Y no confundas wget con curl: curl descarga una URL de maravilla, wget replica sitios enteros. La gente los mezcla constantemente.

Guardar del navegador: la opción que ya tienes

Ctrl+S, Página web completa: el descargador que ya tienes. Guarda una página más una carpeta de recursos. Para un recibo, un artículo o una página de contacto que necesitas ahora mismo, va bien. Incluso tiene un auténtico superpoder: el navegador guarda la página después de que JavaScript se haya ejecutado, así que una página cargada de React que a wget le da una cáscara vacía sale completamente renderizada.

Los límites se notan rápido. Las imágenes de fondo en CSS y las cadenas de @import suelen faltar, los enlaces apuntan de vuelta al sitio en vivo en lugar de unos a otros, y no hay recursión: un sitio de 300 páginas significa 300 guardados manuales. Un truco cercano que conviene conocer: la extensión SingleFile integra todos los recursos en un único archivo HTML autocontenido, después de que JavaScript se ejecute. Para archivar páginas individuales con mucho JS supera limpiamente al simple Ctrl+S. Guardar como PDF es otra historia: captura la apariencia, no la página, y nada dentro funciona.

Una sesión de descarga web, de principio a fin

La primera réplica de un sitio desconocido va mejor con una rutina. La mía:

1. Revisa robots.txt y los términos del sitio antes de rastrear, y usa un flag de espera en servidores pequeños de todos modos.
2. Elige el alcance: todo el dominio o solo una sección. Una regla no-parent o una regla de escaneo de HTTrack evita que un rastreo del blog se trague la tienda de al lado.
3. Ejecuta la réplica y vigila el log. 403s repetidos significan detección de bots; un aluvión de páginas de calendario o tags significa que tu alcance se está escapando.
4. Verifica al azar diez páginas sin conexión, incluyendo una con formulario de contacto y una galería pesada. Roto ahora significa roto para siempre.
5. Compara el número de archivos locales con el sitemap del sitio. Una gran diferencia significa contenido renderizado por JavaScript o reglas de alcance que se comen páginas.

Lo que rompe cualquier descargador web

Elijas la herramienta que elijas, se rompen las mismas cosas, porque los problemas están en el medio, no en el software:

Vigila también los recursos de otros dominios. La mayoría de los crawlers se quedan en el host inicial por defecto, así que las imágenes servidas desde un subdominio de CDN o las fuentes de un host externo se saltan, a menos que amplíes el alcance, y entonces las páginas guardadas llegan a casa llenas de referencias rotas. También está el residuo SEO: las etiquetas canonical, las URLs de Open Graph y los enlaces internos absolutos siguen apuntando al dominio antiguo. Inofensivo en un archivo personal, un problema real si la réplica vuelve a estar en línea.

Un sitio descargado es una estatua: se ve exactamente bien, y nada dentro se mueve.

Cuándo un descargador web no es la herramienta adecuada

El caso obvio: el sitio ya está caído. Un descargador necesita un servidor en vivo que responda peticiones, y un dominio caducado o un host muerto no le da nada que rastrear. La copia superviviente está en la Wayback Machine, y apuntar wget a web.archive.org es un infierno: peticiones limitadas, URLs reescritas por el archivo, una barra de herramientas inyectada en cada página y snapshots desperdigados a lo largo de años.

Para eso existe nuestra plataforma. Restaura sitios a partir de snapshots de archivo con selección de rango de fechas, elimina la morralla del archivo y las analíticas antiguas, y muestra el número exacto de archivos archivados, el tamaño total y un precio cerrado antes de que pagues nada.

Segundo caso de herramienta equivocada: quieres el contenido, no los píxeles, artículos a una hoja de cálculo, productos a una base de datos. Eso es extracción, no descarga. Y tercero: si el sitio necesita recuperar sus funcionalidades basadas en base de datos, una tienda, un foro, una réplica estática te da el aspecto, no la máquina. Necesitas restauración más un backend nuevo.

De archivos a un sitio en vivo otra vez

Una carpeta de réplica no es un sitio web. Volver a ponerlo en línea implica alojarlo en algún sitio, corregir los enlaces absolutos, eliminar scripts de tracking muertos y resolver HTTPS. Se puede hacer a mano, o saltarte la fontanería: Restorix despliega los sitios restaurados directamente a SSH/SFTP, FTP/FTPS o S3, con un CMS ligero incluido para que el sitio vuelva a ser editable, no solo visualizable. De cualquier forma, prueba el resultado en un móvil antes de darlo por bueno.