HTTrack's git checkout has no configure script until bootstrap runs

A checkout has no configure script until bootstrap runs

The source build has one wrinkle that catches people: a git checkout ships only the autotools sources, so `configure` does not exist yet. `./bootstrap` regenerates it, and that step runs `autoreconf`, which is why autoconf, automake and libtool have to be installed before anything else. A released tarball already contains `configure`, so building from a tarball skips `./bootstrap` entirely. The full sequence from a checkout is:

git clone https://github.com/xroche/httrack.git --recurse-submodules
cd httrack
./bootstrap
./configure --prefix=$HOME/usr && make -j8 && make install

There is also a one shot wrapper that does bootstrap, configure and make in a single call and forwards its arguments to configure:

./build.sh --prefix=$HOME/usr

The flag in both examples is the install prefix, and passing it to configure rather than to make install is what decides where the binaries land. The clone is marked `--recurse-submodules`, so a checkout without it is not the tree these instructions assume.

The mirror is a directory tree, not one file

HTTrack is described as an offline browser utility. You give it a site on the internet and it downloads that site to a local directory, building the directory structure recursively as it goes, pulling html, images and other files from the server onto your computer. The part that makes the result usable is the link handling: HTTrack rearranges the original site's relative link structure, so opening any page of the mirrored site in your browser lets you move from link to link as if you were online. Nothing is repackaged into a single archive. What you end up with is a browsable copy on disk, which is also why the tool can act on that copy later. The main site for the project is httrack.com, and this repository is the official development repository rather than a mirror of somebody else's tree.

Updating and resuming are the same tool

Two capabilities beyond the first copy are called out. HTTrack can update an existing mirrored site, so re-running it against a site you already have is a refresh rather than a second full download. It can resume interrupted downloads, so a copy that stopped halfway is continued instead of restarted. The page adds that HTTrack is fully configurable and has an integrated help system. Both of those claims point at the same gap: the help system lives inside the tool, and the page does not reproduce any of it. No option name, no flag, no configuration file format and no example command line appear anywhere on this page. For a reader deciding whether HTTrack can do a specific job, such as limiting depth, skipping a path, or handling a site behind a login, the README is not where the answer is.

Four front ends sit on one command line

The same engine is presented four ways. WinHTTrack is the Windows front end. WebHTTrack covers Linux, BSD and macOS, and on those systems it also arrives through `brew install httrack` and in the release DMG. An Android app is published on Google Play. Underneath all of them sits the `httrack` command line, which is the layer the rest of this repository builds. The page does not say whether every front end can reach every option. It also means four different acquisition routes with four different upgrade stories, and only the source tree is documented here. The licensing is GPL-3.0, with COPYING, license.txt and a French translation of the licence text at the top level.

Releases arrive as 3.50.x patch builds

The release cadence is visible in the tags. Version 3.51.0 was published on 2026-10-28, 3.50.5 on 2026-10-02, and 3.50.4 on 2026-09-24, so three releases in about five weeks. The last push to the default branch, master, was on 2026-10-31. Nothing on the page announces a release policy or a support window for older versions, so what a 3.50.x number tells you is the patch level and nothing about long term maintenance. For anyone who mirrors a site on a schedule, the useful detail is simply that patch releases are frequent and that the tarball for a given tag is the artefact that skips `./bootstrap`. ChangeLog, NEWS and history.txt sit at the top level next to README.md, so the change record is in files rather than in release notes on the page.

Translations, templates and a fuzz directory

The tree shows more of the project's shape than the page does. Interface text lives in lang/ next to lang.def and lang.indexes, so the translation set is part of the source tree rather than a separate download. templates/ holds the file templates used when building a mirrored site, and the documentation is spread across doc/, man/, html/ and a top level httrack-doc.html. Tests live in tests/ with libtest/ alongside them, and there is a fuzz/ directory, which is where fuzzing targets would be kept. Packaging for Debian and Ubuntu is in-tree as debian/, which is where to look if you are packaging rather than just building. Contributor process files are present too: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md and PACKAGING.md. What none of this tells you is how to run any of it, since the page has no test instructions and no mention of the fuzzing harnesses.

The page names no option, no limit and no policy

It is worth being blunt about what the README does not contain. There is no configuration file format, even though configurability is one of the stated features. There is no statement about robots.txt, about crawl depth, about how many parallel connections are opened, or about what happens to a page whose content is produced by a script rather than served as a file. There is no mention of authenticated sites, of pages behind a redirect chain, or of any limit on how much of a site will be copied. The build instructions are complete enough to compile from source, and the mirror behaviour is described accurately in outline, so the gap is entirely in the operating surface. Plan on reading the built in help before promising anyone a specific mirroring behaviour.

Editorial conclusion

HTTrack fits someone archiving a site they control or need to read offline, and someone who wants the same tool to update that mirror later or resume a download that stopped. It does not fit a user who needs an option reference, a configuration file format or a stated crawling policy, because the page documents none of those and points at the integrated help system instead. Before you point it at a site, decide whether you hold the release tarball or a git checkout, because only the checkout needs ./bootstrap plus autoconf, automake and libtool, and remember that Linux, BSD and macOS users can take brew install httrack or the release DMG while Windows and Android users get a front end or an app instead.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. xroche/httrack on GitHub