No staging? No problem: running a live WordPress site locally

Think of a bakery.

• Production is the shop counter: the real site at example-bakery.com that real customers use. Whatever happens here, customers see it.
• Staging is the back kitchen: a private copy on a server where you can test a recipe before it goes on the counter. Customers never see it. Our client doesn't have one.
• Local is your kitchen at home: a copy running only on your own computer. Nobody else can see it, and it doesn't need the internet to work.

You never test new recipes on the shop counter. That's the whole rule.

Because "careful" doesn't stop surprises. A plugin update can clash with the theme, a typo in one PHP file can take down the whole site, and some actions, like sending emails or taking payments, can't be undone. On a local copy, the worst case is you delete it and start again.

A WordPress site is two things in a trench coat

1. Files: the wp-content folder, which holds your theme (how it looks), plugins (extra features) and uploads (images). WordPress's own core files can be re-downloaded any time, so they don't matter as much.
2. The database: a big organised spreadsheet holding every post, page, setting, user and order. It's usually exported as a single .sql file.

Every method in this post is just a different way of carrying those two things from the server to your computer.

A way to boss WordPress around by typing commands instead of clicking through the dashboard. wp plugin list asks "what plugins are installed?"; wp search-replace finds and swaps text across the whole database. Local's site shell has it ready to use.

An API is a door that lets one program talk to another. Turning on API access in WP Engine unlocks a door so Local can ask, "Can I please have a copy of this site?" on your behalf.

wp-config.php stays behind

Local Connect always leaves out wp-config.php (plus wp-admin, wp-includes, .git and node_modules). That's on purpose: the live config has the live server's settings. If you edit your local wp-config.php (and you will, see the gotchas below), those edits stay local. Pull and push exclusions live in .wpe-pull-ignore and .wpe-push-ignore in the site's app/public folder. Local Connect also doesn't support multisite installs.

WordPress stores some settings in a packed-up format that remembers how long each piece of text is. If you swap example-bakery.com (17 letters) for example-bakery.local (20 letters) by hand, the "length" labels are now wrong and WordPress quietly throws those settings away. wp search-replace unpacks, swaps and re-packs them properly.

All-in-One WP Migration packs the whole site (files and database) into one file ending in .wpress. It's like a moving box only that plugin knows how to unpack, so you need the same plugin on both ends.

Installing and activating a plugin on production is touching production. Check with your PM or the client first, make sure your step-zero backup exists, and plan to remove the plugin (and the export file) afterwards.

The free plugin itself doesn't cap imports. The limit shown on the Import screen comes from the server's PHP upload settings, which here means your local server. On Local you control those, so you can raise them for this one site. Uploads that bypass those server limits are a feature of the paid Unlimited Extension. Older tutorials mention a fixed 512MB free limit or editing a plugin constant; that's outdated.

In Local, PHP settings live in a template file. Open the site's folder (Go to site folder) and edit:

upload_max_filesize = 1024M
post_max_size = 1024M
memory_limit = 512M
max_execution_time = 300

Then stop and start the site in Local so it picks up the change.

If production runs PHP 8.1 and your local site runs PHP 8.3, you might see bugs that don't exist live, or miss the one you're hunting. Check production under Tools → Site Health → Info (look under WordPress and Server), then set the same PHP version on the local site's Overview page in Local. Don't click Local's WordPress Update button unless production is updated too. Match what's live.

If a search-replace was missed or only half-worked, clicking a link takes you to the live site, and you might not notice you're now editing production. Watch the address bar. Run the --dry-run check above. Look for hard-coded URLs in theme files, page-builder data and wp-config.php too.

The database is full of real customer email addresses. Trigger an order or a password reset and WordPress tries to email them. Local helps: it routes WordPress mail into Mailpit, a fake inbox (Tools → Mailpit → Open Mailpit), so it never leaves your computer. But if the site uses an SMTP or email-service plugin (one that sends through a mail service's API or SMTP login instead of PHP's normal mail), that can skip Mailpit and send real emails. Deactivate those plugins locally, or switch them to a test/log-only mode.

Payment gateways (Stripe, PayPal…), CRMs, shipping services and analytics/Tag Manager all came across with their live settings. Locally:

• Put payment plugins into test/sandbox mode, or deactivate them.
• Deactivate or disconnect plugins that sync to outside services (newsletters, CRMs, inventory).
• Turn off analytics/Google Tag Manager, or your clicking around shows up in the client's reports.
• Remember DISABLE_WP_CRON from earlier: scheduled tasks (subscription renewals, scheduled emails, syncs) would otherwise run as you browse.

Caching plugins can serve old pages or point to files that only exist on the live server. Security plugins can lock you out, block your local domain, or force HTTPS. Firewalls and login limiters are common culprits. If the site behaves strangely, deactivate caching and security plugins first (locally only), and clear any cache folders inside wp-content.

A site with years of uploads can be tens of gigabytes. Check your disk space before you start. If you only need the code and database, a partial pull (Method A's Select files) or a Partial Backup ZIP without Media uploads is much faster. Images will show as broken, which is fine for most bugs.

Orders, names, addresses, emails: production data is real people's data. Treat the copy like it's confidential, because it is.

• Don't share screenshots that show customer details. Blur them or use your own test orders.
• Don't upload the backup or .wpress file to personal cloud drives, chat apps or tickets.
• When the ticket is done, delete the local site (right-click → Delete in Local) and delete the downloaded .zip/.wpress files and any unzipped folders, including from your Downloads folder and trash.

• Make the backup before you're curious, not after something's gone wrong.
• Lock down email, payments and cron in your local copy before you click anything.
• If you can't reproduce the bug locally, compare versions and plugins before assuming the copy is wrong.
• Write down exactly which method and settings you used. Part 2 is much easier when you know how the copy was made.