Pre-Launch QA: Moving From Staging to Production Without Surprises

A staging site is built to differ from production. It sits on a test hostname, it is hidden from crawlers, it often uses fake data, and it may be behind a password. That is the right setup for building. The trouble starts when the switch happens, because every one of those differences is a thing that must be undone, and a single leftover can hide the new site or send search engines to the wrong address.

This pre-launch QA guide is for developers, project managers and site owners who are about to promote a staging build to production. It does not repeat the full launch SEO checklist. It focuses on the move itself: which settings differ between environments, how to find test URLs buried in content, how to rehearse the cutover, and what to test in the first hour after the switch.

You will finish with a written list of environment differences, a clean crawl of staging, a cutover plan with a rollback option and a smoke test you can run in under an hour. Nothing here predicts how quickly search engines will react. Google notes that changes can take hours to months to show.

Before you begin

People: decide who can approve go or no-go, who edits DNS and who can roll back. Put the names in the plan.
Access: staging and production hosting, DNS, the CMS, the CDN, robots.txt, and Search Console for the production domain.
Time: one to two days of preparation and one to two hours on launch day for a small site.
Risk: the highest-risk actions are the DNS switch, removing the staging block and changing redirects. Keep a rollback path for each.
Back up: snapshot the production site (if one exists), database and configuration. Save the staging robots.txt and the list of staging-only settings.
Tools: a crawler that can authenticate and report status codes, titles, canonicals and links; curl; and a text search over your codebase and database export.

Step-by-step instructions

Step 1: Write down every difference between staging and production

Why: problems come from forgotten differences, not from the ones you remember.

Action: make a table with one row per setting and two columns, staging and production. Include at least:

Base URL or site URL setting in the CMS or framework.
robots.txt content and where it is generated.
Any noindex meta tag or X-Robots-Tag header added for staging.
Password protection or IP allow lists.
Canonical, Open Graph and structured-data base URLs.
Redirect rules and trailing-slash behaviour.
HTTPS certificate, HSTS and security headers.
Analytics and tag-manager IDs.
CDN, cache and firewall rules, including bot-blocking settings (see Cloudflare bot blocking).
Email, forms and payment keys (test versus live).

Mark each row as "same", "must change at launch" or "must stay different". Assign an owner to every "must change".

Confirm: every "must change" row has an owner and a way to check it.

Step 2: Crawl staging as a stand-in for production

Why: a full crawl finds status code, metadata and linking problems while fixing them is still cheap.

Action: crawl staging with authentication and record, for each URL, the status code, title, meta description, canonical, meta robots, H1 and internal links. Compare against your URL list. Look for 4xx and 5xx, redirects among internal links, missing titles, duplicate titles and canonicals that point at another host. A page that returns a 2xx status is passed on for processing, but Google says that does not ensure indexing, and content that looks like an error under a 200 is reported as a soft 404 (see soft 404 errors).

Confirm: you have a crawl export saved as the baseline for the post-launch comparison.

Step 3: Hunt hardcoded staging URLs

Why: content, templates and databases often contain the staging hostname. After launch those become links and canonicals pointing at a site that no longer exists or that is blocked.

Action: search the repository, templates, CMS database export and uploaded files for the staging hostname. Also check:

Canonical tags and og:url values.
Image and script URLs in content bodies.
JSON-LD blocks.
Sitemap files and the Sitemap: line in robots.txt.
Redirect targets and redirect maps.
Email templates and feed URLs.

Use a tool that supports search-and-replace in the database, and take a backup first. Serialized data can break if you edit it by hand.

Confirm: a search for the staging hostname returns nothing in production-bound content.

Step 4: Plan the removal of the staging block

Why: the staging block is the most common cause of a "launched but invisible" site.

Action: write the exact steps and who performs them. A staging block usually has up to three parts: a password or IP restriction, a noindex tag or header, and a Disallow rule in robots.txt. Google recommends noindex or password protection, not robots.txt, to keep a page out of its results, and its migration guide says to plan to remove temporary blocks and noindex rules when the move starts. Remember that Google caches robots.txt, generally for up to 24 hours, so a fix may not be seen at once. For a hands-on method, see prevent staging site indexing.

