Website Launch Checklist: The Order to Go Live In

A website launch checklist is the short list of checks you run, in a set order, when your site goes public. For an AI-built site, that order is: back up, write a rollback plan, connect your domain, confirm HTTPS, test email, remove any search block, check the live site as a visitor, then announce. Done in that order, each step has the earlier ones to lean on.

Your builder's preview never tested what your own domain adds: DNS, a security certificate, email that must prove where it came from, and search settings. This guide covers those parts and their order. For the app itself, use The Vibe Coding Checklist: Before You Share or Launch.

What order should launch day follow?

Each step depends on the one before it.

The day before

1. Back up your code, your saved records, and your current DNS records.
2. Write your rollback plan.

Launch day

1. Publish the site, then connect your domain early in the day, not at 5 p.m.
2. Wait until your builder says the domain is live, then open the address with and without "www" in a private window.
3. Check HTTPS on the pages a visitor will use.
4. Send test emails through your real forms.
5. Remove any search block you no longer want, and confirm your analytics sees your own visit (what to measure is in Beyond the MVP).
6. Click your main path on a real phone.
7. Optional: run a public review of the live address and read its evidence block (more in the last section).
8. Announce only after steps 4 to 9 pass.
9. For the first 24 hours, check your inbox, spam folder, and analytics a few times, and fix what blocks a visitor before anything cosmetic.

How do you connect your domain without breaking it?

DNS (the domain name system) is the address book that tells browsers where your name, like yourname.com, lives. You edit it by adding records at your registrar (where you bought the name) or your DNS host.

Your builder tells you which records to add, and rules differ by tool. Lovable's documentation, as one example, says you can set up a domain at any time, but you need to publish your project before the domain can start serving your site. For a domain bought elsewhere, it asks you to add an A record and a verification TXT record, and it says DNS changes may take up to 72 hours to propagate, though most updates are live within a few hours (page undated, read 5 October 2026; Lovable custom domain docs). Other builders have their own docs, so follow your tool's.

Leftover records can get in the way. The same Lovable page asks you to check that the domain has no AAAA record, because one can interfere with setup and route traffic to the wrong place, and that any CAA records you have allow Lovable to issue certificates. In any tool, copy records exactly as shown, leave your email records alone, send "www" and the bare address to one main address, and keep a note of the old records.

Is HTTPS really working on every page?

HTTPS is the secure version of a web address. It encrypts the connection between a visitor and your site, and it depends on a certificate that your hosting issues. Lovable's docs say it generates and installs one automatically when you connect a custom domain. For domains connected from another provider, its status list says the browser shows a security warning instead of your site until the certificate is ready, and its FAQ says to contact support if the certificate has not been issued after 72 hours.

So on Lovable, a warning while the domain is still setting up is expected: wait for the status to say Live. A warning after 72 hours is a support ticket. Other builders may behave differently.

In a private window, check 3 things:

• Typing http:// at the front sends you to https://.
• The padlock shows on your home, pricing, sign-up, and contact pages.
• No page loads an image or script over plain http. This is mixed content: a secure page pulling in insecure files. Your browser's developer tools console usually logs these as you click through.

A padlock means an encrypted connection, nothing more.

Will your emails actually reach people?

Your site may send contact notices or receipts. Mailbox providers check that a message came from your domain, using 3 records. SPF lists who may send for it, DKIM is a signature showing the message was not changed, and DMARC tells receivers what to do when those checks fail.

Google's sender guidelines say that since 1 February 2024 every sender to Gmail accounts must set up SPF or DKIM, and that senders of more than 5,000 messages a day to Gmail accounts must set up SPF, DKIM, and DMARC. The same page says the DMARC policy can be set to "none" (page undated, read 5 October 2026; Google's email sender guidelines). A new site sends far fewer, so the bigger-sender rule is not yet yours, but setting up all 3 now beats untangling spam complaints later.

Then test it for real: submit your live forms with a Gmail address and a second address, check the inbox and the spam folder, confirm the "from" address uses your own domain, and reply to make sure the reply lands where you read it.

A public review can add one data point. When the audit submits a form once with test details it labels as such, the report has a Confirmation email field under Recorded submissions, so you can see whether a confirmation email arrived after that submission. 2 cautions. The labeled test entry may land in your inbox or your sign-up list, so clear it out before you count real sign-ups. And one email arriving at one address says nothing about SPF, DKIM, DMARC, or where mail lands at Gmail, so the checks above stay yours.

Can search engines see your site, or did you block them by mistake?

Sites are often set to "noindex" (a request that Google leave a page out of its results) while they are private, and robots.txt is a file that tells crawlers where they may go. Google's documentation says the URL Inspection tool in Search Console shows the HTML Googlebot received, so you can confirm what is really live (updated 10 December 2025, read 5 October 2026; Google Search Central on blocking indexing).

Check that pages are not marked noindex and that robots.txt is not shutting out the whole site, then set up Search Console. Google's starter guide says there is no guarantee any site will be indexed and that you should wait a few weeks before judging changes (updated 10 December 2025, read 5 October 2026; Google SEO Starter Guide). Nothing here promises a ranking.

What should you back up before you go live?

Before launch, hold:

• Your code, copied outside your builder (your tool's docs say how).
• Any records the app stores, such as bookings, exported.
• Your current DNS records, written down or screenshotted.
• Your registrar, hosting, email, and analytics logins, in a password manager.

Could you rebuild the site from these copies? A backup you have never tried to use is a hope, not a plan.

What does a rollback plan look like?

A rollback means going back to the last version that worked. A plan answers 4 questions in advance: what makes you roll back, what you put back, who does it, and by when.

Hypothetical example: A potter plans a Saturday launch for a site where people book 6-week pottery classes. The night before, they write this down.

DNS changes spread slowly in both directions, so a DNS rollback is the slowest one. And a booking that arrived an hour ago may not survive restored code, so export new records first. For rollback checkpoints inside the app, see check 10 of the vibe coding checklist.

What will a visitor see in the first minute?

Visitors never see your DNS records. They see whether the page loads, whether they can reach you, and whether the main button works on a phone. Last-minute banners and pop-ups can cover that button.

2 of our six dimensions look at that moment. Trust and Legitimacy asks whether a visitor can tell a real business stands behind the page. Mobile and Access asks how the page holds up on a phone. That is why the phone click in step 8 comes before you announce.

Which launch checks can a public review confirm?

Some, not all. After launch, the report's Recorded evidence block lists what the audit did on your live address: pages crawled, links checked, broken links, buttons clicked, and dead buttons. It also lists anything it did not fully click in the time allowed, and a Not confirmed list for anything it could not verify. For launch day, that can show whether the pages a visitor reaches loaded, whether links on them led anywhere, and whether the buttons it pressed responded. It cannot tell you why something failed.

Public pages only: anything behind a login is outside the review, and it does not stand in for a security review or a full accessibility audit. A clean evidence block is not a launch sign-off. Run it once the real address is live, after step 8, then use it to decide what to fix before you announce.