A checklist before you publish a company site

A website launch checklist is the pass you make after the pages look done and before anyone is asked to trust them. The list is practical: copy, links, forms, mobile, titles, alt text, speed, and the inbox that receives replies. A site can be attractive and still fail every one of those. Publish when the list is clean, not when the team is tired of looking at the design.

Do this on the address you intend to launch, or on a staging site that matches it. A design file cannot tell you that a form delivers mail. Google's Core Web Vitals are the speed bar to use, because they are public and specific: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. Google's title-link guidance is the other bar: every page needs a descriptive title element, not a vague label such as "Home," and not the same stuffed phrase on every URL.

Copy you can say out loud

Read every page aloud. Fix sentences that only make sense to the people who wrote them. The offer, the price note, and the button labels are the ones that cause trouble later, so read those twice.

Check names, dates, and claims. If a number is on the page, you should know where it came from. Remove awards, revenue, and quotes you cannot point to. A seed-stage site is more credible with one true project than with a precise-sounding fiction. If a project is public, describe it at the level you can defend. "We redesigned the shop" is a claim you can support with the work. A percentage lift you never measured is not.

Look for leftover template copy. "Welcome to our website." "All-in-one solution." "Lorem" in a caption. Look for the old name, if you renamed the company, and for a year in the footer that is wrong. These are small, and they are what a careful visitor notices first.

Spell the action the same way everywhere. If the button says "Book an intro call," the confirmation should say that a call was requested, not that a "submission was received." Matching words are part of the copy pass.

Links and forms

Click every link. Navigation, footer, buttons, logos, and text links inside paragraphs. Each one should land on a page you meant, on the right protocol, without a detour through a dead campaign URL.

Check the obvious failures:

• Links that still point at a staging host.
• Buttons that do nothing, or that scroll to the wrong section.
• A logo that does not return home.
• A mail link with a misspelled address.
• Social links that open the wrong account, or an account you no longer use.
• Old URLs that should redirect, if this launch replaces a site people already visit.

Submit every form with a real address you control. Contact, newsletter, checkout, application. Confirm the message arrives in the inbox a human will read, and that the sender sees a confirmation on the page. Send a second test with a missing required field and confirm the error is understandable. Then check the same forms on a phone, because a field that is off-screen is a broken form.

If a form writes to a tool, open the tool. A green success message that never creates a row is a failed launch. Agree who is notified, and turn the notification on before you announce the site. A checklist item that says "hook up email later" will still be open on Monday.

Mobile, titles, and alt text

Hold the phone the way a founder checks a site between meetings. Read the first screen without pinching. The offer and the action should be visible. Tap every control with a thumb. If two links sit so close that you hit the wrong one, separate them. If text overlaps an image, fix the layout rather than hoping a wider phone will save it.

Walk the same pages on a phone and a wide window. Look for content that exists in only one of those views. A paragraph that never appears on the phone never reaches that visitor.

Set the title element on each page. Make it descriptive and distinct. The home page can carry the company name and what you do. Inner pages should say which page they are. "About — Northwind" tells a search result something. "Home" tells it nothing. Keep the titles concise. Google notes that title links get truncated to fit the device, and that repeating the same boilerplate makes pages impossible to tell apart. The visible heading and the title should describe the same page, even if the wording is not identical.

Write alt text for images that carry information. Say what is in the picture: the product, the room, the diagram. Decorative marks can have empty alt text so a screen reader skips them. Do not paste the keyword into every image. A launch is a bad time to turn descriptions into slogans. Check the hero, the work images, and any icons that are the only label on a control. An unlabeled icon is a control some people cannot use.

Speed and stability

Load the main pages on a normal connection, not only on the office network. The largest thing in view, usually the hero image or the heading block, should arrive quickly. Use the Core Web Vitals bar already stated: largest paint within 2.5 seconds, the next paint after a tap under 200 milliseconds, layout shift under 0.1.

The usual causes are ordinary. An enormous image that should have been cropped. A font that blocks the first text. A banner that pushes the page down after it loads. A chat widget and a slider that start before the offer is readable. Remove what you cannot justify. A launch day is a poor moment to add decoration that fights the first screen.

Check the pages you actually linked, not only the homepage. A fast home page that leads to a heavy product page still fails the visitor you most want. If a video is essential, give it a still poster and let the person start it. Autoplay is how a careful page starts to feel careless.

Run the check after the last content change. A new hero image, dropped in on the final afternoon, can undo a week of restraint. Measure once more when the content is frozen.

The inbox, then the announcement

Decide where replies go, and prove it with the form test from earlier. Then decide who answers on the first day. A site that asks for a conversation needs a person at the other end. Grant that person access to the inbox or calendar through their own account before you publish. A password in someone's head is not a handoff.

Set an autoresponder only if it tells the truth. "We received this and will reply by the next business day" is useful. A cheerful note that pretends a human has already read the message is not. If you book directly onto a calendar, place a real meeting on it yourself and confirm the conferencing link opens.

Tell the people who expect the launch: the founder, the person on sales calls, and anyone whose email signature still points at the old site. Update those signatures, the social bios, and the deck that links the company. A perfect homepage still loses if every public profile sends people to the previous URL.

Keep a short list of known gaps and agree they are after launch, in writing. A blog you postponed, a second case study, a language you do not yet need. Naming them prevents a last-minute attempt to build them in the hour before you switch the domain.

The hour you switch the domain is its own sequence: staging, a content freeze, DNS, and someone watching the first visits. That sequence is covered in staging, DNS, and the week before launch. Finish this checklist before you start that week, so the launch argument is about the domain and not about a broken form.

When you want the pages built to survive this list, see Hanabi's design and development services. A launch is easier when copy, speed, and the inbox were part of the work from the start.