WordPress Staging Site Checklist: What to Test Before Going Live

Most WordPress launches happen faster than they should. The staging site looks great. The client is excited. Someone clicks Publish or points the domain, and the site goes live.

Then the emails stop arriving. The contact form submits to a developer's inbox. The booking confirmation never fires. The site is set to noindex and Google cannot crawl it. Stripe is still in test mode.

This checklist is for anyone launching a new WordPress site or migrating a rebuilt site to production: developers, freelancers, agencies, and site owners who manage their own staging environment. Go through each section before you flip the switch. It takes roughly 1 to 2 hours the first time. After that, you will have a process.

Quick Answer

A staging-to-production launch fails most often in six areas:

Area	Most common failure
Search indexing	Site stays set to noindex after launch
Forms and email	Submissions route to developer inbox, not client
Payments	Gateway still in test mode
Bookings	Confirmation emails go to test address
Database URLs	Internal links still point to staging domain
Performance	Caching plugin not activated on production

Each section below walks through what to check, why it matters, and the red flag that tells you something is broken.

1. Verify search engine indexing is enabled

Why it matters: WordPress has a built-in setting under Settings > Reading called "Discourage search engines from indexing this site." This adds a noindex directive to every page and a Disallow rule to robots.txt. On a staging site, this setting should be checked. Before going live, it must be unchecked.

This is the most common post-launch SEO failure. The site looks live, but Google never indexes it. Weeks can pass before someone notices.

What to check:

• Log into WP Admin and go to Settings > Reading.
• Confirm "Discourage search engines from indexing this site" is NOT checked.
• Open the live URL in a browser. View the page source. Search for noindex. If you find a <meta name="robots" content="noindex"> tag, the setting is still blocking crawlers.
• Open the live robots.txt at yourdomain.com/robots.txt. Confirm it does not contain Disallow: /.
• After launch, submit your sitemap to Google Search Console: yourdomain.com/sitemap.xml (or the path your SEO plugin generates).

Red flag: Any noindex meta tag on the live site, or a robots.txt that blocks all crawlers with Disallow: /.

2. Check and fix database URLs

Why it matters: WordPress stores the site URL in two rows of the wp_options table: siteurl and home. If you cloned a staging site to production, these values may still point to your staging domain. That means your admin URLs, media files, and some theme assets resolve to the wrong address. Worse, serialized data across the database can contain hundreds of staging URL references that cause broken images, incorrect redirects, and plugin errors.

What to check:

• Go to Settings > General. Confirm both "WordPress Address (URL)" and "Site Address (URL)" show the production domain, not the staging domain.
• Search the database for staging URL references. The safest method is WP-CLI: wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com' --all-tables. This handles serialized data correctly. Do not use a manual SQL find-and-replace.
• After the search-replace, open the homepage and a few pages. Check that images load, links resolve to the correct domain, and the admin area functions without redirect loops.
• In wp-config.php, if WP_SITEURL or WP_HOME constants are hard-coded, update them to the production URL.
• Set WP_DEBUG to false in wp-config.php for production.

Red flag: Any page loading assets from the staging domain, or the Settings > General screen still showing the staging URL.

3. Test every form submission

Why it matters: Forms that submitted correctly on staging often break after launch for one of two reasons: the SMTP configuration is tied to the staging server's mail relay, or the "To" email address was set to a developer or test inbox rather than the client's business email. Both fail silently: the form appears to submit, no error appears on screen, and nobody receives the message.

What to check:

• Identify every form on the site: contact forms, quote request forms, newsletter sign-up forms, lead magnets, and any WooCommerce checkout email.
• Submit a test entry through each one using a real email address you control.
• Confirm the email arrives in the correct inbox within five minutes.
• Confirm the form's "To" address routes to the client's actual business email, not a dev address.
• If you use WP Mail SMTP, FluentSMTP, or another SMTP plugin: open the plugin settings and verify the From Name, From Email, and SMTP credentials are configured for the production domain and mail service.
• Send a test email from within the SMTP plugin's test tool. If it fails, the SMTP credentials or SPF/DKIM settings need updating before launch.

For a comparison of plugins that improve WordPress email deliverability, see FS Code's guide to the best WordPress contact form plugins.

Red flag: A test submission that shows no error on screen but never arrives in the inbox. Or an inbox full of form submissions during testing that used a developer's email address.

4. Verify payment gateway is in live mode

Why it matters: Stripe, PayPal, and WooCommerce payment extensions all include a test or sandbox mode with separate API keys. In test mode, real credit cards are rejected. Real customers get an error message. You do not see the failure unless you check the payment gateway dashboard.

