Website Launch Checklist: 30 Checks Before You Go Live

Before you launch a website, test every form, booking and payment end to end, confirm that integration keys such as Stripe and email are filled in, and check the custom domain, HTTPS and redirects. Review titles, descriptions and social cards, test on a phone, publish your privacy pages and make sure your plan keeps the site live.

• Test the failure path as carefully as the happy path: declined cards, double bookings and oversized uploads are where launches break.
• On WisyLink, payments, email, social login and site passwords do nothing until their keys are saved under Integrations. Every row should say Ready.
• Move the site to its final domain before you set webhook and login redirect URLs at your providers, or update them after the move.
• After launch, each change goes live as soon as its build finishes, so rerun the money and contact checks after every edit.
• Free links expire after 30 days plus a marked week. A site you announce belongs on a paid plan.

How to use this checklist

Run it on the final build, on the address you'll announce, with real devices. Launch-day failures are rarely in the obvious path. They are a payment key still in test mode, a contact form whose emails land in spam, or a QR code printed with an address that changed a day later. The 30 checks are grouped in the order you'd naturally fix things: content, then the flows that take money and data, then the plumbing, then search and sharing.

What should you test before launching a website, if time is short? Anything that takes money, anything that collects a customer's details, the domain, and the site on a phone, in that order. Everything else can be fixed the week after.

The owner column says who does the work. "You" means you, clicking. "Wisy" means asking for the fix in the site's chat. "Provider" and "DNS" mean the dashboard of your payment or email provider, or wherever your domain's DNS lives. Print the table and initial each row.

Content and copy

AI writes fluent copy, and fluent copy hides invented details. WisyLink's terms put reviewing AI output on you, and the essay on why generated software needs a human last mile explains why this step never goes away.

1. No placeholder or invented content. Read every page, slowly. Look for sample testimonials, team bios you didn't write, "founded in" years, statistics and awards. If you didn't supply it, delete it or replace it with the real thing.
2. Business facts are correct. Prices, opening hours, address, phone, delivery areas and license numbers. These are the details customers act on, and they must match your Google Business Profile.
3. Every link and button works. Navigation, footer, calls to action, social icons, tap-to-call and email links. Click them all on a computer and tap them all on a phone.
4. Images are yours or licensed, with alt text. Stock placeholders are fine for a draft, not for launch. Ask for alt text that says what each image shows ("before and after: tiled shower") rather than "image1".
5. Not-found page and empty states. Type a made-up address on your domain; you should see a helpful page in your site's style. Open any list that has no records yet, such as an empty blog or gallery, and make sure it says something sensible.

Forms, bookings and payments: happy and failure paths

6. Forms work: happy path. Submit each form with realistic data. You should see a confirmation, find the record in the admin area and, if you set up email, receive the notification.
7. Forms fail gracefully. Leave required fields empty, type a broken email address, upload a file over 25 MB or of the wrong type. Each should produce a clear message, never a blank page or a silent nothing.
8. Bookings can't collide. Open the booking page on two devices and book the same last slot at the same moment. One must succeed and the other must be refused. Then cancel a booking and confirm the slot frees up, and check that times show in your business's time zone. The guide to building a booking website with AI covers the setup.
9. Payments work in test mode. How do you test payments without charging real cards? Put your provider's test keys under Integrations first. With Stripe, use the test card 4242 4242 4242 4242 with any future expiry date and any three-digit CVC, as listed in Stripe's testing docs. Check that the order turns paid only after the provider's webhook arrives, and that stock or seats drop exactly once.
10. Payment failures are handled. Pay with Stripe's generic decline card (4000 0000 0000 0002), close the tab on the checkout page, and press back after paying. Then open the success page's address directly without paying: a well-built store never marks an order paid from that page alone. Store-specific checks are in the guide to building an online store with AI.
11. Accounts and admin are protected. Sign up, log out, log in, reset a password (that needs email set up). Then open the admin address in a private window while logged out, and again as an ordinary customer; both should be turned away.

Integrations: are your Stripe and email keys filled in?

A WisyLink site that takes payments, sends email, offers social login or hides behind a password reads those credentials from Integrations. The build sets the fields up, but until you fill them in, the feature stays inert. That matters most for a site password, because an empty one leaves the site open to everyone.

