Downloading a Full WordPress Site: What the Plugins Actually Do

A WordPress site is two things: a directory of files and a MySQL database. Any tool that gives you one without the other has not downloaded your site. That single fact explains why the built-in export tool disappoints people and why migrations fail halfway.

The plugins in this space overlap heavily and market themselves differently depending on whether they are selling backup or migration. Underneath they are doing the same job with different defaults, so it is worth understanding the job before comparing the tools.

Table of contents

• What actually has to come with you
• The plugin approaches, and what each is for
• Where plugin-based downloads fail
• The method that does not break: WP-CLI and rsync
• The rule that makes any of this worthwhile
• How this fits the rest of the stack
• FAQ

What actually has to come with you

The complete picture, in the order things get forgotten:

• wp-content/uploads: every image and file ever uploaded. Usually the largest part by far.
• wp-content/themes and plugins: your theme, any child theme, and every plugin including customisations.
• The database: posts, pages, users, comments, settings, and everything plugins have stored, which is often more than you expect.
• wp-config.php: database credentials and salts. Needed for reference, but never reused verbatim on a new host.
• .htaccess or nginx rules: redirects and rewrite rules that are invisible until they are missing.

The built-in Tools, Export produces an XML file of posts, pages, and comments. It does not include your theme, your plugins, your settings, or your media files, though it does reference their URLs so an importer can attempt to fetch them from the still-running old site.

That makes it useful for moving content between two working WordPress installations and useless as a backup. If the original site is gone, the URLs resolve to nothing and the media is lost.

The second thing people miss: URLs are stored absolutely throughout the database, including inside serialised PHP strings in the options table. A naive find-and-replace corrupts those, because the serialised format records string lengths that no longer match. Every competent migration tool handles this, and a manual SQL replace does not.

The plugin approaches, and what each is for

Three shapes, and the differences matter more than the brand names.

Package-and-installer tools, of which Duplicator is the best known, bundle the files and database into an archive plus a PHP installer script. You upload both to the new host and run the installer, which recreates everything and handles the URL rewriting. This is the cleanest path for a straight move to a different host, and it also produces a genuine full copy for archival.

Scheduled backup tools, such as UpdraftPlus, focus on recurring backups to remote storage, with restore as the primary operation and migration as a paid add-on. This is what you want running continuously; it is a slightly awkward fit for a one-off move.

Export-import pairs, such as All-in-One WP Migration, produce a single file you import through a plugin on the destination. Simplest workflow of the three, and the free version imposes an upload size limit that most real sites exceed, which is where the paid extension comes in.

The selection rule, stripped of marketing: for a one-off move to a new host, use a package-and-installer tool. For ongoing protection, use a scheduled backup tool writing to storage you control. They are different jobs and using one for the other is where the friction comes from.

Where plugin-based downloads fail

All of them run inside PHP, which means all of them are subject to the same limits, and those limits are what break large sites.

• PHP max_execution_time: archiving several gigabytes takes longer than the limit and the process is killed partway, often leaving a truncated archive that looks complete.
• memory_limit: building the archive in memory fails on large media libraries.
• Upload limits on the destination: a 2GB archive cannot be uploaded through a form capped at 128MB.
• Disk space: the archive is written alongside the site, so a site using most of its quota cannot produce one.

The symptom is a process that appears to work and produces a file that fails on restore, which is the worst possible failure mode because you find out when you need it.

Above roughly two or three gigabytes, plugin-based approaches become unreliable and the answer is to stop using the browser. Which brings us to the method that always works.

The method that does not break: WP-CLI and rsync

If you have shell access, this is faster and more reliable than any plugin, and it has no size ceiling.

# 1. Export the database.
wp db export backup.sql --add-drop-table

# 2. Copy everything down, resumable and repeatable.
rsync -avz --progress \
  user@server:/var/www/html/ \
  ./site-backup/

# 3. On the destination, import and fix URLs.
wp db import backup.sql
wp search-replace 'https://old-domain.com' 'https://new-domain.com' \
  --all-tables --precise --skip-columns=guid

# Preview first.
wp search-replace 'https://old.com' 'https://new.com' --dry-run

The search-replace command is the important one. WP-CLI unserialises PHP data, replaces inside it, and re-serialises with correct lengths, which is exactly what a raw SQL replace cannot do.

Skip the guid column. Those values are permanent identifiers used by feed readers to recognise posts, not URLs to be followed, and rewriting them makes every post appear new to subscribers.

rsync is resumable, so a dropped connection mid-transfer costs you nothing. Run it again and it picks up where it stopped, which is the property plugin-based approaches lack entirely.

The rule that makes any of this worthwhile

A backup you have never restored is a hypothesis. The number of teams who discover their backup is incomplete at the moment they need it is not small, and the cause is always the same: nobody tested it.

Restore into a local environment or a staging site once, and check the specific things that go missing: uploaded images actually loading rather than showing as broken, plugin settings present rather than reset to defaults, users and their roles intact, and permalinks working rather than 404ing on every post.

That last one is the classic. Permalinks depend on rewrite rules that live outside the database, so a restore can look perfect on the home page and 404 on everything else. Re-saving the permalinks settings regenerates them.

Do the test once, note what was missing, and adjust what you capture. Then the backup is a backup.

How this fits the rest of the stack

Most of this friction comes from the download being a workaround for not having direct access to the files and the database. Managed WordPress on RunxBuild includes a file manager for browsing, uploading, downloading, and unzipping, and a database browser with SQL, export, and import, both in the dashboard, which turns most of these tasks into something you do directly rather than through a plugin. The RunxBuild hosting calculator shows what a WordPress plan costs from $3 a month.

Useful related references:

• How to Duplicate a Page in WordPress, With and Without a Plugin
• CSS Animations in WordPress Without a Plugin or a Performance Hit
• A WordPress Plugin Stopped Working: The Debug Order That Finds It
• Services on RunxBuild

FAQ

Does the WordPress export tool download my whole site?

No. Tools, Export produces an XML file of posts, pages, and comments only. It excludes themes, plugins, settings, and media files, so it is useful for moving content between two live installations and not usable as a backup.

What is the best plugin to download a WordPress site?

For a one-off move to a new host, a package-and-installer tool such as Duplicator produces files, database, and an installer that rewrites URLs. For ongoing protection, a scheduled backup tool writing to remote storage is the better fit.

Why does my backup plugin time out on a large site?

It runs inside PHP and hits max_execution_time or memory_limit while building the archive. Above two or three gigabytes, use WP-CLI and rsync over SSH instead, which have no such ceiling and are resumable.

How do I change site URLs after moving WordPress?

Use wp search-replace, which unserialises PHP data before replacing so serialised strings stay valid. Skip the guid column, since those are permanent post identifiers rather than URLs and rewriting them breaks feed readers.

Why do all my posts 404 after restoring a backup?

Rewrite rules live outside the database, in .htaccess or the server configuration. Re-save the permalinks settings in the admin to regenerate them, and the posts will resolve again.