WordPress Staging Checklist for Safe Launches in 2026

Build the staging copy before you touch production

A WordPress staging checklist gives you a safe place to test theme changes, plugin updates, payment settings, and content edits before they reach a live store or business site. On Hostperl VPS hosting, that usually means cloning the site, isolating it on a subdomain, and checking that it behaves like production without exposing customers to unfinished changes. If you are still choosing hosting for a busy WordPress site, a Hostperl VPS gives you the control you need for staging, backups, and rollback planning.

This tutorial takes you from a fresh SSH login to a verified staging site. You will see commands for Ubuntu, Debian, AlmaLinux, and Rocky Linux, plus the pieces site owners often miss: search engine blocking, cache separation, file permissions, SSL, and a clean switch back to production when the test copy is ready.

Connect to the VPS and confirm the operating system

On your local computer

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation example. Replace it with the real public IP address assigned to your Hostperl server. If your provider uses a non-root SSH account, you can connect as that user instead, but keep the root session open until the new admin login is verified.

On the VPS as root

cat /etc/os-release

This shows whether you are on Ubuntu, Debian, AlmaLinux, or Rocky Linux. The next steps are split by family because package names, firewall tools, and service names differ.

Create a non-root admin account for staging work

Do this first if you are still working as root. The staging site will be easier to manage, and you will reduce lockout risk later.

Ubuntu and Debian on the VPS as root

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Replace nothing here unless your admin username should be different from deploy. This creates the account, grants sudo access, and copies your current SSH key so you can test a second login.

AlmaLinux and Rocky Linux on the VPS as root

useradd -m deploy
passwd deploy
usermod -aG wheel deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

On RHEL-compatible systems, sudo access usually comes through the wheel group. Keep your root session open.

On your local computer, open a second terminal

ssh deploy@203.0.113.10

After you log in, verify sudo works.

sudo -v
whoami

You should see deploy from whoami and no sudo error. Only after this works should you consider limiting root login.

Update packages, time sync, and basic staging tools

Staging copies go wrong when the server is already behind on patches. Update first, then install the tools you need for WordPress migrations and checks.

Ubuntu and Debian on the VPS as the non-root sudo user

sudo apt update
sudo apt -y upgrade
sudo apt -y install rsync unzip curl ca-certificates certbot python3-certbot-nginx

AlmaLinux and Rocky Linux on the VPS as the non-root sudo user

sudo dnf -y update
sudo dnf -y install rsync unzip curl ca-certificates certbot python3-certbot-nginx

For WordPress operations, the practical tools are rsync, curl, and the web server SSL package. If your site already uses another HTTPS setup, keep that in place and just validate the existing certificate later.

Set time sync so logs and scheduled tasks line up with reality.

timedatectl status

If NTP is not active, enable it.

sudo timedatectl set-ntp true
systemctl status systemd-timesyncd --no-pager

On AlmaLinux and Rocky Linux, chronyd is often the active service instead of systemd-timesyncd.

Prepare a safe WordPress staging directory

A clean staging layout keeps the copy separate from production and makes rollback simpler. Use a distinct path such as /var/www/staging.example.com for the site files and a separate database name.

On the VPS as the non-root sudo user

sudo mkdir -p /var/www/staging.example.com
sudo chown -R deploy:deploy /var/www/staging.example.com
sudo chmod 755 /var/www/staging.example.com
cd /var/www/staging.example.com
pwd

You should see the staging directory printed by pwd. If your live site lives elsewhere, keep that path intact and only clone into this new directory.

Clone the live site into staging

If your WordPress files already exist on the same VPS, use rsync to copy them. If the site is coming from another server, use your normal migration method first, then use the staging copy described here. For a full cutover procedure, Hostperl customers often pair this with the WordPress installation guide and the WordPress staging to production migration guide when they need a separate production deployment plan.

On the VPS as the non-root sudo user

sudo rsync -aHAX --delete /var/www/example.com/public_html/ /var/www/staging.example.com/public_html/

Replace /var/www/example.com/public_html/ with your live WordPress document root. --delete keeps the staging copy aligned with source files, so use it carefully.

Copy wp-config.php only if you intend to adjust database values immediately.

sudo cp /var/www/staging.example.com/public_html/wp-config.php /var/www/staging.example.com/public_html/wp-config.php.bak
sudo chmod 640 /var/www/staging.example.com/public_html/wp-config.php

