Staging in one minute
A staging site is a second, private copy of your live website, kept on the same kind of server, where a developer tries out a change before your customers ever see it.
If an update breaks the menu, a form stops sending or the checkout throws an error, it happens on staging, nobody loses a booking, and the problem gets fixed before anything touches the real site.
That is the whole reason it exists: to separate "trying" from "publishing". When a developer tells you "we will test it on staging first", they mean the change is going to a rehearsal stage, and only after it works there will it be copied across to the public site. For a Bangkok hotel taking direct bookings or a shop running a Songkran promotion, that rehearsal is the difference between a quiet Tuesday fix and a broken website on the busiest weekend of the year.
A staging site is not a backup. A backup is a frozen copy you restore after something goes wrong; staging is a working copy you use so that it does not go wrong in the first place. You need both, and our guide to keeping WordPress backups you can actually restore covers the recovery side.
Development, staging and live
Most professional setups use three copies of the same website; if the wider vocabulary is new to you, our introduction to web development explains the parts. Small sites sometimes merge the first two, but the roles stay the same.
Development
This is where the developer writes code, usually on their own computer. It can be messy and half finished. You rarely see it, and it does not need real content.
Staging
This copy sits on a server and mirrors the live site as closely as possible: same theme, same plugins, same PHP version, a recent copy of the content. It is the version you, the owner, get a link to when we ask you to check a new page layout or a changed booking form. If it works on staging, it should work on live.
Live (production)
The public website on your real domain. Customers, Google and your LINE followers all land here. Nothing experimental should happen on it directly.
The value of staging depends on how closely it matches live. A staging copy running a newer PHP version, or missing the caching layer your host adds, can pass every test and still fail after launch. That is one reason your choice between shared, cloud or managed hosting matters: better hosts make an identical copy easy.
What should you test on staging first?
Not every edit needs a rehearsal. Fixing a typo in a blog post can go straight to live. The changes below are the ones that most often break a working site, so they belong on staging every time.
- Plugin and theme updatesEspecially major versions, page builders, WooCommerce itself and anything that touches forms or payments.
- PHP version upgradesHosts retire old PHP versions; older plugins can fail with a blank page on the new one.
- Redesigns and new templatesCheck every page type on a phone, not only the home page.
- Checkout and payment changesNew shipping rates for Thai couriers, a new PromptPay or card gateway, COD rules or coupon logic.
- New or edited formsContact, booking and quote forms, including where the entries go and the consent checkbox.
- Language switchingOn a bilingual Thai and English site, confirm each page links to its real translation.
How is a staging site created?
There are three common routes. None is wrong; they suit different sites.
Your host's one-click tool
Many managed WordPress hosts include a staging button in their control panel. It copies the site to a private address and later pushes it back. It is the easiest option and usually the best matched to live, because it runs on the same server stack. The catch: each host's push works differently, and some only push everything at once, which matters for shops (more on that below).
A staging plugin
Plugins such as WP Staging create a copy inside your existing hosting account. They work on cheap shared hosting that has no staging tool, but they use your disk space and server resources, and the free versions often cannot push changes back, so you repeat the work by hand on live.
A manual copy on a subdomain
A developer copies the files and database to something like staging.yourdomain.com. It gives full control over what is copied and when, and it is a common choice for sites with custom themes. It needs someone who knows what they are doing, because a careless copy can leave the staging site sending real emails or showing up in Google.
Keeping staging private and out of search
A staging copy is a full duplicate of your website on another address. If Google finds it, you can end up with two versions of every page competing in search, visitors landing on test pages with half-finished prices, and old staging URLs appearing in results months later.
There are two ways to keep it hidden, and they are not equal.
- Noindex. A tag or header that asks search engines not to list the page. Google respects it, but only after it crawls the page and reads the tag, and anyone with the link can still open the site. WordPress has a "discourage search engines" setting that does something similar; it is easy to forget it is switched on and then copy that setting to live by accident, which quietly removes the real site from search.
- Password protection. The server asks for a username and password before showing anything. Search engines cannot crawl what they cannot open, and a curious competitor cannot browse your unreleased pages either.
Password protection wins. Use noindex as a second layer if you like, but make sure it is removed from live after every push. If your staging copy has already been indexed, a password plus a removal request in Search Console usually clears it.
Pushing changes live without losing orders
A website is two things: files (theme, plugins, images) and a database (pages, settings, users, orders, form entries). Pushing staging to live can mean copying either or both, and that choice is where most staging accidents happen.
The WooCommerce trap
Say you copy your shop to staging on Monday and spend three days testing a new checkout. Meanwhile, the live shop takes 40 orders and several new customer accounts. On Thursday you push the whole staging database back to live. Those 40 orders, the new accounts and any stock changes disappear, because the staging database never had them. WooCommerce's developer documentation sums up the rule as "code goes up, content goes down": push code to live, never the staging database.
The same applies to a clinic taking appointment requests through a form, or a hotel storing enquiries in WordPress: a full database push overwrites everything that arrived after the copy was made.
Safer ways to go live
- Push files only when the change is code: theme edits, plugin updates, new templates.
- Recreate settings changes by hand on live, following a written list from staging.
- If the database must move, do it in a short, announced maintenance window, after a fresh backup, with the shop paused.
If something still goes badly wrong, whether from a bad push or an attack, our guide to recovering a hacked WordPress site covers cleanup, which is a different job from testing.
Customer data, emails and payments on staging
A staging copy made from live contains everything live contains: customer names, phone numbers, addresses, order history, form submissions. Under Thailand's Personal Data Protection Act, that data needs the same care wherever it sits, and a forgotten test site with a weak password is an easy way for it to leak, with the consequences described in our guide to PDPA penalties and fines.
Three habits keep staging safe.
- Anonymise where you can. Replace real customer names, emails and phone numbers with dummy values after copying, or delete old orders you do not need for the test. Less real data on staging means less to protect.
- Stop outgoing email. Otherwise, testing an order status change can send a real "your order has shipped" message to a real customer. Developers use a mail-catching plugin or disable sending entirely.
- Put payments in test mode. Switch the payment gateway to its sandbox or test keys so no card is charged and no PromptPay QR points at your real account. Also pause scheduled jobs such as subscription renewals and stock syncs with marketplaces.
Delete staging copies you no longer use. An old copy nobody updates is both a privacy risk and an easy target.
Staging as part of maintenance
Does a small brochure site need staging? A five-page site with no forms beyond a contact button can often skip a permanent one: take a backup, update, check the pages, done. Once a site takes bookings, payments or regular enquiries, staging stops being optional, because the cost of a broken afternoon is real money.
For most businesses, staging is not a one-off project. It is part of what website maintenance is in practice: monthly updates go to staging, get checked, then move to live. A regular maintenance checklist will tell you what to check each month; this article was about where those checks should happen.
If you would rather not manage copies, pushes and test modes yourself, our care after launch can include testing changes before they go live. It is priced per site on request, and the page on what ongoing website care costs explains what shapes that price. You can WhatsApp or call +66 93 004 4098, or email service@websitedevelopmentbangkok.com, every day from 10:00 to 19:00 Bangkok time.
Keep reading
Sources
- Google Search Central: block search indexing with noindex
- WooCommerce developer docs: version control and deployment
- Personal Data Protection Act B.E. 2562 (2019), English translation
Builds and ranks the websites: the systems behind the 17 client sites whose Search Console numbers we publish. This guide was written by the Website Development Bangkok team. More about us