Website Launch Checklist: What to Check Before You Go Live

This website launch checklist covers the checks that matter for a basic small site, grouped into before launch, launch day, and the first 30 days. The checks that most often go wrong, in the launch threads cited on this page and in our own run, are a noindex tag or header left over from staging, a robots.txt that blocks the whole site, a contact form that never reaches an inbox, two hostnames that both answer without a redirect, and a domain or hosting login the owner does not hold. For each item the page says how to test it and what a pass looks like, including the exact curl commands, and it ends with a copyable template. We also ran the checklist on this site and report the results, including the failures. It is part of the website basics library.

Website checklist at a glance

Three phases, one table. Every row is explained in the sections that follow.

Website pre launch checklist

Before launch is about content and ownership, not code. These are the checks a site owner can do without a developer, and they are the ones people regret skipping. They come from a SitePoint thread about what a small-business owner should test before launching a site built with an AI builder, and from a dev.to checklist for WordPress launches.

Content and contact details

• Read every word. Generated or templated sites carry placeholder text, wrong opening hours, and claims nobody checked. One reply in the SitePoint thread suggests the owner search their own business name and phone number to catch "placeholder details or wrong opening hours".
• Test every contact detail. Call the phone number from the page. Send an email to the address shown. Tap the map link on a phone. Pass is a human at the business receiving each one.
• Check hours, prices, and names against the source. Compare the site with the sign on the door, the menu, or the price list, not with memory.

Ownership

• The owner holds the domain, hosting, and billing logins. If the site was built by someone else, the owner should be able to sign in to the domain registrar, the hosting account, and the payment method on file. One SitePoint reply would put this first on the checklist: if the owner does not hold "the domain and billing login, a handover gets painful fast."
• The owner can change one small thing. Before launch, change a phone number or a price together and confirm it appears on the live site. If that needs the builder, the handover is not finished.
• A backup exists outside the hosting account. The dev.to checklist says it plainly: do not keep your only backup on the same hosting account. Download the files and any database export and store a dated copy somewhere else. For a static website, the backup is the folder itself.

Legal pages

• Privacy policy linked in the footer. Most small sites collect something, even if only form submissions and analytics, and a privacy page is the normal way to explain what and why. A terms page matters once you sell or take bookings. This is not legal advice. What your site must say depends on where you and your visitors are, so check the rules that apply to you.

Forms, phones, links, and images

• Submit the form and find the message. Send a real test enquiry, then look in the inbox and in the spam folder. Pass is the message arriving where the owner actually reads mail, not in a mailbox nobody checks.
• Open the site on a phone with wifi off. A SitePoint reply recommends "a real purchase or enquiry from a different phone on mobile data, not wifi", because forms, cookie banners, and booking widgets that work in a desktop preview can break on a real device.
• Click every link. Menus, footer, buttons, and in-text links. Watch for links that still point at a staging or preview address.
• Check image sizes. The same thread names the check that gets missed most often as mobile speed, with builders producing sites that have "massive, uncompressed images that take ten seconds to load on a phone". Resize images to the width they are displayed at before uploading.

New website launch checklist for launch day

Launch day is technical: can search engines and browsers reach the site, and does the site answer consistently? Each check below has a command you can run from a terminal. Replace example.com with your domain. curl is a command-line tool for making web requests; the -I flag asks for the response headers only, and -s keeps the progress output quiet.

No stray noindex, in the meta tag and in the header

A noindex rule tells search engines not to list the page. Google's documentation on blocking indexing with noindex describes it as a rule set with either a <meta> tag or an HTTP response header, so you have to check both places. Staging environments often set the header version, which does not appear in "view source". Check the HTML:

curl -s https://example.com/ | grep -i "robots"

Pass is no <meta name="robots" content="noindex"> line (a robots meta tag with index, follow is fine). Then check the header:

curl -sI https://example.com/ | grep -i x-robots-tag

Pass is empty output, or a header that does not contain noindex. Google's robots meta tag and X-Robots-Tag documentation confirms that any rule that works in the meta tag can also be set as an X-Robots-Tag response header, and MDN's X-Robots-Tag page explains the header the same way. Repeat both checks on a few inner pages, not just the homepage.

