WordPress Staging-to-Live Checklist
Purpose
Step-by-step checklist for moving a WordPress site from staging/temporary domain (*.wpdns.site) to the production domain. Covers pre-cutover QA, client approval, DNS cutover, post-cutover validation, and handoff.
Related Documents:
- WordPress Setup SOP -- Procedure 3 (DNS) and Procedure 5 (Post-Setup Config)
- SC WordPress Stack Standard -- Approved plugin/theme stack
- Elementor Best Practices Guide -- Design system setup
- GTM Validation SOP -- Analytics verification
- Robots.txt SOP -- Crawl access configuration
- Production Gate Checklist -- Generic software launch gates
1. Pre-Cutover Verification (on staging/temp domain)
Complete all items before requesting client approval.
Pages and Content
- All pages built and content finalized
- No placeholder text (lorem ipsum) remaining
- All internal links resolve correctly (no broken links)
- Copyright year and legal footer text correct
Integrations
- Forms submit to correct GHL sub-account (test each form)
- LeadConnector chat widget connected and functional
- SearchAtlas OTTO pixel installed and verified in OTTO dashboard
- Calendar booking widgets connected (if applicable)
Design System
- Global colors set per client brand guidelines
- Global fonts configured (2 families max)
- Default button styles applied
- Header template published to "Entire Site"
- Footer template published to "Entire Site"
- Client logo uploaded (use
{client}_web_wide_trans_300x120.pngfrom GHL Media Storage > Logos/) - Favicon uploaded (use
{client}_web_favicon_trans_32x32.png)
Responsive and Performance
- Mobile responsive at 375px (phone)
- Responsive at 768px (tablet)
- Responsive at 1024px (laptop)
- No horizontal scrolling at any breakpoint
- Cross-browser check: Chrome + one other (Firefox, Safari, or Edge)
- Page load under 3 seconds (test via PageSpeed Insights or GTmetrix)
- Images optimized (compressed, correct format, under 500KB each)
2. Client Approval Gate
- Share staging URL with client for review
- Client completes review and provides feedback
- All revision rounds complete
- Client sign-off received (email or ClickUp comment)
Do NOT proceed to DNS cutover until client sign-off is documented.
3. DNS Cutover
- Create manual backup of staging site (GHL hosting panel or backup plugin)
- Verify backup completed successfully
- Update WordPress Address (Settings > General) to production domain
- Update Site Address (Settings > General) to production domain
- Add production domain DNS records per WordPress Setup SOP Procedure 3
- Wait for DNS propagation (verify via dnschecker.org)
- Verify SSL certificate issued and active (padlock in browser)
4. Post-Cutover Validation
Core Functionality
- Production URL loads correctly (no redirect loops, no errors)
- All pages accessible on production domain
- All forms re-tested on production domain (submit test entries)
- Chat widget re-tested on production domain
- Calendar widgets re-tested (if applicable)
SEO and Analytics
- SearchAtlas OTTO pixel verified on production domain
- Google Search Console property added and verified for production domain
- robots.txt allows crawling (per Robots.txt SOP)
- XML sitemap accessible at
/sitemap.xml - 301 redirects configured (if migrating from an old site)
- Analytics/GTM verified (per GTM Validation SOP)
Technical
- No mixed content warnings (all resources loading over HTTPS)
- Elementor cache regenerated (Elementor > Tools > Regenerate CSS)
- Browser cache cleared and site verified in incognito mode
5. Handoff
- Notify Account Manager: "Site is live at [production URL]"
- Update ClickUp task status to complete
- Create final post-launch backup
- Update client profile with production URL (in
09-clients/[client-slug]/) - Remove or archive staging URL references from any shared documents
- Delete the staging site (GHL > WordPress > Info > Staging Access > Delete)
Why delete staging? A staging site is a frozen snapshot. Once the live site is launched and evolving (content edits, plugin updates, form changes), the staging copy becomes stale immediately. If someone later clicks "Publish" on an outdated staging site, it will overwrite the live site with old content and potentially re-introduce bugs that have already been fixed. Staging sites should be created when needed and deleted when done -- they are not long-term environments.
Document Information
Version: 1.0 Created: 2026-03-18 Review Schedule: Quarterly or when WordPress Setup SOP is updated