guides July 13, 2026 11 min read

The Website Launch Checklist Every Freelancer Needs (2026)

Launching a client website without a checklist is how you end up fixing a broken contact form at 11 pm while the client refreshes the page every four minutes. A good website launch checklist covers four phases: final client sign-off, technical pre-launch checks, the launch itself, and the first 48 hours after go-live. This article gives you the complete checklist, plus the reasoning behind the items freelancers skip most often.

Why launch day goes wrong for freelancers

Here is the uncomfortable truth: most launch disasters have nothing to do with your code. They happen because the launch was treated as a technical event when it is actually a communication event.

You know the scenario. The site is done. The client said "looks great!" on a call three weeks ago. You point the DNS, post it in the group chat, and lean back. Twenty minutes later the messages start:

The client's business partner, who has never seen the site before, wants the hero image changed. The contact form sends enquiries to an inbox nobody checks. Someone on an iPhone SE says the menu is broken. The old site's most-visited page now returns a 404, and the client found out because a customer called them about it.

None of these are hard problems. All of them are miserable to solve in public, on launch day, while your client watches their new site misbehave in front of their customers. And because you are a freelancer, there is no QA team, no project manager, and no second developer to share the pain. It is just you.

A launch checklist does not make you a better developer. It moves every one of these conversations and checks to a point in time when they are cheap: before the DNS change, not after.

The complete website launch checklist

Work through this top to bottom. The order matters: sign-off before technical checks, technical checks before DNS, DNS before announcements.

Phase 1: Client sign-off (1 to 2 weeks before launch)

Share the staging site with every stakeholder, not just your contact person. If the business partner, spouse, or investor is going to have opinions, you want them now.
Collect final feedback in one structured round. Give reviewers a deadline and a single place to comment. Scattered WhatsApp voice notes and screenshot emails are how revisions drag on for weeks.
Get written sign-off on the final version. A simple email reply saying "approved for launch" is enough. Verbal approval on a call is not, because memories differ when something goes wrong later.
Confirm all content is final. Placeholder text, missing legal pages, and "we'll send the team photos later" are launch blockers, not post-launch tasks.
Agree on a launch date and time in writing. Midweek mornings are ideal: you are awake, support from your hosting provider is available, and you have days, not a weekend, to fix issues.

Phase 2: Technical pre-launch (2 to 3 days before launch)

Test every form. Submit each one and confirm the notification actually arrives in the inbox the client will monitor. Wrong recipient addresses are the single most common post-launch bug.
Click every link and button. Yes, all of them. Broken internal links are embarrassing; broken checkout or booking links cost the client money.
Check the site on real devices: at minimum one iPhone, one Android phone, and one laptop. Browser dev tools miss things like iOS Safari viewport quirks and tap target issues.
Set up 301 redirects for every important URL from the old site. Pull the old site's indexed pages from Google (site:clientdomain.com) and map anything with traffic or backlinks to its new home.
Verify SEO basics: unique title tags and meta descriptions on key pages, one H1 per page, image alt texts, and a correct canonical setup.
Remove the noindex flag from the staging environment settings and confirm robots.txt will not block crawlers on the live domain. Forgetting this is a classic. The site launches, and two months later the client asks why they are invisible on Google.
Create an XML sitemap and have it ready to submit.
Test page speed on the staging environment and fix the worst offenders, usually oversized images. Launch day is too late to discover a 9-second load time on mobile.
Confirm the SSL certificate will be active on the live domain from minute one. A "not secure" warning is the worst possible first impression.
Set up the 404 page. It should look designed and link back to the homepage.
Check legal pages: privacy policy, imprint or legal notice where required, cookie consent if the site sets non-essential cookies. This varies by country, so confirm what applies to your client's market.
Make a full backup of the old site, files and database, before you touch anything. If the launch goes sideways, this is your undo button.

Phase 3: Launch day

Lower the DNS TTL a day in advance if you can, so the switch propagates quickly.
Point the DNS and confirm the new site resolves on the live domain.
Repeat the critical checks on the live domain: forms, SSL, redirects, one pass on mobile. Staging and production are never quite identical.
Install analytics and confirm data is coming in. Also submit the sitemap in Google Search Console and verify the domain property.
Tell the client the site is live, and tell them what to expect: DNS propagation can take a few hours, so some visitors may briefly see the old site. This one sentence prevents a dozen panicked messages.

Phase 4: The first 48 hours

Monitor form submissions and analytics for anything unusual, like a sudden spike in 404s.
Check Google Search Console for crawl errors after the first day.
Do a final feedback round with the client on the live site. Small issues always surface after launch. Collect them in one place instead of an endless message thread, fix them in one batch, and close the project formally.
Hand over credentials, documentation, and, if you offer one, your maintenance package. The end of a launch is the best moment to sell ongoing care, because the client has just watched how much can go wrong.

Sign-off is the step that saves you, so do it properly

Almost every horror story in the problem section above traces back to skipped or sloppy sign-off. So it deserves a closer look.

Sign-off fails in two ways. The first is incomplete reviewers: your contact person approves the site, but the actual decision-maker sees it for the first time when it is live. You cannot always force every stakeholder to review, but you can put it in writing: "I'll treat your approval as final for everyone on your side." That sentence alone changes behavior. Suddenly your contact forwards the staging link to their boss.

The second failure is vague feedback on the final round. "Looks good, just a few small things" followed by a voice message naming none of them specifically. When feedback arrives as prose, you spend more time decoding it than implementing it. The fix is to make feedback spatial: reviewers should be able to point at the exact element they mean. This is exactly the problem visual feedback tools solve. With a tool like dotts, you share one link to the staging site, and the client clicks directly on the element they want changed and leaves a pinned comment there. No login, no screenshots, no "the thing under the other thing on the second page". You get a clean, complete list of final changes, and when that list is empty, that is your sign-off signal.

