What I Check Before a Business Website Goes Live

A common launch mistake is treating “the URL loads” as “the site is finished.”

A public URL proves only that the code was deployed. It says nothing about whether product claims are correct, the mobile experience works, buyers know what to do next, or search engines can read the intended version.

This is the order I now use.

1. Define the job of the site

Before building, answer four questions:

Who will land on this page?
What are they trying to solve?
What gives them enough confidence to take the next step?
What should they do next?

Without those answers, navigation, content and calls to action are guesswork.

Manufacturing sites need one more check: when a buyer asks a question, can the company provide accurate product data, documents, logistics details, and a usable quotation?

2. Give every public claim a source

Product specifications, certificates, cases, images, and business outcomes must be reviewed separately. Unconfirmed material can remain in draft, but it should not be published merely to make a page look complete.

I use four practical states:

Verified: a clear source exists and the material can be public;
Draft: the direction is plausible but still needs an owner’s confirmation;
Blocked: the sources conflict or required evidence is missing;
Internal only: useful for the team, not suitable for the public site.

3. Build one complete path

The first version does not need every future idea. It does need one path that works end to end:

Entry page → product or service explanation → evidence → contact → internal follow-up

Add About, Contact, Privacy, Terms and a real 404 as well. They may not attract search traffic, but they affect trust and basic use.

4. Build SEO and AI-search basics into the release

Each page needs its own title, description, H1, canonical URL, and social-sharing image. Add hreflang only when the language pages genuinely correspond.

Also check:

whether the sitemap and robots directives match the release environment;
whether canonical URLs contradict one another;
whether structured data matches the visible page;
whether meaningful images have appropriate alt text;
whether llms.txt explains the topic and evidence boundary clearly.

5. Publish a noindex preview and review it in a real browser

Keep preview sites out of the index until the content is approved. Review at least one desktop size and a 390px phone:

Is any title clipped?
Do navigation, buttons and contact links work?
Do headings and paragraphs wrap naturally?
Does excessive whitespace push useful content below the fold?
Do the 404, privacy and terms pages exist?
Do email, phone or WhatsApp links open the right destination?

Do not merge a candidate into the production branch without explicit approval.

6. Verify the newly deployed version

After production is ready, check HTTPS, primary-domain redirects, canonical, robots, sitemap, social image, schema, 404, security headers and the real contact path again.

A production check run before the new deployment may inspect the previous version instead.

7. Keep release state separate from business state

A useful sequence is:

Deployed → accessible → crawlable → indexed → qualified inquiry → sample or quotation → order

Traffic is not an inquiry. An inquiry is not an order. Keeping those states separate makes later website decisions less reactive.