Website Launch Checklist: 25 Checks Before You Go Live

A website is not ready to launch because the homepage looks finished.

It is ready when customers can use it, enquiries arrive where they should, search engines can crawl the correct pages, analytics records the important actions and the business has a way back if the launch goes wrong.

The checks below are ordered around risk. A typo in a footer can wait. A broken contact form, missing redirect, site-wide noindex directive or failed checkout should stop the launch.

Website launch checklist: what should block a go-live?

1. Test every important form end to end

Do not stop when the form displays a success message.

Submit it using a real external email address. Confirm:

• the form accepts valid information;
• validation works when information is missing;
• the customer sees the correct confirmation;
• the message reaches the correct inbox;
• the sender and reply-to details make sense;
• CRM or automation actions fire where expected;
• spam protection does not block genuine submissions.

If the form appears to submit but the email never arrives, the troubleshooting steps in WordPress contact form not sending emails help separate form, server and mail-delivery problems.

2. Test phone, email and WhatsApp links on a real phone

A phone number can look correct on screen while the underlying link contains the wrong number.

Tap every important call, email and messaging button. Check sticky mobile bars as well as normal page buttons.

3. Complete the main customer journey yourself

Start where a customer might start and complete the action you want them to take.

For a service business, find a service, read the information and submit an enquiry.

For ecommerce, add a product to the basket and complete a test transaction.

For bookings, choose a date, complete the process and check the confirmation.

If you cannot complete the journey cleanly before launch, customers will not magically have a better experience afterwards.

4. Check every automated email

Contact confirmations, booking emails, order confirmations, password resets and internal notifications all need testing.

Check the content as well as delivery. Old staging URLs, placeholder text and incorrect sender names are common launch leftovers.

5. Verify all visible business information

Review:

• phone numbers;
• addresses;
• opening hours;
• prices;
• service areas;
• company number where relevant;
• VAT information where applicable;
• legal and privacy pages;
• social profile links.

A technically perfect website with the wrong phone number is still a failed launch.

6. Test the website on real mobile devices

Responsive previews are useful, but they do not reproduce everything that happens on a real phone.

Check at least one iPhone and one Android device where practical.

Look for:

• menu problems;
• text that is too small;
• buttons hidden by sticky bars;
• horizontal scrolling;
• forms covered by the keyboard;
• pop-ups that cannot be closed;
• images cropping important content;
• cookie banners blocking calls to action.

7. Check the menu, header and footer

Every navigation link should go somewhere intentional.

Look for old staging links, placeholder menu items, duplicate pages and links that rely on redirects unnecessarily.

8. Test forms with mobile keyboards

Email fields should behave like email fields. Telephone fields should be easy to complete. Error messages should remain visible when the keyboard opens.

Small usability failures can destroy form completion even when the form is technically functioning.

9. Test the site away from fast office Wi-Fi

A site that feels instant on a fibre connection can feel sluggish on an ordinary mobile network.

Load the homepage, key service pages and any heavy ecommerce pages over a realistic connection.

10. Check for accidental noindex directives

Staging sites are often intentionally hidden from search engines. The problem is when those settings survive the move to production.

Check important page templates, not only the homepage.

11. Confirm the main heading structure

Important pages should have one clear main H1 and a logical supporting hierarchy underneath it.

Do not obsess over mechanically perfect heading numbers at the expense of readability, but avoid template errors that generate multiple unrelated H1s or skip clear structure entirely.

12. Review page titles and meta descriptions

Priority commercial pages should not all inherit the same generic title.

Make sure titles describe the actual page and fit the intended search role. Descriptions should be useful rather than stuffed with keywords.

13. Check canonical URLs

Live pages should point to the correct preferred live URL.

Look specifically for canonicals referencing:

• the staging domain;
• an old domain;
• HTTP instead of HTTPS;
• another page by mistake;
• parameter versions that should not be preferred.

14. Map important old URLs before replacing an existing site

If the launch is replacing a live website, this is one of the most important checks in the project.

Every valuable old URL should have a deliberate outcome. Keep it where possible. Where it must change, use a direct permanent redirect to the closest useful replacement.

Do not redirect dozens of unrelated old pages to the homepage simply to avoid 404s.

15. Update internal links to the final live URLs

Redirects are for old external references and changed addresses. Your new site should link directly to its final destinations.

Check menus, body links, buttons, breadcrumbs and related-content blocks.

16. Review the XML sitemap

The sitemap should contain the canonical URLs you want search engines to discover.

Remove:

• staging URLs;
• redirected pages;
• test pages;
• private content;
• duplicate parameter versions;
• URLs intentionally marked noindex.

17. Verify Search Console access

Make sure the business can access the correct property and that the people responsible for post-launch monitoring are already added.

The deeper crawl, schema and indexability checks in the technical SEO audit checklist are useful for larger launches where several templates or URL groups are changing.

18. Confirm analytics is collecting real traffic

Open the live or staging site from a device you can identify and verify that the visit reaches your analytics platform.

Check the correct production measurement ID is installed, not a staging property.

19. Test conversion tracking

Pageviews alone are not enough.

Test the actions that matter:

• form submissions;
• phone clicks;
• WhatsApp clicks;
• bookings;
• purchases;
• quote requests;
• downloads where commercially relevant.

If Google Ads or other paid campaigns will send traffic immediately after launch, failed conversion tracking can distort bidding and reporting from day one.

20. Record a pre-launch baseline for redesigns and migrations

Before replacing an existing site, save:

• organic clicks and impressions;
• top landing pages;
• important queries;
• current conversions;
• pages with backlinks;
• any useful rank tracking.

Without a baseline, post-launch diagnosis becomes guesswork.

