Before the DNS Flip: A Privacy Pre-Flight for Elementor Pro Launches
You've built it, the client's happy, and the launch window is Thursday at 9am. Then a colleague sends a screenshot: the staging URL is sitting in Google, complete with last month's test price list and a phone number that belongs to nobody. Cue the deep sigh.
Staging sites leak in predictable ways. Elementor Pro doesn't cause most of these problems, but it's often where they become visible — in a form action, a custom code block, a Theme Builder template that was cloned from another project. Here's the sweep we run before the DNS flip, in the order that tends to catch the most embarrassing stuff first.
First, check whether the site is asking to be found
WordPress has a single checkbox under Settings > Reading — 'Discourage search engines from indexing this site' — and it is a request, not a force field. Reputable crawlers honour it; scrapers and the odd aggressive bot don't. So treat it as one layer, not the layer.
While you're in there, check three more things. Is there a robots.txt file at the root? If so, does it actually disallow everything, or did someone copy a production file across? Does your host put staging behind its own noindex header? Most decent UK hosts do, but it's worth confirming rather than assuming. And has anyone added the staging domain to Google Search Console? If it's indexed, you'll want to remove the URLs there as well as fixing the underlying cause — otherwise you're waiting weeks for a recrawl.
The other classic: someone set up a Search Console property for the live domain months ago and the client's marketing person has been watching the staging site's impressions climb, assuming it was the real thing. Worth a quick message before launch day.
Forms are where the real data hides
Elementor Pro forms are brilliant and slightly too easy to duplicate. That's how a client's actual inbox ends up in the 'To' field of a staging form while you're still testing, and how a real Stripe key ends up pasted into a field that only ever needed a test one.
Work through the Actions After Submit list on every form. Email notifications: are the recipients placeholder addresses or real people? If the client has been receiving test submissions for a fortnight, they've been receiving whatever personal data the form collects — names, emails, sometimes more. Under UK GDPR that's a processing activity nobody signed off on.
Then the integrations. Mailchimp, HubSpot, ActiveCampaign, Zapier webhooks — each one may be pointed at a live list or a live automation. If the staging form has been quietly adding test contacts to a client's real mailing list, someone is going to notice, and it won't be you.
Payments deserve their own pass. If you've wired Stripe, PayPal or a payment field into a form, confirm the account is in sandbox or test mode, and that live keys aren't sitting in a hidden field, a custom code snippet or a snippet in the child theme. It happens more often than anyone admits.
Password protection is not privacy
A password-protected staging page stops a human from reading the content. It does not stop a GA4 tag, a Meta pixel or a LinkedIn Insight tag from firing when you or the client loads the page. That's still personal data — IP address, device, behaviour — being sent to third parties without a lawful basis, and the ICO's line on analytics and consent hasn't exactly softened.
So check Elementor Pro's Custom Code area (Elementor > Custom Code), any tracking snippets in the theme, and any plugin that injects tags site-wide. If you're running a consent tool, confirm it's active on staging too — or strip the tags entirely until the site is live. The simplest option is usually the right one: no tracking tags on staging, full stop.
The bits outside Elementor
Elementor Pro has a Replace URL tool under Tools, and it's genuinely useful, but it only touches Elementor's own data. Staging URLs also hide in the options table, in postmeta, in serialised widget settings and in third-party plugin tables. A proper search-replace — WP-CLI or a reputable plugin — is safer than clicking through the UI and hoping.
While you're at it: check that SSL is live and forcing correctly, that the site URL and home URL match the live domain, and that no leftover 'Coming Soon' mode is enabled by a plugin nobody remembers installing. Elementor's own Maintenance Mode is easy to forget if it was switched on in week one.
A sign-off log you'll actually use
Keep it short enough that people fill it in. A simple table works: item, owner, date checked, notes. Ours covers roughly a dozen lines.
- Search engine visibility off, robots.txt confirmed, staging removed from Search Console
- All Elementor Pro forms: recipients, integrations, payment mode checked
- Tracking tags removed or consent-gated on staging
- Custom Code area reviewed for staging URLs and stray keys
- Database search-replace completed, permalinks flushed
- SSL and canonical domain confirmed
- Client notified that test data will be purged on launch
That last one matters more than it looks. A short email confirming what was tested, what was deleted and when the site goes live saves an awkward conversation later — and if the client has a DPO or a compliance lead, they'll want it on file.
None of this is glamorous. But a half-hour sweep before the DNS flip is cheaper than a breach notification, a confused Google index or a client asking why their mailing list has forty contacts called Test McTestface. Do it once, log it, and launch on time.
