The WordPress Website Launch Checklist: 60 Checks Before You Go Live

A website launch checklist is the difference between a launch day and a firefighting day. After 500+ WordPress projects I can tell you that sites almost never fail at launch because of the hard things – the custom code, the integrations, the design. They fail because of a tick box: the “discourage search engines” setting left on, a contact form that sends mail to nobody, a redirect map that never got imported, caching that was never switched on. Every one of those is a five-minute check, and every one of them has ruined someone’s launch week.

This is the pre-launch ritual I run on every client project before anything goes live – 60 checks, grouped so you can delegate them, with the launch-day order of operations and a first-week monitoring plan at the end. It works for a five-page brochure site and for a WooCommerce store; the store just gets a few extra passes through the same groups. Print the table, work through it top to bottom, and your launch becomes what it should be: boring.

Table of contents

• Why launches break – and how a checklist prevents it
• Content and legal checks (1-10)
• Technical checks (11-22)
• Forms and email checks (23-28)
• SEO and analytics checks (29-38)
• Performance baseline checks (39-46)
• Accessibility quick pass (47-52)
• Security and backup checks (53-60)
• The condensed 60-check table
• Launch day: the order of operations
• The first week after launch
• Frequently asked questions

Why launches break – and how a checklist prevents it

Launch problems share a pattern: they are invisible on staging and obvious in production. Staging sites run with search engines blocked, emails routed to a test address, caching disabled so developers see changes instantly, and licence keys pointed at a development domain. Every one of those differences is correct during the build and wrong the moment the site goes live – which is exactly why “it worked on staging” is the most common sentence in launch post-mortems.

The second pattern is responsibility drift. On a typical project the developer assumes the client proofread the content, the client assumes the developer submitted the sitemap, and the hosting company assumes somebody else configured backups. Nobody is lying; the task simply belongs to nobody. A written checklist fixes both patterns at once: it forces the staging-vs-live differences into the open, and it puts a name next to every check. On my projects I run the technical, SEO, performance, accessibility and security groups myself and hand the client the content group – and we both sign off before DNS changes.

Two rules make the checklist actually work. First, run it on staging in the final week, not on launch morning – half the items (redirects, backups, Search Console) need time to verify. Second, never mark an item done because it “should be fine”. The checks that feel too obvious to test – can visitors reach the site over https, does the purchase email arrive – are precisely the ones that fail in public.

Content and legal checks (1-10)

Content problems will not take the site down, but they are the first thing a client’s customers – and the client’s boss – will notice. This group belongs to whoever owns the words; on my projects that is the client, with me verifying the technical half.

1. Proofread every page in the browser, not in a document. Text reads differently in the design. Check headings, buttons and menu labels, not just paragraphs – “Lorem ipsum” hiding in a footer widget is a classic.
2. Replace every placeholder. Search the database for “lorem”, “TBD”, “coming soon” and the developer’s test phrases. I have found “test test 123” on a live pricing page more than once.
3. Check names, numbers and addresses. Phone numbers, opening hours, the office address in the footer and on the contact page, prices, VAT statements. These are copied from old sites and go stale silently.
4. Click every menu item and footer link. All of them, on desktop and mobile. Menus built during development often keep links to pages that were renamed or dropped.
5. Favicon and home-screen icons in place. A browser tab showing the hosting company’s default icon says “unfinished” louder than any typo. Add the 512px icon so Android and iOS shortcuts look right too.
6. Social sharing preview set. Paste the homepage URL into a social preview checker – the Open Graph image, title and description are what the site looks like in WhatsApp, LinkedIn and Slack.
7. A designed 404 page exists. With a search box or links back to the main sections. Visitors will hit it in week one no matter how good your redirects are.
8. Legal pages published and linked. Privacy policy, imprint where required (mandatory in Germany and Austria), terms, and a cookie or consent notice that matches what the site actually loads. For EU-facing sites this is a legal exposure, not a formality.
9. Old content removed from the new site. Draft pages, unused templates, sample posts, the theme’s demo content. Set anything not ready to draft, not “hidden from the menu” – hidden pages still get indexed.
10. Print a key page. Thirty seconds, and you find the white-text-on-white-background surprise before an accountant printing your terms does.

