Content and forms
Go through every page type on a phone and a computer. Look for placeholder texts, test data, broken images and links to the staging address. Check that legal pages, contact details and company information are current.
Submit every form with real-looking data and follow the enquiry to the end: does it reach the right inbox or CRM, does the visitor see a clear confirmation, and what happens if a field is missing? Our guide on connecting website forms to a CRM covers what to test when the CRM is involved.
Check error pages too. A useful 404 page with search or links to main sections keeps visitors who arrive through an old or mistyped address.
Search engines and analytics
Staging sites are usually closed from indexing, and that setting is easy to carry over to the live site by mistake. Check the robots.txt file, the robots meta tags and the canonical addresses on the live domain. Make sure the sitemap lists live addresses only. If any of this sounds unfamiliar, a technical SEO review before launch is cheaper than recovering lost visibility.
If the site replaces an old one, every old address that had traffic or links needs a permanent redirect to its closest new equivalent. Test a sample of them after the switch.
Install analytics before launch and test the events that matter: form submissions, calls, messenger clicks. Decide what counts as an enquiry, so that your marketing analytics reports can be trusted from the first day.
We use the same checks on our own site: how we built our Laravel site and admin panel.
Speed, security and the first week
Measure loading speed on a mobile connection for the home page and one page of each type. The usual culprits are oversized images, too many scripts and fonts. Fixing them before launch is easier than after.
Confirm that the site works over HTTPS only, that administrator accounts have strong passwords and that backups run and can actually be restored. Remove test accounts and unused plugins.
Plan the first week: who watches the 404 log and the form submissions, who checks search console reports for errors and who can roll back a change. A launch is finished when the site has worked normally for several days, not when the domain is switched.
Who checks what on launch day
| Area | What to check | Who |
|---|---|---|
| Forms | Send a test enquiry and confirm it arrived | Site owner |
| Indexing | robots.txt, noindex, sitemap | Developer |
| Redirects | Old addresses open the right new pages | SEO specialist |
| Analytics | Key events fire once per action | Marketer |
Checklist: launch day
- Review every page type on a phone and a computer.
- Submit every form and follow the enquiry to its destination.
- Open the live site for indexing and check the sitemap.
- Redirect old addresses and test a sample after the switch.
- Test analytics events, backups and the 404 page.
- Name who watches errors and enquiries during the first week.
Example: the form that sent nowhere
A new site goes live on a Friday. Pages look right, but the contact form still sends to the test mailbox used during development. Nobody notices until the following week, when a client calls to ask why no one replied.
A launch checklist with one line, “submit every form and confirm receipt”, would have taken five minutes and avoided the problem.
Common mistakes
- Testing by the people who built the site. The team that built it knows where everything is. Someone fresh notices the missing confirmation or the broken link.
- Carrying over the staging noindex. A setting that kept the test site out of search is easy to copy to the live domain by mistake.
- Skipping redirects. Old addresses with links or traffic need permanent redirects to their closest new equivalents, checked after the switch.
- Treating launch day as the finish. Problems show up in the first week, when real visitors, search engines and forms meet the new site.
Questions
What should I check on launch day?
The essentials are in the checklist above: every page type on a phone and a computer, every form followed through to its destination, indexing settings and the sitemap, redirects from old addresses, analytics events, backups and the 404 page. Do them in that order, because forms and indexing cause the most expensive problems.
How do I know Google can index the new site?
Open the live robots.txt and the page source of a few key pages and check that nothing blocks indexing and that canonical tags point to live addresses. Then use the URL Inspection tool in Search Console on those pages and submit the sitemap. If any of this is unfamiliar, a technical SEO check before launch is the safer route.
Who should test the forms?
Ideally the site owner or the person who handles enquiries, not the developer. They know where each enquiry should land and what a customer needs to see after sending it. They should send a real-looking test through every form and confirm it arrived in the right inbox or CRM.
What should you do in the first week after launch?
Watch the 404 log, form submissions and the Search Console reports for errors every day, and agree who can roll back a change if something breaks. Fix broken links and missing redirects as they appear. The launch is finished when the site has worked normally for several days.
