The website launch checklist

What actually has to be finished before launch?

Whatever gets more expensive later. That is the only test that separates a launch checklist from a wish list: the colour of a button can change tomorrow, but three things never come back.

First, data. If analytics is not installed on day one, that week of traffic is gone for good and no tool recovers it. Second, ownership. A domain registered in the agency name is a negotiation later, not a setting. Third, access. The hosting account, the domain panel and the site administrator user, if they are not handed over on the day, are usually chased a year later at the worst possible moment.

The rest can be repaired, but not at the same price. One leftover tag can keep a site out of the results for weeks. A contact form whose mail does not arrive means leads you never learn existed. That is why this list sits in four columns, with the technical one first: not because it matters most, but because its failures are the quietest.

Technical: the two lines that do the most damage

Both come from the staging version and both are invisible. The first is a noindex tag in the head of the page, the second a Disallow: / line in robots.txt. You have seen the site that went live, works, is fast, and six weeks later somebody asks why it is not in Google.

In WordPress that tag usually comes from a checkbox: under Settings and Reading there is an option that asks search engines not to index the site. On staging it is right for it to be on; on launch day it has to go off, and that should be the last switch you flip, not the first.

Checking takes thirty seconds, and looking at the page will not answer it, because neither of them is visible. Open the page source and look for the robots tag, and open robots.txt directly in the browser. If you have a terminal, the exact command is in the fast path section of this lesson.

Three more items in the same column:

• One canonical hostname. The site should come up on one address only and every other form should 301 to it: without https to with https, and with www to without www or the other way round. Do not build redirect chains; every form should go straight to the final destination. The SSL certificate has to be valid both with and without www, and the SSL checker shows you its expiry and its issuing chain.
• A real 404. Open a meaningless address. You should see your own 404 page and the status code should genuinely be 404, not a 200 with the words "not found" on it. A page that returns 200 is a healthy page as far as Google is concerned.
• Sitemap and robots. The sitemap should be reachable and hold only indexable URLs, and robots.txt must not block CSS and JavaScript. The robots and sitemap tool reads both together.

Content: the pages that must not be half done on day one

A site with ten finished pages launches better than a site with forty half finished ones. The minimum is this: a contact page with a channel that actually answers, an about page with the names of real people, terms and privacy pages, and a 404 page that offers a way to the home page and to search rather than a dead end.

Then the small things, all of which take five minutes and all of which are usually forgotten. Add the favicon, or the browser tab shows a blank sheet. Add the sharing image and test it: send your own link to yourself in a WhatsApp or Telegram chat and look at what appears; that is the only real test of those tags. The title and meta description of every page should be unique, and the meta tag checker shows that page by page.

And two things that hit the experience directly: no placeholder text should survive onto the live site, and every image should carry a width and a height. The second is so the browser holds the space before the image arrives, otherwise the text shifts under the reader; the same thing we know from site speed as layout shift.

Does the site email actually arrive?

This is the only item on the whole list whose failure gives no sign at all. The contact form shows a green "sent", WordPress says it did its job, and the message never reaches anybody inbox.

The reason is that when the WordPress mail function returns true it has said only one thing: I handed the message to the sending system. Whether the destination server accepted it, dropped it in spam, or refused it outright is outside that function view. So any test that stops at the green message has proved nothing.

Three DNS records decide this and all three belong in place before launch. SPF says which servers are allowed to send mail in your domain name. DKIM puts a cryptographic signature on the message itself so the receiver can be sure it is untouched and came from where it claims. DMARC tells the receiver what to do when those two do not line up, and where to send the report. There is a fourth record that is not in your DNS at all and sits with the server provider: the reverse record, or PTR, which turns the sending IP back into a name. Large mail providers look suspiciously at mail arriving from an IP with no reverse name.

The right test has two steps. First a real send, not from inside a plugin but through the site own form, to two different destinations: a Gmail address and a company one. Second, reading the send log on the server, the place where the destination server acceptance line is written. Until you have seen that line, you are guessing that the mail arrived.

Measurement: the thing you cannot make up later

Analytics and Search Console go in before launch, not after. The reason is simple and has nothing to do with SEO: there is no retrospective data. Install them a month later and that month is a black hole no tool will fill.

Three jobs in this column. First install Google Analytics 4 and make one test hit to confirm data really arrives; the realtime report answers you on the spot. Second verify ownership in Search Console, preferably with a DNS record, because that method does not depend on a file or a tag on the site and does not vanish when the theme changes. Third submit the sitemap; the guide to submitting a site to Google has that step by step.

One thing that usually gets left out: define the contact form submission as an event. Without it, next month you will know how many people arrived and not how many got in touch, and it is the second number that shapes every decision after launch.

Ownership and legal: what belongs in the contract

This column has no code in it and produces most of the arguments that follow a handover. Four things have to be settled on launch day and preferably written into the contract before it: in whose name the domain is registered, in whose name the hosting account stands, who holds DNS management, and to whom the site files and design sources are delivered.

One sentence makes it simple: the designer should have access, the owner should have ownership. A domain registered in the agency name is no problem at all while the relationship is good, and on the day it cools, the only real asset of the site is in the other party hands. A web design contract is the right place to write those four items down.

On the pages side, two are needed: terms and conditions, and a privacy page. The privacy page has to say what data you collect and with which tools; if you run analytics, that belongs there.

And a boundary, honestly stated: if your site is a shop, the permits and marks required to sell online are a separate subject with their own process, and it starts before launch rather than after. We say nothing about the details here because we have not checked them.

The first forty eight hours after launch

Launch is not the end of the work, it is the start of the two days in which most of the errors surface. Watch four things: the server error log, the URLs returning 404 (if there was a previous site, this is where a missing redirect shows itself), the arrival of form email, and the pages section of Search Console over the following days.

And one thing that eats a lot of people time because nobody thinks about it in advance: cache layers. You make a small change, open the page, see the previous version and conclude the change did not take. Usually it did, and what you are looking at came from a cache.

On this site there are three layers between you and PHP: the page cache on the server itself, the content delivery network cache at the edge, and the browser cache. The headers on public pages here tell the edge to keep the HTML version for 2592000 seconds, which is thirty days. So a fix that is already sitting on the server may not reach a visitor until that cache is cleared. Before launch, know which layers you have and how each of them is cleared; launch day is not the time to discover it.