Website launch checklist: check your site before it goes live
Most launch checklists are a list you tick from memory. This one loads your site and checks it — the staging settings that quietly ship, the links that only work on a developer's laptop, the missing privacy policy — and gives you a go or no-go, plus a checklist you can paste into a ticket.
We read the site like a visitor and a search engine would. Nothing is submitted, signed into or changed.
What the checklist covers
- Search engines
- robots.txt, noindex, the canonical URL, the sitemap, the title and description, and whether missing pages return a real 404
- Security
- HTTPS and the http redirect, secret keys in public JavaScript, a public .env file, insecure forms, mixed content, basic headers
- Content and links
- Placeholder text, links to localhost or preview deploys, broken internal links, the favicon and the link preview image
- Mobile and quality
- Sideways scrolling on a phone, failed requests and console errors on load, slow first paint, accessibility basics
- Legal and consent
- A privacy policy when you collect data, terms when you take payments, consent before tracking
- Measurement
- Whether analytics is installed before launch day rather than after
- SPF and DMARC on your domain, so sign-up and reset emails do not land in spam
The mistakes that survive staging
The launches that go wrong rarely go wrong on the homepage. They go wrong on settings that were correct on staging and nobody thought to change: a robots.txt that still turns every search engine away, a noindex tag, a canonical URL pointing at the preview address, a link to localhost in the footer, a test API key in the bundle.
None of these look wrong in a browser. The site loads, the design is right, the demo works — and three weeks later someone notices it is not in Google. That is why this checks rather than asks: every one of them is visible from outside if you know where to look.
Production or staging
Tell it whether you are checking production or staging. The same finding means opposite things on each: a noindex tag is right on staging and removes you from search on production.
Checking staging first, then production on launch day, is the pattern that works. Anything marked as a reminder on staging becomes a blocker on production if it is still there.
What it cannot check
Every report lists these for a person to confirm, adjusted to what your site appears to use.
- Whether backups restore, whether rollback works, whether anyone gets paged when the site goes down — the report lists these for you to confirm by hand.
- Flows behind a login, and payments. It never submits a form, signs in or buys anything.
- Every page. It checks the address you give it and a sample of the pages it links to, not a full crawl.
Questions before launch day
Should I check staging or production?
Both, in that order. Check staging while there is time to fix things, then production on launch day. Choose which one you are checking before you run it — staging settings like noindex are correct there and are reported as reminders, not blockers.
What does “Do not launch yet” mean?
At least one finding would hurt you on day one: search engines shut out, a secret key public, a link to a developer's machine, placeholder text, a form sending data over plain http. “Fix before launch” means something is broken but not dangerous. “Ready, with warnings” means nothing is stopping you.
Does it test my forms, sign-up or checkout?
No. It never submits, signs in or buys anything — it only reads what a visitor's browser would. Those flows are on the “confirm by hand” list in every report, adjusted to what your site appears to use.
Why does a launch checklist look at email records?
Because launch day is when your site starts sending email — sign-up confirmations, password resets, replies to the contact form. Without SPF and DMARC on your domain, more of those land in spam, and it takes a DNS change and a day of propagation to fix.
Is this an SEO audit?
It covers the SEO mistakes that break a launch — being blocked, being noindexed, pointing search engines somewhere else — not rankings or keywords. It is a launch gate, not a growth tool.
Is it free?
Yes, with no account. If you want the fixes made, Refinar can do that in your repository: it makes each change in a live preview and opens a pull request for you to approve.