How to Launch a Website: A Technical Checklist From Domain to Go-Live
Most advice about making a website is about design and content: picking colours, writing the About page, choosing photos. That part matters, but the problems that hurt new sites most often are technical and invisible. A domain that quietly expires, email that lands in spam, a staging setting that keeps the site out of Google for months.
None of these need deep technical skill to get right. They need to be done once, in the right order, before launch day. This checklist walks through them from the domain to the first weeks after go-live, in plain language. It applies whether you use a website builder, a content management system or a custom-built site.
The checklist at a glance
- Choose how the site will be built and who will maintain it.
- Register the domain with auto-renew, a transfer lock and two-factor sign-in.
- Set up DNS and hosting; keep a record of every setting.
- Serve the site over HTTPS only, on one address (
wwwor not). - If you send email from the domain, set up SPF, DKIM and DMARC.
- Publish the essential pages: contact, privacy policy, and a useful 404 page.
- Write titles and descriptions; add a sitemap and a correct robots.txt.
- Add analytics with consent where the law requires it.
- Check speed and security before launch, then monitor after.
Choose how you will build it
There are three broad routes, and none is right for everyone:
- Website builders (hosted, drag-and-drop services) handle hosting, security updates and HTTPS for you. They are the quickest start and need the least maintenance. The trade-off is less control: you work within the platform’s features, and moving away later can mean rebuilding.
- A content management system (CMS), open source or hosted, gives you more flexibility through themes and plugins, and a large pool of people who can help. Self-hosted, it also makes you responsible for updates, backups and security, either yourself or through someone you pay.
- A custom-built site fits unusual requirements exactly and can be very fast, but every change goes through a developer, and you depend on their availability.
Decide by asking: who will update the site every week, what it needs to do in a year (a shop, bookings, several languages), and who fixes it when something breaks. A simple site that someone maintains beats an ambitious one that nobody updates.
Register the domain properly
The domain is the one part of your site you can’t easily replace. Choose a name that is short, easy to spell after hearing it once, and on an extension your audience trusts. Then set up the registrar account with care:
- Turn on auto-renew and keep a valid payment card on the account. Register for several years if you can.
- Use a contact email that doesn’t depend on the domain itself. If renewal notices go to an address on the same domain and it expires, the warnings stop arriving with it.
- Enable two-factor authentication on the registrar account, and make sure the business, not one employee or agency, owns it.
- Keep the transfer lock on (often called registrar lock), so the domain can’t be moved to another registrar without your action.
Our domain expiry guide covers what to check and what happens if a renewal fails.
DNS and hosting
DNS (the Domain Name System) is the address book that tells browsers and mail servers where your domain lives. You’ll manage a few record types: A and AAAA records point the domain to your server’s address, CNAME points a name to another name, MX says where email goes, and TXT holds text such as verification and email authentication records. Your builder or host will tell you which values to enter.
Write every record down, with the reason it exists. When you change provider later, that list saves hours. Changes can take time to reach everyone; the record’s TTL (time to live) sets how long other servers may keep the old value.
When choosing hosting (if your platform doesn’t include it), compare on things you can check: a server region close to your visitors, current software versions, automatic backups you can restore yourself, included HTTPS certificates, and how quickly support answers. Ask how a restore works before you need one.
HTTPS and one canonical address
Every page should load over HTTPS, the encrypted version of HTTP. Browsers mark plain HTTP pages as not secure, and forms on them can’t be trusted. Most hosts and builders include free certificates (for example from Let’s Encrypt) with automatic renewal. Check that renewal is really automatic: certificates are valid for a limited time, and lifetimes are getting shorter. Our HTTPS guide and the post on TLS certificate hygiene cover the details.
Then decide on one address: https://www.example.com or https://example.com. Both work; what
matters is that one is the main address and the other redirects to it with a permanent (301)
redirect, along with every http:// variant. Otherwise search engines may treat them as duplicate
sites. See www vs non-www for how to choose.
Email that arrives
If you send email from your domain, whether from a mailbox, a contact form or a newsletter tool, mailbox providers check that you are allowed to. Three DNS records prove it:
- SPF lists the services allowed to send mail for your domain.
- DKIM adds a cryptographic signature to each message; your email provider gives you the record.
- DMARC tells receivers what to do with mail that fails those checks, and where to send reports.
Without them, your mail is more likely to land in spam, and anyone can send mail that looks like it
comes from you. Large mailbox providers such as Gmail and Yahoo now require these records from bulk
senders, and they help every sender. Start DMARC in monitoring mode (p=none), read the reports,
then tighten it. If the domain never sends email, publish records that say so, which stops others
from spoofing it. Our email authentication guide shows example records.
Pages and search basics
A few pages are expected on every business site:
- Contact details that people can actually use, and an About page that says who runs the site.
- A privacy policy. If you collect any personal data, even through a contact form or analytics, data protection laws such as the GDPR generally require you to explain what you collect and why. Shops and paid services also need terms and a refund or returns policy.
- A helpful 404 page with links back to the main sections, for mistyped or old links.
For search engines, give each page a unique, descriptive title (roughly 50–60 characters shows in full in most results) and a meta description that summarizes the page. Add a favicon and Open Graph tags so links shared in chats and social media show a proper preview.
Two files tell search engines how to crawl the site. An XML sitemap lists the pages you want
found; most platforms generate one, and you can submit it in Google Search Console. A robots.txt
file says what crawlers may fetch. The most common launch mistake is leaving the staging setting that
blocks everything (Disallow: /, or a “discourage search engines” option, or a noindex tag) in
place after go-live. Check it on launch day. Our XML sitemap guide explains
what a good sitemap contains, and Google’s
SEO starter guide is a
reliable overview of the rest.
Analytics tells you whether the site is working for you. In many places, including the EU and the UK, analytics and advertising cookies need the visitor’s consent before they are set, so add a consent banner that actually blocks those scripts until someone agrees, or choose an analytics setup that doesn’t need consent under your local rules.
Before and after go-live
Before launch, test the finished site the way a visitor would: on a phone, over mobile data, logged out. Click through every form and check that the messages arrive. Then run a speed and security test of the home page and your most important page. A launch is the cheapest moment to fix an oversized hero image, a missing redirect or a missing security header, because nobody depends on the site yet. You can run a free scan to check performance, security and SEO basics in one report.
On launch day, switch DNS, confirm HTTPS and the redirects work on every address variant, confirm search engines aren’t blocked, and submit the sitemap.
After launch, problems arrive quietly: a certificate that doesn’t renew, a domain whose payment card expired, a plugin update that slows the site down. Monitoring catches them before visitors do. A free PerfoMetrix account can watch one site on a weekly schedule and email you about issues such as certificate and domain expiry or a site that stops responding. Whichever tool you use, the post on what deserves an alert helps you set it up without drowning in notifications.
Keep the record you made along the way: registrar, DNS records, hosting, email settings, and who has access to each. The next person to work on the site, possibly you in two years, will need it.