Websites rarely fail loudly on launch day. They fail quietly: a contact form still emailing a developer’s test inbox, a “noindex” setting left on from staging, an analytics tag counting every visit twice. The site looks finished, so nobody notices for weeks. A website launch checklist is how you catch those problems first.
This one groups the checks by who should run them, then sets out the launch-day order and what to watch in week one. It assumes the site was built on staging, a private copy used for testing; our guide to the website development process explains where that fits.
How to use this website launch checklist
Most launch problems come from what changes at launch: the domain, often the server, the certificate, how email is sent, the caching. A form that worked on staging can fail on the live domain for reasons unrelated to the form.
So use this as both a pre-launch website checklist and a go-live checklist: run each check on staging, fix what you find, then repeat it on the live site within an hour of switching over.
| Area | Who runs it |
|---|---|
| Search engine blocks, HTTPS, redirects, 404 page, speed, backups and monitoring | Developer |
| Integrations with your CRM, bookings or payments | Developer, plus whoever uses the other system |
| Analytics, consent, social previews, browsers, devices and accessibility | Marketing |
| Forms and notifications | Whoever receives the enquiries |
| Accounts, content sign-off, timing and a way back | Business owner |
One person may hold several roles, but every row needs a name.
Developer checks
Search engine blocks and staging passwords
Staging is usually hidden from Google in several ways. All of them must come off:
If the staging hostname appears anywhere in the page source, run a database search-and-replace with a tool that handles how WordPress stores settings. Leftover blocks are a common reason for a new website not showing on Google.
HTTPS and mixed content
The certificate should cover every version of the domain, with and without “www”, and renew automatically. Every variant should reach one preferred HTTPS address, ideally in a single redirect.
Then look for mixed content: a secure page loading images, scripts or fonts over plain HTTP, usually from addresses hard-coded during the build. Browsers block insecure scripts and fonts, and upgrade or block insecure images: expect anything from a missing image to a broken menu. The browser console flags each case; check it on every page template.
Redirects from old URLs
On a redesign, every page that exists today needs somewhere to go tomorrow. Build the list from a full crawl of the old site, plus the pages Search Console shows receiving clicks or links from other sites. Use permanent (301) redirects, in one hop, to each page’s closest new equivalent rather than the homepage. Include old PDFs and every language version.
After launch, test the whole list on the live site. The website migration SEO checklist covers the ranking side; if you’re also changing hosting company, our guide to moving to a new host covers DNS and email, where server moves usually go wrong.
The 404 page
Type a nonsense address on your domain: you should get a helpful page in the right language, linking to your main sections and contact details. Its status code, shown in the developer tools’ Network tab, must be 404. A “not found” page returning 200 tells search engines the page exists, and Search Console reports pages like that as “soft 404” errors.
Speed
Run PageSpeed Insights on the homepage, a key service page and your heaviest page, mobile results first. Its real-visitor data (from the Chrome UX Report) covers the previous 28 days, so a brand-new site has none yet and a redesign will mostly show the old site for a few weeks. Until then, treat the lab results as an early warning, not a verdict.
Confirm production settings are on (page caching, image compression, any CDN) and staging-only tools, such as debugging plugins, are off. How to read a PageSpeed Insights report explains which numbers matter.
Backups, monitoring and security
Once the new site is live, confirm that:
These checks also open your website maintenance checklist: launch is when a site’s care begins.
Integrations
CRMs, booking calendars, email tools and payment providers are often connected in test mode during the build. At launch, confirm live API keys have replaced test keys, webhooks point at the live domain, and services that only accept approved domains, such as Google reCAPTCHA, list it.
Send one test record through end to end and ask the person who uses that system daily to inspect it: they will spot a missing field or a misrouted lead faster than any developer. Our guide to website integrations explains why these connections tend to fail silently.
Marketing checks
Analytics and consent
Open the Realtime report in Google Analytics 4 and browse the live site. Check that:
Where consent is required, decline on the banner and check the browser’s developer tools (Application → Cookies in Chrome): no analytics or advertising cookies should appear until you accept. The privacy policy should list the tools the new site actually uses. Tracking enquiries in GA4 covers event set-up step by step.
Social previews
Link previews on LinkedIn, Facebook and messaging apps come from Open Graph tags: og:title, og:description and og:image. Every key page needs its own, with a share image (1200 × 630 pixels is a common choice) that keeps important text away from the edges, where some platforms crop. Paste live URLs into Meta’s Sharing Debugger and LinkedIn’s Post Inspector to see the preview and refresh any stale copy.
Cross-browser and device testing
Your analytics show which browsers and devices visitors use. For most business sites, that means Chrome, Safari, Edge and Firefox on a computer, plus a real iPhone and Android phone on mobile data. On each, check that:
- The menu opens, closes and scrolls.
- Forms work with the on-screen keyboard open, including date pickers and uploads.
- Nothing scrolls sideways, and sticky headers or chat buttons don’t cover content.
- Switching language keeps you on the equivalent page.
Then ask two colleagues who haven’t seen the site to find a service and get in touch, and watch where they hesitate.
Accessibility basics
These quick checks catch many common barriers:
Automated checkers such as Lighthouse and WAVE help but catch only part of the picture; the web accessibility guide covers the rest.
Owner and sales-team checks
Forms and notifications
Forms are where launch problems cost most, because a broken form looks exactly like a quiet week. Whoever receives the enquiries should submit every form, in every language, from a phone and a laptop, and confirm that:
If notifications land in spam or never arrive, the cause is usually how the site sends email. By default, WordPress sends it from the web server through PHP’s mail function, and many mail providers distrust those messages. Sending through an authenticated email service, with SPF, DKIM and DMARC records set up for your domain, solves most cases. For the design side, see web form design.
Accounts, timing and a way back
Before anyone flips the switch, the business owner should confirm:
- Accounts. Domain, DNS, hosting, analytics and Search Console are in the company’s name, with your own administrator logins.
- Content sign-off. Prices, phone numbers, addresses and legal pages have been read by someone who would know if they were wrong.
- Timing. The builder and the person receiving enquiries are both free for the rest of launch day, and it isn’t the eve of a holiday or campaign.
- A way back. The old site and its backup stay ready, so the domain can be pointed back if something serious breaks.
Launch day, in order
A launch day checklist is mostly about sequence. This order keeps the risky window short:
- Pause content edits on the old site, so nothing added that day is lost.
- Take and download a full backup of the old site.
- Update the DNS records to point the domain at the new server. Their TTL (how long other networks may keep using the old address) should have been lowered a day or two earlier, so the change spreads quickly. Leave the email (MX) records alone; if DNS is moving provider, copy them across first.
- Remove staging protections and confirm HTTPS on every domain variant.
- Submit every form, test the redirect list and check GA4 Realtime.
- Check that Google Search Console still shows the site as verified (a verification file or tag on the old site may not have come across), then submit the XML sitemap.
- Tell your team the site is live, and give them one place to report problems.
The first week after launch
Some problems only appear once real visitors and search engines arrive. Watch four things:
- Indexing. On day one, run Search Console’s URL Inspection on key pages; “Test live URL” should confirm each can be indexed. Request indexing for the most important, then watch the Page indexing report, which lags by a few days.
- Enquiries. Compare them with a normal week. If they drop to zero, retest the forms before assuming the market went quiet.
- Missing pages. Look for 404s in Search Console, in analytics and in anything customers mention. Each is a missing redirect or a broken link.
- Tracking and backups. GA4 key events should roughly match the enquiries your team received, and the first scheduled backups should have run.
After that, launch turns into improvement: a fuller review with the technical SEO checklist once Google has processed the new site, and a continuous-improvement plan for the first 90 days.
Before you set a launch date
Copy the table above into your project plan, put a name against each row, and don’t fix a launch date until every check has passed on staging.
Already live and unsure these checks were ever run? A free website audit looks at several of them from the outside, including indexing, speed, HTTPS and the route to an enquiry, and we send the findings in writing within two business days.
Planning a redesign? Our website redesign projects redirect every old URL and launch without taking the site offline, and our care plans keep backups, updates and monitoring running afterwards.