One site builder exposed this problem in a Figma forum thread: the site was live, nothing was indexed, and the cause was an "Exclude from search engine results" setting that had been switched on. Builders hide the noindex behind a checkbox, so look for that checkbox.

robots.txt does not block the site

curl -s https://example.com/robots.txt

Pass is a 200 response with no Disallow: / line under User-agent: * (a line that disallows a specific path such as /search/ is fine). Google's introduction to robots.txt is clear that the file "tells search engine crawlers which URLs the crawler can access on your site" and "is not a mechanism for keeping a web page out of Google". So robots.txt should not be used to hide pages, and it should never accidentally hide everything.

sitemap.xml exists and is referenced from robots.txt

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/sitemap.xml

Pass is 200, and a Sitemap: https://example.com/sitemap.xml line in robots.txt. Google's sitemap overview says you might need a sitemap when "your site is new and has few external links to it", because crawlers find pages by following links from pages they already know. A new site has no such links yet, which is exactly the launch situation. The same Figma thread above began with sitemap.xml and robots.txt both returning "Not Found" after publishing. How the pages in that sitemap should be organized is covered in website structure examples.

One hostname, HTTPS everywhere

curl -sIL http://example.com/

The -L flag follows redirects and prints every hop. Pass is a chain of 301 responses that ends with a single 200 at your chosen hostname over https://, for example http://example.com/ to https://www.example.com/. Run it four times: http:// and https://, with and without www. All four should end at the same URL. If www and non-www both answer 200, pick one and redirect the other. Google's documentation on canonical URLs recommends linking consistently to the URL you consider canonical. What the protocol and hostname parts of an address mean is explained in website URL examples, and what visitors see when the HTTPS half is missing is shown in the not secure website example.

A real 404 status for pages that do not exist

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/does-not-exist/

Pass is 404. A "page not found" message delivered with a 200 status is a soft 404. Google's HTTP status code documentation says that when a 2xx response "suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error". The custom 404 page can be as friendly as you like, as long as the status code is honest.

Title, meta description, and canonical on every page

curl -s https://example.com/ | grep -i -E "<title>|name=\"description\"|rel=\"canonical\""

Pass is one <title>, one meta description, and one canonical link, each specific to the page. Google's title link documentation asks for "descriptive and concise" title text and warns against "repeated or boilerplate text" across pages, and its snippet documentation has a section titled "Create unique descriptions for each page on your site". The canonical should be an absolute URL that matches the hostname you chose above. For patterns, see website title examples.

Favicon and share preview

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/favicon.ico

Pass is 200 for whatever icon file your <link rel="icon"> tag points to. Google's favicon documentation requires a link tag on the homepage and a crawlable icon file, square, and recommends larger than 48 by 48 pixels. Also request /favicon.ico and /apple-touch-icon.png directly, because clients that ignore the link tag ask for those paths, and a 404 there is easy to miss (ours did, see below).

For the share preview, check the Open Graph tags:

curl -s https://example.com/ | grep -i "og:"

Pass is og:title, og:type, og:url, and og:image, the four properties the Open Graph protocol lists as required. Without og:image, a link shared in a chat app or on social media shows text only. Then paste the URL into a messaging app and confirm the preview card shows the image you expect.

Analytics and Search Console

• Analytics receives a visit. Open the live site, then open the real-time report in your analytics tool. Pass is your own visit appearing. If it does not, the tag is on the staging site but not the live one, or a consent banner is blocking it.
• Search Console is verified and the sitemap is submitted. Add the property for your chosen hostname, verify it, and submit the sitemap through the Sitemaps report. Google's sitemap submission guide says this "will allow you to see when Googlebot accessed the sitemap and also potential processing errors". Pass is the sitemap listed with a success status. Do this on launch day, not later. On this site the sitemap had never been submitted when we checked in November, and the effect is in the results table below.

First 30 days after launch

The month after launch is when you find out whether search engines picked up the site and whether the plumbing still works. Set a reminder for one week and for one month.

