A launch should be boring. If it is exciting, something was left until too late.
A launch should be boring. If it is exciting, something was left until too late.
Content finalised, redirects mapped from every old URL, analytics and search console configured, performance and accessibility checked, and a rollback path agreed. All of it done in advance, not discovered on the day.
Deploy early enough that there is time to react. Verify the redirects, the forms, the tracking and the transactional email. Check on a real phone on a real connection, not just a desktop on office wifi.
Watch the error logs and the search console for coverage problems. Most launch issues surface within days and are trivial to fix if someone is looking.
We do not launch on a Friday, and we do not treat launch as the end of the project. It is the point at which the useful data starts.
The most common launch failure is losing search visibility because old URLs were not mapped to new ones. Every URL that exists today needs a destination tomorrow, including the ones nobody remembers creating.
Export the current URL list from analytics and the search console rather than from the sitemap. The sitemap tells you what you meant to publish; the logs tell you what people actually visit.
Submit the contact form. Complete a purchase with a real card. Check the confirmation email arrives, renders correctly, and comes from an address that will not land in spam.
Transactional email is the single most commonly missed item on launch day, because it is the one thing that lives outside the site you have been staring at for weeks.
Agree in advance what would trigger a rollback and who gets to make that call. Write it down before launch day, when everyone is calm.
It is almost never needed, and having it is enormously calming for everybody involved.
Every URL that has ever earned a link or a ranking must resolve to the closest equivalent, with a permanent redirect. Not to the homepage — a bulk redirect to the homepage is read as a soft error and throws away the value you were trying to keep.
Build the list from server logs and search console rather than from the sitemap of the old site, because the pages that matter include ones nobody remembers exists.
Test the map against the real list before launch, not after. This is the single most common cause of a traffic collapse in the weeks after a redesign, and it is entirely preventable.
Analytics and search console verified on the new property. Transactional email sending and arriving, checked in a real inbox rather than a log. Forms submitting and reaching a human. Payment tested with a live transaction, then refunded.
Staging noindex removed, robots and sitemap correct, canonical tags pointing where they should. Backups taken and restore tested — an untested backup is a hope, not a plan.
Error monitoring switched on before the deploy rather than after, so the first hour is observed rather than reconstructed.
Agree the rollback before you need it: what triggers it, who decides, and how long it takes. A decision made calmly on Tuesday is far better than one made at speed on Thursday.
Keep the old system available but unreachable for a short window rather than deleting it on the day. The cost of a fortnight's extra hosting is trivial against the cost of needing it and not having it.
And deploy in the morning, early in the week. Not because Friday deploys always fail, but because when they do, the people who can fix them have gone home.