Technical checks (11-22)

This is the group where staging-vs-live differences live, and the group I never delegate. Every item here has a horror story behind it.

11. The search engine visibility toggle is OFF. Settings, Reading, “Discourage search engines from indexing this site” – unticked. This box is correctly ON for staging and must be turned off at launch, and it is the single most damaging thing to forget. I have seen a site sit invisible for six weeks because of it; check it first and check it again after migration, because copying the staging database can bring the setting along.
12. No stray noindex or blocking robots.txt. The toggle is not the only blocker: SEO plugins can set sitewide noindex, and some hosts write a blocking robots.txt for development URLs. View source on key pages and open /robots.txt directly.
13. SSL valid and forced everywhere. The certificate covers www and non-www, http redirects to https, and there are no mixed-content warnings – hard-coded http image URLs from staging are the usual cause. One canonical version of the domain (I usually pick non-www) with everything else 301-redirecting to it.
14. The redirect map is imported and spot-checked. If this launch replaces an old site, every old URL that had traffic or backlinks needs a 301 to its new equivalent. Crawl the old site for its URL list, map the top pages one to one, and test the twenty most important by hand. This is the same discipline as a domain move – I cover it in depth in website migration without losing SEO rankings.
15. Staging config replaced by production config. Search-and-replace the staging URL in the database (serialised-data safe), swap test API keys for live ones (payment gateways especially), point licence keys at the live domain, and set WP_DEBUG to false. A staging Stripe key on a live checkout takes real orders and no real money.
16. Caching switched on and verified. Page caching, object caching if the host offers it, and the CDN if there is one. Staging runs uncached so developers see changes; production must not. Load a page twice and check the cache-hit header.
17. Backups configured on the live site. Automated, daily for a content site, more often for a store, stored off the server, with retention you have actually looked at. “The host does backups” is a hope, not a check – see item 58 for the restore test.
18. Cron and scheduled tasks running. WordPress cron drives scheduled posts, backups and store housekeeping. If the host disables loopback requests, set a real server cron. A missed backup schedule fails silently for months.
19. Search works. Site search returns sensible results and the results template is styled. Nobody tests this and every visitor assumes it works.
20. The site behaves logged out. Browse in a private window. Membership plugins, cookie notices and cached-for-admins pages all behave differently for visitors than for the logged-in developer.
21. Real-device pass on the top pages. A real phone and a real tablet, not just a resized browser: home, contact, one service or product page, checkout if there is one. Touch targets, sticky headers and viewport quirks only show up on glass.
22. Time zone, date format and email sender name correct. Small, but “server time, UTC” on a German invoice or “WordPress” as the email sender undermines trust immediately.

Forms and email checks (23-28)

Forms are the site’s revenue pipe and the most common silent failure I see: the form looks fine, submits fine, and the enquiry lands in a spam folder or nowhere at all. Every form gets tested end to end – meaning a real submission followed by a real received email, not a green “message sent” banner.

23. Submit every form for real. Contact, quote, newsletter, callback, careers – each one, from the live URL, with a plausible test entry you delete afterwards.
24. Confirm delivery at the receiving end. The notification arrives in the client’s actual inbox, not the developer’s test address that staging was pointed at. Check the reply-to is the visitor’s address so the client can answer with one click.
25. Send email over SMTP or a transactional service, not PHP mail. Default WordPress mail lands in spam often enough to cost real enquiries. An SMTP plugin with a transactional provider takes twenty minutes and includes a delivery log – which turns “did the form send it?” from a guess into a lookup.
26. Spam protection active and invisible. A honeypot plus a modern challenge on public forms. Check the protection actually fires on the live domain – several anti-spam services are keyed per domain and silently pass everything on an unregistered one.
27. Confirmation states and error messages make sense. The success message tells people what happens next (“we reply within one working day”), and validation errors say what to fix, not “an error occurred”.
28. Store transactions tested with a real card. For WooCommerce: one live-mode order with a real card (refund it afterwards), confirming payment capture, stock reduction, the customer email, the admin email and the correct tax on the invoice. Test mode proves the theme works; live mode proves the money works.

