What should you check before launching a WordPress site?
Before a WordPress site goes live, check that search engines are allowed to see it, that a backup can actually be restored, and that every form sends its enquiry somewhere a person will read it. Then check speed on a phone, old URLs, and leftover demo content.
Most launch mistakes are not visible on launch day. The page looks right while the site is hidden from Google, or the form says thank you while the email goes to spam.
- Visibility: the "discourage search engines" setting is off on the live site, and old URLs redirect to their new pages
- Recovery: a backup exists outside the server, and someone has restored one to prove it works
- Enquiries: a test submission from every form arrives in the inbox, not in spam, and lands wherever enquiries are tracked
Why launches go wrong quietly
A broken page gets noticed in minutes, because someone looks at it. The expensive launch mistakes are the ones nobody looks at: a setting that tells Google to ignore the site, a form whose notification never arrives, an old page that used to bring in visitors and now returns an error.
None of these show up when you click around the new site and admire it. They show up weeks later as an empty enquiries inbox or a site that never appears in search, by which time nobody connects the problem to launch day.
The original version of this article listed six checks. They still matter, but they were the visible ones. This version keeps them and adds the checks that fail without telling anyone, arranged so you can run the whole list in an afternoon.
The checklist, by what breaks if you skip it
Run this on the live site once the domain points at it, not only on the staging copy. Several of these checks behave differently on the real domain.
| Check | How to test it | If you skip it |
|---|---|---|
| Search engine visibility | Settings, then Reading: the "discourage search engines" box must be unticked on the live site | The site stays out of Google with no error anywhere to tell you why |
| Backups | Confirm a scheduled backup is stored off the server, then restore one to a test copy | The first time anyone learns the backup was incomplete is the day it is needed |
| Demo and placeholder content | Search the site for "lorem ipsum", "sample page" and the theme demo's own wording | Placeholder text in search results and on pages a buyer reads |
| Old URLs | List the old site's pages that had visitors or links, and open each one on the new site | Visitors and search history from the old site land on a not-found page |
| Every form | Submit each form yourself with a real address you can check | Enquiries vanish while the visitor sees a thank-you message |
| Notification email | Check the inbox and the spam folder for the form notification and the visitor's copy | Leads arrive in spam, or not at all, and nobody notices for weeks |
| Where the enquiry lands | Find the test enquiry in the CRM or shared inbox your team actually works from | Enquiries sit in one person's inbox with no owner and no follow-up |
| Speed on a phone | Load the home page and a heavy page on a phone over mobile data | Visitors leave before the page finishes loading |
| Layout with real content | Open the longest page and the contact page on a phone and a wide screen | Menus, tables or forms that overflow on the screens most visitors use |
| Site Health | Open Tools, then Site Health, and read every critical issue | Known security or performance problems ship with the site |
| Accounts and updates | Remove test and former-staff admin accounts, and decide who applies updates | Old logins stay open and updates wait until something breaks |
The speed and layout rows deserve more than a glance. The guide to speeding up a slow WordPress site covers what to fix when the phone test is slow, and what responsive web design is and how to test for it explains what a passing layout looks like.
If the theme itself is still undecided, settle that first. How to choose a WordPress theme has the checks to run before you buy one, including the bundled features that make a later switch painful.
The one setting that hides a new site
WordPress has a box on its Reading settings screen labelled "Discourage search engines from indexing this site". It is the right setting on a staging copy, and it is often still ticked when the site moves to its real domain.
According to the WordPress documentation for the Reading screen (checked 15 October 2026), ticking it adds a robots meta tag with noindex and nofollow to every page. Search engines then leave the site out, and nothing on the site itself looks any different.
The check takes ten seconds: open the live home page, view its source, and search for "noindex". If it is there and you did not put it there deliberately, untick the box and resubmit the sitemap in Google Search Console.
Test the enquiry path end to end
A form test is not finished when the thank-you message appears. That message only proves the form accepted the data; it says nothing about whether anyone will ever see it.
Run one test enquiry through the whole path, the same way a buyer would:
- Submit the form from a phone, using an address outside your own company.
- Check that the notification reached the person who handles enquiries, in the inbox rather than spam.
- Check that the visitor's confirmation email arrived, if the form sends one.
- Find the enquiry in the CRM or shared inbox, with the right owner attached.
- Note how long a reply would have taken if this had been a real buyer.
Step two fails more often than any other. By default WordPress sends mail through the web server, and mail that is not authenticated for your domain is easy for providers to distrust. Google's email sender guidelines (checked 15 October 2026) require every sender to Gmail accounts to set up SPF or DKIM, so send form mail through an authenticated mail service on your own domain.
Steps four and five are where a working website still loses business. Connecting WordPress to a CRM sets out the ways to send each form submission somewhere it gets an owner, and what a landing page needs after the form is sent covers the confirmation and follow-up a buyer should get next.
This is the part of a launch we build. Our CRM setup and management work connects WordPress forms to GoHighLevel, HubSpot, Keap, ActiveCampaign and other CRMs, with an instant reply so no enquiry waits for someone to notice it.
The first week after launch
Some problems only show up once real visitors and real search engines arrive. A short routine in the first week catches them while the launch is still fresh in everyone's mind.
| When | What to check |
|---|---|
| Launch day | Submit the sitemap in Google Search Console, then send one more test enquiry from the live domain |
| Day two or three | Look for not-found errors in Search Console and the server logs, and add redirects for any old URL that still gets visits |
| End of the first week | Compare enquiries received with the weeks before launch, and inspect a few key pages in Search Console |
A sudden drop in enquiries after launch is almost never the design. It is usually a form, a notification or a connection that stopped working quietly, which is the pattern described in automation mistakes that quietly lose you leads.
The same checks are worth repeating whenever the site changes underneath you. A host moving it to a newer PHP version is one example, and what a host PHP upgrade can break on WordPress lists what to test afterwards.
If an agency is launching it for you
Ask for the checklist itself, not only the promise that one exists, and ask who owns each line after launch. Backups, updates and the form connection each need a named person, or they become nobody's job by the second month.
What to settle before hiring a WordPress web design company lists the questions to agree before work starts, and what a WordPress website really costs shows where the running costs sit once the site is live. If one developer is doing the build, how to vet a WordPress developer covers how they should test and hand it over.
Where AI helps, and where it does not
An AI assistant is useful for the tedious half of a launch. It can turn an export of old URLs into a draft redirect map, scan page text for placeholder wording, and explain a Site Health warning in plain language.
It cannot submit your form and look in the right inbox, and it cannot tell you whether the person who should answer an enquiry actually saw it. Those checks need a real test from a real phone, and they are the ones that decide whether the launch brings in business.
Common questions
How long before launch should I start the checklist?
Start about a week before the planned date. Email authentication and redirect mapping can take a few days to get right, and you want time to fix what the checks find. Then run the whole list again on launch day, on the live domain.
Should a new WordPress site be hidden from Google before launch?
The staging copy should be, using the discourage search engines setting or a password. The live site should not. Forgetting to untick that setting when the site moves to its real domain is one of the most common reasons a new site never appears in search.
Why do WordPress form emails go to spam?
Usually because they are sent from the web server without authentication for your domain. Send form mail through an authenticated mail service with SPF and DKIM set up. Gmail has required SPF or DKIM from all senders since February 2024.
Do I need redirects when replacing an old site?
Yes, whenever a page's address changes. Point each old URL that had visitors or links at its closest new page with a permanent redirect. Without one, that traffic and the page's search history end on a not-found page.
Can you test our WordPress forms and connect them to a CRM?
Yes. We trace every enquiry from the form to the inbox and the CRM, fix where it breaks, and add an instant reply and follow-up so no lead waits. Every project is quoted after we understand the setup (how automation projects are priced explains why), so tell us where your enquiries arrive today and we will say what is worth connecting.
