Key takeaways
- Record the current site, traffic, and conversion counts before anything changes.
- Test the form failure path, not only the successful submission.
- Confirm consent blocks non-essential tags until a choice is made.
- Keep the previous deployment available until the new one is stable.
On this page
Record the baseline before anything changes
Export the current state before the first deployment: the sitemap, the robots file, the top landing pages, the conversion counts for the last four weeks, and the DNS records with their time to live. The website and ecommerce service includes this launch checklist. Without a baseline, nobody can tell whether a drop after launch is a fault or normal variation.
Lower the DNS time to live to a few minutes at least a day before the switch, so a rollback does not wait for caches to expire. Freeze content changes during the launch window; a copy edit is easy to repeat, but a broken form during a campaign is not.
Test every form, including the failure path
Submit each form on staging and again on production using an address you control. Once it works, add GA4 conversion tracking so submissions are measured. Confirm the recipient, the reply-to address, the subject line, and the auto-response. Check that the success message is specific and that refreshing the page does not send the message twice.
Then break it on purpose. Point the mail credentials at a test value and confirm the page shows an error instead of a success message. A form that silently discards leads is worse than one that fails loudly.
- Required fields validate on the server, not only in the browser.
- Malformed requests return a client error rather than a success page.
- Oversized submissions are rejected before they reach the mail service.
- Rate limiting returns a clear retry message.
- Spam protection blocks bots without blocking real users or assistive technology.
- The reply-to address accepts replies and reaches a monitored inbox.
Verify analytics and consent
Load the site in a clean browser and confirm the analytics tag fires once, not twice. Check that the consent banner blocks non-essential tags until consent is given, and that the choice persists across pages and return visits.
Exclude internal traffic, or use a debug mode while testing so your own visits do not pollute the launch data. Agree the campaign parameter convention before launch; retrofitting consistent tracking parameters across live links is tedious and always incomplete.
Check redirects, canonicals, and indexation
Every URL that changes needs a single permanent redirect to its closest replacement. Chains and loops waste crawl budget and lose the signal. Keep one trailing-slash policy across the site and apply it to redirects as well.
Remove the noindex directive from production, confirm the sitemap lists only canonical URLs, and check that the robots file does not block CSS, JavaScript, or images. Test the custom 404 page and make sure it returns a 404 status rather than a soft error.
Walk the asset and interface checks
Open the site on a slow connection and a small screen, because that is where launch faults appear first. The checks below take under an hour and catch most of the problems that reach customers on day one.
- CSS, JavaScript, fonts, and images return 200 from the production domain.
- No mixed content on HTTPS pages.
- Favicon, touch icon, and social preview image are present and correct.
- Layout holds at 320 and 390 pixels without horizontal scrolling.
- The mobile menu opens, traps focus, closes on Escape, and returns focus.
- The 404 page and the contact page are reachable from the navigation.
Run a fixed cutover sequence
Write the order down and give each step an owner. A workable sequence: deploy the build, run the smoke test on the new host, switch DNS, verify the certificate, submit the sitemap, then watch error logs and form submissions for the first hour.
Keep the previous deployment available until the new one has been stable for a full business day. Record what changed, who verified each check, and the time it passed, so the next launch starts from a known state.
| Area | Check | Pass condition |
|---|---|---|
| Forms | Submit on production | Recipient receives, reply-to works |
| Forms | Simulate a mail failure | Error shown, no false success |
| Analytics | Clean browser load | One tag, correct consent state |
| Redirects | Sample old URLs | Single 301 to the right page |
| Indexation | Robots and sitemap | Production indexable, staging blocked |
| Assets | CSS, JS, and images | All return 200 over HTTPS |
Frequently asked questions
When should tracking be tested?+
On staging before launch and again on production immediately after the switch. Staging proves the implementation; production proves the domain, consent settings, and tag configuration.
Should staging be blocked from search engines?+
Yes. Use authentication or an allowlist as the primary control and a noindex directive as a second layer. Keep the staging sitemap out of Search Console.
How long should the old site stay available?+
Keep the previous deployment and DNS records for at least a week, and longer if the site carries paid traffic. A rollback should be a decision, not a rebuild.
Need help applying this?
Get help with Websites & ecommerce.
Review the service scope or tell us what you are trying to improve. We will reply with a clear next step.
Free KPI definition templateRelated reading
A data quality checklist before starting a BI project
The checks that prevent a dashboard from failing after launch: ownership, definitions, completeness, duplicates, and reconciliation.
When to move from spreadsheets to a database
The signals that a spreadsheet has become a database, and the simplest path to a more reliable system.