What Contractors Should Get at Website Launch: The Handoff Checklist

Launch day is a handoff, so treat it like a punch list

You already run punch lists. A job is not done because the paint is dry; it is done when the walk-through is signed and the homeowner has the warranty paperwork in hand. A website launch is the same. The site going live is the paint being dry. The handoff is the walk-through, and most contractors skip it because nobody told them there was one.

Here is why it matters. A website is an asset you should own outright, like a truck with a clean title. Too many contractors find out a year later that the domain is registered to the web guy's personal account, the site lives on a platform they cannot export, and the person who built it stopped answering the phone. The site works until it doesn't, and then they are locked out of their own front door with no way in.

Do the handoff at launch and none of that can happen. The punch list below is what a straight builder hands over and what you should demand if it is not offered. Print it, walk it item by item, and do not consider the job closed until every line is checked. Fifteen minutes of asking on launch day saves you a lawyer's afternoon two years from now.

One note on our own stance, because it shapes the whole list. We build hand-coded static sites, no WordPress, no page-builder platform. That is not a sales line here; it changes what handoff even means. There is no CMS login to hand you because there is no CMS, and the whole site is a folder of files you can hold. A platform-built site has a different handoff, and we will flag where those differ so you know what to ask either way.

First, the ownership: domain, hosting, and the actual files

This is the part contractors get burned on, so it goes first. Three things must be in your name and under your control on launch day, no exceptions.

The domain. The web address itself (yourcompany.com) should be registered in an account you own, with your email and your credit card, at a registrar you can log into. Not the builder's account with a promise to transfer it later. If it is in someone else's name, you do not own your own address, and that is the single most expensive mistake in this business. Ask to see the registrar login. Log in yourself before you sign off.

The hosting. The place the site actually lives should also be an account you can reach. On our builds that is a Cloudflare account, and you get access to it. On a platform, it is whatever dashboard the platform gives you. Either way, if the only person who can reach the hosting is the person who built it, you have a problem the day they disappear.

The files. Ask for a copy of the actual site, the folder of HTML, CSS, and images that is your website. On a hand-coded static site, this is trivial: it is a folder, and you should get it, so any competent developer on earth could pick it up. On a locked platform, you often cannot get a usable export at all, which is the trap of renting. Get the files, put them in a drive you control, and you can never be held hostage.

The logins list: what keys should be on your ring

A clean handoff comes with a written list of every account tied to your site and who holds the login. Not a verbal "don't worry, I've got it." A document, so that if you change developers, or the one you have gets hit by a bus, nothing about your own website is a mystery.

At minimum, get logins or confirmed access for each of these. Keep them in a password manager, not a sticky note on the monitor.

• Domain registrar (where the address is registered).
• Hosting or platform (where the site lives).
• DNS control (often the same as the registrar or hosting; this is what points your address at your site and your email).
• Any analytics account tied to the site, so the traffic data is yours.
• Domain email, if your address routes email ([email protected]).
• The form service that receives your contact-form leads, so you can change the destination inbox yourself.

Notice what is not on this list for a hand-coded static site: a CMS or website-editor login, because there is no CMS to log into. That is a feature, not a gap. There is nothing to hack, nothing to update every week, nothing to break in a plugin update at 2 a.m. When you want copy changed, your developer edits the file and redeploys. On a platform-built site you would instead get an editor login, and you should confirm on launch day that it actually works and you can make a small change without breaking the page.

The test is simple. On the day after launch, sit down and log into every account on the list yourself. If any one of them stops you, that key is not on your ring yet, and launch is not done.

Then, the things that must actually work, not just look right

A site can look finished and still be dead where it counts. The handoff is where you prove the working parts work, before a real customer finds the broken one for you. Do not take anyone's word. Test each of these yourself, from your own phone, on launch day.

The phone links. Every place your number appears, tap it on a phone and confirm it dials your actual number, not a typo, not an old line. Do the same for tap-to-text. Your number should match your Google listing exactly, digit for digit, because a mismatch there quietly hurts you in ways beyond this page's lane.

The contact form. This is the one that fails silently and costs the most. Fill it out as a stranger would, from your phone, and confirm the lead lands in the inbox you actually check. Then check that the auto-reply, if there is one, fires. A form wired to a bounced email has been eating leads on more contractor sites than anyone wants to admit. Test it, and test it again in a month.

