Guide to Creating a Staging Subdomain and Preventing Indexing

Your main site is up, customers are buying, and you can't risk testing a new plugin directly on the production version. So you create a subdomain: test.example.com. Half an hour later, you discover Google has indexed that test page, the test site's contact form is sending real emails, and the test version's internal links point to the main domain. This article is exactly about these three pains.

Where to create the staging subdomain: DNS or hosting panel

The first decision is whether to create the DNS record yourself or let the hosting panel do it. If the domain is on the same server as the hosting, the panel usually adds an A record automatically and that's that. If you manage DNS elsewhere, you need to add it manually:

test.example.com.    3600    IN    A    203.0.113.45
www.test.example.com. 3600   IN    CNAME    test.example.com.

The number 3600 is the TTL, meaning one hour. For a staging subdomain, lower this number; 300 means five minutes. The reason is simple: when you later change the IP or delete the subdomain, you don't want to wait an hour for the DNS cache to clear worldwide. If you're not sure whether the record was published correctly, use the DNS and network lookup and compare the returned value with what you entered in the panel.

A point that trips up many people: the subdomain is created in DNS, but the web server must also know to serve this domain. If you only create the A record and don't add the domain in the hosting panel, the browser will get the server's default page or a 404 error. The correct order is: first add the domain in the panel, then set the DNS record.

Preventing the staging subdomain from being indexed

This is the most important part, and the biggest mistake happens right here. A test subdomain that gets indexed can produce duplicate content and, in the worst case, show the test version instead of the main version in search results. There are three layers of protection, and I apply all three at the same time.

Layer one: the X-Robots-Tag header

This header rides on every response the web server sends, even PDF files and images that have no way to carry a meta tag. In the .htaccess file at the subdomain root:

Header set X-Robots-Tag "noindex, nofollow, noarchive"

If the mod_headers module isn't enabled, this line is silently ignored. Test it: curl -I https://test.example.com and see whether the header is in the output. You won't notice its absence with the naked eye; only Google sees it.

Layer two: robots.txt

User-agent: *
Disallow: /

This file blocks crawling, but not indexing. If something links to the test page, Google can index it even without crawling. That's why robots.txt alone isn't enough and must be combined with the noindex header. If you want to see the full list of directives, the complete htaccess directives reference for Linux hosting explains all the options with examples.

Layer three: HTTP authentication

If you want no bot to even reach the login page, put the entire subdomain behind a password:

AuthType Basic
AuthName "Staging"
AuthUserFile /home/user/.htpasswd
Require valid-user

The cost is that you yourself have to enter the password every time, and tools like PageSpeed Insights can no longer analyze the page. For quick tests, this is annoying. I usually always apply layers one and two, and only enable layer three when a real client is working on the test version.

Here's where people make a mistake: many put a robots.txt file on the subdomain but forget that WordPress by default generates a virtual robots.txt file and ignores the physical file. The result is that the file is on disk, opens in the browser, but Google sees something else. The solution: in the reading settings, enable the prevent-indexing option from within WordPress itself, or override the physical file with the relevant filter.

Syncing the staging subdomain with the main site

After the subdomain is created and hidden from Google's view, the next question is: how do we bring production content onto the test site without breaking anything?

Database

Create a separate database, don't connect to the main database. If the test version's wp-config.php points to the production database, the first plugin test can alter real tables. For creating a database and user, creating a database and connecting it to the site walks through the steps.

To transfer, take a dump and import it. If the database is over a few hundred megabytes, a simple import from phpMyAdmin usually hits a timeout error. We've explained the correct method in importing a large SQL file without timeout and errors.

After importing, replace the URLs. A simple sed is enough:

sed -i 's|https://example.com|https://test.example.com|g' dump.sql

If you don't do this, your test version will link to the main domain everywhere and every user click will take them out of the test environment. I've seen this a lot in practice: the site admin tests, clicks a button, and unknowingly lands on the main site.

Files and permissions

Copy files with rsync, not with cp -r. The reason is that rsync only transfers the differences, and the second time you want to update the test site, it takes seconds instead of minutes:

rsync -avz --exclude='wp-content/cache' /var/www/main/ /var/www/test/

Don't change file permissions manually. chmod 777 isn't a solution, it's a new security problem. See the correct values in chmod values: the meaning of each digit and the correct value for each file, and if you're not sure which file needs what level, read file permissions on Linux hosting.

Scheduled tasks and email

Everyone forgets these two. If the main site's cron has also been copied to the subdomain, two versions of the same script run simultaneously and may record a row twice. Disable the subdomain's crons or move their schedule to hours that don't conflict. We have the correct field syntax in cron syntax: complete reference for the five fields.

Same with email. WordPress on the test subdomain sends real transactional emails. Install an SMTP plugin and route all emails to a local inbox. Otherwise, customers receive duplicate order confirmation emails and you have to explain.

Which method should I choose?

My choice for most projects is the first option. It's fast, has no extra cost, and is enough for 90% of tests. But if you want to upgrade the PHP version or test server behavior under real load, a subdomain on the same hosting won't work because both versions share a resource pool and your test won't give real results. In that case, get a dedicated server or a separate environment.

There's another limitation that's rarely mentioned: if the main site has high traffic, the test subdomain on the same hosting can raise the main site's TTFB during peak hours. If you notice the main site has slowed down after creating the subdomain, this is probably why.

Frequently asked questions

Does a staging subdomain affect Google search?

If you set the noindex header and robots.txt correctly, no. The problem arises when you set only one of the two, or when the physical robots.txt file is ignored by WordPress. After setup, check with a site:test.example.com search on Google that no page has been indexed.

Why doesn't my subdomain open after creating the DNS record?

In most cases, because the domain hasn't been added in the hosting panel. The DNS record only routes traffic to the server IP; it's the web server that must know which folder to serve for that domain. The correct order: first the domain in the panel, then the DNS record. If both are correct, check the record value with the DNS lookup tool.

How do I know the test subdomain isn't connected to the main database?

Open the test version's wp-config.php file and check the DB_NAME value. If it's the same as the main database, change it right now. A faster way: open both databases in phpMyAdmin and see whether they have identical tables with the same row counts.

After testing is done, how do I delete the subdomain?

Three things are needed: remove the domain from the hosting panel, delete the DNS record, and delete the test files folder and database. If you only delete the DNS record, the files remain on the server and take up disk space. If you only delete the folder, the domain remains in the panel and may later be served by mistake.

Before you touch production, create the subdomain and apply the three layers of protection the same day. Adding them later isn't hard, but forgetting them is costly.