{"id":220,"date":"2026-06-07T08:42:06","date_gmt":"2026-06-07T08:42:06","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=220"},"modified":"2026-08-27T05:43:31","modified_gmt":"2026-08-27T05:43:31","slug":"create-staging-site-on-offshore-hosting","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/create-staging-site-on-offshore-hosting\/","title":{"rendered":"How to Create a Staging Site on Offshore Hosting"},"content":{"rendered":"
\n

Tutorial<\/span><\/p>\n

Somewhere to break things safely<\/h2>\n

A staging site is a full copy of your live site on a subdomain, with its own files and its own database, where you can update plugins and try changes without any of it reaching visitors.<\/p>\n

Two things make a staging site useful rather than a liability: it must have a separate database<\/strong>, and it must be invisible to search engines<\/strong>. Get either wrong and staging becomes the problem instead of the safety net.<\/p>\n

\n
Time<\/strong>30 minutes to set up.<\/span><\/div>\n
Must have<\/strong>Its own database. Not the live one.<\/span><\/div>\n
Must not<\/strong>Be indexable, or reachable by the public.<\/span><\/div>\n<\/div>\n<\/div>\n
On this page<\/strong>The subdomain<\/a>Copying the site<\/a>Its own database<\/a>Fixing the URLs<\/a>Keeping it out of Google<\/a>Pushing changes live<\/a>FAQ<\/a><\/div>\n

The subdomain<\/h2>\n

Create staging.yourdomain.com<\/code> in your panel, or add a vhost with its own document root on a plain VPS<\/a>. Give it its own directory, separate from the live site.<\/p>\n

Issue a certificate for it too. A staging site over plain HTTP behaves differently from the live one, and browsers block mixed content in ways that send you chasing bugs that do not exist on production.<\/p>\n

Copying the site<\/h2>\n
mkdir -p \/var\/www\/staging.yourdomain.com\ncp -a \/var\/www\/yourdomain.com\/. \/var\/www\/staging.yourdomain.com\/\nchown -R www-data:www-data \/var\/www\/staging.yourdomain.com<\/code><\/pre>\n
The -a<\/code> flag preserves permissions and ownership, and the dot after the source path copies hidden files such as .htaccess<\/code>. Miss the dot and you copy the visible files only, which on Apache means your permalinks stop working and the cause is not obvious.<\/p>\n
Its own database<\/h2>\n
This is the part that matters most. If staging points at the live database, then deleting a test post on staging deletes it from the live site, and a plugin update that mangles data mangles it for real visitors.<\/p>\n
mysqldump --single-transaction --quick -u root -p livedb > \/tmp\/live.sql\nmysql -u root -p -e \"CREATE DATABASE stagingdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;\"\nmysql -u root -p stagingdb < \/tmp\/live.sql\nrm \/tmp\/live.sql<\/code><\/pre>\n
\"Terminal
Export from live, import into a database that only staging uses.<\/figcaption><\/figure>\n
Then point the staging copy at it, in \/var\/www\/staging.yourdomain.com\/wp-config.php<\/code>:<\/p>\n
define( 'DB_NAME', 'stagingdb' );\ndefine( 'DB_USER', 'staginguser' );\ndefine( 'DB_PASSWORD', 'a-different-password' );<\/code><\/pre>\n
Before you go further, confirm it. Change the site title on staging and reload the live site. If the live title changed too, staging is still on the live database and you need to stop and fix it now.<\/p>\n
Fixing the URLs<\/h2>\n
The copied database is full of absolute URLs pointing at the live domain, so staging will pull images from live and redirect you to live when you log in.<\/p>\n
wp search-replace 'https:\/\/yourdomain.com' 'https:\/\/staging.yourdomain.com' \n  --path=\/var\/www\/staging.yourdomain.com --dry-run<\/code><\/pre>\n
\"WP-CLI
Always dry run first. It shows exactly which tables would change and how much.<\/figcaption><\/figure>\n
Use WP-CLI rather than editing the SQL file. WordPress stores serialised PHP in the options and meta tables, and a plain text replace leaves the recorded string lengths wrong, which silently breaks widgets and theme settings.<\/p>\n
Drop --dry-run<\/code> once the counts look sensible.<\/p>\n
Keeping it out of Google<\/h2>\n
A staging copy that gets indexed is a duplicate of your entire site competing with the original. Use two layers, because either one alone can fail.<\/p>\n
A password on the whole subdomain.<\/strong> This is the reliable one, since a crawler that cannot load the page cannot index it:<\/p>\n
htpasswd -c \/etc\/nginx\/.htpasswd staging<\/code><\/pre>\n
Then in the staging server block:<\/p>\n
auth_basic \"Staging\";\nauth_basic_user_file \/etc\/nginx\/.htpasswd;\nadd_header X-Robots-Tag \"noindex, nofollow\" always;<\/code><\/pre>\n
And<\/strong> tick Discourage search engines in Settings, Reading on the staging copy. That adds a noindex tag as a second layer.<\/p>\n
The reason for both is that the WordPress setting is a request, not an enforcement, and it is also the setting that occasionally travels back to production when someone copies staging over live. That mistake removes a live site from Google, which is why the password matters more.<\/p>\n
\"WordPress
The second layer. The password on the subdomain is the one that actually holds.<\/figcaption><\/figure>\n
Pushing changes live<\/h2>\n
Do not copy the staging database over the live one. Live has comments, orders and posts created since you took the copy, and overwriting it loses all of them.<\/p>\n
Push only what you changed:<\/p>\n