WordPress Staging & QA for Agencies: The Complete Workflow
A client sends a Slack message at 9pm: "The contact form on the staging site isn't sending emails." You check production and realise someone pushed directly to live two weeks ago — and three forms have been silently failing since. This is what happens without a proper staging and QA workflow. Here is the system I use with agencies to make sure this scenario never happens.
Why Staging Is Not Optional
Professional agencies do not develop on live sites. This might sound obvious, but I still encounter agencies that make small changes directly on production because "it is just a quick fix." Every quick fix on production is one mistake away from taking a client's site down during business hours.
A staging environment gives you a sandbox that mirrors production — same PHP version, same server configuration, same plugin stack. When something breaks on staging, nobody sees it except your team. When something breaks on production, everyone sees it — including the client's customers.
Setting Up the Right Environment Stack
1. Local Development Environment
Every developer needs a local copy. Use Local by Flywheel, Laravel Valet, or Docker-based setups (DevKinsta, Lando). This is where code gets written and tested in isolation before it touches anything shared.
2. Staging Environment
A shared staging site that mirrors production as closely as possible — same hosting, same PHP version, same plugins. This is where client review happens. Tools like WP Staging, InstaWP or host-provided staging (Kinsta, WP Engine, SiteGround) make this straightforward.
3. Production Environment
The live site. No direct edits. No plugin installations without testing on staging first. Everything that reaches production goes through the full pipeline — local → staging → production.
The QA Checklist: What to Test Before Client Review
Never send a staging site to a client without testing it first. The fastest way to erode client trust is to have them find bugs you should have caught. Here is my pre-client-review checklist:
Visual & UX
- Compare every page to the design file side-by-side
- Test at 320px, 768px, 1024px, 1440px and 1920px
- Verify typography scaling matches design specs
- Check hover states, animations and transitions
- Test in Chrome, Firefox, Safari and Edge
Functional
- Every contact form sends email (test with real address)
- Navigation works on all pages, all breakpoints
- Search returns relevant results
- 404 page displays correctly
- All internal links resolve (use a link checker)
Performance & SEO
- Run Lighthouse — target 90+ on mobile
- Verify all images have alt text and proper sizing
- Meta titles and descriptions are present on every page
- XML sitemap generates and is accessible
- Schema markup validates in Rich Results Test
Security & Access
- Staging site is password-protected or IP-restricted
- WordPress admin uses strong passwords and 2FA
- User roles are properly configured for client access
- No debug mode, test credentials or developer notes exposed
Managing Client Review Without Endless Revisions
Client review can derail a project if you let it. Here is the framework I use with agency partners to keep it controlled:
- One feedback channel, no exceptions. All feedback goes through your project management tool — Basecamp, ClickUp, Notion, Trello. No Slack DMs, no WhatsApp messages, no "while I have you on the phone" requests. Scattered feedback gets lost.
- Two review rounds, clearly defined. Round 1 is for structural and functional feedback — "this section is in the wrong order," "this form doesn't work." Round 2 is for polish — "tighten this spacing," "change this font weight." Anything after round 2 is billable.
- Bug vs change request: Define this upfront. A bug is something that does not match the agreed design or specification. A change request is something new — even if the client frames it as a bug. Change requests are billable.
The Go-Live Checklist
- All client feedback has been resolved and signed off
- SSL certificate is active and auto-renewing
- Caching is configured for production (not development-level caching)
- Database has been cleaned — remove staging content, test users, test orders
- Search engine visibility is enabled (not "discourage search engines")
- Google Analytics / Tag Manager is connected
- XML sitemap is submitted to Search Console
- Backups are configured and tested with a restore
- DNS and email deliverability confirmed
Need Staging & QA Support on Agency Projects?
I set up staging environments, run QA checklists and manage the client review process for agency WordPress builds. Your team gets a clean staging workflow without the overhead of building it from scratch.