Blog

A WordPress staging site lets you test changes on a private copy before editing the live site. You can update plugins, change themes, or rebuild comparison pages without putting working affiliate pages at unnecessary risk.

Setup is straightforward, but pushing changes live needs care. You don’t want yesterday’s staging database replacing today’s new posts, leads, or customer records.

Start with the simplest method your hosting setup supports, then protect, test, and deploy that copy properly.

Choose Your WordPress Staging Site Method

A WordPress staging site starts as an exact copy of your live site’s files and database. You use it to test theme updates, plugin changes, custom code, and redesigns.

There are three practical routes:

My advice is to start with your hosting provider’s tool when it’s included. There’s no benefit in creating extra work.

If you’re choosing hosting, my guide to budget hosting for affiliate websites covers backups, support, and costs beyond the introductory offer.

Back Up and Protect Your Staging Copy

Save more than your posts

Before cloning anything, create a full backup containing your database and website files. Keep an independent copy outside the hosting account, and know how you’ll restore it.

Export your affiliate links and settings from Pretty Links or ThirstyAffiliates if you use them.

Keep a simple spreadsheet recording each important page, button text, branded redirect, final destination, affiliate ID, and sub-ID. Add the last-tested date. This gives you something concrete to compare after the changes.

A staging copy doesn’t replace a recoverable backup.

Keep visitors and search engines out

Password-protect staging through your hosting controls. Then enable Settings > Reading > Discourage search engines from indexing this site, or apply a sitewide noindex directive.

That setting discourages indexing; it doesn’t make the site private. A robots.txt crawl block alone also doesn’t guarantee that a URL stays out of search results.

Disable customer emails, scheduled promotional sends, live payment connections, and external automations. Use test credentials where available. Otherwise, your copied site could still contact real subscribers.

Set Up Staging Through Your Hosting Provider

WordPress.com: Create the managed copy

WordPress.com’s staging instructions cover Business and Commerce plans. Free, Personal, and Premium sites need an upgrade to access this feature.

Open your site’s hosting settings, find the staging controls, and create the copy. Once cloning finishes, open its separate dashboard before making changes.

The staging address prepends staging- plus four random characters to the production address. That random string changes whenever you recreate staging.

WordPress.com blocks search engines from indexing staging by default. A custom robots.txt file in the root folder can override that behavior, so don’t copy one across without understanding its rules.

WP Engine: Copy production into staging

In WP Engine’s User Portal, open your site and create or select its staging environment. Copy production into staging, paying attention to the source and destination.

Its environment-copying controls use Push to and Pull from, with Full and Custom copy options.

Now, log into the staging dashboard and confirm your latest posts, images, plugins, and affiliate layouts are present. Give the environment an obvious label so you don’t confuse it with production.

Other hosts follow a similar pattern, but button names and copying options vary.

Create a Copy With WP Staging

The WP STAGING plugin can clone your site’s files and database without a built-in hosting tool. Cloning is free, but pushing changes back to live requires a paid upgrade.

Here’s the basic process:

1. Install and activate WP STAGING through your live WordPress dashboard.
2. Open its staging controls, start a new clone, and give it a clear name.
3. Review the included files and database tables, then start cloning.
4. Open the completed staging site and confirm you’re editing the clone before making changes.

Make sure your hosting account has space for the additional files and database. Large image libraries can make the copy much bigger than expected.

For a small update, the free version can be enough. Test the change, then repeat the successful update on the live site after taking another backup. That avoids paying for deployment features you don’t need.

Use Manual Staging or Local When Needed

Manual setup on your hosting account

Create a staging subdomain and a separate database. Create a restricted FTP account, then copy your WordPress files into the staging folder.

Import the production database into the new database, then update the staging wp-config.php with the new credentials. Reopen wp-config.php to confirm the settings match.

Enable HTTPS and password protection. Select the WordPress “Discourage search engines” setting and confirm a noindex rule is present before testing. This copy is still technically online.

This route can work on cPanel hosting without changing providers. However, deployment needs more care. Elementor’s staging guide warns that manual deployment can temporarily interrupt the live site. It also flags privacy concerns around plugin-based staging. Protect copied subscriber and customer data.

Local: Work on your computer

Local by Flywheel, now called Local, runs WordPress on your computer rather than on a public server. Older tutorials may still use the name Local by Flywheel for the same app.

Import a copy of your site, match its PHP version to production, and test your changes there.

Local Connect supports moving sites between Local and supported hosting accounts, including pulling a remote site and pushing changes back. It isn’t a universal connection to every hosting provider.

A local environment is useful for development, but server settings, caching, and integrations can differ from production.

Test Updates and Performance Before Launch

Change one thing at a time

