I am trying to mirror a fairly large site (20,000+ pages) prior to a major overhaul. Basically, I need a backup before cutting over to the new one in case we forgot something we need (we'll have about 1,000 pages at launch). The site is run on a CMS that I cannot easily extract usable data from, so I'm trying to make the copy with wget.

My problem is that wget does not appear to be actually converting links, despite the presence of --convert-links or -k in the command. I've tried a couple of different combinations of flags, but I haven't been able to get the output I need. Most recent failed attempt was:

nohup wget --mirror -k -l10 -PafscSnapshot --html-extension -R *calendar* -o wget.log http://www.example.org &

I've also included the --backup-converted, and --convert-links instead of -k (not that it have mattered). I've done it with and without -P and -l, again no that they should matter.

Results in files that still have links like:

  • Do the URLs really have a double-slash // after the hostname? I wonder if that's throwing off wget's parser... – coneslayer Apr 15 '10 at 17:11
  • Some do (did I mention I'm getting rid of the existing service), some don't. I grabbed a random example which happened to, but not all do. I'll update the question, since I most do not. – acrosman Apr 15 '10 at 18:33

This is an old post, but I'm putting the answer here for future searchers.

The --convert-links feature happens only after the site download is complete. I would guess that, with such a large site, you tried to stop the process after a few pages were completed and therefore the process hadn't kicked off yet.

See also https://stackoverflow.com/questions/6348289/download-a-working-local-copy-of-a-webpage

From the wget docs

After the download is complete, convert the links in the document to make them suitable for local viewing. This affects not only the visible hyperlinks, but any part of the document that links to external content, such as embedded images, links to style sheets, hyperlinks to non-html content, etc.

Each link will be changed in one of the two ways:

    The links to files that have been downloaded by Wget will be changed to refer to the file they point to as a relative link.

    Example: if the downloaded file /foo/doc.html links to /bar/img.gif, also downloaded, then the link in doc.html will be modified to point to ‘../bar/img.gif’. This kind of transformation works reliably for arbitrary combinations of directories.
    The links to files that have not been downloaded by Wget will be changed to include host name and absolute path of the location they point to.

    Example: if the downloaded file /foo/doc.html links to /bar/img.gif (or to ../bar/img.gif), then the link in doc.html will be modified to point to http://hostname/bar/img.gif. 

Because of this, local browsing works reliably: if a linked file was downloaded, the link will refer to its local name; if it was not downloaded, the link will refer to its full Internet address rather than presenting a broken link. The fact that the former links are converted to relative links ensures that you can move the downloaded hierarchy to another directory.

Note that only at the end of the download can Wget know which links have been downloaded. Because of that, the work done by ‘-k’ will be performed at the end of all the downloads. 

Maybe you've run into wget -k converts files differently on Windows & Linux due to OS filename restrictions?


I have the same with a 6Gig site I'm trying to backup. After a few days, wget finishes, without an error message, and exit status 0, but without converting the links. Doing a smaller retrieval with the same options works fine. It's as if an internal table of whats been downloaded gets washed or corrupted before wget ends.

I'm going to try refetching the site with -nc (which shouldnt refetch anything, because it's already been downloaded, and finish off with converting the links - see Make wget convert HTML links to relative after download if -k wasn't specified )

  • .. but that didnt work. -nc was clobbering because of the -E option (even with -K on). – commonpike Dec 18 '10 at 15:38
  • I tried a similar thing, and wget rejected the combination of -nc and -k (apparently since wget 1.13, see savannah.gnu.org/bugs/?31781). – Matthijs Kooijman Jul 25 at 13:29

-k is ignored if you also have -o as per manual:

Note that a combination with ‘-k’ is only permitted when downloading a single document, as in that case it will just convert all relative URIs to external ones; ‘-k’ makes no sense for multiple URIs when they’re all being downloaded to a single file; ‘-k’ can be used only when the output is a regular file.

  • Did you mean -O (redirect content) rather than -o (redirect wget progress output)? The OP used the latter, which should not affect -k AFAICS (just combined them successfully with wget 1.20). – Matthijs Kooijman Jul 25 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.