Also check how production's robots.txt behaves when the server is unavailable. A 4xx response is treated as no restrictions. For a 5xx response Google stops crawling for the first 12 hours, then uses the last good copy for up to 30 days.

Confirm: the plan lists each block and the order in which it is removed.

Step 5: Test redirects before they go live

Why: if you are replacing an existing site, redirects carry the old URLs to the new ones.

Action: put your redirect map in staging and test every old URL with a script. Check that each returns a permanent status (301 or 308) in one hop to a page that returns 200. Google's guidance is to avoid chains and not to point many unrelated old URLs at the home page. Keep a list of URLs you intentionally drop; they should return 404 or 410. See redirect chains and loops and the migration checklist.

Confirm: a script run shows zero chains, zero loops and zero redirects to error pages.

Step 6: Rehearse the cutover and agree a rollback

Why: a practised switch is calmer than an improvised one.

Action: write the order of events. A typical sequence:

Freeze content and code.
Confirm the production certificate is installed for every hostname.
Deploy the build with production settings.
Remove the password or IP restriction.
Remove staging noindex tags and the blanket Disallow.
Switch DNS or the CDN origin.
Run the smoke test.

Ask your DNS provider how long the old records can remain cached, and plan around that window. Decide in advance what would trigger a rollback, such as widespread 5xx errors, and who makes that call. Server capacity matters too: Google's migration guide says it temporarily crawls more heavily after a move, so make sure the server can cope.

Confirm: every person on the plan has read it and knows their step.

Step 7: Run a one-hour smoke test after the switch

Why: this catches the leftovers that testing on staging could not.

Action: within the first hour, run these checks on production:

/robots.txt returns 200 with the production rules and the right Sitemap: line.
Home page and five key templates have no noindex in HTML or headers.
Canonical tags point at the production host.
The four HTTP/HTTPS and www variants redirect to one canonical address.
A made-up URL returns a real 404.
The sitemap loads and lists production URLs only.
No mixed-content warnings and the certificate is valid.
Forms, search and checkout work with live credentials.
Analytics fires once per page.
In Search Console, run a live URL Inspection on the home page and a key template page, and confirm the page can be crawled and indexed. See URL inspection and live test.

Confirm: all ten checks pass, or each failure has an owner and a fix time.

Final verification checklist

An environment-difference table exists with an owner per change.
A baseline crawl of staging is saved.
No production-bound content contains the staging hostname.
The password, noindex and robots.txt blocks are listed with removal steps.
Redirect tests show single hops to 200 pages.
A cutover order and a rollback trigger are written down.
The post-switch smoke test has passed.
Search Console shows the production property and submitted sitemap.

Common mistakes to avoid

Treating staging as identical to production. Document the differences and test each one.
Fixing robots.txt and expecting instant results. Crawlers cache it, so give it time and re-check.
Using robots.txt as the only staging protection. It stops crawling, not indexing; use a password or noindex.
Leaving staging hostnames in the database. Search and replace carefully, with a backup.
Launching on a Friday evening without rollback. Choose a time when people who can fix problems are available.
Changing several big things at once. Google advises changing one thing at a time, such as domain first and design later.
Skipping the live test after launch. The browser can look fine while the HTML says noindex.
Forgetting live credentials. Test payments and email with live keys under controlled conditions.

Frequently asked questions

Should staging be password protected or marked noindex?

Password protection is the stronger control because crawlers cannot fetch protected pages. Add noindex as a backup if the password could be removed accidentally. Remove both at launch.

How long should I keep the staging site after launch?

Keep it behind a password so you can compare behaviour and test fixes. Do not let it return to being public.

Can I launch in stages?

Yes. Google suggests moving small and medium sites all at once and larger sites by section, which makes problems easier to find.

What if I find `noindex` after launch?

Remove it, confirm the page is not blocked in robots.txt, and request a recrawl using URL Inspection. See request indexing. Recovery time is not fixed.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.