Create a separate staging database and user

Never point staging at the live database. That is how test changes leak into production.

Ubuntu and Debian on the VPS as the non-root sudo user

sudo apt -y install mariadb-server
sudo systemctl enable --now mariadb
sudo mysql -e "CREATE DATABASE wp_staging CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wpstage'@'localhost' IDENTIFIED BY 'ChangeThisStagingPassword!'; GRANT ALL PRIVILEGES ON wp_staging.* TO 'wpstage'@'localhost'; FLUSH PRIVILEGES;"

AlmaLinux and Rocky Linux on the VPS as the non-root sudo user

sudo dnf -y install mariadb-server
sudo systemctl enable --now mariadb
sudo mysql -e "CREATE DATABASE wp_staging CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'wpstage'@'localhost' IDENTIFIED BY 'ChangeThisStagingPassword!'; GRANT ALL PRIVILEGES ON wp_staging.* TO 'wpstage'@'localhost'; FLUSH PRIVILEGES;"

Change ChangeThisStagingPassword! before you expose the site to anyone else. For database-focused planning, see how to choose the right database for VPS hosting in 2026 and the PostgreSQL backup guide if your stack includes other services on the same server.

Now update the staging wp-config.php file.

sudo nano /var/www/staging.example.com/public_html/wp-config.php

Replace the database settings so they match the staging database.

define('DB_NAME', 'wp_staging');
define('DB_USER', 'wpstage');
define('DB_PASSWORD', 'ChangeThisStagingPassword!');
define('DB_HOST', 'localhost');

Save and exit with CTRL+O, Enter, then CTRL+X. The file should now point at the isolated staging database.

Block search engines and separate cache behavior

Staging should not be indexed. Add a robots.txt file and make sure any cache plugin uses a separate cache prefix or is disabled on staging.

On the VPS as the non-root sudo user

cat <<'EOF' | sudo tee /var/www/staging.example.com/public_html/robots.txt
User-agent: *
Disallow: /
EOF

That tells crawlers not to index the test copy. It does not protect the site by itself, so use HTTP authentication or IP restrictions if the staging site is public.

If you use a cache plugin, change its settings in the WordPress admin later. For a live site review of performance tradeoffs, the article on Nginx vs Apache for VPS hosting helps teams decide where to place cache and reverse proxy logic.

Set up the web server vhost for staging

Use the section that matches the web server on this VPS. You only need one of these blocks.

Nginx on the VPS as the non-root sudo user

sudo nano /etc/nginx/sites-available/staging.example.com

server {
    listen 80;
    server_name staging.example.com;
    root /var/www/staging.example.com/public_html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }

    location ~* \.(css|js|png|jpg|jpeg|gif|ico|webp|svg)$ {
        expires 30d;
        access_log off;
    }
}

Enable the site, test the config, then reload.

sudo ln -s /etc/nginx/sites-available/staging.example.com /etc/nginx/sites-enabled/staging.example.com
sudo nginx -t
sudo systemctl reload nginx

You should see syntax is ok from nginx -t. If your Ubuntu or Debian server uses a different PHP socket, replace php8.3-fpm.sock with the version installed on the box.

Apache on the VPS as the non-root sudo user

sudo nano /etc/apache2/sites-available/staging.example.com.conf

<VirtualHost *:80>
    ServerName staging.example.com
    DocumentRoot /var/www/staging.example.com/public_html

    <Directory /var/www/staging.example.com/public_html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Enable the site and check the syntax before reload.

sudo a2ensite staging.example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

AlmaLinux and Rocky Linux with Apache on the VPS as the non-root sudo user

sudo nano /etc/httpd/conf.d/staging.example.com.conf

<VirtualHost *:80>
    ServerName staging.example.com
    DocumentRoot /var/www/staging.example.com/public_html

    <Directory /var/www/staging.example.com/public_html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Then test and reload.

sudo apachectl configtest
sudo systemctl reload httpd

If SELinux blocks the document root on AlmaLinux or Rocky Linux, label it correctly.

sudo restorecon -Rv /var/www/staging.example.com/public_html
sudo getenforce

For many site owners, this is the point where a managed VPS saves time, because hosting teams can help trace permission and web server issues before launch. That is one reason Hostperl customers often pair WordPress staging work with Hostperl shared hosting for smaller sites or a VPS for more control.

Enable HTTPS on the staging hostname