SEO and analytics checks (29-38)

Launch is the moment search engines re-evaluate the site. Done right, rankings carry over and new pages start being discovered within days; done wrong, you spend months recovering. This group takes an hour and protects years of accumulated authority.

29. Titles and meta descriptions set on every important page. Home, services, products, key landing pages – written for humans, unique per page. Auto-generated “Home – Sitename” titles are a wasted first impression in search results.
30. One H1 per page and a sane heading hierarchy. Page builders and careless templates love to make every widget title an H1. View source and check the top pages.
31. XML sitemap generated and reachable. Open it in the browser: it lists the real live URLs, not staging URLs, and excludes drafts, tag archives you do not want indexed, and media attachment pages.
32. Search Console verified and the sitemap submitted. Do this on launch day, not “next week” – it is also your early-warning system for the crawl errors and coverage problems you will watch in week one.
33. Canonical URLs correct. Spot-check that canonicals point to the live domain and to each page’s own URL. A sitewide canonical still pointing at the staging domain quietly deindexes everything.
34. Redirects re-checked from search results. Google the old site, click the top ten results, and confirm each lands on the right new page with a 301 – the visitor-eye view of item 14.
35. Analytics installed and receiving data. Open the real-time report while you browse the live site. Verify your own visits and office IPs are excluded, and that the consent banner and analytics agree with each other – analytics that fires before consent is a compliance problem in the EU.
36. Conversion events tracked. Form submissions, phone-number clicks, purchases. If launch day is the baseline, you want the measuring tape working from hour one.
37. Schema markup valid. Organisation or LocalBusiness sitewide, Product on products, FAQ where used – run key pages through a rich results test and fix warnings before Google finds them.
38. Permalinks are final. Clean, keyword-sensible URL structure, decided now – changing permalinks after launch means a second redirect project. Flush the permalink settings once after migration; it cures a surprising number of phantom 404s.

Performance baseline checks (39-46)

You do not need a perfect score on launch day; you need a known baseline and no obvious regressions from staging. Perfect can come later – unknown cannot, because “the site feels slow” is unanswerable without a number from day one.

39. PageSpeed run on three real pages. Home, the heaviest template (usually a product or portfolio page) and one plain content page – mobile scores, recorded in the project notes. My handover target on a custom build is 90+ on mobile; on a rescued site, “measurably better than the old site” is the honest goal.
40. Core Web Vitals within thresholds. LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds on the tested pages. CLS problems at launch are usually a late-loading font or an unsized hero image – both ten-minute fixes.
41. Images sized, compressed and lazy-loaded. No 4,000-pixel originals scaled down in CSS, WebP served where supported, lazy loading on everything below the fold but NOT on the LCP image.
42. Caching verified from a cold and warm hit. First load primes the cache, second load should come back in well under half a second server-time. If the second load is as slow as the first, the cache is configured but not working.
43. Fonts under control. Two families maximum, subset, preloaded, with font-display swap – and served locally rather than from a third party, which is also a GDPR point in Germany.
44. Unused plugins and scripts removed. Launch is the cheapest moment to delete the three plugins that were tried and abandoned during the build. Every one is load time and attack surface.
45. PHP version and object cache confirmed with the host. Current PHP (not the host’s conservative default) and Redis or Memcached if the plan includes it. Five minutes with support, easily 20-30% server-response improvement on dynamic pages.
46. The heaviest realistic page tested under load. For stores and campaign sites: a simple load test against the cached page, so launch-announcement traffic does not become the first stress test. The full tuning menu is in my complete WordPress speed guide.

Accessibility quick pass (47-52)

A full audit is a project of its own; this is the 30-minute pass that catches the failures affecting the most visitors – and, in a growing number of markets, the failures with legal weight. Roughly one visitor in ten benefits directly, and every item here also improves usability for everyone else.