This one is easy to miss because everything looks correct. The checkout page renders. The order form submits. The error only appears in the customer's browser at the final payment step, or in the gateway logs afterward.

What to check:

• Open your payment plugin settings (WooCommerce > Payments, Stripe for WooCommerce settings, or your specific gateway plugin).
• Confirm test/sandbox mode is disabled.
• Confirm the live API keys are entered: Stripe uses separate publishable and secret keys for test and live modes. Confirm you are using the live keys from your Stripe dashboard, not the test keys.
• If the gateway supports it, place a small live order using a real card to verify the full checkout flow works end to end.
• Check that the payment gateway's webhook URL is registered to the production domain, not the staging domain. Stripe webhooks, for example, are registered per URL in the Stripe dashboard. Registering only the staging webhook means order status updates will not fire on production.
• Confirm order confirmation emails and admin notifications both arrive after a successful transaction.

Red flag: Any "test mode" badge visible in the checkout or gateway settings, or API keys that match your gateway's test key format (Stripe test keys begin with sk_test_).

5. Test booking and appointment flows

Why it matters: If the site uses a booking or appointment plugin, the end-to-end booking flow touches multiple systems at once: the booking plugin, the email service, the calendar integration, and sometimes a payment gateway. Any one of them can break silently after migration.

A broken booking confirmation is a direct business impact: clients book, think they are confirmed, and either show up without staff knowing, or never receive confirmation and do not show up at all.

What to check:

• Make a test booking using a secondary email address you control (not the admin inbox).
• Confirm the customer receives a confirmation email with the correct business name, address, and appointment details.
• Confirm the staff or admin receives a notification email.
• Confirm the appointment appears in the admin panel with the correct date, time, and client details.
• If the booking plugin syncs with Google Calendar or another calendar service, confirm the event appears there.
• If the booking plugin collects deposits or payments, confirm the test payment processes correctly in live mode (not test mode).
• Check the "Reply To" and "From" email settings inside the booking plugin. These are separate from your main SMTP settings and are often left pointing to staging configuration.

If you are choosing or evaluating a booking plugin for a new site, FS Code has a comparison of the best WordPress booking plugins.

Red flag: A booking that completes without error but sends no confirmation email. Or a confirmation email that shows the staging domain in the booking URL or contact details.

6. Check email deliverability

Why it matters: Even if your forms and booking plugin are configured correctly, emails can fail to deliver if the sending domain's DNS records are not set up for production. SPF, DKIM, and DMARC records tell receiving mail servers that your domain is authorized to send email. Without these records pointing to your production domain and mail service, emails land in spam or are rejected outright.

What to check:

• Confirm your DNS has an SPF record that includes your SMTP service (Mailgun, Postmark, SendGrid, Google Workspace, or whichever you use). An example SPF record for Mailgun: v=spf1 include:mailgun.org ~all.
• Confirm your SMTP service's DKIM keys are added to your DNS. These are provided by the mail service when you verify your domain. Find them in your Mailgun, Postmark, or SendGrid domain settings.
• After adding DNS records, allow up to 24 hours for propagation.
• Use a free tool such as mail-tester.com to send a test email and check your spam score. Aim for 9/10 or higher.
• Send a test email to a Gmail address and a non-Gmail address. Check both spam folders.
• Confirm the "From" email address is on a domain you control, not a generic [email protected] if that inbox is not monitored.

Red flag: Test emails arriving in spam, or a mail-tester.com score below 7/10. Any SPF failure or DKIM signature missing in the email headers.

7. Audit user accounts and roles

Why it matters: Staging sites accumulate test accounts. Developers create Administrator accounts during setup. Clients receive temporary access. Plugin activation sometimes creates system users. These accounts should not exist on the production site with admin-level permissions.

What to check:

• Go to Users > All Users in WP Admin.
• Remove any Administrator or Editor account that belongs to a developer, agency, or test process not related to the ongoing site.
• Confirm the site owner has an Administrator account with a strong password and two-factor authentication enabled.
• Confirm the admin email under Settings > General matches the site owner's business email, not the developer's address. WordPress sends password reset and security alerts to this address.
• For sites with customer-facing accounts (WooCommerce customers, LMS students, membership users): confirm the default user role for new registrations is set to Subscriber or Customer, not Administrator or Editor.
• Check whether the WordPress default admin username (admin) is still in use. If so, create a new Administrator with a different username and delete the admin account.

For guidance on changing the WordPress login URL to reduce brute-force exposure after launch, see FS Code's guide to changing your WordPress login URL.

