Google can find a staging site nobody linked to. A developer pastes a staging link into a public issue tracker, a browser extension reports visited pages, a certificate transparency log lists the new host name, or a page on staging links to itself with a full address. Within days, test pages, placeholder text, or unreleased announcements can appear in search results alongside your real site, sometimes above it.
Why it matters
- Duplicate content: two copies of the same pages compete in search, and the wrong one can win.
- Unfinished work in public: draft pages, lorem ipsum, broken layouts, or test forms that send real email.
- Leaked information: an announcement, price, or personnel change published early on staging.
- Confused visitors: people bookmark the staging address and wonder why it stops working.
The right way: require a sign-in
The only reliable protection is to keep staging behind a sign-in, such as single sign-on, a password prompt, or an IP restriction. Search engines cannot index what they cannot reach. A robots.txt file that says "do not crawl" is a request, not a lock: well-behaved crawlers obey it, but pages can still appear in results as bare links when other sites link to them, and anyone can still open them.
The second layer: noindex
A noindex instruction tells search engines not to list a page, even if they reach it. It can be set as a meta tag in the page or as an X-Robots-Tag header for the whole site. For it to work, the crawler must be able to read the page, so do not block the same pages in robots.txt at the same time. Make sure the setting is never copied to production: a staging setting carried over at launch can remove the live site from Google.
If staging is already in Google
- Protect the staging site with a sign-in first.
- Add the staging host to Google Search Console as its own property, verified through DNS.
- Use the Removals tool to hide its pages from results quickly. This is temporary on its own, which is why the protection in step 1 matters.
- Search
site:staging.example.orgover the following weeks to confirm pages are dropping out.
Check your own sites
Search Google for site: followed by each non-production host name you use, such as staging, test, dev, or old. Also search for a distinctive phrase from a page that exists only on staging. If anything appears, follow the steps above.
At launch: the opposite problem
When a new site goes live, check that it does not still carry the staging site's noindex setting or a "discourage search engines" option. WordPress has a setting under Settings, Reading for exactly this, and it is a common cause of a new site vanishing from search after launch.
Notes by platform
WordPress: "Discourage search engines from indexing this site" adds noindex; it does not password-protect. Drupal: use access restrictions at the server or a module, and environment-specific settings so production is never affected; see structuring Drupal environments. Cascade: staging destinations are separate hosts; protect them at the hosting layer.
Common questions
Can we just delete the staging site? If it is no longer needed, yes, and remove its DNS record too. If it is needed, protect it.
Will removing staging pages hurt the live site? No. It usually helps, by removing duplicate copies.
Do AI crawlers follow the same rules? The major ones honor robots.txt and noindex, but only a sign-in stops all of them.
Google Search Console emailed us about indexing issues. Is that the same thing? Not necessarily. Those emails often concern the live site: pages blocked by mistake, redirects, or 404s. Read which host and pages they name before acting.
Can staging share the live site's sitemap? No. Each environment should only list its own pages, and staging should not submit a sitemap at all.
How eWay handles staging
On environments eWay manages, staging and development sites are separate environments, configured so production settings and staging settings do not cross over. eWay can put a staging site behind single sign-on or an IP restriction, add noindex headers, verify the host in Search Console with you, and check at launch that no staging setting reaches production.
What to include in a support ticket
- The staging or test addresses that appear in search
- How your team signs in to staging today, if at all
- Who should have access
eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: Dev, Test, and Live environments and requesting access to staging sites.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article