# Pre-launch and deployment checklist

Free checklist from Plain Talk Developers · plaintalk.dev/skills/

Work this top to bottom before you point a domain at anything. Every item is
here because skipping it broke a real launch.

The rule underneath all of it: **verify against the deployed site, not the
source.** A build that compiles proves nothing about what a visitor receives.

---

## Before cutover

### Routing
- [ ] Every internal link resolves. Click them, do not assume.
- [ ] Every form submits and the submission arrives somewhere you checked.
- [ ] Thank-you and confirmation pages exist and are reachable.
- [ ] 404 page exists and looks intentional.
- [ ] No link points at a staging or preview hostname.

### Content truthfulness
- [ ] No placeholder phone numbers, emails or addresses anywhere. Grep for
      them, do not read for them.
- [ ] No lorem ipsum, including in meta descriptions and alt text.
- [ ] Every operational claim traces to something the owner actually said.
      Turnaround times, guarantees, licensing, insurance, service areas.
- [ ] No fabricated reviews, ratings or counts. Pull them live or leave them
      out.
- [ ] Prices and offers match what the business will honor today.

### Staging flags
- [ ] `noindex` removed from the production build.
- [ ] `robots.txt` no longer blocking everything.
- [ ] Test or demo banners removed.
- [ ] Analytics is pointing at the real property, not a test one.

### Accounts and ownership
- [ ] Hosting, registrar, analytics and the repo are all in the **owner's**
      name. You are a collaborator. Anything else holds a business hostage by
      accident.
- [ ] Environment variables set in production, not only locally.
- [ ] Someone other than you can get into every account.

---

## DNS cutover

- [ ] Lower the TTL on the existing records **24 hours before** you plan to
      move. Doing this at cutover time does nothing.
- [ ] Record the current DNS state before changing it. Screenshot it.
- [ ] Change **web records only**: A, AAAA, CNAME. Never touch MX or email
      TXT records unless email is explicitly part of the job. Taking a
      business's email down is a different category of mistake.
- [ ] Both apex and `www` resolve, and one redirects to the other
      consistently.
- [ ] HTTPS works with no certificate warning.

### Prove the new host works before DNS moves

Bypass DNS entirely and hit the new host directly:

```bash
curl -s --resolve example.com:443:NEW.IP.ADD.RESS https://example.com/ \
  | grep -o '<title>[^<]*</title>'
```

If that returns the new title, the host is configured correctly and anything
still wrong is DNS propagation, not your build.

### While it propagates
- [ ] Check more than one resolver. They disagree for a while:
      `nslookup example.com 8.8.8.8` and `nslookup example.com 1.1.1.1`
- [ ] Do not diagnose from your own browser. Your machine will serve the old
      site from cache long after the public resolvers have updated.

---

## After launch, same day

- [ ] Submit the sitemap in Search Console.
- [ ] Confirm the live site is indexable: fetch it and check for `noindex`.
- [ ] Submit a real lead through every form and confirm it arrives in **both**
      the inbox and the CRM.
- [ ] Confirm the conversion event actually fires. Not that the tag is
      present, that the event fires.
- [ ] Check the site on a real phone on cellular data, not desktop responsive
      mode.
- [ ] Watch the server logs for the first hour.

## After launch, first week

- [ ] Old URLs redirect to their new equivalents, if this replaced a site.
- [ ] Search Console shows no coverage errors.
- [ ] Core Web Vitals measured on the live site and recorded with the date.

---

## The one that costs the most

A site once shipped with every lead form redirecting to a 404. Nobody noticed
for weeks, while ad spend kept running.

**Submit a real lead yourself, after launch, on production.** Not a test in
staging. Not a glance at the form. Submit it, and go look for it where it is
supposed to land.

---

**Want the reasoning behind each of these?** The Launch Verification and
Deploy and Domain skills cover the mechanics, the failure modes, and what to
do when DNS misbehaves.

plaintalk.dev/skills/