Website Launch Checklist: 25 Checks Before You Publish
Launching a website is not the moment to discover that search engines cannot crawl it, social shares have no preview image, or every page points to the wrong canonical URL. A useful launch checklist catches small configuration mistakes before they become public problems.
1. Confirm the site is publicly reachable
Open the production URL in a private browser window and on a mobile connection. The page should load without a password, development banner, staging warning, or certificate error. Check both the preferred HTTPS address and common variants such as the HTTP URL. A production site should redirect visitors to one consistent HTTPS version rather than leaving several versions accessible.
Also check the status code of important pages. A normal page should return HTTP 200. Redirects should be intentional, and a missing page should return a real 404 rather than a 200 response containing an error message.
2. Review titles, descriptions and headings
Every important page needs a specific title that describes that page, not a repeated company name. Add a useful meta description for search snippets, and make sure the visible page has a clear primary heading. These elements do different jobs: the title identifies the document, the description summarizes it, and the H1 gives the reader an immediate topic.
Do not write them for a score. Write them for a person deciding whether the page answers a question. Avoid stuffing the same keywords into every field.
3. Check canonical URLs and indexing controls
Canonical tags should point to the preferred public URL for each page. A staging hostname, old domain, localhost address, or accidental generic homepage canonical can cause search engines to consolidate the wrong URL.
Review robots.txt and any robots meta tags at the same time. A common launch mistake is leaving a temporary noindex directive or a broad robots.txt block that was useful during development. Search engines cannot index pages you explicitly tell them not to index.
4. Publish and test the XML sitemap
A sitemap is a discovery aid, not a substitute for navigation. It should contain the canonical public URLs you actually want indexed. Remove preview hosts, redirected URLs, test pages and duplicate variants. Reference the sitemap from robots.txt and submit it in Google Search Console after the production domain is stable.
A small site does not need a complicated sitemap generator. Accuracy matters more than size.
5. Verify social preview metadata
When a page is shared in messaging apps or social networks, Open Graph and similar metadata influence the preview. Check og:title, og:description, og:image and the page URL. Use an image that is publicly reachable and meaningful when seen without the rest of the page.
A broken social image does not usually break the website, which is why it is easy to overlook until a launch announcement already went out.
6. Review HTTPS and security headers
The browser should receive a valid certificate and use HTTPS consistently. Useful response headers can reduce exposure to common browser-side risks. Examples include HSTS, X-Content-Type-Options, a sensible referrer policy, and a permissions policy. Content Security Policy is powerful but should be configured carefully because an overly strict policy can break legitimate scripts.
A header checker is a launch signal, not a penetration test. Security also depends on application logic, dependencies, authentication, server configuration and ongoing maintenance.
7. Test mobile usability and real content
Confirm the viewport meta tag is present and then use the website on a real phone. Check navigation, forms, buttons, text size, horizontal scrolling and tap targets. A technically responsive layout can still be frustrating if a banner covers controls or important text is hidden behind a sticky header.
Finally, read the actual content. Remove placeholder copy, dead links, empty sections, default images, unfinished pricing and claims that are not ready to be public.
8. Make the launch repeatable
Record the critical checks you expect to pass on future releases. A launch checklist becomes more valuable when it is reused after redesigns, domain changes, framework migrations and major content updates. Automated checks can catch predictable technical regressions, while a short human review catches context, wording and visual issues that automation cannot judge.
The goal is not a perfect score. The goal is to publish a site that is reachable, understandable, indexable, shareable and maintainable.
Automated checks can confirm whether a public signal exists and looks technically reasonable. They cannot replace human review of content, accessibility, security, business logic or legal requirements.
Check a website