Red flag: Any developer account with Administrator access that will not be ongoing. An admin email still pointing to the developer's inbox.

8. Test mobile layout and cross-browser rendering

Why it matters: A staging site is often built and tested on a single desktop browser. The live site serves visitors on dozens of device types and three to four major browsers. Mobile-specific layout bugs, font rendering differences, and touch interaction failures are common and invisible until real visitors hit them.

What to check:

• Open the production site on at least two physical devices: a phone and a tablet, or a phone and a laptop.
• Test the home page, a key service or product page, and the most important form or checkout page on each device.
• Test in Chrome, Safari, and Firefox. Safari's rendering engine (WebKit) differs from Chrome (Blink) in ways that affect fonts, flex layouts, CSS grid, and input styling.
• Check that navigation menus collapse and expand correctly on mobile.
• Test that any popups, overlays, or drawers close when expected and do not block the main content.
• Check that form fields are large enough to tap accurately on a phone screen (minimum 44px touch target).
• Confirm no horizontal scrolling appears on mobile.

Red flag: Content overflowing its container horizontally, navigation that does not close after tapping, or form fields that are unusable on a phone screen.

9. Run a performance baseline

Why it matters: Caching plugins, CDN configurations, and image optimization settings are often not fully activated on staging. When the site goes live, the first visitors hit an uncached, unoptimized version. Performance problems that were hidden on staging (because the staging server is lightly loaded and already warm) become visible on production.

A slow load on day one affects first impressions, bounce rate, and Google's Core Web Vitals assessment of the new site.

What to check:

• Test the production URL through Google PageSpeed Insights (pagespeed.web.dev) within an hour of launch. Test both mobile and desktop views.
• Record the mobile score. Below 50 on mobile is a priority issue.
• Check Core Web Vitals: LCP (Largest Contentful Paint) should be under 2.5 seconds on desktop and under 4 seconds on mobile for most WordPress sites. CLS (Cumulative Layout Shift) should be below 0.1.
• Confirm your caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, or similar) is active and caching public pages on the production domain.
• If your site uses a CDN, confirm the CDN is pointed at the production domain and serving assets.
• Test image load speed. Images should be in WebP format where possible and sized correctly for their display dimensions.

For a deeper performance optimization resource, see FS Code's WordPress speed optimization guide, and for plugin-based solutions, the guide to free WordPress speed plugins.

Red flag: Mobile PageSpeed score below 50, LCP above 4 seconds on mobile, or the caching plugin showing "no pages cached" in its dashboard after the first few page visits.

10. Test 301 redirects

Why it matters: If this is a site rebuild or a domain migration, some or all old URLs are changing. Visitors and search engines following old links need to be redirected to the correct new pages with a 301 (permanent) redirect. Without redirects, old URLs return 404 errors. Google drops the ranking equity accumulated by those old URLs. Bookmarked links break.

What to check:

• Make a list of the most important old URLs: the home page under the old domain, key service pages, blog posts with inbound links, and any URL mentioned in marketing materials, social profiles, or other sites.
• For each old URL, visit it in a browser and confirm it redirects to the correct new URL with a 301 status code. Use a redirect checker tool (such as httpstatus.io) to verify the status code, because browsers follow redirects automatically without showing the code.
• Confirm that the old domain (if changing domains) redirects at the root level, not just specific paths.
• Confirm that HTTP URLs redirect to HTTPS.
• Confirm that the non-www version of the domain redirects to the www version (or vice versa), not both returning 200.
• Do not create redirect chains longer than two hops. Old URL > new URL is one hop. Old URL > intermediate URL > new URL is a chain. Chains slow down load time and dilute redirect equity.

Red flag: Any important old URL returning a 404, a redirect chain longer than two hops, or HTTP not redirecting to HTTPS.

11. Confirm SSL is active and HTTPS is enforced

Why it matters: A production site must serve all pages over HTTPS. HTTP pages show a "Not Secure" warning in Chrome. Google treats HTTPS as a ranking factor. Mixed content errors (HTTPS pages that load HTTP assets) cause browser warnings and can silently block scripts and images.

What to check:

• Open the production URL and confirm the browser padlock appears with no warning.
• Check for mixed content errors: open Chrome DevTools (F12), go to the Console tab, reload the page, and look for "Mixed Content" errors. These indicate scripts or images loading over HTTP on an HTTPS page.
• Confirm Settings > General shows https:// for both WordPress Address and Site Address.
• Confirm HTTP URLs redirect to HTTPS at the server level (not just in a plugin), so the redirect works even if WordPress is unavailable.
• If your SSL certificate is Let's Encrypt, note the renewal date. Let's Encrypt certificates renew every 90 days. Most hosts handle this automatically, but confirm auto-renewal is configured.

