You or someone on your team was actively working inside a SiteGround staging copy earlier today or perhaps just now, and now the live domain, the one real visitors and customers actually use, is showing that same staging content. Maybe there is a staging banner across the top of every page. Maybe a password prompt is blocking visitors entirely. Maybe visitors just see a site that looks completely broken, with missing styling and links pointing to a staging subdomain that visitors have never heard of. Whatever the exact symptom, the underlying question is the same, and it deserves a calm, methodical answer rather than a panicked guess: how did staging content end up on the live URL, and what is the fastest, safest way to get the real site back for everyone visiting it right now.
This is one of the more stressful hosting incidents because it is visible to every visitor immediately, unlike a slow performance issue or a quiet backend error that only shows up in analytics days later. The good news is that SiteGround’s Site Tools platform only has a small number of ways this can actually happen, and once you know which one occurred, the fix is usually fast. This guide walks through each cause, how to tell them apart, and the exact recovery steps for each.
Why this happens and what it actually means
SiteGround’s staging feature, available on GoGeek and higher plans along with cloud hosting, creates a full copy of your live site, files and database together, accessible through its own subdomain, typically something like staging1.yourdomain.com. That staging copy is meant to remain completely separate from the live site until a deliberate action, called Push to Live, moves specific changes across. Staging content appearing on the actual live URL means one of a small number of specific things happened outside of that intended, deliberate workflow, either a push action ran when it should not have, a caching layer served the wrong content under the live domain, or the site’s own configuration was pointed at the wrong location. None of these are common in isolation, which is exactly why this incident tends to catch people off guard, it is rare enough that most site owners have never seen it before and do not immediately know which of the small number of causes applies to their specific situation.
The four ways staging content ends up on your live domain
First, an accidental or premature Push to Live action, meaning someone clicked the push button inside Site Tools before changes were actually ready, or a team member pushed changes without realizing the live site was actively being used by real visitors and customers at that exact moment. Second, a caching layer, either SiteGround’s own built in caching or a connected Cloudflare integration, serving a cached staging response under the live domain’s hostname, which can happen when both the staging and live versions were recently accessed close together in time and a cache key collision or an incomplete cache purge left stale content being served. Third, the WordPress database’s own siteurl and home values, normally correct on both staging and live independently, ending up pointed at the wrong domain, typically after an interrupted or partial push that updated files but not the database, or the reverse, leaving the two layers out of sync with each other in a way that is not immediately obvious from the dashboard alone. Fourth, a document root misconfiguration at the server level, where the live domain’s web server configuration was, usually through a manual change made through Site Tools or support, temporarily or permanently pointed at the staging copy’s file location instead of the live site’s own directory.
Cause 1: an accidental push to live
This is the single most common cause behind this exact symptom, and it is also the easiest to confirm. SiteGround’s Push to Live feature, found inside Site Tools under the Staging section, offers two modes, Easy Push, which copies both files and database changes from staging to live in one action, and Advanced Push, which lets you review and select specifically which files and database changes to include before confirming. An Easy Push triggered by mistake, or by a team member who did not realize the potential impact, copies the entire staging environment onto the live site immediately, including any staging specific content, placeholder text, broken links pointing to the staging subdomain, or password protection settings that were only ever meant for the staging copy. Checking the Staging section inside Site Tools for a recent Push to Live entry in the activity log confirms within seconds whether this specific action is what happened, and the timestamp on that log entry, compared against when the live site started showing staging content, is usually an exact match.
Cause 2: a cached response served by the cdn
If no push action shows in the activity log, the next most likely cause is caching. SiteGround’s platform includes its own built in caching layer by default, and many accounts additionally use SiteGround’s Cloudflare integration for a further CDN layer in front of that. Both of these caching layers are designed to key cached content by hostname, but a misconfiguration, a recent DNS change, or an edge case where staging and live briefly shared infrastructure during a plan change or account migration, can result in a cached staging response being served under the live domain’s hostname until that specific cache entry expires or is manually purged. This cause is distinguishable from an accidental push because the underlying files and database on the live site remain completely untouched, meaning a cache purge alone resolves it entirely, with nothing to restore, roll back, or repair afterward.
How to tell a push accident apart from a caching issue quickly
Since the fix for each of these two most common causes is completely different, one requiring a restore and the other requiring only a cache purge, correctly identifying which one occurred before taking action saves meaningful time. A push accident changes the actual files and database sitting on the server, meaning the incorrect content persists consistently across every browser, every device, and every network, with no variation at all. A caching issue, by contrast, is frequently inconsistent, showing the correct live content from some networks or devices while showing the stale staging content from others, specifically because different cache layers and different geographic CDN edge locations expire and refresh on their own independent schedules rather than all at once. Testing the live URL from at least two clearly different networks, for example your office WiFi and a phone on mobile data with WiFi turned off, and comparing what each shows, is frequently enough on its own to distinguish between the two before checking anything inside Site Tools at all. A push accident shows the same broken result everywhere immediately, while a caching issue often shows the correct result from at least one of the two networks tested.
What actually happens when files and database get pushed together
Understanding what a push genuinely does mechanically helps explain why the symptom looks the way it does. An Easy Push copies the entire staging file structure over the live site’s file structure, replacing themes, plugins, uploads, and core files wholesale rather than merging changes selectively, and simultaneously copies the staging database over the live database in the same action. This means any content, orders, comments, or form submissions that existed only on the live site, created after the staging copy was originally made, are overwritten and lost the moment the push completes, not just visually replaced but genuinely gone from the live database unless a backup exists from before the push happened. This is precisely why SiteGround’s own interface displays a warning before confirming an Easy Push, though that warning is easy to click past quickly, particularly under time pressure or when a team member is not fully aware of how much live activity has happened since the staging copy was created.
Why staging copies can get stale without anyone noticing
A staging copy is a snapshot taken at a specific moment, and unless it is refreshed deliberately, it does not automatically stay in sync with ongoing changes to the live site. A staging copy created weeks earlier, then pushed to live without first being refreshed, effectively rolls the live site back to that earlier snapshot, undoing any legitimate content updates, plugin updates, or configuration changes made directly on the live site in the meantime, in addition to whatever unrelated staging content triggered the original concern about pushing at all. This is a subtler variant of the same underlying problem, since the visible symptom, staging content appearing where live content should be, looks identical whether the staging copy is a day old or two months old, but the practical impact of restoring from backup afterward differs significantly depending on how much legitimate live activity happened during that gap.
Related reading on siteground and hosting migration troubleshooting:
1. Cloudways vs SiteGround: cloud hosting for traffic spikes
2. FTP connection times out after switching to SiteGround
3. SiteGround gzip compression not working after enabling in dashboard
4. Bluehost cPanel shows disk quota exceeded right after migration
5. WordPress multisite returns 404 on all subdomains after host change
Cause 3: wp-config or database urls pointing at staging
WordPress determines which domain it considers itself to be running on through two specific values stored in the database, siteurl and home, both found inside the wp_options table, along with any hardcoded values inside wp-config.php on some custom configurations. An interrupted push, one that copied files successfully but was cancelled, timed out, or failed partway through the database portion, can leave these values pointing at the staging subdomain even though the files themselves are correctly sitting in the live site’s directory. This produces a distinctive symptom, the live domain loading in a browser but every internal link, every image, and every asset URL pointing back to the staging subdomain instead, often breaking styling entirely since stylesheets fail to load from what looks, to the browser, like an entirely different and possibly password protected domain. Checking these two specific values, either through phpMyAdmin accessible through Site Tools, or through WordPress’s own wp-config.php file if hardcoded there, confirms this cause directly, and correcting them back to the live domain’s correct URL resolves the symptom immediately once saved.
Cause 4: a document root misconfiguration
This is the least common cause but the most serious, since it means the web server itself, not WordPress or any caching layer, has been told to serve the staging copy’s files when a visitor requests the live domain. This typically only happens following a manual change made either directly by SiteGround support during a troubleshooting session, or through a domain or subdomain management action inside Site Tools that inadvertently altered which physical directory the live domain points to. Confirming this cause specifically requires checking Site Tools under Site, then Website, for the exact document root path currently assigned to your live domain, comparing it against the path your staging copy uses, which is normally listed clearly in the Staging section. If these two paths match, or if the live domain is somehow pointing inside what should be the staging copy’s own directory structure, this is confirmed as the cause, and the fix requires either SiteGround support directly correcting the document root assignment, or careful manual correction if you have the access and confidence to do it yourself.
More hosting intelligence
Step by step: your first response checklist
Before diagnosing which of the four causes applies, take a few immediate steps that apply regardless of the underlying cause. First, avoid making further changes to either the staging or live environment until the cause is confirmed, since additional pushes or edits made while troubleshooting can make the eventual fix more complicated by mixing correct and incorrect changes together. Second, check the Push to Live activity log inside Site Tools immediately, since this single check either confirms or rules out the most common cause within seconds. Third, open the live site in an incognito or private browser window, and separately try loading it from a mobile network rather than your regular WiFi, since this distinguishes a genuine server side issue, which shows the same way from both, from a caching issue specific to your own browser or network, which often shows correctly from one and incorrectly from the other.
Restoring from a backup: the fastest way back to normal
If an accidental push is confirmed as the cause, SiteGround’s automatic daily backups, included on every plan, provide the fastest reliable path back to a working live site. Inside Site Tools, under the Backup section, selecting a backup from immediately before the accidental push, then choosing to restore, brings the live site back to its exact pre-push state, files and database together. This is generally faster and safer than attempting to manually reverse specific individual changes, since a restore addresses every affected file and database table at once rather than requiring you to identify and correct each one individually. The one tradeoff worth knowing before restoring is that any genuine order, comment, form submission, or other live database activity that happened between the backup’s timestamp and the moment of restoration will be lost along with the accidental push, which matters significantly more for an active ecommerce site than for a mostly static brochure site, and is worth weighing before choosing a restore point.
Purging siteground's cdn and browser caches
If caching is confirmed as the cause rather than an actual content change, no restore is needed at all, only a cache purge. Inside Site Tools, under Speed, then Caching, a Flush Cache option clears SiteGround’s own built in dynamic caching layer immediately. If Cloudflare is connected through SiteGround’s integration, a separate purge is needed specifically at the Cloudflare level, accessible through the same Speed section or directly through a connected Cloudflare account if managed separately, since SiteGround’s own cache and Cloudflare’s edge cache are two distinct layers that do not automatically clear each other. After purging both layers, testing again from an incognito window and a different network, as covered in the first response checklist, confirms whether the correct live content is now being served consistently rather than only appearing correct intermittently as different cached edges expire on their own separate schedules.
Fixing stale site url values in the database
If the siteurl and home values in wp_options are confirmed as pointing at the wrong domain, correcting them directly through phpMyAdmin, accessible inside Site Tools under the Database section, resolves the issue without needing a full restore. Locating the wp_options table, finding the rows where option_name equals siteurl and option_name equals home, and editing the option_value field for each to the correct live domain, saves and takes effect immediately on the next page load. For a WordPress installation using a security or configuration plugin that hardcodes these values inside wp-config.php instead of relying on the database alone, checking that file specifically for a WP_SITEURL or WP_HOME constant, and correcting the domain there as well, is necessary since a hardcoded value in wp-config.php overrides whatever the database itself contains.
Protecting the staging environment properly going forward
SiteGround’s Protected URLs feature, found under Security inside Site Tools, lets you set a username and password specifically on the staging subdomain, which serves two purposes simultaneously, keeping the unfinished work private from search engines and casual visitors, and, just as importantly, making an accidental visit to the staging URL immediately obvious to whoever is doing the visiting, rather than looking like a normal, finished page. Confirming this protection is active on every staging copy, not just the one currently being worked on, closes an entire category of confusion where a client or team member stumbles onto an old, forgotten staging copy and reports it as if it were a live site problem.
Setting up a safer push to live workflow for teams
For any team with more than one person able to trigger a push, agreeing on a specific, simple rule, that only Advanced Push is used rather than Easy Push, and that a second team member reviews the list of changes before confirming, adds a deliberate checkpoint that catches an accidental or premature push before it actually happens rather than after. Scheduling pushes for specific low traffic windows, rather than whenever a change happens to be finished, reduces both the visible impact of a genuine accident and the pressure to rush the confirmation step. Keeping a simple shared log, even something as basic as a shared note listing who pushed what and when, gives whoever discovers a problem later a fast starting point rather than needing to reconstruct the timeline from Site Tools activity logs alone under time pressure.
Communicating with clients and visitors while you fix it
If the live site is genuinely down or showing broken content while you work through the diagnosis, having a short, calm message ready for anyone who reports the issue, whether a client, a customer, or your own team, keeps the incident from escalating into a bigger perception problem than the technical issue itself. Acknowledging the report immediately, even before the exact cause is confirmed, and giving a realistic estimate based on which cause seems most likely, sets expectations honestly rather than leaving someone refreshing the page repeatedly with no information. A short message along the lines of confirming the issue is known, actively being worked on, and expected to be resolved within a specific short window, goes a long way toward keeping a client calm even before the technical fix itself is complete, since most of the anxiety in these situations comes from uncertainty about whether the problem is even being addressed at all rather than from the outage itself. For a site handling live transactions specifically, checking whether a payment gateway or checkout process was affected during the incident, separate from the visible content issue, matters because a customer who attempted a purchase during the window when staging content was showing may have encountered a broken checkout rather than simply an unusual looking page, which is worth following up on directly rather than assuming no real transactions were affected.
When to involve siteground support directly
Most causes covered in this guide are fixable independently through Site Tools without needing to open a support ticket at all, but a few specific situations genuinely warrant contacting SiteGround support directly rather than continuing to troubleshoot alone. A confirmed document root misconfiguration, since correcting it requires server level access beyond what Site Tools exposes to account holders directly, is the clearest case. A situation where the Push to Live activity log itself appears incomplete, missing an entry you are certain should be there, or showing a timestamp that does not match what your team remembers, is worth flagging to support as well, since an inconsistency in the platform’s own logging is unusual and worth having confirmed rather than assumed. SiteGround’s live chat support, generally responsive around the clock, is typically faster for this kind of active incident than a ticket queue, and having your domain name and a brief, specific description of what you have already checked ready before starting the chat speeds up the resolution considerably compared to describing the symptom from scratch.
A real world walkthrough of this exact incident
A marketing agency was finishing a redesign for a client’s law firm website inside a SiteGround staging copy, planning to review it with the client the following morning before pushing anything live. A junior team member, intending to push a single unrelated content fix to the live site for a different client entirely, selected the wrong website inside Site Tools and triggered an Easy Push, instantly replacing the law firm’s live site with the unfinished redesign, complete with placeholder images and a visible staging banner. The senior developer, checking the Push to Live activity log within minutes of the client reporting the issue, confirmed the exact timestamp and immediately restored from the automatic backup taken just before the push, which had run only twenty minutes earlier as part of SiteGround’s daily schedule. The live site was back to its correct, original state within ten minutes of the client’s report, and the agency’s only lasting change afterward was formalizing a rule that every push, regardless of urgency, required a second team member confirming the correct website was selected before the button was clicked. The agency also added a small but effective habit to their process afterward, renaming each staging copy inside Site Tools to include the client’s name directly in a note field, rather than relying on developers to remember which numbered staging subdomain belonged to which client purely from memory during a busy afternoon juggling several projects at once.
The bottom line on staging showing up on your live url
This incident looks alarming because it is instantly visible to real visitors, but the underlying causes are a short, specific list, an accidental push, a caching issue, a stale database URL, or a document root misconfiguration, and each has a clear, fast fix once identified. Checking the Push to Live activity log first, since it is the single fastest check and also the most common cause, followed by a cache purge if the log shows nothing, resolves the overwhelming majority of cases within minutes, well before a client or customer has time to notice anything beyond a brief, easily explained blip. The broader habit worth building from any single incident like this one is not to eliminate every possible cause forever, since mistakes and misconfigurations happen even with careful teams, but to make sure the diagnostic order, activity log, then cache, then database, then server configuration, is second nature the next time something looks wrong, so the actual downtime stays measured in minutes rather than growing into an anxious afternoon of guessing where to even start looking.
