Website Development Checklist Before Launch

Launch is the moment DNS points at something you will be judged on: search snippets, a contact form, a checkout, or a login. Teams that skip a structured review discover HTTPS warnings, empty Open Graph images, and a 404 for /privacy after the campaign has already started. This article is the editorial companion to Palmate’s interactive website launch checklist — use the tool to tick items; use this page to understand why they are on the list.

If you are still scoping the build, the website cost estimator separates a brochure site from a portal. Delivery itself is web development: information architecture, performance, and a handover that does not depend on one laptop.

Treat launch as an operations event

A site can look finished in staging and still be unsafe to point DNS at. Staging often uses a different host, no CDN, no production analytics, and a robots.txt that blocks everything. The launch review is the conversion of “it works on my machine” into “we can restore it, measure it, and explain it to a stranger.”

Walk the list in one sitting with someone who did not build the last feature. Fresh eyes catch the missing favicon and the form that still posts to a staging inbox.

SEO: what crawlers and people see first

Every important URL needs a unique title and meta description that match the page. Canonical URLs should be explicit if you have trailing-slash or www variants. Open Graph tags need a real image, not a broken relative path.

Sitemaps and robots.txt should allow the public site and still block leftover staging paths if those URLs are somehow reachable. Internal links should work without redirect chains. If you have an insights section, new articles should appear in the sitemap without a manual XML edit.

Structured data is optional until it is wrong. If you emit Organization or Article JSON-LD, it must match visible content. Fake review schema is a trust problem, not an SEO trick.

Performance: the first load is the product

You do not need a perfect Lighthouse score. You do need images with dimensions, a font strategy that does not flash unreadable text for two seconds, and JavaScript that is not a dumping ground for every marketing pixel.

Check mobile: tap targets, horizontal scroll, and forms that do not hide behind the keyboard. If the homepage hero is a 4MB video, that is a launch defect, not a “nice to have.”

Caching and CDN behaviour should be tested with a hard refresh and with a logged-in user if you have both public and authenticated pages. Cache-Control that serves a private dashboard to the wrong person is a security incident; cache that never caches a static marketing page is wasted money.

Security: HTTPS is the floor

TLS should be valid and set to renew without a calendar reminder. Mixed content (HTTP images on HTTPS pages) will trip browsers.

Cookies for sessions need Secure and appropriate SameSite. Admin URLs should not be the default wp-admin with admin/admin if you are on WordPress — but renaming a URL is not a substitute for updates and backups. If you operate the server yourself, complete the Linux production baseline before you call the site “live.”

Headers such as a sensible Content-Security-Policy take iteration; do not copy a maximal policy from a blog and break your own analytics. Start with HTTPS, no mixed content, and secrets that are not in the client bundle.

The interactive checklist’s security section is hygiene, not a penetration test and not a certification.

Accessibility: launch is too late to start

Heading order, form labels, keyboard focus, and colour contrast are cheaper to fix before the press release. Alt text on informative images, skip links if you have a large nav, and captions or transcripts if you shipped video are part of shipping, not a later “a11y sprint.”

This is not a WCAG audit. It is the minimum so a keyboard user can send the contact form. Legal obligations depend on your audience and jurisdiction; the disclaimer and privacy pages are not a substitute for advice.

Analytics, content, and legal

Analytics should fire on production only, with IDs from environment variables — not a leftover staging property. Confirm the privacy policy describes what you actually collect. If you have not enabled a tracker, do not claim you have.

Content: 404 page, 500 page, and a working contact path. Placeholder copy and lorem ipsum are launch blockers. So is a blog index with no posts if you advertised a knowledge centre.

Legal pages — privacy, terms, cookies — should exist, be linked in the footer, and not contradict the cookie banner. If non-essential cookies are off by default, the banner must not imply they are already on.

Backup and deployment

Know how you deploy, how you roll back, and how you restore the database and uploads. A git tag and a documented reverse-proxy config beat “SSH and hope.” Off-site backups that have been restored into staging once are infinitely more valuable than a zip in someone’s drive.

If the site is on a VPS, you are in cloud and DevOps territory even if the pages were a web development project. Hosting choice still matters: shared vs VPS vs dedicated is the article to read if production is still “the cheapest panel.”

Use the uptime calculator only if you are about to print an SLA. Most marketing sites need a restore drill more than they need 99.99% theatre.

Deployment day

Check	Why
DNS TTL lowered in advance	Faster rollback if the cutover is wrong
TLS live on the new host	Avoid a certificate error at switch
Forms to a real inbox	Staging mail is not production mail
Redirects from old URLs	Campaigns and search will hit yesterday’s paths
Monitoring / uptime ping	You should hear about downtime before Twitter

Keep a written rollback: revert DNS, or revert the last release. The containerised VPS sample is a reminder that deploy-from-git and a previous image are part of launch, not a later “DevOps phase.”

After the tick list

The website launch checklist stores progress in the browser so a team can share a printout or JSON export in a review meeting. It is not a compliance certificate. Accessibility, privacy, and security obligations still depend on what you built.

If you are choosing who does the work, how to choose a software development company covers process and ownership — including who stays responsible the week after launch, when the real tickets start.