We push client sites live almost every week, and the pattern never changes: launches do not fail because of design. They fail because of a missing MX record, a leftover noindex tag from staging, a contact form that silently stops delivering, or a redirect map nobody built. Each of those mistakes is invisible on launch day and expensive three weeks later.
This WordPress website launch checklist is the exact sequence we follow internally, reordered so a business owner can use it as a review document. For every item you get the check, the reason it exists, and the specific consequence of skipping it. Print it, send it to your developer, and ask for a yes or no next to each line before you approve the handoff. (via https://adammclaughlin.net)
How to use this launch checklist
Order matters. Half of these checks only make sense before DNS is switched, and the other half can only be validated once the site answers on the live domain. Work through the phases in order.
| Phase | Items | When | Usually owned by |
|---|---|---|---|
| 1. Environment and content freeze | 1 to 5 | 7 days before | Developer + client |
| 2. DNS, SSL and hosting | 6 to 10 | 48 hours before | Developer |
| 3. URLs and 301 redirects | 11 to 13 | Before and right after switch | Developer + SEO |
| 4. Forms, email and payments | 14 to 16 | Launch day, live domain | Client validates |
| 5. Analytics and Search Console | 17 to 19 | Launch day | Developer + marketer |
| 6. Indexing and on-page SEO | 20 to 22 | Within 1 hour of going live | Developer |
| 7. Mobile, browser and speed QA | 23 to 25 | Launch day + 24 hours | Both |
| 8. Backups, security, monitoring | 26 to 27 | Before and after switch | Developer |
One rule from experience: never launch on a Friday afternoon or the day before a holiday. If something breaks, you need people available to fix it.
Phase 1: Environment and content freeze (items 1 to 5)
1. Confirm staging and production run the same stack
Compare PHP version, WordPress version, MySQL/MariaDB version, plugin and theme versions, and PHP memory limit between staging and the live server.
If you skip it: a site built on PHP 8.3 that lands on a server still running an older branch can throw a fatal error on go-live, and your visitors see a white screen instead of a homepage.
2. Freeze content and clean out placeholders
Search the whole site for lorem ipsum, “Insert text here”, stock photos meant to be replaced, dead internal links, and the WordPress defaults: the “Hello world!” post, the “Sample Page”, the default comment, and any auto-generated “Uncategorized” category.
If you skip it: Google indexes junk URLs and your first impression includes a page that says “Lorem ipsum dolor” under your best service.
3. Delete unused plugins, themes and demo data
Deactivate is not enough. Deleted is the goal. Remove theme demo importers, page builder starter content, duplicated draft pages, and any plugin that made it into the build for testing only.
If you skip it: every dormant plugin is still a file on the server with a known vulnerability history, and your update dashboard becomes noise nobody reads.
4. Audit user accounts and access
- Remove developer, freelancer and test accounts that are no longer needed
- No user literally named “admin”, “administrator” or the domain name
- Unique strong passwords, ideally stored in a shared password manager vault
- Two-factor authentication enabled on every administrator account
- Editors and contributors get editor or author roles, not admin
If you skip it: bots start hammering your login page within hours of the domain resolving. A weak admin account with a guessable username is the single most common WordPress compromise we clean up. There’s a solid take on this from one agency that does this well.
5. Publish legal and consent pages
Privacy policy, cookie policy, terms of service, and for ecommerce: shipping, returns and refund policies. If you have European visitors, your cookie banner must block analytics and marketing scripts before consent, not after.
If you skip it: exposure to GDPR complaints, plus analytics data that was collected without a legal basis and may have to be discarded.
Phase 2: DNS, SSL and hosting (items 6 to 10)
6. Lower DNS TTL 24 to 48 hours before the switch
Drop the TTL on your A, AAAA and CNAME records to 300 seconds a day or two before launch, then restore a normal value afterwards.
If you skip it: with a 24-hour TTL, some visitors hit the old site and some hit the new one for a full day. Form submissions and orders land in two different places and you cannot tell which.
7. Document every DNS record before touching nameservers
This is the most damaging mistake in the whole checklist. Export the current zone file and rebuild it record by record on the new provider.
| Record | What it controls | Breaks if missing |
|---|---|---|
| A / AAAA | Root domain to server IP | Site unreachable |
| CNAME (www) | www version of the domain | Half your backlinks land on nothing |
| MX | Business email delivery | All incoming email stops, silently |
| TXT (SPF, DKIM, DMARC) | Email authentication | Your emails go to spam |
| TXT / CNAME verifications | Search Console, Microsoft 365, CRM | Verified properties and integrations drop |
| Subdomains | shop., app., mail., booking. | Tools your team uses daily go offline |
If you skip it: moving nameservers without copying MX and TXT records takes down company email during the exact week you are announcing a new website. We have been called in to fix this more times than anything else on this list.
8. Install and verify SSL for every hostname
The certificate must cover both example.com and www.example.com, plus any subdomain in use. Confirm the expiry date and that auto-renewal is active. whitelabeliq.com goes into the numbers.
If you skip it: visitors get a full-page “Your connection is not private” warning. Conversion drops to almost zero, and browsers cache the warning.
9. Force HTTPS and one canonical hostname, then kill mixed content
- Choose www or non-www and 301 redirect the other version
- Redirect all HTTP traffic to HTTPS at server level
- Run a crawl to find hardcoded
http://images, scripts, iframes and fonts - Check WordPress Address and Site Address in Settings for the correct protocol and hostname
If you skip it: mixed content warnings break the padlock, and browsers block insecure scripts, which often means sliders, maps or checkout widgets that simply do not load. Full details on https://fourfoldtech.com.
10. Confirm hosting is sized and configured for the real site
Page caching, object caching where relevant, a current PHP branch, HTTP/2 or HTTP/3, gzip or Brotli compression, and enough PHP workers for the traffic you expect on announcement day.
If you skip it: the newsletter announcing your launch sends 3,000 people to a shared plan that returns 503 errors. You only get one launch day.
Phase 3: URL structure and 301 redirects (items 11 to 13)
11. Lock permalink structure before anything is indexed
Settings, Permalinks. Post name is the safe default. Decide on category bases, product bases and any custom post type slugs now.
If you skip it: changing the structure after launch invalidates every indexed URL and every link anyone has shared.
12. Build a complete old-to-new 301 redirect map (redesigns only)
If you are replacing an existing site, this single item protects more revenue than everything else on the checklist. Crawl the old site, export every URL, then pull the pages with traffic and backlinks from analytics and Search Console.
| Old URL | New URL | Type | Tested |
|---|---|---|---|
| /services-page.html | /services/ | 301 | Yes |
| /blog/?p=142 | /blog/post-slug/ | 301 | Yes |
| /old-product-discontinued | /category/closest-match/ | 301 | Yes |
Rules we apply: one hop only, never redirect everything to the homepage, and map to the closest relevant page rather than a generic category when possible.
If you skip it: years of accumulated rankings and link equity point at 404 pages. Organic traffic typically falls sharply within two to four weeks, and recovering it costs far more than building the map would have.
13. Test redirects, trailing slashes and the 404 page after the switch
Run the old URL list through a crawler on the live domain and look for 404s, redirect chains, redirect loops and 302s that should be 301s. Also test uppercase variants, URLs with query strings, and the old XML sitemap URL.
Then check your 404 template: it should carry navigation, a search box and links to key pages, and it must return an actual 404 status code.
If you skip it: a redirect rule that looks fine in the plugin dashboard can loop in production, and a looping URL is a page nobody can ever reach.
Phase 4: Forms, transactional email and payments (items 14 to 16)
14. Test every form end to end on the live domain
Not on staging. On the real domain, from an outside network, on a phone and on a desktop.
| Check | What to confirm |
|---|---|
| Submission | No error, correct thank-you page or message |
| Validation | Required fields, email format, phone format |
| Notification | Reaches the right inbox, correct reply-to |
| Storage | Entry saved in WordPress or CRM as backup |
| Spam protection | Honeypot or captcha active, real users not blocked |
| Tracking | Conversion event fires once, not twice |
| Consent | Unchecked consent box with a link to the policy |
If you skip it: silent lead loss. The form looks like it works, the visitor sees a confirmation, and the email never arrives. Clients often discover it a month later when they wonder why the phone stopped ringing.
15. Send WordPress email through SMTP or an email API
Default PHP mail from a web server is the fastest way to land in spam. Configure a dedicated sending service, then align SPF, DKIM and DMARC records on the domain.
Test delivery to Gmail, Outlook and at least one corporate mail server, and check the spam folder each time.
If you skip it: order confirmations, password resets and quote requests go to junk. On an ecommerce site that generates support tickets and chargebacks.
16. Run a real transaction if you sell anything
- Payment gateway switched from sandbox to live keys
- One genuine low-value purchase, then a full refund from the dashboard
- Taxes, shipping rules and thresholds calculating correctly per region
- Coupon codes, stock levels and back-in-stock behaviour
- Order confirmation to the customer and to the shop owner
- Checkout completed on a phone, including a wallet payment method
- Terms checkbox, currency and invoice details correct
If you skip it: a store left in test mode accepts orders that never charge anyone. Or worse: tax settings are wrong and every invoice for the first month has to be reissued.
Phase 5: Analytics, Search Console and tracking (items 17 to 19)
17. Install GA4 once, and only once
Check for duplicate tags from a theme option, a plugin and Google Tag Manager all firing together. Then set up:
- Internal traffic filter for your office and your agency IPs
- Data retention set to the maximum available
- Key events marked as conversions: form submit, call click, purchase, quote request
- Consent mode wired to the cookie banner
If you skip it: duplicated tags inflate sessions and destroy bounce and conversion data, so your first three months of decisions rest on numbers that are wrong.
18. Verify Google Search Console and submit the sitemap
Use a domain property so all hostname and protocol variants are covered. Submit the XML sitemap, then check the Pages report and the URL Inspection tool on the homepage and two key pages. Do the same in Bing Webmaster Tools, which also feeds AI answer engines.
If you skip it: you have no early warning system. Search Console is where a noindex mistake, a server error spike or a manual action shows up first.
19. Validate ad pixels and call tracking in preview mode
If you run Google Ads, Meta or LinkedIn campaigns, confirm each pixel fires on the right page and each conversion is counted once. Use tag preview and debug tools rather than assuming.
If you skip it: ad platforms optimise on broken signals and spend rises while reported conversions fall.
Phase 6: Indexing settings and on-page SEO (items 20 to 22)
20. Turn off staging blocks: the most expensive single check
Immediately after go-live, verify all of the following:
- Settings, Reading: “Discourage search engines from indexing this site” is unchecked
robots.txtdoes not containDisallow: /- No
noindexmeta tag orX-Robots-Tagheader on public pages - No HTTP basic authentication or IP restriction left on the live domain
- No maintenance mode or coming-soon plugin still active
- SEO plugin indexing settings reviewed page type by page type
If you skip it: the site is invisible in Google for weeks and nobody notices until someone asks why the new website gets no traffic. Check this twice, once at go-live and once the next morning.
21. Clean the sitemap and canonical tags
Open the XML sitemap and read it. It must contain live domain URLs only, no staging or dev hostnames, no attachment pages, no thin archive pages you do not want indexed. Then view source on three pages and confirm each canonical points to itself on the live domain over HTTPS.
If you skip it: canonicals pointing at a staging subdomain tell Google your real pages are duplicates of a site it cannot even access.
22. Finish the on-page essentials
| Element | Requirement |
|---|---|
| Title tags | Unique, descriptive, no “Home” or “Page not found” leftovers |
| Meta descriptions | Written for key pages, not auto-truncated text |
| Headings | One H1 per page, logical H2 and H3 order |
| Images | Alt text on meaningful images, compressed, sensible filenames |
| Open Graph | Share image and title tested in a debugger |
| Schema | Organization or LocalBusiness, Product, FAQ where relevant, validated |
| Favicon | Present in all sizes, not the theme default |
| NAP consistency | Name, address and phone identical to Google Business Profile |
If you skip it: your pages get indexed with weak, duplicated titles and lose clicks to competitors who bothered to write theirs.
Phase 7: Mobile, browser and performance QA (items 23 to 25)
23. Mobile QA on real devices, not just a resized browser
Most traffic and most conversions happen on phones, and emulators hide the problems that matter.
- No horizontal scrolling on any page or breakpoint
- Mobile menu opens, closes and scrolls, including submenus
- Tap targets large enough and not overlapping
- Sticky headers and cookie banners do not cover the call to action
- Phone numbers are click-to-call, addresses open in maps
- Forms usable with the on-screen keyboard, correct input types
- Tables and price grids readable, images not cropped awkwardly
- Popups dismissible with a thumb
If you skip it: you pay for a site that converts on desktop and leaks on the device two thirds of your visitors are using.
24. Cross-browser and accessibility pass
Test Chrome and Safari on iOS, Chrome on Android, plus Firefox, Edge and Safari on desktop. Then run a quick accessibility review: colour contrast, keyboard navigation with visible focus states, form labels, alt text, and video captions.
If you skip it: Safari-specific layout bugs are common and you exclude users who navigate by keyboard or screen reader, which in many markets is also a legal risk.
25. Verify Core Web Vitals on mobile before you announce
Test key templates, not only the homepage. Compress and convert images to modern formats, lazy load below-the-fold media, keep caching and a CDN active, and cut render-blocking scripts from plugins you barely use.
| Metric | Target | Usual culprit |
|---|---|---|
| LCP | Under 2.5s | Oversized hero image, slow server response |
| INP | Under 200ms | Heavy JavaScript from sliders and trackers |
| CLS | Under 0.1 | Images without dimensions, late-loading fonts and banners |
If you skip it: a slow mobile experience raises bounce rates on paid and organic traffic alike, and every euro of ad spend works harder for less.
Phase 8: Backups, security and monitoring (items 26 to 27)
26. Configure automated backups and prove a restore works
- A manual snapshot taken immediately before the DNS switch
- Automated daily backups of files and database, more often for busy stores
- Copies stored off the web server, in separate cloud storage
- Retention long enough to roll back past a slow-burning problem, 30 days minimum
- One documented test restore, ideally onto staging
If you skip it: an untested backup is not a backup. We have opened archives that were incomplete, corrupted, or contained a database from a plugin conflict three weeks earlier. Test once and you know.
27. Turn on security, uptime monitoring and a maintenance routine
- Firewall or WAF, login rate limiting, XML-RPC restricted if unused
- File editing disabled in the dashboard, correct file permissions
- Uptime monitor with alerts by email or SMS, checking every few minutes
- A written update policy: who updates core, plugins and themes, how often, and on staging first
- Staging environment kept for future changes, never edit live
- Credentials, licence keys and documentation handed over in writing
If you skip it: outdated plugins are the most common entry point for WordPress hacks, and with no uptime alerts you learn your site is down from a customer, hours later.
The first 48 hours after go-live
- Re-check the indexing settings from item 20 the morning after launch
- Confirm GA4 realtime is recording sessions from the live domain
- Watch Search Console for crawl errors and a spike in 404s
- Submit a fresh crawl of the old URL list and fix any remaining 404s
- Send yourself one test form submission and one test order per day for the first week
- Check that company email is still flowing in and out normally
- Restore normal DNS TTL values
- Read server error logs once before closing the project
Questions to ask your developer at handoff
If you are not technical, these six questions expose whether the checklist was actually followed:
- Can you show me the 301 redirect map and the crawl report proving no old URL returns a 404?
- Which email service sends transactional mail, and are SPF, DKIM and DMARC configured?
- Where are backups stored, how often do they run, and when did you last test a restore?
- Which Search Console property is verified, and has the sitemap been accepted?
- Is indexing enabled, and can you screenshot the Reading settings and robots.txt?
- Do I own the hosting, domain and all licences, and do I have the credentials in writing?
Any hesitation on those answers is worth an hour of review before you sign off.
FAQ: WordPress website launch checklist
How long before launch should I start working through this checklist?
Start Phase 1 about a week out, handle DNS preparation 48 hours before, and reserve a two to three hour window on launch day for the checks that can only run on the live domain. Rushed launches are where redirects and indexing settings get skipped.
Who should own the domain and DNS, me or my agency?
You should own the domain registration and hosting account, with your agency given delegated access. It costs nothing and prevents the situation where a relationship ends and you cannot move your own website.
What is the single most commonly skipped item?
Two of them, consistently: the 301 redirect map on redesigns, and the leftover noindex setting from staging. Both are invisible on launch day and both cost real traffic. Item 20 and item 12 deserve a second pair of eyes.
Do I need to resubmit my sitemap after launch?
Yes. Submit it in Search Console on launch day so crawling of the new structure starts quickly, then use URL Inspection to request indexing on your most important pages. Expect a few weeks of fluctuation on a redesign even when redirects are perfect.
My traffic dropped after launching a redesign. What do I check first?
In order: indexing settings and robots.txt, the redirect map for 404s on your previously top pages, canonical tags pointing to the wrong hostname, and whether analytics is even tracking correctly. In our experience a large share of “traffic drops” turn out to be broken tracking rather than lost rankings.
Should I keep the staging site after launch?
Yes, and make sure it is password protected and set to noindex. Every future update, plugin change and template edit should be tested there first. Editing a live site directly is how avoidable outages happen.
Launching soon? Have it reviewed by people who do this weekly
A launch is not a design milestone, it is a technical handover with consequences that surface weeks later. If you want an independent pass over your DNS, redirects, tracking, indexing and backups before you go live, or you want your next WordPress site built and launched against this exact checklist, the team at Pluton WP can help. Get in touch before your launch date, not after.