12. Every integration shows Ready. Open Integrations from the site's chat, on the web or in the mobile app. Each row should read Ready; any row showing keys needed is a feature that doesn't work yet. Paste keys there, never into the chat.
13. Email reaches inboxes. Email goes through your own email (SMTP) account. Send test messages to two different providers, such as a Gmail and an Outlook address, and check spam folders. Use a sender address on your own domain, and set up the sender authentication records your email provider documents, typically SPF and DKIM.
14. Live keys and live webhook in place. Once the tests pass, replace the test keys with live ones. Stripe's go-live checklist notes that test and live webhook endpoints are separate, so register the live endpoint too, and that products and prices created in test mode don't exist in live mode. Then make one small real purchase and refund it.
15. Callback URLs use the final domain. Webhook endpoints and login redirect URLs (for Google or GitHub sign-in) are set in each provider's dashboard and point at a specific address. The setup instructions in Integrations always show the site's current domain, so re-read them after you move to your own domain and update the provider side to match.

Domain, HTTPS and redirects

16. Domain verified and serving the site. In Domains, the domain should show Verified and name this site. You can connect your own domain on any plan, and assigning it moves the site off its wisylink.com address. The full process is in how to connect a custom domain.
17. HTTPS on bare and www addresses. Load yourdomain.com and www.yourdomain.com. Both should show the padlock. WisyLink issues certificates automatically and redirects www to the bare domain once the www name also points to the site; if www fails, give it the same target as the bare domain.
18. Old URLs redirect. Replacing an older site? List its most visited pages and ask Wisy for permanent redirects to their new equivalents, so bookmarks and search results don't hit a dead end. If you moved your nameservers to WisyLink, recreate your email (MX) and TXT records first, because delegation replaces every existing record.
19. No stray DNS records. Many registrars add parking-page A or AAAA records. For the hostname your site uses, keep only the records Domains asks for. Verification keeps checking for up to 6 hours; if it fails, look for a leftover record first.

SEO and social sharing

20. Titles and descriptions reviewed. WisyLink sites ship a unique title and description for each page. Read them as a searcher would: does each say what the page offers and where? Ask for rewrites in the chat.
21. Sitemap and robots.txt correct. Open /sitemap.xml and /robots.txt on the final domain. The sitemap should list every page, including record pages such as products or posts, and robots.txt must not block them. Because the site builds its URLs from the address it is served on, check this after the domain move. More in SEO for AI-built websites.
22. Social card previews well. Paste the link into a messaging app and look at the preview: image, title, description. Every site gets a share image on its first build; if you renamed or restyled the business since, ask for the share image to be redone.
23. Search Console set up. Verify your domain in Google Search Console and submit the sitemap. Google's guide to asking Google to recrawl is candid that crawling can take from a few days to a few weeks and inclusion isn't guaranteed, so do this a little before launch day, not on it.

Mobile, speed and accessibility

24. Works on real phones. An iPhone with Safari and an Android phone with Chrome, in portrait and landscape. Fill in a form with the on-screen keyboard open, check that nothing scrolls sideways and that buttons are easy to hit with a thumb.
25. Fast on mobile data. Load the home page and your main conversion page on cellular, not office Wi-Fi. If a page drags, a common cause is a large photo you uploaded; resize and compress it, then ask Wisy to swap it in.
26. Passes accessibility easy checks. Tab through each page with a keyboard and watch the focus outline, zoom to 200%, and check text contrast and form labels. The W3C's Easy Checks walk you through page titles, alt text, headings, contrast, keyboard focus, zoom and form labels without special tools.

Legal and privacy

27. Privacy policy matches reality. It should name what each form collects, which providers process it (payment, email, analytics) and how long you keep it. If you added analytics, many countries require consent before non-essential cookies load.
28. Terms and business details published. Stores and memberships need refund, cancellation and delivery terms, and some countries require company details on the site. The small business website checklist lists the common ones.

After launch: monitoring, plan capacity, link lifetime

29. Monitoring in place. WisyLink has no built-in visitor analytics dashboard, so connect the analytics tool you prefer through Integrations, behind consent where required. Add an external uptime monitor for the home page. Watch the Resources panel: storage, database and bandwidth count against your plan, and accounts that stay over capacity risk having links suspended.
30. Plan keeps the site live. Community links stay live for 30 days, then one more week marked for deletion, with email warnings before they go. Paid plans keep links live while you're subscribed; a custom domain works on any plan.

What if something breaks after launch? Describe the symptom in the same chat, with the steps that reproduce it, and ask for the fix. A failed build never replaces the live version, but a successful one goes live as soon as it finishes and there is no one-click rollback, so after every change rerun checks 6 and 12 and make one small real purchase that you refund. For a large redesign, try it on a separate link first.

Haven't built it yet? Start free on Community, describe your site in one message and run this checklist on the live link. When it passes, compare plans to keep it live on your own domain. The product page explains how WisyLink isolates each site and deploys builds all-or-nothing.