Create a WordPress Staging Site on Shared Hosting

Testing changes directly on a live WordPress website is a risk that professional developers avoid. A staging site is a separate clone of your production site used to test plugin updates, new themes, and code changes safely before going live. This guide walks you through creating a WordPress staging site on shared hosting with DirectAdmin, step by step.

What is a Staging Site and Why Does It Matter?

A staging site is an isolated copy of your production site used for testing. Key benefits include:

• Test WordPress core updates without affecting the live site
• Try new plugins or themes in a safe environment
• Test code and CSS changes before publishing
• Prevent downtime caused by a broken update
• Show clients previews before approving changes

Prerequisites

Before you begin, you will need:

• A subdomain for staging, e.g. staging.yourdomain.com
• A separate database for staging
• Enough disk space (at least equal to your production site size)

Step 1 — Create a Staging Subdomain

1. Go to DirectAdmin → Domain Setup → Subdomains
2. Enter staging as the subdomain name
3. Click Create
4. DirectAdmin automatically creates the subdomain folder in File Manager

Step 2 — Create a New Database

1. Go to DirectAdmin → MySQL Management
2. Click Create New Database
3. Name it username_staging
4. Create a database user and password, then click Create

Step 3 — Copy WordPress Files

Use File Manager to copy all files from public_html/ to the staging subdomain folder:

1. Open File Manager
2. Select all files in public_html/
3. Click Copy and set the staging folder as the destination

Or via SSH:

cp -r /home/username/public_html/. /home/username/domains/staging.yourdomain.com/public_html/

Step 4 — Export and Import the Database

1. Go to DirectAdmin → phpMyAdmin
2. Select the production database, click Export → Go, save the .sql file
3. Switch to the staging database, click Import, select the .sql file

Step 5 — Update wp-config.php

Edit wp-config.php in the staging folder to use the new database credentials:

define('DB_NAME', 'username_staging');
define('DB_USER', 'staging_user');
define('DB_PASSWORD', 'your_staging_password');
define('DB_HOST', 'localhost');

Step 6 — Update URLs in the Database

Run this SQL in phpMyAdmin to update URLs from production to staging:

UPDATE wp_options SET option_value = 'https://staging.yourdomain.com'
WHERE option_name = 'siteurl' OR option_name = 'home';

Or use WP-CLI: wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com'

Full Manual Staging Workflow at a Glance

To see the whole process end to end, here is the complete order of operations for creating a WordPress staging site on shared hosting with DirectAdmin. Follow these steps in sequence and you will end up with a fully working clone of your site on a subdomain:

1. Create a subdomain — In DirectAdmin → Subdomains, create staging.yourdomain.com so it has its own folder and address separate from production.
2. Copy every file — Copy all files from public_html/ (including the wp-content folder, the .htaccess file, and all hidden files) into the staging folder.
3. Clone the database — Export the production database from phpMyAdmin, then import it into the newly created staging database.
4. Edit wp-config.php — Point DB_NAME, DB_USER, and DB_PASSWORD to the staging database.
5. Update URLs in the database — Use wp search-replace or SQL to change siteurl/home and any URLs embedded in serialized content to the staging domain.
6. Block indexing and lock access — Add Password Protection and noindex so Google never crawls the staging copy.

The next sections cover the spots beginners most often get wrong: search-replacing URLs, pushing changes back to production, and whether to use a plugin to help.

WP Staging Plugin vs Doing It Manually — Which Is Better?

You can build a staging site either the "manual" way through DirectAdmin and phpMyAdmin as described above, or with a plugin such as WP Staging, Duplicator, or WP Migrate. Each approach has clear trade-offs:

Recommendation: for small to medium sites that need speed, a plugin like WP Staging is the easiest option. But if you want full control over every step, a deeper understanding of the system, and you would rather not install another plugin on your production site, doing it manually through DirectAdmin is more flexible and does not affect live-site performance.

Push Staging to Production Safely

Once your changes pass testing on staging and you are ready to take them live, do not blindly copy the entire folder or database over production. While you were testing, the production site may have accumulated new data (orders, comments, new members). Overwriting everything would wipe that data. Follow this approach:

1. Always back up production first — Back up both the files and the database through DirectAdmin before touching anything, so you can roll back instantly if something breaks.
2. Separate the type of change — If you only changed a theme, plugin, or code, copy just the files in wp-content/themes or wp-content/plugins and leave the database alone.
3. Be careful overwriting the database — If you must bring tables up from staging, import only the relevant tables (e.g. wp_options for settings) rather than overwriting the whole database.
4. Replace URLs back to the live domain — When importing data from staging, remember to search-replace https://staging.yourdomain.com → https://yourdomain.com first, or links and images will point to the wrong place.
5. Test immediately after pushing — Open the homepage, key pages, and the login page right away to confirm the live site still works correctly.

If you are worried about data added during testing, the safest path is to redo the changes directly on production during a low-traffic window instead of overwriting the entire database from staging.

Common Pitfalls to Avoid

A carelessly configured staging site can cause problems for production or for your SEO. Watch out for these:

• Always set staging to noindex — Go to Settings → Reading and tick "Discourage search engines," and add Password Protection via DirectAdmin so Google never indexes staging as duplicate content that harms your live rankings.
• Don't forget to search-replace every URL — WordPress URLs are stored in serialized data. A direct SQL UPDATE can corrupt serialized values, so use wp search-replace (which understands serialized data) or a plugin that handles it.
• Clear the cache on staging — If production uses a caching plugin (WP Super Cache, LiteSpeed Cache, etc.), flush the cache on staging after cloning, or you will see stale pages or links still pointing to production.
• Disable WP-Cron on staging — Add define('DISABLE_WP_CRON', true); so staging does not run scheduled tasks such as sending emails, auto-posting, or calling live APIs in duplicate with production.
• Isolate SMTP and payments from the real ones — On staging, disable or use sandbox values for payment gateways and email delivery so you never accidentally email or charge real customers during testing.

Frequently Asked Questions

Does a staging site use an extra subdomain, and does it affect my live SEO?

Staging uses a separate subdomain such as staging.yourdomain.com, which does not affect the SEO of your main domain as long as you set it to noindex and lock it with Password Protection. Google will not index it as duplicate content. AsiaGB Hosting supports unlimited subdomains, so you can create staging at no extra cost.

Is creating a staging site hard for beginners?

Doing it manually requires understanding three main things: subdomains, cloning the database, and editing wp-config.php — all of which this guide covers. If you want it easier, you can use the WP Staging plugin to clone your site in a few clicks. But doing it manually through DirectAdmin helps you understand the system and avoids installing another plugin on your live site.

Should I delete the staging site after testing?

You should delete or disable staging when not in use to save space and reduce security risk (old staging sites often have outdated plugins/themes and become a vulnerability). If you need it often, keep it but always lock it with Password Protection and noindex, and back up both production and staging regularly.

Will customer data be lost when I push changes from staging to production?

It can be lost if you overwrite the entire database, because production may have gained new orders or members during testing. The safest path is to back up production first, then push only the changed theme/plugin files or import only the necessary tables — not overwrite the whole database.