How to Create a Staging Site on Offshore Hosting

Before you start

The goal: make a private copy of your live site at something like staging.yourdomain.com, test your changes there, and only touch the live site once you are happy.

The easy path first. Many panels — cPanel, aaPanel — and most managed WordPress hosts have a one-click “Create staging” button. If you have it, use it: it copies the files and database for you and keeps staging hidden. The steps below show the manual way for servers and VPS plans that don’t have that button.

Take a backup first. Before copying anything, make a backup or a server snapshot you can roll back to. Back up both the files and the database.

• Keep your domain (or Cloudflare) login ready to add a subdomain.
• Keep your hosting/server panel login ready.
• Keep the server IP, username, and password (or SSH key) ready.
• Open a notes file and write down every change you make.
• Know your live database name, user, and password (check wp-config.php).

Where does each change happen?

Each part of this lives in a different place. Here is the simple rule:

• The subdomain (DNS) → your domain or Cloudflare panel.
• Files and folders → your hosting panel or the server over SSH.
• The database copy → phpMyAdmin or the command line.
• WordPress settings & passwords → wp-config.php and your web server config.

The steps

Step 1: Make a subdomain for staging

In your domain or Cloudflare panel, add a subdomain like staging.yourdomain.com and point it to a new, empty folder on your server (for example /var/www/staging.yourdomain.com). This keeps the copy completely separate from your live site.

Check: dig staging.yourdomain.com shows your server IP, and the new folder exists.

Step 2: Copy the live files and database

Copy all the live files into the staging folder, then dump the live database and load it into a new staging database. The -a flag keeps file permissions intact.

cp -a /var/www/yourdomain.com/. /var/www/staging.yourdomain.com/
mysqldump -u root -p livedb > /tmp/live.sql
mysql -u root -p stagingdb < /tmp/live.sql

Replace livedb with your real live database name and stagingdb with a fresh database you created for staging.

Check: the staging folder has all your files, and the staging database has all your tables.

Step 3: Keep search engines OUT of staging

This is the most important step. A second copy of your site that Google can see causes duplicate-content problems. So lock it down two ways: put it behind a password (HTTP auth), and add a noindex rule so search engines never index it.

htpasswd -c /etc/nginx/.htpasswd staging
# then add to the staging server block:
#   auth_basic "Staging - private";
#   auth_basic_user_file /etc/nginx/.htpasswd;
#   add_header X-Robots-Tag "noindex, nofollow" always;

In WordPress, also tick Settings → Reading → Discourage search engines on the staging copy.

Check: opening staging.yourdomain.com asks for a password, and the page sends a noindex header.

Step 4: Test your changes, then push to live

Now make your change — a plugin update, a theme tweak, new code — on staging only. Click around and confirm nothing broke. When you are happy, repeat the same change on the live site (or push staging back to live with your panel’s deploy tool).

Check: staging works perfectly with the change, and only then does live get touched.

Extra commands you may need

Run these only on your own server. If your server uses a managed panel, check with support before changing system-level settings.

Fix the URLs inside the staging copy (WP-CLI)

The copied database still points everything at your live domain. This swaps those URLs for the staging one, so staging stops linking to live.

wp search-replace "https://yourdomain.com" "https://staging.yourdomain.com" --path=/var/www/staging.yourdomain.com

Run it from the server. Add --dry-run first if you want to preview the changes.

Point staging at its own database

Open wp-config.php in the staging folder and update the database details to the staging database — not the live one. If you skip this, your “test” changes will hit the real database.

define( 'DB_NAME', 'stagingdb' );
define( 'DB_USER', 'staginguser' );
define( 'DB_PASSWORD', 'StrongStagingPassword' );

Use your own staging database name, user, and password.

How to test after setup

1. Open staging.yourdomain.com — it should ask for the password first.
2. After logging in, open the homepage, an inner page, and a blog post.
3. Confirm the links point to staging, not your live domain.
4. View the page source or headers and confirm a noindex rule is present.
5. Make your change, then re-check those pages still work.
6. Search Google for site:staging.yourdomain.com — it should return nothing.

Quick troubleshooting

Final checklist

• Staging subdomain created and pointing to its own folder.
• Live files and database copied over.
• Password and noindex in place — staging is hidden.
• URLs fixed with search-replace; wp-config points to the staging DB.
• Change tested on staging before going live.

FAQ

What exactly is a staging site?

It is a private copy of your live website. You test updates, new plugins, or design changes there first. If something breaks, only the copy breaks — your real visitors keep seeing the working site.

Will having a staging site hurt my Google ranking?

Only if you leave it open. A visible second copy of your site can confuse search engines. Keep staging behind a password and a noindex rule, and there is no problem — in fact, testing safely keeps your live site more stable, which helps. Your content and links still decide ranking.

Do I have to do this manually?

No. If your panel (cPanel, aaPanel) or managed WordPress host has a one-click “Create staging” button, use it — it handles the copy and the hiding for you. The manual steps here are for servers that don’t offer that.