47. Keyboard-only walk-through. Tab through the header, menu, a form and the footer. Everything reachable, in a sensible order, with no keyboard traps – mobile menus and modal popups are the usual offenders.
48. Visible focus states. You can always see which element has focus. Themes that remove focus outlines for aesthetics fail real users to look marginally tidier.
49. Colour contrast at AA. Body text, buttons and links against their backgrounds – the automated check flags them in seconds, and light-grey-on-white body text is the most common failure I see in delivered designs.
50. Meaningful alt text on meaningful images. Describe what the image communicates; decorative images get empty alt attributes, not keyword stuffing.
51. Forms properly labelled. Real label elements tied to inputs (placeholders are not labels), and error messages announced where assistive tech can find them.
52. Lighthouse accessibility 95+ on key pages. Automated checks catch maybe a third of real issues, but scoring under 95 on the automated third means the manual two-thirds are certainly worse. On my builds this score is part of the definition of done, not an aspiration.

Security and backup checks (53-60)

A fresh launch is a soft target: new DNS, default settings, and an admin team busy celebrating. Ten minutes of hardening now is cheaper than any cleanup later.

53. All software current at launch. Core, theme, every plugin – launching with pending updates means launching with published vulnerabilities.
54. Admin accounts cleaned up. No “admin” username, strong unique passwords, two-factor for administrators, and every build-phase account (the designer, the content agency, the old developer) removed or downgraded. Each person gets their own account – audit trails matter the day something goes wrong.
55. Login protection active. Rate limiting on login and XML-RPC disabled unless something genuinely needs it. Bots find a new WordPress login page within hours of DNS propagating.
56. File editing disabled and keys rotated. DISALLOW_FILE_EDIT in wp-config, fresh salts, correct file permissions, and database credentials that are not reused from staging.
57. Security headers in place. X-Frame-Options, X-Content-Type-Options, referrer policy and a content security policy where feasible – one config block, permanent benefit.
58. A restore actually tested. Take a full backup of the finished site and restore it to a local or staging environment once. A backup you have never restored is a theory; you do not want to test the theory during an emergency.
59. Uptime and error monitoring switched on. An uptime monitor pinging the live URL and alerting the right inbox, plus 404 and error logging you can read – these are your eyes for the first week.
60. The maintenance plan agreed before launch. Who applies updates, who checks backups, who answers when the site is down at 9pm – decided now, in writing. A launch without a maintenance owner is a countdown; my weekly routine is in the WordPress maintenance checklist, and the maintenance and security service exists for clients who would rather hand it over.

The condensed 60-check table

This is the version I actually print and tick off with clients – one row per group, with owners and the check in each group that gets missed most often. The numbers refer to the full list above.

Two habits make the table work in practice. First, every row needs a named owner before launch week starts – a group owned by “the team” is a group owned by nobody. Second, the sign-off is per group, not per project: the client signs content and legal, I sign the rest, and DNS does not change until all seven rows are signed. It feels bureaucratic exactly once, and then it feels like the reason the launch was quiet.

Launch day: the order of operations

The checklist gets the site ready; launch day is about doing things in the right order, because several steps depend on each other. My sequence, refined over hundreds of launches:

