Making changes to a live WordPress website always involves some risk. A plugin update might cause a conflict, a new theme could affect your layout, or a small development change might break an important feature.
That’s where a WordPress staging site comes in.
A staging site gives you a separate copy of your website where you can test changes before applying them to the live version your visitors use.
You can experiment with updates, troubleshoot problems and review new features without immediately exposing customers to those changes.
In this guide, we’ll explain how to create a WordPress staging site, using either your hosting provider’s staging tools or the WP STAGING plugin.
We’ll also cover how to protect your staging environment, test changes properly and avoid overwriting important information when you’re ready to update your live website.
What Is a WordPress Staging Site?
A WordPress staging site is a separate testing copy of your existing website.
Your live website, also called the production site, is the version that customers and visitors normally access.
A staging site lets you work on a copy while keeping your proposed changes separate from production.
For example, your live website might be available at:
https://example.com
Your staging website might use an address such as:
https://staging.example.com
Alternatively, it could use a subfolder:
https://example.com/staging
The staging website normally contains copies of your WordPress files, plugins, themes, content and database.
However, it isn’t necessarily identical to your live website in every respect.
The hosting environment, caching configuration, external services and database content may differ. The two websites can also become increasingly different as new content and orders are added to production.
The important distinction is that changes made on staging don’t automatically become changes on your live website.
You need a separate process to transfer the changes you want to publish.
Why Use a WordPress Staging Site?
A staging environment is useful whenever you’re planning changes that could affect how your website works.
Test WordPress, plugin and theme updates
Updates can introduce changes to functionality, compatibility or appearance.
Testing them on staging gives you an opportunity to identify problems before applying them to production.
For example, you might discover that a plugin update affects your contact form or that a theme update changes the layout of an important page.
You can investigate the problem without immediately disrupting the live website.
For more guidance, see our article on how to update WordPress safely.
Troubleshoot plugin conflicts
If your website has a plugin-related problem, staging gives you somewhere to investigate it.
You can deactivate plugins, test different configurations or change themes without making those experimental changes directly on the live site.
This is particularly helpful for websites that rely on WooCommerce, booking systems or membership functionality.
Our guide to fixing WordPress plugin problems explains how to isolate common conflicts.
Preview redesigns and new features
Staging is also useful when working on larger changes.
You might want to redesign your homepage, introduce a new checkout experience or test a different navigation layout.
A staging copy lets you review these changes with your team or developer before deciding what should go live.
However, remember that the staging website may contain older versions of your live content. You’ll need to account for any newer changes when deploying your work.
Reduce the risk of downtime
Testing changes in advance can help you catch problems that might otherwise cause downtime or broken features.
It doesn’t eliminate every risk. Differences between staging and production can still cause unexpected behaviour during deployment.
But a properly configured staging environment gives you more opportunity to identify and resolve problems before visitors are affected.
Before You Create a WordPress Staging Site
A little preparation will make the process easier and reduce the chance of problems.
Make sure you have a reliable backup
Before copying or changing your website, create or verify a recent backup of its files and database.
Ideally, the backup should be stored separately from the live server, and you should know how to restore it.
A staging site is not a replacement for a backup.
Although staging creates a separate copy of your website, that copy might share hosting resources with production. It may also be incomplete or contain changes that make it unsuitable for restoration.
Check your hosting resources
Creating a staging copy requires additional storage, and the cloning process can temporarily increase server activity.
Large websites with extensive media libraries or databases may require substantial resources.
Check that your hosting environment has enough available storage and capacity.
If you’re unsure, ask your hosting provider before starting.
Confirm your access and available staging options
You’ll usually need administrator access to WordPress or permission to manage the website through your hosting control panel.
Before installing a staging plugin, check whether your host already provides a built-in staging feature.
If it does, that may be the simplest option.
You don’t necessarily need a separate domain name, FTP account or staging plugin to create a staging site.
Consider sensitive information and external integrations
A staging copy may contain real customer information, form submissions, orders or membership records copied from production.
It may also inherit connections to payment gateways, email services, analytics systems and other external platforms.
Plan how you’ll protect that information and prevent the staging copy from interacting with real customers.
We’ll cover these precautions in more detail below.
Method 1: Create a Staging Site Through Your Hosting Provider
Many managed WordPress hosting providers include staging tools in their control panels.
This is often the easiest approach because the hosting platform handles much of the website copying and configuration.
The exact steps depend on your provider.
Step 1: Log in to your hosting dashboard
Sign in to the account where your WordPress website is hosted.
Look for the website you want to copy and open its management area.
You may find staging options under a section called Staging, Environments, Development or something similar.
Not every hosting plan includes this functionality.
If you can’t find a staging option, check your provider’s documentation or contact its support team.
Step 2: Create a staging environment
Select the option to create a new staging environment.
Your hosting provider may ask you to choose a staging name, confirm the source website or select which data to copy.
Review the available options before proceeding.
For most straightforward websites, the default settings will be suitable.
If your host offers the choice between copying files, the database or both, make sure you understand what will be included.
A useful testing environment generally needs the files and database information relevant to the changes you intend to test.
Step 3: Allow the hosting platform to create the copy
Start the staging creation process.
Your hosting provider will copy the required files and database information into the staging environment.
The process may take longer for websites with large databases or extensive media libraries.
Once it finishes, your host should provide a staging URL and a way to access the copied website.
Step 4: Log in and check the staging website
Open the staging address and sign in.
Confirm that the main pages load correctly and that important functionality is available.
Some hosting platforms automatically restrict staging access or disable certain external integrations.
Others require you to configure these safeguards yourself.
Review the staging settings before testing anything that could trigger emails, payments or scheduled activities.
Before making changes, confirm that you’re logged in to staging rather than the live website.
Step 5: Review how your host deploys changes
Your hosting provider may offer a button to copy staging changes to production.
Don’t use it immediately.
First, find out whether the deployment replaces files, database tables, selected content or the entire website.
This matters because production may have received new orders, users, comments or content since staging was created.
We’ll explain the deployment risks later in this guide.
Method 2: Create a WordPress Staging Site with WP STAGING
If your hosting provider doesn’t offer a suitable staging feature, you can use a WordPress plugin.
WP STAGING provides a straightforward way to create a separate testing copy of a WordPress website.
The free version can create a staging copy in a subfolder on compatible WordPress hosting.
For example:
https://example.com/testing
WP STAGING Pro adds functionality for more advanced staging setups, migrations and pushing selected changes back to production.
For this tutorial, we’ll focus on creating a staging website using the free version.
Step 1: Install the WP STAGING plugin
Log in to your live WordPress dashboard.
Navigate to Plugins > Add New Plugin.
Search for WP STAGING and locate the plugin in the WordPress plugin directory.
Review the plugin details to make sure you’re installing the correct one.
Click Install Now, followed by Activate.
If you need more help with this process, follow our WordPress plugin installation guide.
Step 2: Open the staging site manager
After activating the plugin, find WP STAGING in your WordPress dashboard.
Open the Staging Sites section.
Look for the option labelled Create New Staging Site.
The precise layout and button labels may vary depending on the plugin version.
The official WP STAGING documentation provides updated instructions if your screen looks different.
Step 3: Name your staging website
Enter a name for your staging site.
For example, you might call it testing or development.
With the standard free-version setup, this name forms part of the staging URL.
A site named testing might be accessible at:
https://example.com/testing
You don’t need to buy another domain for this configuration.
Use a name that makes it easy to recognise the staging environment.
Step 4: Review the files and database settings
WP STAGING provides options for selecting which files and database tables to include in the clone.
For a straightforward staging copy, it’s generally best to leave the default selections unchanged.
This helps ensure that the staging website contains the files and database information it needs to function correctly.
Advanced users may choose to exclude certain large files or tables when they know those items aren’t required for testing.
However, excluding the wrong tables or folders can produce an incomplete staging environment.
If you’re unsure what a particular option does, leave it at its default setting.
Step 5: Start cloning your website
Click Start Cloning.
WP STAGING will begin creating the staging copy.
The time required depends on factors such as website size, database size, available server resources and hosting configuration.
Avoid making unnecessary changes while the cloning process runs.
If the process fails, review the error message rather than repeatedly starting new clones without investigating the cause.
Step 6: Open your staging site
When cloning finishes, WP STAGING should provide an option to open the new staging website.
Click Open Staging Site, Open or the corresponding link shown by your version.
You may be asked to log in using the WordPress credentials that were copied when the staging environment was created.
WP STAGING also provides additional access protection for staging sites, so you may encounter an extra login screen.
Once you’ve signed in, check that you’re viewing the staging URL.
Step 7: Check that the staging copy works
Before making changes, visit several pages and check that important functionality is present.
For example, confirm that:
- The homepage and key pages load correctly.
- Images and stylesheets appear as expected.
- You can access the WordPress dashboard.
- The active theme and plugins are present.
- Important forms and interactive features display correctly.
- Links point to the appropriate locations.
Some features may behave differently on staging because of URL changes, caching or external services.
That’s normal to a degree, but investigate anything that prevents the staging environment from being useful for your intended tests.
At this point, you have a separate WordPress environment where you can begin testing changes.
How to Protect Your WordPress Staging Website
Creating a staging site is only the first part of the process.
A copied website can still interact with customers, external services or search engines if it isn’t configured properly.
Before testing, make sure the environment is protected.
Restrict access to authorised users
A staging site should normally be private.
Use your hosting provider’s access controls, password protection or another suitable authentication method.
WP STAGING provides additional login protection for staging copies.
Check that these safeguards are working before sharing the staging URL.
This is particularly important if the copy contains customer accounts, unpublished content or personal information.
Keep staging out of search results
You don’t want search engines indexing a second copy of your website.
That could expose unfinished pages or create duplicate-content issues.
WordPress provides a Discourage search engines from indexing this site option under Settings > Reading.
However, this setting isn’t a reliable security measure. Search engines aren’t required to respect it, and the site can still be publicly accessible.
Use proper access restrictions as your primary protection, and confirm that the staging configuration discourages indexing.
Prevent real emails from being sent
A copied website may still contain settings for contact forms, newsletters, order confirmations and automated notifications.
If those systems remain active, staging tests could accidentally send messages to real customers.
Disable outgoing emails or configure a safe email testing service that captures messages without delivering them to actual recipients.
Check this before submitting test forms or creating test orders.
Disable or isolate scheduled tasks
WordPress and its plugins can run scheduled tasks in the background.
These might include sending reminders, renewing subscriptions, importing information or communicating with external services.
If the staging website continues running those tasks, it could duplicate work or affect live systems.
Disable or safely isolate scheduled tasks and integrations that shouldn’t operate on staging.
For more complex websites, ask your developer or hosting provider to confirm the appropriate settings.
Use test payment credentials
If your website accepts payments, make sure staging uses the relevant payment provider’s sandbox or test mode.
Never assume a payment integration automatically becomes safe simply because the website has been copied.
Review payment gateways, subscription renewals, webhooks and other related services before testing.
For a WooCommerce store, this is especially important because the staging environment may contain real customer and order information.
Protect personal and customer data
Staging copies often contain information from the live database.
Limit who can access the environment, avoid unnecessary exposure of personal data and remove test copies when they’re no longer needed.
Where possible, use anonymised information for development or testing that doesn’t require genuine customer records.
Staging should receive appropriate security and privacy controls, just like the live website.
How to Test Changes on Your Staging Site
Once you’ve confirmed the staging environment is protected, you can begin testing.
The aim isn’t simply to check whether the homepage still loads.
You should test the features most likely to be affected by the changes you’ve made.
Test the intended changes first
Start with the reason you created staging.
If you’re testing a plugin update, update the plugin and check the features it controls.
If you’re testing a theme change, review the website’s layout and responsive behaviour.
If you’re investigating a conflict, change one relevant component at a time so you can identify what causes the problem.
Avoid making several unrelated changes at once unless you’re specifically testing how they work together.
Check important website functionality
Use a checklist appropriate to your website.
For example:
- Homepage, service pages and important content.
- Navigation menus and internal links.
- Contact forms and other submissions.
- Search, filters and interactive features.
- Mobile and tablet layouts.
- User registration and account access.
- WooCommerce product, basket and checkout flows.
- Membership access and restricted content.
- PHP errors, browser errors and unexpected warnings.
For transactions and notifications, use safe test data and test-mode integrations.
Check for obvious performance problems
Staging is useful for identifying performance regressions.
For example, you may notice that a plugin update causes a particular dashboard screen or page to become significantly slower.
You can also use website performance tools to investigate specific changes.
However, staging performance won’t necessarily match production.
The two environments may have different caching, traffic, server resources or external integrations.
Use staging results as evidence, not a guarantee that production will perform identically.
Our guide to website performance testing explains the importance of measuring website behaviour rather than relying on assumptions.
Record what you’ve changed
Before deploying anything, make a note of the changes made on staging.
Identify which files, plugins, settings or content were modified.
Also record which tests passed and whether any issues remain unresolved.
This makes it easier to choose the correct deployment method and check the live website afterwards.
How to Push Staging Changes to Your Live Website
After testing, the next step is deciding how to apply the approved changes to your live website.
This requires care.
Copying everything from staging to production can overwrite newer information on the live website.
For example, suppose you created a staging copy on Monday and your WooCommerce store received 50 orders before Friday.
If you replace the live database with Monday’s staging database, those newer orders could be lost.
The same problem can affect customers, form submissions, bookings, comments and content updates.
Decide what actually needs deploying
Different changes require different deployment approaches.
| Change made on staging | What to consider before deployment |
|---|---|
| Plugin or theme file updates | File changes may be sufficient if no database changes are required. |
| Plugin settings | Settings often reside in the database and may need separate handling. |
| New or edited pages | Changes may involve content, metadata and related database records. |
| WooCommerce functionality | Protect live orders, customers, subscriptions and transactional data. |
| Website redesign | Identify which theme files, media, content and settings have changed. |
| Database structure changes | Review compatibility, dependencies and the correct migration process. |
Avoid assuming that transferring an entire database table is a safe way to deploy a small change.
A single table can contain information from many unrelated parts of the website.
Option 1: Apply the changes manually
For a small number of changes, manually repeating the tested work on the live website may be the simplest option.
For example, you might test a plugin update on staging, confirm it works, and then install the same update on production.
You might also test a particular setting before applying it to the live version.
Make sure you have a recent production backup before doing so.
After applying the changes, test the live website again.
This approach is particularly useful if you’re using WP STAGING Free, which doesn’t include the standard staging-to-live Push Wizard.
Option 2: Use your hosting provider’s deployment tools
If your hosting provider offers staging, it may also provide a way to deploy changes.
Check whether the tool supports file-only deployments, selective database changes or complete site overwrites.
Don’t assume that a button labelled Push to Live will preserve information added to production since staging was created.
Read the hosting provider’s documentation and confirm what will be replaced.
For active eCommerce or membership websites, a developer may need to prepare a more selective deployment process.
Option 3: Use WP STAGING Pro
WP STAGING Pro provides a Push Wizard for transferring staging changes to the live website.
The available features can depend on your licence and configuration.
Before using the Push Wizard:
- Create a fresh backup of the live website.
- Confirm that staging contains the changes you actually want to publish.
- Review the required WordPress and plugin version compatibility.
- Select the relevant files and database tables.
- Check which live data would be overwritten or deleted.
- Confirm the deployment plan before starting the transfer.
Where possible, transfer only the components needed for the approved change.
For example, a theme file update might not require transferring the database at all.
But changes to plugin settings or website content commonly do involve database records, so the correct approach depends on exactly what has changed.
WP STAGING’s official push-to-live documentation explains how its deployment options work.
If your live site regularly receives new orders, users, bookings or other transactions, don’t perform a broad database overwrite without a carefully reviewed plan.
Always test the live website after deployment
Even when everything works on staging, the final production changes still need checking.
Open the live website and test the functionality you updated.
Check important forms, login processes, navigation and any business-critical features.
For a store, review checkout functionality using a safe, appropriate testing method and confirm existing orders remain intact.
Also check for PHP errors, missing assets and unexpected changes to URLs or site settings.
If something goes wrong, use your backup and deployment records to investigate the safest way to recover.
Be particularly careful with database restores on active websites, as restoring an older database can itself remove newer live records.
Common WordPress Staging Problems
Staging environments don’t always work perfectly on the first attempt.
Here are some problems you might encounter and what to investigate.
The staging site won’t finish cloning
Cloning can fail because of insufficient disk space, timeouts, file permissions or database issues.
Check the available storage and any error messages from the hosting platform or staging plugin.
Large databases and media libraries may take longer to copy.
If you’re using WP STAGING, consult its documentation before changing advanced cloning settings.
Avoid excluding database tables unless you understand their purpose.
You can’t log in to the staging website
Confirm that you’re using the correct staging address.
Your hosting provider or staging plugin may add another authentication screen before WordPress login.
If the staging database was copied earlier, account changes made on production since then might not appear on staging.
Check your hosting or plugin documentation for the appropriate way to recover access.
Images, links or styles are missing
Copied WordPress websites sometimes retain URLs that refer to the original domain or location.
This can lead to broken links, missing images or mixed-content warnings.
Caching and file permissions can also affect how the staging site displays.
Use your hosting or staging plugin’s supported URL-handling tools to investigate these issues.
Avoid running an ordinary database search-and-replace query without accounting for WordPress’s serialised data.
The staging website behaves differently from production
A staging site may use different caching rules, server settings, PHP versions or external integrations.
Some plugins may also behave differently when their licence or API connection is tied to a particular domain.
Compare the environment settings and identify any important differences before relying on test results.
You don’t have enough storage for staging
A staging copy may duplicate much of your website’s files and database.
On a large site, this can require significant additional storage.
Check your hosting capacity and whether you can safely remove unused staging copies or temporary backup files.
Don’t delete an environment that another team member is actively using.
Frequently Asked Questions
Can I create a WordPress staging site for free?
Yes.
Some hosting providers include staging as part of their plans.
WP STAGING also offers a free plugin that can create a staging copy in a subfolder on compatible hosting.
However, advanced features such as automated staging-to-live deployment may require a paid plan.
Do I need a separate domain for a staging site?
No.
Staging can use a subdomain, subfolder or a separate environment provided by your host.
WP STAGING Free normally creates a subfolder-based staging site.
Your hosting provider may offer other configurations.
Will a staging site affect my live website?
A properly configured staging environment keeps your testing changes separate from production.
However, staging can still affect the live website indirectly if both environments share limited server resources or if copied integrations interact with real services.
For example, a staging site might send real emails or trigger external processes unless those functions are safely isolated.
Check the environment’s configuration rather than assuming every staging copy is completely independent.
Should my staging website be password protected?
Yes, restricting access is strongly recommended.
A staging site may contain unpublished changes, user information or other sensitive data.
Password protection or another suitable authentication method helps keep it private and prevents search engines and unauthorised visitors from accessing it.
The WordPress search-engine discouragement setting alone is not sufficient protection.
Can I use staging with WooCommerce?
Yes, but WooCommerce staging requires additional care.
Use test payment settings, prevent unwanted customer notifications and review scheduled processes.
When deploying changes, protect live orders, customers, subscriptions and other transactional information.
For an active store, avoid copying an outdated staging database over production.
Is a staging site the same as a backup?
No.
A staging site is a testing environment where you can experiment with changes.
A backup is a recovery copy intended to help restore files or data if something goes wrong.
Both are useful, but they serve different purposes.
You should maintain reliable backups even when you use staging.
Should I delete a staging site after finishing?
If you no longer need the staging environment, removing it can free storage and reduce maintenance responsibilities.
Before deleting it, confirm that all required changes have been transferred or saved elsewhere.
Also check that nobody else is still working on the staging copy.
If you regularly test updates or development changes, keeping a properly secured and maintained staging environment may be more convenient.
Make WordPress Changes with Confidence
A WordPress staging site gives you a safer place to test updates, troubleshoot problems and review website changes before making them available to visitors.
For many websites, your hosting provider’s staging feature will be the simplest option. If your host doesn’t provide one, WP STAGING offers another way to create a testing copy.
Whichever method you use, remember that staging is only one part of a safe update process.
Protect the staging environment, test important functionality, back up production and carefully choose what to deploy.
This is especially important for websites that process orders, manage memberships or regularly receive new customer information.
If you’d rather have someone manage WordPress updates, backups and routine checks, our WordPress Maintenance service can help keep your website properly looked after.
With a reliable maintenance process in place, you can make changes with greater confidence while reducing the risk of avoidable problems.
