20 Things to Do Before You Launch a Website

Nearly every site I've seen go live with a problem had the same cause, which is that the last day got spent on the design and nobody ran the boring list. This is the boring list. Twenty things, most of them under ten minutes.

The full twenty, in the order they appear below:

hide your keys · force HTTPS · form validation · spam protection · test on a real phone · fix broken links · check page speed · compress images · custom 404 · page titles and descriptions · social preview image · favicon · sitemap · analytics · privacy policy · terms page · cookie banner · alt text · colour contrast · one clear call to action

They're grouped by job rather than ranked, but the order genuinely matters on two of them, so there's a recommended sequence at the bottom.

Security first, because it's the only one that can't be undone

1. Hide your passwords and keys. API keys, database passwords and access tokens committed into your code or left in a public file get found by automated scanners within minutes of a domain going live, because those scanners run continuously against new certificates. Check your commit history as well as your current files, because deleting a key from today's version does not remove it from the commit that added it. And if one has been exposed at any point, rotate it rather than hiding it, because you have to assume it was taken.

2. Force HTTPS. Not merely available over HTTPS, forced. Every plain HTTP request should redirect, and ideally you set HSTS so the browser stops trying. Browsers now show active warnings on forms served over HTTP, which means a visitor filling in your contact form sees a security warning from their own browser at the exact moment you were asking them to trust you.

17. Form validation. Check what happens when someone submits an empty form, a malformed email address, a very long string, or a script tag. Unvalidated input is how the boring vulnerabilities get in, and broken validation is how you silently lose enquiries without ever knowing they were attempted. Validate on the server, not only in the browser, since the browser check is trivial to bypass.

18. Spam protection. Every public form gets found by bots, usually within days. With nothing in front of it your contact form becomes a spam feed inside a week, you stop reading it, and then you miss the one real enquiry buried in there. A honeypot field or a modern invisible check costs nothing and stops nearly all of it.

Does it actually work

3. Does it work on a phone. Not "is it responsive" in theory, and not the browser's device emulator either. Open it on a real phone, on mobile data rather than your office wifi, and go through the whole journey including the form. Most of your traffic is mobile and most sites get built on a large desktop monitor, which is the entire reason this gap keeps happening.

4. Fix broken links. Run a crawler over the finished site before launch. Broken internal links are the clearest possible signal to a visitor that nobody checked the work, they waste your crawl budget with search engines, and they cost nothing to fix. Check the footer especially, because it's copied across every page and nobody ever reads it.

14. Check page speed. Run PageSpeed Insights and read the mobile score, not the desktop one, because the desktop number flatters everything. Look at Largest Contentful Paint in particular, since that's the one users actually feel. Most of the damage on most sites is uncompressed images, which is the next item.

13. Compress your images. The single biggest speed win available on almost every site I look at. A four megabyte hero photograph straight off a camera is the most common cause of a slow page, and it is entirely invisible to the person who uploaded it on a fast connection. Get them under a few hundred kilobytes, serve modern formats like WebP, and set explicit width and height so the layout doesn't jump while they load.

16. A custom 404 page. People will hit one, through an old link, a typo, or a search result pointing at a page you moved. A default server error page with no navigation loses that visitor completely. A page that says plainly what happened and offers a route back to something useful keeps them, and it takes fifteen minutes.

So people can find it

8. Page titles and descriptions. Every page needs its own, written for a human deciding whether to click rather than for a keyword. The default of your site's name repeated across twenty pages is the most common SEO failure I see on small business sites, and it's an hour of work to fix properly. Keep titles under about sixty characters so they don't get truncated in results.

9. A social preview image. The Open Graph image that appears when someone shares your link in a message, a group chat or a post. Without it your link posts as a bare grey rectangle, which quietly costs you every share you would otherwise have got. Set one per page if you can, or at minimum a good default for the whole site.

