Tutorial · migration-hosting · Published 2026-08-15 · 3 min read
Going from staging to live cleanly
Staging to live launch: promote files and database, fix theme and plugin config, test URLs and caches and release in order.
Staging to live is a copy, not a cutover
Staging lets you edit and test without the live site noticing. Moving to live is not "just upload": the staging database stores the live domain in its options, the URLs in its content, and the same value in its canonical headers. Going live in the wrong order is how sites come up with every link pointing at the staging domain, or worse with the staging site publicly indexed.
Step 1: get the list of what changes
- Files: upload or rsync from staging to the live document root.
- Database: restore the staging DB over the live DB (or export/import), whichever the setup allows; on shared hosting this is usually an import.
- Configuration:
.env,wp-config.phpor CMS config must point at the live database and the live-only settings (cache, debug, email). - Uploads and generated media: copy the media folder to its live location.
Step 2: the staging -> live URL conversion
The live DB contains URLs from staging (https://staging.example.com/). Before anyone visits:
- Run the database search-replace from staging URL to live URL (the WordPress tooling or the WP-CLI
search-replace; both are covered in the restore order article). - Include schemes: https and http variants, and the www version, whatever you standardized in www vs non-www.
- Never run find-replace across serialized data by hand; the WP-CLI
--preciseguard is the safe form.
Step 3: the mixed items
Staging leaks through three things the DB swap does not catch:
| Leak | Where it hides | Fix |
|---|---|---|
| Hardcoded URLs | templates, redirects, emails | grep for the staging domain across the file set |
| Staging proxying/anti-bot | a staging-only basic-auth or firewalled access | remove before the DNS cutover |
The wrong home and siteurl | in the options table | part of the search-replace, line one |
Step 4: launch in the right order
- Push files and DB.
- Point the live domain's DNS or the hosting setup at the new copy (if the staging was a subfolder, this is just a document-root change).
- Disable staging-only layers (maintenance, proxy, dev mode).
- Test the live URL hard: home, an internal page, the login, https, and one deep URL with the URL inspection tool once Search Console is attached.
Step 5: the launch list
Before telling anyone:
- Confirmed SSL serves on the live domain.
- The staging site is locked or removed so search engines do not clone it (a noindex or basic HTTP auth does that).
- The sitemap returns the live URLs only, and the sitemap was rebuilt if the URL structure changed.
- The old staging URL either remains temporarily or returns a 404, not a live copy of the site (preventing a duplicate-content problem covered in canonicals).
The purpose-built sibling pages are useful together: replicate to a new host when the destination is a new host, and the host migration checklist when the whole environment moves.