Use Let’s Encrypt if the staging subdomain resolves publicly and you want browser-safe testing. If the site is private, you can skip this and test over HTTP inside your network.

On the VPS as the non-root sudo user

sudo certbot --nginx -d staging.example.com

For Apache, swap --nginx with --apache. Certbot should write the certificate, update the vhost, and prompt you to redirect HTTP to HTTPS. After that, test renewal.

sudo certbot renew --dry-run

Successful output means the certificate can renew without human intervention.

Run WordPress-specific checks before you publish

Now log into the staging WordPress admin and test the exact actions that usually break on live sites: product save, checkout, contact forms, image upload, and permalink changes. If you use WooCommerce, run a test order using a sandbox payment mode and confirm the order completes without shipping or tax errors.

On the VPS as the non-root sudo user

curl -I https://staging.example.com
curl -s https://staging.example.com | head

The first command should return 200 or a redirect to HTTPS. The second should show the HTML of your staging homepage, which confirms the vhost is serving content.

Check PHP-FPM and web server status if pages fail.

systemctl status php8.3-fpm --no-pager
systemctl status nginx --no-pager
journalctl -u php8.3-fpm -n 50 --no-pager

Replace php8.3-fpm with your installed PHP version if needed. On Ubuntu and Debian, the service name often includes the major PHP version. On AlmaLinux and Rocky Linux, the package may be php-fpm or a versioned stream.

Lock down production only after staging passes

Do not disable root password login or make firewall changes until you have verified the new admin account and the staging site both work. If you still need firewall setup, add the new allow rule before removing the old one.

Ubuntu and Debian on the VPS as root or the non-root sudo user

sudo apt -y install ufw
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status verbose

AlmaLinux and Rocky Linux on the VPS as root or the non-root sudo user

sudo dnf -y install firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

For a broader hardening workflow, the guide on SSH, UFW, and Fail2Ban on a fresh VPS fits naturally with this staging setup.

Go live and keep a rollback path

When the staging site passes functional checks, copy the updated files or database changes back to production during a quiet window. The exact method depends on what changed, but the order matters: take a backup, sync the approved files, import database changes if needed, then test the live URL.

On the VPS as the non-root sudo user

sudo rsync -aHAX --delete /var/www/staging.example.com/public_html/ /var/www/example.com/public_html/
curl -I https://example.com

Replace /var/www/example.com/public_html/ with the real production path. The live site should return the expected HTTP status and render the final version you approved in staging.

For agencies and store owners handling repeated launches, a Hostperl VPS is usually the right balance of control and support. If you need more room for traffic spikes or a larger WooCommerce catalogue, compare Hostperl VPS and other hosting options before your next release.

FAQ

Should staging use the same plugin set as production?

Yes, unless a plugin causes the problem you are testing. A staging copy should mirror production closely so you can catch conflicts before launch.

Can I let customers access staging?

Only if you protect it with a password and keep search engines blocked. Public staging sites often get indexed or linked by accident.

What if my live site uses a different PHP version?

Match the production PHP version in staging whenever possible. Version gaps can hide bugs that appear only after launch.

How do I know the staging site is ready?

Test login, forms, checkout, image upload, cache behavior, and a real page refresh after clearing the browser cache. Then check the logs for PHP or web server errors.

What is the safest way to roll back?

Keep a fresh backup of the live database and files before you copy staging changes over. If the launch fails, restore the backup and verify the homepage, login, and checkout again.

Troubleshooting common staging failures

Blank pages or 500 errors
Run journalctl -u php8.3-fpm -n 50 --no-pager and tail -n 50 /var/log/nginx/error.log or the Apache error log. A PHP fatal error usually appears there. Fix the plugin, theme, or database issue, then reload the service.

Staging redirects to production
Check wp-config.php and the siteurl and home values in the staging database. Update them with the staging hostname, then clear any cache plugin and browser cache.

SSL fails to issue
Run sudo certbot certificates and confirm DNS for staging.example.com points to the server. If the domain does not resolve publicly, use HTTP for staging or issue the certificate after DNS is fixed.

Files cannot be edited by the web server
Check ownership with ls -la /var/www/staging.example.com/public_html. On SELinux systems, also run getenforce and restorecon -Rv /var/www/staging.example.com/public_html.

Cache changes do not appear
Disable any persistent object cache on staging and clear plugin caches. Then confirm with curl -I https://staging.example.com that the server is serving the refreshed content.