I’m also a user of Siteground, and when they made their staging tool available to my hosting plan level I tried to implement it, but back then I concluded that it was not possible without un-proxying the staging subdomain.
Take the following with a pinch of salt, as this is my guess based on my attempts to make staging work, not their official word on this (you may want to check with their support). Their documentation says you need to have a DNS A record pointing to the staging subdomain, but I believe what they expect is that the A record point to your Siteground-assigned IP address, so their staging bot can know which of their servers hosts it.
When you add the staging subdomain as an A record in Cloudflare and set it to be proxied (), though you of course see your origin server IP address on the CF dashboard, visitors, including Siteground bots, will only see the Cloudflare-assigned IP address, not your origin IP address.
The only way I have been able to make Siteground staging work was by un-proxying () the A record for the subdomain. But that has the following consequences:
- all Cloudflare protections (WAF, Firewall Rules, Page Rules etc) as well as all performance enhancements (caching, image optmization if applicable, etc) are NOT applied to the subdomain; and
- the IP address of your origin server is exposed.
For those reasons, I gave up their staging tool. As a turnaround, I use Softaculous to copy my WordPress installations into test. subdomains. Though not as good a solution as staging would be, it helps me test plugins, page layouts etc, before implementing them on the production site.