21. Check HTTPS and SSL

The preferred live URL should load securely without certificate errors.

Check for mixed-content warnings caused by old HTTP images, scripts or stylesheets.

22. Crawl for broken links

Internal 404s should be fixed before launch.

Also look for links that still point at staging, old development paths or URLs that immediately redirect.

23. Take a final backup and prove it can be restored

A backup is only useful if it contains the files and database needed for recovery and somebody knows how to restore it.

The process in testing a WordPress backup is worth completing before a business-critical site is replaced.

24. Confirm who owns and controls the important accounts

The business should know who controls:

• domain registrar;
• DNS;
• hosting;
• WordPress or CMS admin;
• analytics;
• Search Console;
• Tag Manager;
• payment gateways;
• email services;
• premium licences.

Launch day is a bad time to discover the domain is still registered in the previous developer’s account.

25. Define the rollback conditions before launch

Agree what would justify reversing the deployment.

Possible rollback triggers include:

• checkout failure;
• widespread 500 errors;
• critical forms not working;
• serious DNS or SSL failure;
• missing high-value redirects;
• a site-wide indexing block;
• loss of a business-critical integration.

Do not make that decision for the first time while customers are already hitting the broken site.

26. Check accessibility basics

Accessibility belongs before launch, not in a someday backlog.

At minimum, review:

• keyboard navigation;
• visible focus states;
• form labels;
• colour contrast;
• image alt text;
• heading structure;
• button and link clarity;
• whether key actions are possible without a mouse.

27. Check consent and tracking together

A cookie banner is not useful if it says one thing while analytics and advertising tags do another.

Verify the intended scripts respect your consent setup and that conversion tracking still works once consent is granted.

28. Validate relevant structured data

Check schema used on important pages for validity and accuracy.

Remove stale staging markup or template-generated data describing the wrong business, product or breadcrumb path.

29. Test multiple browsers

At minimum, check current versions of Safari and Chrome plus another major browser where practical.

Sticky headers, forms, date fields and viewport behaviour are common places for browser-specific surprises.

30. Check real-world performance

Use performance tools for diagnosis, but also load the important pages yourself.

Look for:

• oversized hero images;
• layout shifts;
• heavy video;
• unnecessary third-party scripts;
• fonts delaying rendering;
• pop-ups appearing before the page becomes usable.

31. Check social sharing and browser presentation

Confirm the favicon, social-preview image and page title are sensible. These are not launch blockers, but they are quick to fix before customers begin sharing the site.

32. Check legal and privacy pages match the actual setup

Do not copy an old privacy policy onto a new site without checking whether the technology changed.

New forms, analytics tools, chat systems, payment providers and marketing integrations can alter what the site actually collects.

33. Check 404 behaviour

Visit a made-up URL deliberately.

The site should return a genuine 404 status and offer a useful route back rather than silently redirecting everything to the homepage.

34. Check email sending from the live domain

Staging and production can use different server settings. Test transactional and form email again after the final domain is active.

35. Check DNS records beyond the website

A website launch should not accidentally break business email.

If DNS changes are involved, preserve the records required for email and other services.

36. Check redirects on the real server

A redirect spreadsheet is only a plan until the server is actually returning the correct responses.

Test a sample of high-value old URLs immediately after launch.

37. Check server errors and uptime

Watch for unexpected 5xx responses, memory problems or resource limits after real users and crawlers reach the new site.

38. Repeat the customer journey after DNS changes

The final production environment is the one that matters.

Submit the form again. Make a test purchase. Complete the booking. Check the confirmation email.

39. Crawl the live site again

Compare it with staging.

Deployment can introduce problems that were not present before the switch: wrong URLs, missing files, broken internal links or production-specific canonical rules.

40. Monitor the first week

For a replacement site, watch:

• Search Console indexing;
• 404s;
• organic landing pages;
• conversions;
• server errors;
• forms and sales;
• customer feedback.

The launch is a controlled change, not a ceremonial button press.

What should happen in the first 30 days?

Once the urgent launch checks are stable, start judging whether the new site is actually doing its job.

Compare:

• enquiry volume;
• conversion rate;
• mobile behaviour;
• organic impressions and clicks;
• important page traffic;
• checkout or booking completion;
• support issues reported by customers.

A redesign should eventually be judged by business performance, not whether everybody liked it on launch day.

Who should sign off the launch?

One named person should have final go-live authority.

Other people can own individual checks — development, SEO, forms, content, analytics — but somebody needs the authority to say the launch criteria have been met.

That is particularly important when several agencies or suppliers are involved.

Planning the project before launch

A good launch starts before development. The website brief guide helps define pages, functionality and responsibilities early, while the website build timeline guide shows where the weeks normally go.

How we approach launch readiness

Our web design service in London treats forms, mobile behaviour, analytics, redirects and post-launch checks as part of getting a website live properly rather than optional extras after the visual work is finished.

Frequently asked questions

When should a new website be submitted to Google?

Once the live site is crawlable, important pages are indexable and the XML sitemap contains the correct canonical URLs. Search Console can then be used to submit and monitor the site.

Is Friday a bad day to launch a website?

The real issue is support availability. Launch when the people needed to fix DNS, hosting, forms, checkout or redirects will be available afterwards.

How long should a website be monitored after launch?

Critical functions should be watched immediately, while indexing, organic performance and conversions should be reviewed over the following days and weeks.

Should a site launch with small visual issues?

Minor cosmetic issues can often be fixed after launch. Business-critical problems involving forms, payments, security, redirects, indexability or tracking should be resolved first.

Who should own the domain after launch?

The business should normally control the domain or have clear contractual access to it. The same principle applies to important analytics and platform accounts.