1. Inspect a few URLs in Search Console. The URL Inspection tool, as Google describes it, "provides detailed crawl, index, and serving information about your pages, directly from the Google index". A status of "URL is unknown to Google" means Google has not seen the page yet. Run the live test, check that the page is available, and request indexing. This is what one Reddit poster was asking when they wanted to know "how do I check that Google can crawl and index everything", and the replies pointed to exactly this tool.
2. Open the sitemap's page indexing report. From the Sitemaps report, open the page indexing view for your sitemap. Google's Search Console getting started guide describes this report as "an overview of all the pages Google indexed or tried to index in your website", and says submitting a sitemap "might speed up your site's discovery". "Discovered - currently not indexed" means the page was found but not crawled yet, which is normal in the first weeks. Errors are not normal, so read each one.
3. Repeat the link check. New pages, edited menus, and renamed files break links after launch. Pass is the same as before: no dead links.
4. Submit the form again. Mail providers change spam rules, and form plugins update. Pass is the message arriving in the same inbox as before.
5. Confirm a backup dated after launch exists. If the host runs backups, download one. If not, make one. Pass is a copy you can restore from, stored off the host.
6. Name who handles updates. Software updates, content changes, and renewals need an owner and a cadence. The website maintenance plan example is a copyable schedule for exactly that.

If you are reviewing a site that has been live for a while rather than launching one, the website audit report example covers the same ground in report form.

We ran this checklist on our own site

Here is how www.basicwebsiteexample.com scored on 2026-11-10, with every technical row re-checked with curl from a server the same morning. We publish the failures too, because that is the point of a checklist. This page only reports them. The fixes are listed, not applied.

Two lessons from our own run. First, a site can pass every on-page check and still have nobody tell Google it exists. Second, the two failures are the kind that no visitor reports: a missing share image and missing headers do not break the site, they just quietly cost you.

Website launch checklist template

Copy this into a text file or a task manager and tick the boxes as you go. Replace example.com with your domain.

# Website launch checklist for example.com

## Before launch
- [ ] Every page read in full; no placeholder text, wrong hours, or unchecked claims
- [ ] Phone number called, email address tested, map link opened
- [ ] Owner can sign in to the domain registrar, hosting, billing, and the site
- [ ] Owner has changed one small thing (phone number or price) and seen it live
- [ ] Privacy page linked in the footer (terms page if selling or booking)
- [ ] Backup of files and database downloaded and stored off the host
- [ ] Contact form submitted; message found in the inbox or spam folder
- [ ] Site opened on a phone with wifi off; menu, links, form, buttons work
- [ ] Every link clicked; no links to a staging or preview address
- [ ] Largest images resized to display width

## Launch day
- [ ] curl -s https://example.com/ | grep -i robots     -> no noindex
- [ ] curl -sI https://example.com/ | grep -i x-robots-tag  -> empty or no noindex
- [ ] curl -s https://example.com/robots.txt            -> 200, no "Disallow: /"
- [ ] curl -s -o /dev/null -w "%{http_code}" https://example.com/sitemap.xml -> 200
- [ ] robots.txt has a Sitemap: line
- [ ] curl -sIL http://example.com/                     -> 301s ending at one https URL
- [ ] Same test for https://, http://www., https://www. -> all end at the same URL
- [ ] curl -s -o /dev/null -w "%{http_code}" https://example.com/does-not-exist/ -> 404
- [ ] Unique <title>, meta description, and canonical on every page
- [ ] curl -s -o /dev/null -w "%{http_code}" https://example.com/favicon.ico -> 200
- [ ] og:title, og:type, og:url, og:image present; preview checked in a chat app
- [ ] Analytics real-time report shows your own visit
- [ ] Search Console property verified
- [ ] Sitemap submitted in Search Console

## First 30 days
- [ ] URL Inspection run on the homepage and three inner pages
- [ ] Sitemap page indexing report read; errors fixed
- [ ] Link check repeated
- [ ] Form submitted again; message arrived
- [ ] Backup dated after launch exists off the host
- [ ] Name and cadence written down for updates

FAQ

Where to go next

Now that the site is live, the website maintenance plan example gives you the schedule for keeping it that way, and the website audit report example is the format for a fuller review a few months in. If you are still deciding how to build, the static website example shows the simplest kind of site this checklist applies to.