Redirects and the noindex flag: the two SEO launch killers

If a relaunch tanks a client's Google rankings, it is almost always one of two mistakes, and both are on the checklist above.

Mistake one: no redirect map. When the URL structure changes and old URLs die without 301 redirects, Google treats the old pages as gone and the new pages as strangers. Rankings built over years evaporate in weeks. The fix costs an hour: list the old site's URLs, keep the ones with traffic or backlinks, and redirect each one to the closest matching new page. Not everything needs a redirect, but the money pages absolutely do.

Mistake two: launching with noindex still on. Staging environments are (correctly) set to noindex so Google does not index the half-finished site. The problem is that this setting travels silently into production, especially with one-click deploys and copied environment configs. The site looks perfect, works perfectly, and is completely invisible to search engines. Check it on the live domain, in the page source, within the first hour after launch. It takes thirty seconds.

Launch communication: manage the client, not just the server

The technical part of a launch is largely predictable. The client's emotional state is not, unless you manage it.

Clients experience launch day with a mix of excitement and anxiety. It is their business on the line, and they do not know what DNS propagation is. If you go silent for three hours while "waiting for DNS", they fill the silence with worry, and worried clients send many messages.

The playbook is simple. Before launch, send one short message: what will happen, when, and what they might notice (old site flickering back, email working as normal, and so on). At launch, confirm it is live and that you are monitoring. After your live checks, send a short "all checks passed" summary. Three messages, maybe ten minutes of effort, and the client experiences you as calm and in control, which is precisely the impression that gets you the next project and the referral.

Real-world example: Marta's second launch

Marta is a freelance web designer from Rotterdam. Her first solo launch, a site for a physiotherapy practice, went the way first launches go. The practice owner approved the site, but his co-owner saw it live and demanded a different color scheme. The booking form pointed to the practice's old info@ address, which nobody had opened since 2023. And the old "prices" page, their most-visited URL, 404ed for two weeks before anyone noticed. Marta spent the launch week doing damage control for free and the client, though polite, never referred her.

For her next project, a site for a small architecture firm, she used a checklist. Both partners reviewed the staging link through a shared dotts link and left their comments directly on the pages; the color debate happened there, ten days before launch, where it was cheap. She tested the contact form against the inbox the office manager actually uses. She mapped the firm's twelve most-visited old URLs to redirects. Launch day consisted of a DNS change at 9 am, a checklist pass on the live domain, and three short messages to the client. The whole thing took ninety minutes, and the firm sent her a referral within a month.

Same designer, similar projects. The difference was not skill. It was sequence.

Bottom line

A website launch checklist is not bureaucracy; it is the cheapest insurance a freelancer can buy. Get written sign-off from all stakeholders before touching DNS, test forms and redirects like the project depends on it (it does), and over-communicate on launch day. If you only adopt three items, make them these: structured final feedback with sign-off, a redirect map, and a noindex check on the live domain.

Frequently asked questions

What should be on a website launch checklist?

Four phases: client sign-off (structured final feedback, written approval, final content), technical pre-launch (forms, links, mobile testing, 301 redirects, SEO basics, SSL, backups), launch day (DNS switch, live-domain re-checks, analytics, sitemap submission), and the first 48 hours (monitoring, Search Console, a final feedback round, handover). The full 26-point website launch checklist above covers each phase in order.

How long before launch should the client sign off?

One to two weeks before the launch date. That leaves room for the final change round without pushing the date, and it protects the launch week for testing instead of last-minute design debates. Get the approval in writing, even if it is just a one-line email.

What is the most common mistake freelancers make when launching a website?

Untested forms are the most common bug, but the most damaging mistake is skipping 301 redirects on a relaunch. Broken forms lose a few enquiries until someone notices; missing redirects can wipe out years of accumulated Google rankings, and recovery takes months.

Should I launch a website on a Friday?

No. Launch midweek, ideally Tuesday or Wednesday morning. If something breaks, you have normal working days and responsive hosting support ahead of you instead of a weekend. A Friday launch means either working the weekend or letting a broken site sit until Monday.

How do I collect final feedback before a website launch?

Give all stakeholders one shared link to the staging site, one deadline, and one place to comment. A visual feedback tool like dotts lets clients click directly on the element they mean and leave a pinned comment, without creating an account. That turns the final round into a clean checklist instead of a scattered thread of emails and voice messages.

How do I stop a new website from disappearing from Google after launch?

Two checks: first, map 301 redirects from every old URL with traffic or backlinks to its new equivalent. Second, confirm the live site does not carry a noindex tag left over from staging and that robots.txt allows crawling. Then submit the XML sitemap in Google Search Console and watch the coverage report for the first week.

What should I check immediately after the DNS switch?

Re-run your critical checks on the live domain: SSL certificate active, forms delivering to the right inbox, redirects resolving, one pass on a real phone, analytics receiving data. Staging and production environments are never perfectly identical, so a green staging checklist does not guarantee a green live site.

What do I hand over to the client after launch?

Credentials for CMS, hosting, and domain (or confirmation of where they live), a short documentation of how to edit common content, backup and update responsibilities, and a maintenance offer if you provide one. A clean handover formally closes the project, which is what allows you to bill the final invoice without awkwardness.

Launch your next site without the 11 pm panic. [Try dotts free →](https://dotts.se)

Start Collecting Feedback in Seconds with dotts

Forget messy email threads and unclear revision requests. dotts makes feedback fast, clear, and organized so you can focus on what matters—getting work done.

Try it for Free