A demo site you send a client is a full WordPress install, not a picture of one. It runs the same PHP, the same plugins and the same keys as the site you are building, which means it can send real email, take real payments and appear in real search results before anyone has agreed to launch.
Every guide to building a WordPress site demo stops at "here is the URL". The interesting part is what happens in the days between sending that link and going live, because that is when a demo does something to the outside world that nobody asked it to.
This is the opposite problem to the one we wrote about in what a WordPress staging plugin can test. There the question was whether the copy behaves enough like production. Here it is whether the copy touches production, or your client's customers, when it should not.
It will send email, and to real addresses
This is the one that costs money and trust.
You built the site with a contact form, a WooCommerce checkout and an abandoned-cart plugin. All three call wp_mail(), and wp_mail() on a working server sends.
Now the client clicks around their demo at 11pm to see how the checkout feels. They place a test order with their own address, and the order confirmation goes out. If they imported the real customer list to check how the account pages look, a plugin doing a welcome sequence can reach every one of those addresses from a site that does not exist yet.
The usual advice is to install an SMTP plugin and leave it unconfigured, which is not a fix. WordPress falls back to PHP mail() when no SMTP is configured, and on plenty of hosts that still delivers, just badly.
Two things actually work. Either the environment has no mail path at all, or something intercepts wp_mail() before it reaches one.
We do the second, because "no mail path" also means you cannot check the email is right. On SandyWP every wp_mail() call is captured with its subject, recipients, headers and rendered body, and nothing leaves unless you configure your own SMTP credentials. That is the Email Log, and it exists because "did the receipt actually fire, and what did it look like" is a question you need answered on a demo more than anywhere else.
Whatever you use, verify it rather than assuming. Trigger a password reset on the demo and confirm the message landed somewhere you can read and nowhere you cannot.
Google will index it if you let it, and noindex is a request
A demo of an unlaunched business is a page you do not control the reputation of.
The standard step is Settings, then Reading, then Discourage search engines. That writes a noindex meta tag, and a noindex tag is a polite request that most crawlers honour and some do not. It also does nothing about the link your client pastes into a Slack channel that syncs to a public archive.
For an unlaunched brand the difference matters. A demo indexed under the client's company name can be the first result for that name, showing placeholder copy and lorem ipsum, weeks before the real site is ready to compete with it.
HTTP authentication is the version that actually holds, because a crawler that ignores noindex still cannot get past a 401. A demo you password-protect is one you never have to think about again.
If you can only do one thing, do that one. It is stronger than noindex and it takes less time to set up.
The keys in wp-config.php are still live
A demo built from a copy of a working site carries whatever that site was configured with.
The list is short and worth reading down every time:
- Payment gateways. A Stripe or PayPal plugin left in live mode charges a real card. Test mode is a per-gateway setting, and having one gateway in test mode says nothing about the second one the theme bundled.
- Analytics and pixels. A GA4 or Meta pixel firing from the demo pollutes the property you will report on later, and does it with traffic that is you clicking around.
- Transactional email providers. A Postmark or SendGrid key sends regardless of what WordPress thinks its site URL is.
- CRM and marketing integrations. A form plugin wired to HubSpot or Mailchimp writes test submissions into the real list.
- Backup and sync plugins. This is the one that goes both ways. A backup plugin still pointed at the client's production site can push the demo's database over the real one.
Search the database rather than trusting your memory of what you installed. On a sandbox with SSH access that is one command, because WP-CLI is already there:
wp option list --search="*_api_key*" --format=table
wp plugin list --status=active --field=name
Read the active plugin list out loud. Anything that talks to a third party is a decision you have not made yet.
The client edits the demo, and now you have two sites
This is the failure that is not technical, and it is the most common one.
You send the demo. The client likes it, then fixes a typo on the About page, then rewrites the whole thing, then adds four images. Meanwhile you have kept working on your copy.
There is now no merge. Someone is going to hand-copy changes between two WordPress installs and lose something in the process, and it will be discovered after launch.
Decide before you send which copy is the source of truth, and say it in the message with the link. Either the demo is read-only and feedback comes back as comments, or the demo is the working site and you stop editing your own.
Be honest about the tradeoff here, because it is the real one. A demo has no path back to production. If what you need is a copy that you change and then deploy, you want staging with a deploy-back path, and we do not have one: SandyWP sandboxes are for the cases where the copy is meant to be thrown away.
A demo is the right shape when the client is approving, not editing, and when the environment itself should not survive the conversation.
Nobody plans for the demo's last day
Two opposite mistakes, both common.
The demo expires while the client is still deciding, and the work that won the approval is gone. Or the demo never expires, and eighteen months later there are forty client demos running, each with a live database and somebody's contact details in it.
Pick the lifespan when you create it rather than when it bites. SandyWP account sandboxes default to a week, and you can set anything from an hour to a month, or mark one permanent while a decision is pending. Expired sandboxes sit in a retention window before deletion, which is the difference between a close call and a rebuild.
The durable version is not the running site anyway, it is a Template. A template captures the WordPress and PHP versions, plugins, themes, files and database as a snapshot you can relaunch, so the demo can expire without the work expiring with it.
That is also how you send the second demo. Relaunch the template, do not rebuild the site.
What to check before you send the link
Five minutes, in this order, because each one has a real cost if you skip it:
- Mail. Trigger a password reset and confirm the message was captured and not delivered.
- Access. HTTP auth on, not just
noindex. - Payments. Every gateway in test mode, checked one at a time.
- Third parties. Read the active plugin list, disable anything that writes to a real account.
- Ownership. Say in the message whether the client should edit the demo or comment on it.
Then send it, with the expiry date written in the message. A client who knows the demo dies on Friday is a client who looks at it before Friday.
When a demo site is the wrong tool
If the client needs to work in the site for weeks, building content that has to survive, that is not a demo. That is their site, early, and it should live where the real one will.
If you need to test whether an upgrade breaks their existing site, you want a copy of production rather than a copy of your build, which is a different job covered in upgrade testing.
And if the answer is "we need to change it and then ship it", you need staging, not a sandbox. Saying so is cheaper than discovering it the week of launch.
For the case a demo does fit, which is showing an agency client something they can click before anything reaches their server, the pattern is on our agencies page. The short version is that the demo is a real WordPress, so treat it like one: assume it will send, index and charge unless you have specifically stopped it.
