Website launch checklist
Last updated
Two lists. The first is what to check before a new site goes live, ordered by what it costs you to miss. The second is the handover — the list that decides, years later, whether you can move to a different developer at all. Copy both. They are more useful in your own document than on ours.
What is on a website launch checklist?
Grouped by consequence rather than by topic, because the usual checklist puts "favicon" next to "redirects" as though they are comparable.
Group 1 — miss these and you lose money
| Check | How to verify it yourself |
|---|---|
| Every old address redirects to its new one | Take ten addresses from the old sitemap and open them. Each should land on the matching new page, not the homepage and not a 404 |
| The contact form actually arrives | Submit it from your phone, then check the inbox and the spam folder ten minutes later |
| The phone number works and is tappable | Tap it on a phone. It should dial, not select text |
| The site is not left on noindex | The staging setting that hides a site from search is the single most common launch mistake. Ask for it in writing, then check yourself |
| Nothing is blocked in robots.txt that should be indexed | Open yourdomain.com/robots.txt and read it. A blanketDisallow: / from staging survives launch more often than anyone admits |
| Prices, hours and addresses are current | Read them. Content copied from a five-year-old site arrives five years out of date |
Redirects are the expensive one and the one most often skipped. Google recommends permanent redirects for a move and says to "keep the redirects for as long as possible, generally at least 1 year", and warns that "a small to medium-sized website can take a few weeks for most pages to move" (Google Search Central). If your current site ranks for anything at all, read redesigning without losing your rankings before launch day rather than after it.
Those last two interact, and the interaction catches people out. Google is explicit: "For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler" — because "if the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results" ( Google Search Central). So a launch that removes the block but leaves the noindex, or the reverse, is still broken. Check both.
Group 2 — miss these and you lose the evidence
- Analytics connected before launch, not after. Data that starts the week after go-live cannot tell you whether the new site is better than the old one, which is the only question anybody will ask in month two.
- Search Console verified, and the new sitemap submitted. It is free, it takes ten minutes, and it is the only place Google tells you what it thinks of your site.
- A record of how the old site performed. Screenshot the traffic for the last twelve months before you switch. Once the old property stops reporting, that comparison is gone.
Group 3 — miss these and you lose time
- A valid certificate, and every page loading over https
- Backups running, and a restore actually tested once
- Uptime monitoring pointed at the homepage
- A 404 page that offers a way back rather than a dead end
- Readable on a phone: text without pinching, buttons hittable with a thumb
The handover list
This is the one that matters in three years, and the one nobody asks for in week one. Ask at launch, while everyone is pleased with each other. Asking during a dispute is how people discover it was never written down.
| What to get | Why it matters |
|---|---|
| Where the domain is registered, and in whose name | If it is not your name on your own account, you do not control your address. Check it rather than take the answer |
| The hosting account and how to log in | Without it a new developer cannot take over, only rebuild |
| Where DNS is managed | Often a fourth company nobody mentions, and the thing that has to change to move anywhere |
| Where email is handled | The classic disaster: moving the site and taking the email down with it |
| A complete copy of the site and its content | Files and text. Ask what format, and ask while they are still being helpful |
| Analytics and Search Console, with you as owner | Not as a guest on somebody else's account |
| Any licences bought on your behalf | Themes, plugins, fonts, stock photographs — and whether they renew |
The domain line is the one to verify personally rather than accept. Who owns your website has the WHOIS check, what each of the four separate things you might not own actually is, and a copy-paste email for a developer who will not hand something over.
What to ask before you hire anybody
These belong at the start, not the end, and the answers should be in writing rather than said on a call.
- Who will the domain be registered to?
- What happens to the site if I stop paying?
- What is included after launch, and what is billed?
- How many revisions before launch, and what counts as one?
- Can I have a complete export of the site whenever I ask?
How to hire a web designer has the longer list and the red flags; freelancer versus agency covers which kind of supplier to be asking.
A brief, if you are the one supplying the content
Most delay on a website project is content waiting on the client. Fill this in once, in a document, and hand it over — it is worth more than any number of meetings.
WEBSITE BRIEF 1. Business name, address, phone, hours - exactly as they appear on your Google Business Profile. Character for character. 2. One sentence for the top of the homepage: "We [service] for [who] in [town]." 3. Your top 3 services. A short paragraph each, in your own words. 4. Service area: the towns you cover, or a radius in miles. 5. 6-10 real photographs of your work, your van, your team. No stock photography. 6. What a visitor should do next: call, text, or a 4-field form (name, phone, town, the job). Never more than 4 fields. 7. Licence and insurance numbers, if your trade has them. 8. The 3 questions customers always ask, and your answers. 9. Anything you must NOT say - claims you are not licensed to make. If a quote does not cover all nine of these, ask what it does cover.
Where this goes for us
Worth saying which of the above we do, so the list is usable as a comparison rather than just advice. Redirects from every old address, the certificate, nightly backups, uptime monitoring and Search Console are part of the build and the monthly plan rather than extras. The handover list is not something to request: your domain is registered in your name from the start, we are only ever a Manager on your Google Business Profile, and a complete export of the site is free the same day you ask it, at any time, including while you are still paying us.
And the brief above is optional with us for one specific reason — if you already have a site, your services, hours, photographs and wording are already published on it, and we take them from there. See how we work for the timeline, or moving your website if the launch you are planning is a move rather than a first build.
Common questions
- What should be on a website launch checklist?
- Four groups, and they are not equally urgent. Things that lose you money if missed: redirects from every old address, a working contact form tested from a phone, and the site being indexable rather than left on noindex. Things that lose you evidence: analytics and Search Console connected before launch, not after. Things that lose you time: certificate, backups, uptime monitoring. And the handover, which is the only group nobody misses until they need it.
- What is a website handover document?
- The list of everything you would need to move to a different developer tomorrow: where the domain is registered and in whose name, where the site is hosted and the login, where the DNS is managed, where the email is, a copy of the site's files and content, and the accounts for analytics and Search Console. Ask for it at launch, while goodwill is high. Asking for it during a dispute is how people discover it does not exist.
- What should I ask before hiring someone to build a website?
- Five questions, and the answers should be in writing rather than on a call. Who will the domain be registered to? What happens to the site if I stop paying? What is included after launch and what is charged? How many revisions before launch, and what counts as one? And can I have a full export of the site whenever I ask? The fifth is the one that reveals the arrangement.