Delivery is the launch, and the proof that it worked. There are two lists: what has to pass, and what puts things back if it does not. Then the DNS change. Then the proof again, on the live domain, before anyone calls it done.
What is the launch proof?
The visitor’s view first. A cookie-cleared browser, as a guest, on a real phone, on the live domain, before anything else is measured. Then Lighthouse on the live domain, median of several runs: performance 90 or above, accessibility 100, best practices 100, SEO 100. Loading, responsiveness and layout stability measured on the phone, not estimated.
Accessibility beyond the score: the six checks a tool cannot see. Every interactive path walked with a keyboard alone, including the skip link. A visible focus outline. No keyboard trap. Focus moving in reading order. Form errors announced. Reduced motion honoured.
Security headers read from the live site’s own response and saved, because a green best-practices score does not assert them. Every form watched delivering to the destination named in discovery, then the test submission deleted so it never becomes a fake lead; the rate limit and the bot control watched refusing a burst and a scripted submission. For a rebuild, every address from the old site checked to arrive at its new home. Structured data, sitemap, robots and the count of outside requests, all on the list. And the live pages measured against the locked kit one last time.
What happens before the DNS change?
A short list Richard owns. The data processing agreement signed. Two-factor authentication on every admin login. Backups in place: server-level every morning, external cloud backups for WordPress sites, and a restore tried once so we know they work. Hosting and the domain in your own accounts, where that is the arrangement.
Then the rollback, written before cutover and rehearsed once. The DNS time-to-live is dropped at least a day ahead so a change takes minutes rather than hours. The revert is dry-run against staging in that window and the result saved. The revert itself is one named command or one DNS change, and Richard runs it. A DNS change is never done alone.
What happens after the switch?
The launch proof runs again, on the live domain. If it fails, the revert runs. Not a hotfix on the live site.
The staging site stays reachable to us for fourteen days, locked behind a password, hidden from search engines, with its forms switched off, so it is never a second public copy of your site. Once the new site has taken its first real enquiry, order or account, the plan says how those records would be carried across if we ever had to go back, because a revert that strands a real customer is not a revert.
Do you check it on a real phone?
Yes. Before delivery is called done, Richard opens the live site on his own handset. A browser window narrowed to phone width is not a phone; it shares none of the real viewport, the real fonts or the real thumbs. If you can do the same and tell us what you see, better still.