The launches that go wrong for us rarely go wrong in the design. They go wrong in a setting: a staging site still hidden from Google, a form still sending to the developer, a redirect that was never added. This list is those settings, in the order we check them.
By Ali Demirci, founder of Woofocus. Updated October 24, 2026.
We have launched client sites on WordPress, Webflow, Framer and Shopify. The platform changes where a setting lives, not the list itself. The lines marked with a platform name are the ones we have seen forgotten on that platform.
Run the first part a few days before launch, when there is still time to chase the client for DNS access. Launch day should be short and boring. The week after is where you catch what only real visitors find.
The template
Website launch checklist
Tick each line. Lines with a platform name apply only to that platform.
The week before
Client sign-off for launch, with the date and time agreedUsually: Producer
Access to the domain's DNS confirmed, or a named person at the client who will make the changeUsually: Producer
Full backup of the current site, if there is oneUsually: Developer
Redirect map: every old address that gets traffic points to its new pageUsually: Developer
Every form tested on staging, and every message arrived at the agreed addressUsually: QA
Privacy policy, cookie notice and consent banner in placeUsually: Client, developer
Favicon, social sharing image and page titles setUsually: Developer
A useful 404 pageUsually: Developer
Analytics property ready, with the client given accessUsually: Developer
WordPress: plugins and theme updated, admin users reviewed, email sending set up through SMTPUsually: Developer
Shopify: a test order placed and refunded, order and shipping emails checkedUsually: Developer
Launch day
Switch the domain (DNS or the platform's domain settings) at the agreed timeUsually: Developer
SSL certificate active, and http and www both go to the one https addressUsually: Developer
Search engines allowed on the live siteUsually: Developer
WordPress: Settings, Reading, Discourage search engines is untickedUsually: Developer
Webflow: the webflow.io staging subdomain is kept out of search resultsUsually: Developer
Shopify: the online store password page is removedUsually: Developer
Framer or Webflow: the site is published to the custom domain, not only to stagingUsually: Developer
robots.txt does not block the site, and the sitemap address opensUsually: Developer
Redirects tested from a few old addressesUsually: QA
Forms tested again on the live domainUsually: QA
Analytics receiving visits from the live domainUsually: Developer
Client told it is live, with what to check and who to callUsually: Producer
The week after
Sitemap submitted in Google Search Console, and the domain verifiedUsually: Developer
Search Console checked for pages that cannot be indexed and for 404sUsually: Developer
Broken link check across the live siteUsually: QA
Page speed checked on mobile on the live domainUsually: Developer
Form messages from real visitors are arrivingUsually: Client
Backups running on the live site, and the first one restored somewhere as a testUsually: Developer
Staging site locked or removed so it cannot be foundUsually: Developer
Notes from the client's first week collected in one list and sortedUsually: Producer
In Proofyard this list works best as a Library checklist on the project's launch or testing phase, with each line given to the person who does it. Turn on the phase rule Checklist must be complete, and the task cannot leave that phase with a line still open.
Going live is one of the things Claude never does on its own. An agent can prepare a site change and show it on the task, but it waits for an admin to press Approve on that exact change. For the week after, the client keeps leaving notes on the live site with the feedback button, and they land on the project's Feedback board with the page and the device.
In our projects: the setting that hides the staging site from search engines left on in the live site, forms still sending to a developer's address, and redirects from the old site. All three are on the launch day list.
Should we launch on a Friday?
We avoid it. If DNS or a form goes wrong, you want the developer and the client both around the next day. Early in the week, in the morning, gives a full working day to fix things.
How long does a DNS change take?
Often minutes, sometimes longer, depending on the record's time to live and the provider. Lowering the TTL a day or two before launch shortens the wait. Keep the old site running until the new one answers everywhere.
Does Google Search Console need setting up for every launch?
If the domain is new to the client, yes: verify it and submit the sitemap. If it was verified for the old site, check the same property still works and submit the new sitemap.