Red flag: Any browser padlock warning, Mixed Content console errors, or HTTP pages that return 200 instead of redirecting to HTTPS.

12. Set up a backup before and after launch

Why it matters: The moment before and after launch is the highest-risk period in a site's lifecycle. Pre-launch: you need a clean copy of staging to roll back to if the migration breaks something. Post-launch: you need a baseline backup of the production site before real visitors start adding content, orders, or bookings.

What to check:

• Before migrating staging to production: create a full backup of the staging site (database and files) and store it off-site. This is your rollback point.
• Before going live: create a full backup of the current production server (if replacing an existing site) so you can restore the old site if the launch fails.
• Immediately after launch and initial testing: create a baseline backup of the new production site.
• Confirm your backup plugin is active and scheduled on production. Daily backups with off-site storage (Google Drive, Dropbox, Amazon S3, or Backblaze) for new sites receiving bookings, orders, or contact submissions.
• For a comparison of backup tools with staging and restore support, see FS Code's guide to the best WordPress backup plugins.

Red flag: No confirmed backup before migration begins. No automated backup scheduled on the production site after launch.

Practical Scenarios

Service businesses with bookings and appointments

Your highest-risk launch item is the booking confirmation email. Test it before you announce the site is live. A missed booking costs real revenue. Test the full flow: select a service, pick a time, fill in the form, submit, and confirm the confirmation email arrives in the client's inbox (not the developer's).

Also: confirm your booking plugin is sending from the production email address, not a staging address, and that the booking confirmation contains the correct business name, phone number, and service location.

WooCommerce and eCommerce sites

Payment gateway mode is the most critical check. Test mode is designed to look identical to live mode. The only difference is that real cards get rejected. Place a test order before launch, then switch to live keys and place a small real transaction.

Also check: order confirmation emails, admin order notification emails, tax and currency settings, shipping method configuration, and stock management settings. These are often set differently per environment.

Portfolio and brochure sites

Indexing and redirects are the main concerns. Confirm noindex is off, the sitemap is submitted to Google Search Console, and any old portfolio URLs (from a previous domain or site structure) redirect correctly to the new content.

Also check: the contact form routes to the correct inbox, social media profile links in the footer or header point to live social accounts, and the LinkedIn, Twitter, or Instagram URLs are current.

Rebuilt sites with existing SEO history

Redirects are critical here. If the rebuild changes any URL structure, those redirects must be tested before launch. A site with existing Google rankings can lose significant traffic in the first weeks after launch if redirects are missing or misconfigured.

Also check: meta titles and descriptions are present on all key pages, the XML sitemap includes all new URLs, and Google Search Console is verified for the production domain.

Mistakes to Avoid

• Going live without disabling test mode on the payment gateway. The checkout page will look correct. Real cards will fail. Customers will not tell you why they left.
• Forgetting to update the admin email in Settings > General. WordPress sends password reset requests and security warnings to this address. If it points to the developer's inbox, the site owner cannot reset their own password without calling the developer.
• Skipping the database search-replace after staging migration. Serialized data in the database can hold staging URLs that break media files and plugin configurations silently.
• Assuming email deliverability works because it worked on staging. Staging and production often use different mail relays. Set up SPF and DKIM before launch, not after the first complaints about missing emails.
• Not testing mobile on a real device. Browser DevTools mobile simulation is helpful but not identical to real device behavior. Safari on iPhone renders differently from Chrome on Android.
• Treating "looks done" as "ready to launch." Functional testing covers the gaps: submit the form, complete the booking, process the payment, check the inbox.
• Launching without a backup rollback plan. The staging site should be backed up before migration. If production already exists, it should be backed up before the new site overwrites it.
• Redirecting all 404s to the homepage. Blanket homepage redirects look like soft 404s to Google, which is worse for SEO than a clean 404. Set up specific 301 redirects for each old URL that has value, and let irrelevant URLs return a real 404.

Recommended Next Step

If you are within a few days of a launch, print or bookmark this checklist and block two hours to run through each section on your staging site.

The items that break most often, in order of how much damage they cause:

1. Payment gateway in test mode
2. Contact form routing to wrong email
3. noindex still set after launch
4. Database still containing staging URLs

Start with those four. Then work through the rest of the list before you announce the site is live.

After launch, switch to a recurring maintenance routine. The staging checklist is a one-time gate. The ongoing work is a different schedule. For what to check weekly, monthly, and quarterly after your site is live, see the WordPress website maintenance checklist for small businesses.