20 Things you Should Check Before You Launch a Website

Getting a website live has become much easier.

You can give Claude a design brief, let it write the code, connect the pieces, fix the obvious bugs, and have a surprisingly polished site running in a short amount of time.

That speed is useful. It is also where people get careless.

The website looks finished, so you publish it. Then someone clicks a broken link. The social preview is still showing the default image. The mobile layout falls apart on a smaller screen. A form accepts garbage. An API key has accidentally made its way into the frontend. Your analytics are not recording anything.

None of these problems is particularly exciting. That is exactly why they get missed.

Before launching a site, I would give Claude a final checklist and make it go through the boring stuff systematically. The goal is not to delay the launch for three weeks trying to achieve perfection. It is to catch the small problems that become embarrassing, expensive, or difficult to fix once real visitors are using the site.

Start with the things that can cause real problems

The first checks should be the things you do not want to discover after launch.

Make sure the privacy policy and terms and conditions are in place where they need to be. They are easy to forget when most of the development work is focused on the actual website.

Then look through the frontend for secrets.

API keys, private credentials, tokens, database credentials, or anything else that should remain server-side should not be sitting inside JavaScript that every visitor can inspect. This is one of those mistakes that can happen because the site works perfectly during development.

Working does not mean secure.

HTTPS should also be enforced properly so visitors are not being sent through insecure connections. If the site uses cookies that require consent, make sure the cookie consent experience is actually implemented rather than leaving it as another item on a future to-do list.

These are not design details. They are launch requirements.

Then make the site understandable to search engines and social platforms

Once the basic security and legal pieces are handled, Claude can work through the metadata.

Every important page should have an appropriate meta title and description rather than relying on whatever happens to be generated automatically. The site should have a sitemap and a sensible robots.txt file, and important images should have useful alt text where appropriate.

Then check the social preview.

Share a page and see what actually appears. Is the correct title displayed? Is the description correct? Is there a proper image? Does the site look like something you would actually want someone to click?

The favicon belongs here too.

It is a tiny detail, but a missing favicon is one of those things that immediately makes a finished website feel unfinished.

Make the site fast enough to use

A site can look beautiful in development and still be painfully slow for someone visiting it on a normal connection.

Run a page-load and performance check before launch. Look at oversized images, unnecessary scripts, large assets, blocking resources, and anything else that is making the browser do unnecessary work.

Image compression is one of the obvious places to start.

You do not need to make every image microscopic. You need to make sure you are not serving a four-megabyte photograph when the page only needs a properly sized compressed image.

Claude can help identify the likely causes of poor performance, but do not treat its suggestions as automatically correct. Make the change, test the site again, and see whether the problem actually improved.

Check the experience on a phone

A website is not finished because it looks good on the developer's monitor.

Check it at different viewport sizes.

Look for overflowing text, buttons that are difficult to tap, navigation problems, images that break their containers, sections that become unnecessarily tall, forms that are awkward to complete, and anything that requires horizontal scrolling.

Mobile responsiveness is not a final visual polish step. For many websites, it is the primary experience.

The same applies to color contrast.

Text that looks perfectly readable to the person who designed the site can become difficult to read once it is placed over a particular background or viewed on a different screen. Check the contrast rather than assuming it is fine because the design looks good.

Try to break the website

One of the most useful things you can ask Claude to do before launch is to stop admiring the website and start trying to break it.

Click every important link.

Submit every important form.

Try invalid form inputs.

Leave required fields empty.

Enter unexpected values.

Check error messages.

Visit pages that do not exist.

That last one is where the custom 404 page comes in.

A visitor will eventually land on a URL that does not exist. Instead of showing an ugly default server page, give them a useful 404 page that explains what happened and gives them somewhere sensible to go next.

Then check for broken links across the site.

A single broken link may not destroy a business, but broken links are exactly the kind of small problems that make a website feel neglected.

Protect the forms

Forms deserve their own test because they are often where websites quietly fail.

Make sure validation works on both the expected inputs and the obvious bad ones. Make sure successful submissions actually reach the intended destination.

Then add appropriate spam protection.

A beautiful lead-generation website that quietly sends its owner hundreds of spam submissions is not a successful launch.

This is also where you should verify what happens after someone submits the form. Is there a confirmation message? Does the lead reach the CRM or email inbox? Is the correct event recorded? Does the user know what happens next?

The form is part of the business system, not just another section of the page.

Make sure analytics actually works

Analytics should not be treated as something you will install later.

Set it up before launch and test it.

Visit the site yourself. Trigger the important events. Submit a form. Click the important CTA. Check whether the expected data is actually appearing.

There is a big difference between having an analytics script somew