1. Pick a boring time. Mid-morning on a Tuesday or Wednesday, never Friday afternoon, never before a holiday. You want the whole team available for the hours after, and a working day at the host’s support desk.
2. Freeze changes and take the final backup. Full files-and-database backup of the finished staging site AND of the old live site if one exists. This is the undo button for everything that follows.
3. Migrate and configure. Move the site to the production environment, run the URL search-and-replace, swap in the live API keys and licence domains, and set debug off. Verify the site on the host’s preview URL before touching DNS.
4. Point DNS. Lower the TTL a day in advance if you can; then change the records. Propagation is usually minutes to a few hours – use it for the next steps, not for waiting.
5. Force SSL and activate redirects. Certificate issued for the live domain, https forced, canonical domain redirecting, and the old-site redirect map live. Test the top twenty old URLs immediately.
6. Open the site to search engines. Untick the visibility toggle, confirm robots.txt allows crawling, confirm no sitewide noindex survived the migration. This is deliberately AFTER DNS and SSL, so Google’s first crawl sees the finished site.
7. Switch caching on and prime it. Enable page cache and CDN, browse the top pages to warm them, verify cache-hit headers.
8. Submit the sitemap and verify tracking. Sitemap into Search Console, a live test of analytics real-time, conversion events firing.
9. Run the smoke test. The short version of the full checklist, on the live domain: every form submitted for real, one live transaction on a store, top pages on a real phone, PageSpeed on the home page. One hour, no shortcuts.
10. Announce – after the smoke test. The newsletter and social posts go out only when step 9 is green. Announcing at DNS-change time is how launch traffic finds a certificate warning.

Keep the old site’s backup and hosting for at least a month – it costs a few euros and it is the rollback plan nobody regrets having. And keep the developer on standby for the day: on my launches this is included, because the fastest fix is the person who built it watching the logs.

The first week after launch

Launch is not the finish line; it is the start of the only week when small problems are still small. Fifteen minutes a day, seven days, watching four things:

• The 404 log, daily. Every real 404 with traffic behind it is a redirect you missed – add it the same day. The log goes quiet within a week or two on a well-mapped launch; if it does not, the redirect map has holes.
• Search Console, daily. Coverage and indexing: pages being discovered, no unexpected “excluded by noindex”, no crawl errors climbing. If old URLs still dominate the index after a week, re-check the redirects and canonicals rather than waiting.
• Form entries against the inbox. Compare the form plugin’s entry log with the emails that actually arrived. A mismatch means deliverability broke after launch – the transactional-mail log from check 25 tells you exactly where.
• Real-world performance. Re-run PageSpeed mid-week once caches are warm and real traffic exists, and watch server response times if the host provides them. Traffic exposes what test clicks never do – if the numbers sag, the tuning list in the speed optimisation service is where I start.

At the end of the week, hold a 30-minute retrospective: what broke, what was missed, what gets added to the checklist for the next launch. My 60 checks started as about 25; every addition since has been paid for by a launch that taught me something. Then the site moves from launch mode to maintenance mode – the daily-weekly-monthly rhythm linked above – and the checklist goes back in the drawer until the next project.

Want a launch that goes quietly?

I run this exact checklist on every site I build and every site I help launch – as part of a custom WordPress development project or as a standalone pre-launch review of a site someone else built. Fixed price quoted within 24 hours, reply within 24 hours, and the boring launch day you are hoping for. See the portfolio or get in touch with your go-live date.

Frequently asked questions

What is a website launch checklist?

A written list of checks – content, technical, SEO, performance, accessibility and security – that a site must pass before going live. It exists because launches fail on small forgettable settings, not on hard problems.

How long does the full 60-check list take?

About a day of focused work spread over the final week: the content group a couple of hours on the client side, the technical and SEO groups half a day, performance, accessibility and security the rest. The smoke test on launch day itself takes about an hour.

What is the most common launch mistake on WordPress sites?

Leaving “discourage search engines from indexing this site” switched on after migrating from staging. It is correct during development, catastrophic in production, and invisible unless you look.

When should I submit the sitemap to Search Console?

On launch day, right after DNS, SSL and the visibility toggle are sorted – so Google’s first crawl of the new site sees the finished version and indexing starts immediately.

Do I need the checklist for a small five-page site?

Yes – the checks that break launches (forms, SSL, visibility toggle, backups) apply at any size. A small site just moves through the groups faster, in half a day instead of a full one.

What should I monitor in the first week after launch?

The 404 log for missed redirects, Search Console for indexing and crawl errors, form entries against the actual inbox for deliverability, and real-world performance once caches are warm.

Who should run the launch checklist – the developer or the site owner?

Both, with named owners per group: the owner signs off content and legal, the developer signs off technical, SEO, performance, accessibility and security. Nothing goes live until every group is signed.