Every page and link. Click through the whole site. No page should 404. No link should go nowhere. The service pages and the town pages should each load, on a phone, under 2 seconds. The footer year should say the current year.

The mobile view. Most of your callers are on a phone. Hand your phone to someone who has never seen the site and watch them try to call you from it. Every place they stumble is a lead you would lose. This five-minute test at handoff catches more than any spec sheet.

Get a written confirmation from your builder that forms, phone links, and analytics were tested and are firing on launch. If they cannot say yes in writing, they did not check.

Redirects and the old site: do not let your traffic die on launch day

If you had a website before, launch day has a hidden trap that eats jobs for months: broken links from your old pages. Say your old site had a page at yourcompany.com/services/roof-repair, and people had it bookmarked, other sites linked to it, and Google sent searchers to it. If the new site does not have that exact address anymore, every one of those people hits a dead page instead of your new site. The traffic you spent years earning evaporates on the day you launch.

The fix is redirects. A redirect is a forwarding order: it tells the browser and the search engine that the old address now lives at the new address, and sends the visitor straight there. A proper launch maps every meaningful old page to its new home with a permanent (301) redirect. This is invisible plumbing, and it is the single most-skipped step in a rushed launch.

Ask your builder point-blank: was a redirect map built from the old URLs to the new ones? If the answer is a blank look, that is a red flag. A contractor who has been online a few years can lose a real chunk of their found traffic to this, and the worst part is you never see the calls you did not get. Nothing errors on your screen. The visitor just lands nowhere and leaves.

Two more old-site items for the punch list. First, keep a full backup of the old site before you flip the switch, files and all, in case you need to reference the old copy or something got missed. Second, do not cancel the old hosting the same afternoon. Let it sit for a few weeks until you have confirmed the new site is live, indexed, and the redirects are catching traffic. Cheap insurance against a launch that went sideways.

Built to be found: the structure you should get, not the campaign

A handoff is also where you confirm the site was built with the right bones, the structure that lets it be found and quoted later. This is a build decision, made once, at construction. It is not the ongoing campaign to rank, and we will keep those lanes straight because they matter to what you pay for and who does the work.

What you should get in the box at launch: a real page for each service you sell, a real page for each town you work, clean trade-noun copy that says plainly what you do and where, page titles and meta descriptions written for each page, and the technical files a search engine expects (a sitemap, a robots file). You should also get pages structured so the newer answer engines can read them: when a homeowner asks ChatGPT, Perplexity, or Google's AI answer "who does emergency AC repair near me," those tools read clean, concrete pages and decide whom to quote. A site written in vague "full-service solutions" language gives them nothing to pull. Building the site so it is readable that way is a launch item and lives here.

Now the boundary, stated plainly so you are not oversold. Building the pages is the asset, and it is what this handoff covers. Making those pages climb the rankings over months, earning links and grinding organic growth, is ongoing SEO work and belongs to a different program. Owning the map pack, your Google Business Profile, citations, and reviews is local SEO, also separate. Running an AI-answer visibility campaign as a monthly effort is its own program too. The site being structured to support all three is a build decision you get at launch. The recurring work that happens after is not something a launch checklist can hand you, and any builder who says one launch buys you rankings is selling you a story.

The paperwork: warranty, support terms, and one page that says who owns what

Last on the list and the one contractors skip most: the paperwork. You give homeowners a warranty and a scope of work. Ask for the same on your website, in writing, so there are no surprises the first time something needs a change.

Three documents close out a clean handoff. First, a plain statement of what you own, the domain, the files, the accounts, spelled out so there is never a question later about whose website this is. Second, the support terms: what happens when you need a copy change, a new service page, or a fix. Is there a rate? A turnaround? A number to call? A site with no support plan is a site that slowly goes stale the day the builder moves on. Third, any warranty on the build itself, what is covered if something breaks that was not your doing, and for how long.

Get the small operational things in writing too. Who renews the domain each year so it never lapses (a lapsed domain can take your site and email down overnight). Where the analytics live and who can pull a traffic report. How to reach a human when the form stops sending. None of this is glamorous. All of it is the difference between owning a working asset and holding a link you are afraid to touch.

Here is the honest close. A good handoff is not a sign that a builder is being difficult; it is the sign of one who expects you to still be their client in five years and has nothing to hide. If a launch comes with none of this, no logins list, no files, no redirect map, no support terms, that is your warning. The site may look done. The handoff tells you whether you actually own it.