Start by opening a real review page, comparison page, and opt-in page. These give you a useful baseline.

Then update WordPress core, plugins, and themes in controlled steps. Test after each change. If something breaks, you’ll have a much better idea which update caused it.

For PHP upgrades, change the staging environment first when your host supports separate PHP settings. Test the dashboard, forms, redirects, and important pages.

Theme updates deserve special attention. Links stored inside posts usually remain, but theme-specific widgets, shortcodes, and templates may disappear. Test with your actual content, not an attractive demo.

Compare speed under similar conditions

Run important pages through PageSpeed Insights or GTmetrix before launch when staging is publicly reachable by those tools. Save the GTmetrix baseline report for comparison. Don’t remove access protection just to get a score; browser-based Lighthouse can test locally.

Staging often lacks production’s caching or CDN configuration, so slower results don’t automatically mean your changes caused a problem. Compare similar settings.

WP Rocket’s staging guidance covers these environment differences. Qualifying local and staging domains also don’t count as an additional domain against its license.

Repeat performance testing on production after deployment and cache clearing. Compare the new GTmetrix report with your baseline.

Run Your Affiliate Pre-Launch Checklist

A page can look fine and still lose useful clicks. Before publishing, work through the parts that connect your content to subscribers and buyers.

• Open priority affiliate links and follow the complete redirect path. Confirm the intended merchant page loads and affiliate IDs, sub-IDs, and tracking parameters survive. My affiliate link audit guide gives you a repeatable process.
• Submit opt-in and contact forms using test details. Confirm validation, thank-you pages, and intended notifications work without triggering a real promotional sequence.
• Test analytics and click events in a separate test property or through preview tools. My GA4 affiliate tracking guide explains click measurement, which doesn’t prove a commission.
• Open pages on a phone. Check menus, comparison tables, buttons, cookie notices, and sticky elements for overlap or awkward scrolling.
• Keep affiliate disclosures visible near recommendations, and retain appropriate sponsored-link attributes. Confirm consent controls still handle your tags as intended.

Prioritize paid-traffic landing pages and your busiest reviews.

Push Changes Live Without Losing New Data

Decide what needs to move

This is where you need to slow down a little.

A full staging database can overwrite newer activity on the live site. That includes new posts, comments, form entries, orders, customer records, affiliate settings, and user accounts.

A staging copy can pass every test and still contain older data than production.

WordPress.com’s syncing guidance warns that WooCommerce syncing can permanently erase orders, customer information, and product changes. Database synchronization also replaces the destination’s user list.

Use selective deployment when supported. Code-only changes may need files alone, but page-builder layouts, menus, and plugin settings often require a selective transfer.

For a few changes, repeating the tested edits on production can be safer than pushing a full copy.

Back up, deploy, and test again

Take a fresh backup of the production site immediately before deployment. Use a low-traffic period, and pause publishing or transactions if the transfer could overwrite new data.

Confirm the live site is the destination, then review the source and selected content before transferring.

After deployment, clear relevant caches and repeat your affiliate checklist on the public site. Confirm production remains indexable and doesn’t inherit staging’s password protection or noindex settings.

If a fault appears, stop further changes and use your rollback plan. Remember that restoring an older copy can also remove newer activity.

Remove Old Staging Copies Safely

Keep the staging site until production passes its checks. Then remove unused copies, temporary accounts, and unnecessary access credentials.

Deleting a WordPress.com staging site is permanent. Sync approved changes or export anything you need before deletion.

For an ongoing test environment, refresh staging from production before your next project. Save any unfinished staging work first, because refreshing can overwrite it.

An old clone isn’t a reliable starting point for testing today’s website.

Frequently Asked Questions

What is a WordPress staging site?

A staging site is a copy of a live WordPress site’s files and database that you use to test changes before publishing them. It lets you check updates and page changes without editing the live site first.

What’s the easiest way to create a staging site?

Start with your hosting provider’s staging tool if your plan includes one. WP STAGING can clone your site if your host doesn’t offer a built-in option, while manual or Local setups require more work.

Does a staging site need protection from visitors and search engines?

Yes. Password-protect it and enable WordPress’s “Discourage search engines from indexing this site” setting or a sitewide noindex directive. The setting alone doesn’t make the site private.

Can I push the whole staging site to live?

A full database push can overwrite newer posts, orders, form entries, customer records, and other live data. Back up production first, use selective deployment when possible, then test the live site again.

Key Takeaways: Protect the Site That’s Already Working

Use the simplest staging method your setup supports, and keep a separate backup. Test the pages that produce clicks and subscribers with your real content and plugins.

The biggest precaution is protecting newer live data during deployment. Move only what you need, then test production again.

That’s a practical way to improve your affiliate website without turning a routine update into an avoidable repair job.