Using a Staging Environment for Website Redesigns
How to use a WordPress staging environment for a Tampa website redesign — subdomain vs separate, QA pass, client review, and launch.
A staging environment is a private copy of the site where the redesign gets built, reviewed, broken, fixed, and approved before it touches the live site. It is one of those pieces of infrastructure that sounds boring and turns out to be load-bearing. Projects that have a real staging environment ship cleanly. Projects that skip it ship with bugs, missing redirects, broken forms, and an owner watching the analytics fall off a cliff.
This page covers what staging is, how we set it up for Tampa SMB redesigns, the differences between subdomain staging and fully separate staging, and the QA workflow that runs before launch.
What staging is for
Three things.
Building without breaking the live site. The current site keeps serving traffic, taking leads, and ranking in Google. The new site is built in parallel on staging. No half-built pages show up to customers. No “under construction” banners. No 500 errors during a rebuild.
Catching problems before they cost money. Forms that don’t fire to the CRM. Phone numbers that aren’t tap-to-call on mobile. Images that don’t render on iOS. Schema markup that’s malformed. JavaScript errors in the console. All of these are catchable on staging at zero customer cost. Catching them after launch costs leads.
Giving the client a real review before approval. Staging is where the client clicks through every page, fills out every form, taps every phone number, and approves the site as ready. Without a staging environment, the client’s first interaction with the new site is launch day — which is the wrong moment for surprises.
Subdomain staging vs separate staging
Two main setups for staging. Each has trade-offs.
Subdomain staging
The staging site lives at a subdomain of the client’s main domain — usually something like staging.example.com, dev.example.com, or new.example.com. It runs on the same hosting account or a related account. DNS is configured to point the subdomain at the staging server.
Advantages:
- Easy to set up — most managed WordPress hosts (WP Engine, Kinsta, Cloudways, Flywheel) offer one-click staging environments at this style
- Easy to launch — when staging is approved, the “push to live” function does most of the work
- Inherits the domain’s email and DNS context — less risk of email delivery issues during the build
- SSL certificates are usually handled automatically
Disadvantages:
- Visible to anyone who guesses the subdomain — needs to be password-protected and blocked from search engines
- Tied to the existing host — if the redesign also includes a hosting migration, the staging environment needs to move too
For 80% of Tampa SMB redesigns, subdomain staging on the existing managed host is the right choice. It’s simple, fast, and reliable.
Separate staging
The staging site lives on a completely separate server, usually under a different domain entirely — something like clientname-staging.ourstagingdomain.com or on a development host like a private WP Engine sandbox.
Advantages:
- Fully isolated from the production environment — no risk of accidentally affecting the live site
- Works when the client doesn’t yet have managed hosting set up, or when the redesign includes a host migration
- Allows the agency to control the staging environment without depending on the client’s host
Disadvantages:
- DNS migration at launch is more involved (more on this below)
- SSL has to be set up explicitly
- Less seamless launch process
For redesigns that include hosting migrations, or for new businesses that don’t yet have professional hosting in place, separate staging is the right choice.
What we default to
For most Tampa SMB redesigns where the client is staying on the same host (or moving to a managed host we control), we use subdomain staging on the destination host. For redesigns that include a host migration from a budget shared host to a managed host, we use separate staging on the new managed host so the staging environment doubles as the new production environment.
Setting up staging properly
A staging environment is more than just “a copy of the site.” Done right, it includes:
Password protection. Either HTTP Basic Auth at the server level or a plugin-level password gate. The staging URL should not be publicly accessible.
Search engine blocking. A robots.txt that disallows all crawling, plus a meta robots noindex, nofollow tag in the page head. We do not want Google to index the staging version. Even with a noindex, a robots.txt block is belt-and-suspenders.
No analytics firing to production. The staging site should either have analytics turned off entirely, or it should fire to a separate “staging” property in Google Analytics. Otherwise the staging activity pollutes the real analytics data.
Forms in test mode. Forms on staging should not fire submissions to the live CRM or trigger client notifications. We typically point staging forms to a test inbox or a CRM sandbox. The forms themselves still get tested end-to-end before launch.
Real data, sanitized. Staging is a clone of the production database with sensitive data (customer email addresses from past form submissions, etc.) sanitized or removed.
Same plugin and theme versions as production will have. The staging environment is a representative test bed. Plugins set to “auto-update” should be set to the same policy on staging as production.
The QA pass
Before staging gets shown to the client, the QA pass runs internally. This is the “is everything actually working” check that catches the obvious bugs before the client review.
What we check:
Functional QA
- Every form submits and the submission arrives in the test inbox
- Every phone number on mobile is tap-to-call
- Every email address is tap-to-email
- Navigation works on desktop and mobile, including dropdown and mobile menu
- Internal links don’t 404
- External links open correctly (target attribute set where intended)
- Search functionality, if present, returns results
- Filtering and sorting, if present, work
- Any integrations (booking widgets, CRM, chat, calculators) fire correctly
Content QA
- No lorem ipsum left in the build
- No placeholder images left in the build
- Headlines and body copy match the approved wireframes
- Spelling and grammar pass
- Brand voice is consistent
- All required legal pages exist (privacy, terms, accessibility)
- Footer information (phone, address, hours) is correct
Visual QA
- Pages render correctly on Chrome, Safari, Firefox, and Edge
- Mobile rendering on real iPhone and real Android devices
- Tablet rendering in portrait and landscape
- Print stylesheet, if any, works
- No layout shifts during load (CLS under 0.1)
- All images load and have alt text
- Typography hierarchy is consistent
Performance QA
- PageSpeed Insights mobile score above 85 on homepage and primary template pages
- Largest Contentful Paint under 2.5s on mobile
- Interaction to Next Paint under 200ms
- Cumulative Layout Shift under 0.1
- Total page weight under 1.5MB on homepage
- This connects to the performance improvements work done during build
SEO QA
- Every page has a unique title tag and meta description
- H1 hierarchy is correct (one H1 per page, used semantically)
- Schema markup is valid (LocalBusiness, Organization, etc. — checked with Google’s Rich Results Test)
- XML sitemap is generated and complete
- Robots.txt is correct (will switch from “disallow all” on staging to “allow with sitemap reference” at launch)
- Canonical tags point correctly
- The 301 redirect map has been built and tested in a staging redirect plugin
Accessibility QA
- Color contrast meets WCAG 2.1 AA on every page
- All images have alt text (decorative images have empty alt)
- All form fields have labels
- Keyboard navigation works (tab through the page, every interactive element is reachable and visible-focus is clear)
- Heading hierarchy is correct
- ARIA landmarks are set
- Skip-to-content link works
The internal QA pass typically takes 1-2 days for a 20-50 page site. We don’t move to client review until the internal QA is clean.
The client review
After internal QA, the client gets the staging URL and the password. We send a one-page review brief with:
- A checklist of what to look for (content, conversion paths, brand feel)
- The specific decisions we’re asking the client to approve or revise
- A timeline for feedback (typically 3-5 business days)
- A note that this is the structural and content review — final tweaks are for the next pass
Client reviews almost always produce a list of requested changes. We expect 10-30 items for a 30-page site. Some are real bugs we missed (good — catch them now). Some are content tweaks. Some are personal preference items we’ll push back on if they conflict with the discovery goals. The push-back is part of the work — agencies that say yes to every change end up shipping a worse site than they could have.
Two rounds of client revisions is the norm. By round three, decisions are being relitigated and the site is getting worse, not better. We try to close the loop in two rounds and move to launch.
What changes on launch day
When staging is approved, launch is a planned event, not an improvisation.
For subdomain staging on the same managed host, launch is usually a “push to live” function provided by the host. The staging environment becomes the production environment. The previous production environment is archived. DNS doesn’t change.
For separate staging on a different host, launch involves:
- Final content sync from staging to the new production server (if there’s any drift)
- DNS cutover — pointing the domain’s A records to the new server’s IP, or updating nameservers
- SSL verification on the new server
- Removing the
noindexand staging password protection - Submitting the new sitemap to Google Search Console
- Activating the redirect rules
DNS propagation can take a few hours to a few days, though for most modern setups it’s largely done within 1-2 hours. We launch on a Tuesday or Wednesday morning, never on a Friday afternoon, so any issues can be fixed during a normal work week.
The full launch process is on the pre-launch checklist.
Common staging mistakes
A few patterns to avoid.
Skipping staging entirely. Some agencies build directly on production behind a maintenance plugin. This is a path to launch-day disasters. Always use a staging environment.
Staging that diverges from production. If the staging environment uses different plugin versions, a different theme, or different PHP configuration than production will have, the launch is going to surface mysterious bugs. Keep staging and production aligned.
Staging indexed by Google. This happens more than it should. A subdomain staging environment that gets accidentally indexed creates duplicate content issues and confuses the SEO migration. Belt-and-suspenders: password protection, robots.txt disallow, and meta noindex on every page.
Client review without a brief. Sending a staging URL with “let me know what you think” produces unfocused, contradictory feedback. The review brief structures the feedback into actionable items.
Next step
If you’re considering a redesign and want to know how the build-and-review cycle runs end-to-end, the discovery and wireframing pages cover what happens before staging. The redesign service page has pricing and timelines for the full engagement.
Want this applied to your Tampa business?
If you’re working through this for a real Tampa project, get a written diagnostic instead of guessing. The $500 SEO audit is refundable against any build engagement.