WordPress client staging: build it, test updates, then deploy

Why a staging site rather than testing on the live site

What a staging site gives you

• Updates without surprises — every core, theme or plugin change is seen on screen before it reaches visitors.
• A readable diagnosis — errors go to a log, not in front of the client, and the cause is found before they call.
• A shared review — the client or their project manager signs off on a separate address, without touching the public site.
• A change log — you note the version before and after for each plugin, and replay exactly the same on production.
• A trial for new things — new theme, new page builder, new payment module: everything is judged on a copy.
• A prepared rollback — the backup is made and checked before the test, not after the incident.

Prerequisites, with numbers, before copying

Build the staging site, step by step

1. 01

   Back up production before any write

   From the live site's folder:
   mkdir -p ~/preprod-backups
wp db export ~/preprod-backups/before-staging.sql --single-transaction
tar -czf ~/preprod-backups/files-before-staging.tar.gz -C ~/public_html .
   Check that both files exist and are not empty with ls -lh ~/preprod-backups. The plan's own backups do not replace this step: their frequency depends on the plan, so they may be several days old.

2. 02

   Create the subdomain and its folder

   Create staging.your-domain.com in cPanel (the guide "Create a subdomain in cPanel" details the screen) with its own document root, preferably outside public_html, for example ~/staging.your-domain.com. A folder placed inside public_html would also be reachable through an address of the live site. Wait until the subdomain's TLS certificate is issued before testing.

3. 03

   Copy the files

   rsync -a --exclude='wp-content/cache/' ~/public_html/ ~/staging.your-domain.com/
   Adapt the source path to the client site's document root. Without a terminal, the cPanel file manager lets you compress the folder, move it, then extract it into the subdomain's folder.

4. 04

   Create a dedicated database and user

   In the MySQL databases section of cPanel, create a new database and a user, and give it all privileges on that database only. Then open the copy's wp-config.php and change DB_NAME, DB_USER and DB_PASSWORD. This is the costliest mistake in this guide: copying wp-config.php without changing those three lines makes the staging site write into the production database.

5. 05

   Import the database

   From the copy's folder:
   cd ~/staging.your-domain.com
wp db import ~/preprod-backups/before-staging.sql
wp option get siteurl
   The last command should still show the production address: that is normal, the URLs have not been replaced yet. If it fails, wp-config.php still points to the wrong database.

6. 06

   Replace the URLs, as a dry run first

   wp search-replace 'https://your-domain.com' 'https://staging.your-domain.com' --all-tables --skip-columns=guid --dry-run
   Read the report: it lists the tables and the number of replacements. Then run the same command without --dry-run. WordPress stores many settings as serialized data, where each string carries its length: a sed on the export changes the URL length without fixing that count, and the settings become unreadable. wp search-replace understands this data and rewrites it correctly.

7. 07

   Set the staging settings in wp-config.php

   Add, above the line "That's all, stop editing":
   define('WP_ENVIRONMENT_TYPE', 'staging');
define('DISABLE_WP_CRON', true);
define('DISALLOW_FILE_EDIT', true);
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
   Errors go to wp-content/debug.log without showing to visitors. WP_ENVIRONMENT_TYPE has existed since WordPress 5.5 and accepts local, development, staging and production: it lets themes and plugins adapt, but it does not hide the site from search engines, hence the next step.

8. 08

   Close access and request noindex

   Under Settings › Reading, tick "Discourage search engines from indexing this site", or from the command line: wp option update blog_public 0. Then add HTTP authentication to the copy's folder: a .htpasswd file created with htpasswd -c ~/.htpasswd-staging client, then in the folder's .htaccess the directives AuthType Basic, AuthName "Preproduction", AuthUserFile pointing to that file and Require valid-user. Failing that, restrict access to an IP list.

9. 09

   Check the copy the way a robot would

   curl -sI https://staging.your-domain.com/
   The response should be a 401. Then, with the credentials:
   curl -s -u client https://staging.your-domain.com/ | grep -i robots
   You should see a meta name='robots' tag containing noindex. If a cache or SEO plugin replaces it, that is the one to configure. Finally, check that the theme contains no hard-coded production address: grep -r "https://your-domain.com" wp-content/themes.

10. 10

    Attach staging to your agency routine

    Turn this setup into a template: one subdomain per client, in the client's cPanel account, with the same checklist. The order of operations for moving a site to another host is covered by the guide "Migrate a client WordPress site without downtime"; the staging site described here is a lasting tool, not a cutover step.

Really isolate it: noindex is not enough

Neutralise emails, payments and scheduled tasks

Checklist before touching a single plugin

• Emails — sending plugin in test mode or redirected to a review mailbox, shop notifications switched off.
• Payments — gateway in test mode, production keys removed from the copy, callback addresses (webhooks) not declared for staging.
• Scheduled tasks — DISABLE_WP_CRON set, pending events listed with wp cron event list.
• File editing — DISALLOW_FILE_EDIT active so code cannot be edited from the admin.
• Error log — WP_DEBUG_LOG active and WP_DEBUG_DISPLAY set to false.
• Third-party integrations — CRM, directories, analytics tools and production API keys replaced or removed.
• Search engines — noindex set and authentication in place, checked with curl as above.

Test updates, one at a time

When the update breaks: reading debug.log

Troubleshooting: the other symptoms you really meet

• The site redirects to production — wp option get siteurl and wp option get home still show the old address, or a page builder keeps hard-coded URLs; run the replacement again, with --precise if needed.
• "Error establishing a database connection" — the copy's DB_NAME, DB_USER, DB_PASSWORD or DB_HOST are wrong, or the user has no rights on the new database.
• Images or styles loaded from production — escaped URLs, such as https:\/\/ in page builders' JSON data, escaped the replacement; run it again with that form.
• Login loop or immediate logout — the cookies belong to the old domain; clear them and check siteurl and home.
• The staging site shows up in a search engine — noindex was set too late or a plugin overrides it; switch to HTTP authentication and request removal of the address.

Files or database: what moves, and how

Scroll the table

Moving to production, and being able to go back

A routine that holds at portfolio scale