10. The little tab icon. The favicon. Absent, you get a generic document or globe icon in the browser tab, which is the cheapest possible way to look unfinished, and it's the version of your brand sitting in front of anyone who keeps your tab open. Supply the modern sizes, including one that works against a dark tab bar.

11. A sitemap. Generate it and submit it to Google Search Console. It's how search engines learn what exists on a brand new site that has no inbound links pointing at its inner pages yet. While you're in there, check that robots.txt isn't still blocking everything from the staging build, which is a genuinely common launch-day disaster.

19. Set up analytics. Before launch, not after, because otherwise the first week, which is the week you learn the most about who actually shows up, goes unmeasured forever. Then confirm it's actually recording by visiting the site yourself and watching the realtime view. An installed tag that fires nothing is worse than no analytics at all, because you will trust it and plan around it.

The ones people leave out

5. A privacy policy page. Required the moment you collect anything, and a contact form counts as collecting.

6. A terms page. What you provide, what you don't, and the limits of your liability.

7. A cookie banner. If you run analytics or marketing cookies and serve anyone in a jurisdiction that requires consent, this isn't optional, and it has to genuinely block those cookies until consent is given rather than just announce that they exist.

Those three overlap with the legal exposure list, which goes considerably deeper on what each page needs to contain. Here they're just "must exist before you're live".

12. Alt text on images. An accessibility requirement, a search benefit, and the thing that makes your site usable to somebody navigating with a screen reader. Describe what the image shows and why it's there, rather than stuffing it with keywords.

15. Fix colour contrast. Light grey on white is the most common accessibility failure on the web and it fails WCAG AA outright. A checker takes two minutes and the fix is usually a single variable in your stylesheet.

20. One clear call to action. The one people get wrong by doing too much rather than too little. If your homepage offers five equally weighted next steps you have effectively offered none, because the visitor has to make a decision you should have made for them. Decide the single thing you most want someone to do, make it the most visually obvious element on the page, and let everything else be secondary.

The prompts I use

I don't run this by hand any more. The version that works is asking for one item at a time with evidence, because a general "check my site" gets you a confident summary that skips things.

For the whole list: "Go through this launch checklist against my site one item at a time. For each, say present, partial or missing, quote what you found as evidence, and give me the exact change. Don't summarise until all twenty are done."

For the security items: "Search this repository and its commit history for anything that looks like an API key, token, password or connection string. Include files that are gitignored now but were committed before."

For the metadata: "List every page with its current title tag, meta description, OG image and canonical URL in a table, and flag any that are missing, duplicated across pages, or over the length that gets truncated in search results."

For the mobile pass: "Load each page at 390 pixels wide and tell me every element that overflows horizontally, is smaller than a 44 pixel touch target, or overlaps something else."

That last one catches more real problems than any amount of looking.

FAQ

What is the most important thing to do before launching a website?

Hiding your API keys and passwords. It's the only launch task that can still cost you money a year after you fix it, because an exposed key has to be assumed taken.

How long does a website launch checklist take?

Most items take under ten minutes. The ones that can take longer are the real-phone test and page speed, because they can turn up something that needs rebuilding.

Does a website with only a contact form need a privacy policy?

Yes. A contact form collects personal details, and that's enough to need one.

Can Claude run a website launch checklist for me?

Yes. Give it a launch checklist like this one and ask for one item at a time with evidence, present, partial or missing, and no summary until all twenty are done.

The order I'd do them in

Security first and without exception, because item 1 is the only thing on this list that can still be costing you money a year after you fix it.

Then item 3, the real phone, because it's the one most likely to reveal something that needs actual rebuilding rather than a setting.

Then speed and images together, since they're the same job.

Then everything else, which is mostly filling in fields.

The thing I'd actually say to anyone launching this month is that none of this is skilled work. It's a list somebody has to hold, and the reason sites go live without it is never that it was hard. It's that the last day always gets spent on the part that's fun. I built my whole website process around making this stage a checklist rather than a memory test, and it's the single change that stopped things shipping broken.