Article Getting Started

The website launch checklist

Everything worth checking before you point a domain at a new site and tell people about it, in the order that actually makes sense.

iFastHosting Support Team Updated 26 August 2026 9 min read Beginner

A website that goes live with a broken form or a missing SSL certificate is a worse first impression than one that launches a day later fully working. Most launch problems are not complicated — they are simply things nobody checked before the domain went live. This is the order worth checking them in.

Content, before anything technical

Every page has real content. Placeholder text left over from a template is the single most common thing missed on a first launch.
Contact details are correct and current — an address, phone number or email left over from testing is easy to overlook once it works technically.
Links go where they should. Check navigation menus and any links inside page content, not just the homepage.
Spelling and basic proofreading are done on every page, not just the ones you looked at most while building.

Test it before the domain is live

Do this on the actual hosting account, before switching the domain over, rather than assuming it will simply work once it is public. Previewing a site before changing DNS covers how to load and test the site using a temporary address or a hosts file entry, so any problem is found while only you can see it.

Check	Why it matters
Every page loads without errors	Not just the homepage — check every page in the navigation
Forms actually submit and arrive	A contact form that silently fails is invisible until a customer tries it
Images and styling load correctly	Broken references are common when a site is moved between environments
The site works on a phone	A large share of visitors to most sites arrive on mobile

SSL and security

Confirm SSL is active and the whole site loads over https:// without a browser warning. Free SSL is included, and it is usually issued automatically once the domain points at your hosting.
Check for mixed content — pages that load over HTTPS but still reference an image, script or style sheet over plain HTTP, which triggers a warning even with a valid certificate installed.
Use strong, unique passwords for every login involved — hosting, control panel, and any admin account the site itself has, such as a CMS login.
Turn on two-factor authentication where it is available, particularly on the account that controls the hosting itself.

Email

If the domain will send or receive email, confirm mailboxes exist and are actually working before launch, not after the first customer email bounces. Setting up your first email address covers creating a mailbox, and it is worth sending a genuine test message in both directions rather than assuming a newly created mailbox works.

Backups

Set up backups before launch, not after something goes wrong. A site with nothing in it yet is a fine time to confirm backups are actually running, since there is nothing valuable at stake if the first test needs adjusting. Once the site has real content, you want backups already proven to work rather than being tested for the first time under pressure.

Search engines and analytics

Decide whether the site should be indexed yet. A site still being built should generally stay out of search results until it is ready; a site launching for real should not be accidentally blocked from indexing by a setting left over from development.
Set up basic analytics before launch rather than after, so you have a baseline for traffic from day one instead of a gap in the data.
Submit a sitemap once the site is genuinely ready to be found, so search engines can discover its pages efficiently rather than relying entirely on crawling links.

Performance, before people are waiting on it

Compress images before upload rather than after launch — this is usually the single largest, easiest improvement available on a new site.
Enable caching if your platform and control panel support it, so repeat visits and crawler requests are served efficiently from the start.
Remove anything left over from development — test plugins, debugging tools, or scripts added temporarily while building the site — that has no reason to still be active once it is public.

Point the domain, last

Once everything above is checked and working on the hosting account itself, pointing the domain at it is the final step, not the first. Pointing a domain to your hosting covers making that change, and it typically takes a few hours to spread fully — worth knowing in advance so it does not look like something has gone wrong when it has not.

Keep the old site up until the new one is confirmed live everywhere

If you are replacing an existing website, do not cancel the old hosting the moment you switch DNS. Different visitors will see the old and new site during the hours DNS takes to spread, and both need to keep working properly during that window.

Troubleshooting: common launch-day problems

What you see	Likely cause	What to do
Some visitors see the new site, others still see the old one	Normal during DNS propagation — different visitors are resolving the domain against different, temporarily out-of-date DNS caches	Wait it out rather than repeating the DNS change; it resolves itself as caches expire
The site works on your phone's data connection but not on your home Wi-Fi	Your router or ISP is caching the old DNS result longer than usual	Restart your router, or temporarily switch to mobile data to confirm the site itself is actually fine
A security warning appears even though SSL is showing as active	Mixed content — some part of the page is still loading over plain HTTP	Check the browser's page information panel for what specifically is flagged, then find and fix that one reference
A form worked in testing but not for a real visitor	Often a spam filter or validation rule that behaves differently with real-world input than with your own test data	Ask the visitor what they entered, and try to reproduce it with the same input rather than your original test values
The site is noticeably slower than it was during preview	Real traffic and search engine crawlers arriving at once, rather than the single-visitor load testing saw	Check caching is actually enabled, and confirm images were compressed rather than assuming it from the checklist alone

After launch

Check the site again a day or two after going live, once DNS has fully spread and real visitors have used it — a handful of small issues typically surface only under genuine traffic that never appeared during your own testing. Common mistakes people make launching a first website is worth a read at this stage too, since several of them are things that only become obvious once the site is actually public.

Frequently asked questions

How long should I wait after pointing the domain before assuming something is wrong?

Give it a few hours before troubleshooting, since DNS changes typically take that long to spread fully, and up to 24 to 48 hours in less common cases. If the site works correctly through the temporary address or a hosts file entry but not yet through the live domain, the site itself is fine and you are simply waiting on propagation rather than fixing a bug.

Do I need to redo this whole checklist for a small update to an existing live site?

No — this list is aimed at a first launch or a full site replacement, where everything is unproven at once. A small update to a site that is already live and working only needs the parts relevant to what changed, such as re-checking a form if you edited one, rather than the full sequence from content through to DNS.

Should I launch outside business hours to be safe?

It is not required if the checks above are done properly, but it is a sensible precaution, particularly for a business site where a brief issue during the DNS switch would otherwise be seen by customers actively trying to reach you. A quiet period simply reduces the audience for anything unexpected, rather than being a fix in itself.