WP Engine Deployment Workflow — Staging to Production

Overview

WP Engine organizes WordPress sites into environments — each site can have up to three: production, staging, and development. Understanding which environment to build on, and how domains relate to servers, is critical to avoiding data loss and deployment confusion.

This article documents the correct workflow, common mistakes, and how to handle edge cases like preserving an old site during a rebuild.

Derived from a live incident with ^[1] where a staging-to-production push overwrote a newly built site because the developer had built directly on production.

Core Concepts

Environments vs. Domains

A domain (e.g., finwellu.com) is an address — not the website itself. The website lives on a server at a physical location (e.g., WP Engine). The domain is configured in DNS (via Cloudflare) to point to the server's IP address.

• WP Engine assigns internal URLs to each environment: nextlevel-prd1.wpenginepowered.com (production), nextlevel-stg.wpenginepowered.com (staging)
• A custom domain becomes "live" when you set it as the primary domain in WP Engine and the DNS A record points to the correct IP
• If the DNS points to a server but the domain isn't registered on that server, traffic arrives but gets a 404 — "the lights are off and the door is locked"

The Standard Push Flow

Build on Staging → Push to Production → Set Primary Domain → Configure Redirects

1. Build on staging. Start with either an empty WordPress install or a copy of the current production site.
2. Push staging → production. In WP Engine, use Actions → Push to Production. WP Engine rewrites all internal URLs from STG to PRD variants automatically.
3. Set the primary domain. Either before or after the push, set the custom domain (e.g., finwellu.com) as primary in WP Engine. This triggers a URL rewrite across the database.
4. Configure redirects. Ensure www and any WP Engine internal URLs redirect to the primary domain to avoid duplicate content penalties from Google.
5. Fix SSL. After domain changes, SSL certificates may need to be reset/reissued in WP Engine.

Never build on production. If you build on production and then push staging → production, the push overwrites everything you built.

Handling an Old Site During a Rebuild

This is the most common source of environment confusion. There are two scenarios:

Scenario A: Keep the Old Site Live (Concurrent Operation)

If the old site needs to remain publicly accessible while the new one is being built:

1. Spin up a new WP Engine server (separate install) for the old site
2. Point the old domain to the new server via Cloudflare DNS
3. Build the new site on the existing server's staging environment, completely independently
4. When the new site is ready, redirect the old domain → new domain via a Cloudflare redirect rule
5. Decommission the old server

Using staging or development as a "holding area" for the old live site is fragile — it can be overwritten by a push at any time.

Scenario B: Keep the Old Site for Reference Only

If the team just needs a copy to reference during the build (not publicly accessible):

1. Copy the old site to the development environment
2. Add a WP Engine site note (visible in the dashboard) clearly stating: "DO NOT PUSH — historical reference only"
3. Communicate explicitly to all developers: do not push the dev environment

This approach carries risk. An accidental push from dev → staging can still cause data loss. Backups mitigate but don't eliminate the problem.

Domain & DNS Checklist

When switching a domain to a restored or newly built site:

• [ ] Confirm the correct site is visible at the WP Engine internal URL (e.g., nextlevel-prd1.wpenginepowered.com)
• [ ] Set the custom domain as primary in WP Engine → triggers URL rewrite
• [ ] Verify Cloudflare DNS A record points to the correct WP Engine IP (check via WP Engine → Domains → View DNS Details)
• [ ] Add redirects: www.finwellu.com → finwellu.com, prd1.wpenginepowered.com → finwellu.com
• [ ] Reset/reissue SSL certificate in WP Engine if errors appear
• [ ] Confirm client login URL: finwellu.com/wp-admin (not any old domain)

Incident Reference: Finwell U Deployment Mix-up (2026-04)

What happened: Developer (Jeff) built the new Finwell U site directly on the production environment, keeping the old "Financial Wellness Done Right" site on staging as a reference. When Karly pushed staging → production, the old site overwrote the new one.

Resolution:
- Mark restored production to the 7:53 PM WP Engine daily checkpoint backup
- Confirmed the restored site was the correct new build via the nextlevel-prd1 URL
- Switched finwellu.com to point to the restored production site
- Set redirects for www and internal WP Engine URLs

Follow-up actions:
- Karly to email Jeff re: build-on-production practice
- Mark to set finwellu.com as primary, fix SSL, confirm redirects

See also: ^[2]

Quick Reference