How to Block Google From Accessing a Staging Website

When you use a staging website for developing or testing purposes, you might be confronted with the question of what is the best way to protect your staging site from being indexed by Google.

Since the first release of WP Staging, the staging site is protected by a custom authentication login prompt. We have always believed this is the only reliable solution to prevent Google from accessing the staging site.

If it is not accessible, there is no risk that Google can index the staging site content at all. That is very important because any duplicate content can lead to a loose of rankings in the search engine as a final consequence.

There are additional technics like setting up the header meta tag to noindex – which is something WP Staging also does – and to prevent accessing the staging site by adding an entry in the robots.txt. Unfortunately, none of these options are reliable enough, and a small error in your configuration can lead to an openly accessible staging website, which would be a bad thing for your search engine results.

We are glad that John Müller – Webmaster Trends Analyst at Google – recently answered this question and confirmed that server authentication is the best way to do this:

“Ideally, what you would want to do is provide some kind of server-side authentication on the server so that normal users when they go there they would get blocked from being able to see the content; that would include GoogleBot.

And you can do that on an IP address basis, you can do it with a cookie, you can do it with normal authentication on the server.

Anything where you have to prove that you’re the right person and you can actually look at that content.

I think that’s generally the best approach for staging servers…”

Watch John Müller’s answer here:

You can read more about this topic here:
https://www.searchenginejournal.com/how-to-block-google-staging-site/

Author: Rene Hermenau

I'm René Hermenau, founder of WP STAGING. I've been building WordPress infrastructure software since 2013 and writing code on GitHub since 2011. My repos live at github.com/rene-hermenau. WP STAGING started as a small developer project solving the same problem I kept hitting on client work: there was no fast, safe way to clone a WordPress site for staging or migration without breaking serialized data, file paths, or media references. Today we are a team of more than 10 people. The free plugin runs on hundreds of thousands of WordPress installations, and the Pro version powers backup, migration, and staging workflows for agencies, hosting platforms, and ecommerce stores. I'm still hands-on with the codebase and technical architecture. Our releases are built as a team, but many of the core architectural decisions are ones I helped design, test, and evolve over the years: how we handle large database exports, how we keep memory usage flat on multi-GB sites, and how we make migrations atomic against partially written tables. "When you touch code, leave it 10% better than before and write a test." If you're stuck on a WP STAGING question, the docs are at wp-staging.com/docs. If you hit a bug, file it on GitHub at github.com/wp-staging. Our team reads everything that lands there.