Skip to main content

Troubleshooting

Keeping staging and development sites out of Google

Last updated Mon, Nov 2, 2026

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

  1. Protect the staging site with a sign-in first.
  2. Add the staging host to Google Search Console as its own property, verified through DNS.
  3. 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.
  4. Search site:staging.example.org over 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

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article

Platform Notes

Get practical WebOps and cloud insights in your inbox

We publish articles on managed operations, cloud infrastructure, CMS platforms, government technology, and security, written by engineers who operate these environments every day. No marketing fluff. Unsubscribe any time.

We respect your privacy. No spam, no third-party sharing. Unsubscribe any time.