Website Launch Checklist: What to Check Before You Go Live

The Short Version

Most launch checklists are a flat list of fifty items, which is the wrong shape for the problem. The checks are not equally urgent and they do not belong in the same week.

Three groups matter:

1. Steps that run on someone else's clock — domain access, DNS, certificates, Google Business Profile. Start these two weeks out. They cannot be compressed on launch morning.
2. Checks that fail silently — an indexing block, a canonical pointing at staging, two hostnames resolving at once. The site looks perfect and is invisible or duplicated. These are the expensive ones.
3. Checks a visitor would catch in ten seconds — a form that does not deliver, a phone number that is not tappable, placeholder text on the about page. Embarrassing, but cheap to fix once found.

If you are replacing a site that already ranks, you need the website migration SEO checklist as well as this page — a replacement adds a URL inventory and a redirect map, and skipping those is how a redesign loses traffic it had already earned. This page is for a first launch, where there is nothing to preserve and everything to set up.

Two Weeks Out: The Steps That Run on Someone Else's Clock

Almost nothing in this table is work. It is mostly waiting, which is exactly why it has to start early.

The Checks That Fail Silently

This is the group worth being systematic about, because none of these announce themselves. The site looks finished.

1. Remove the staging indexing block. Search the codebase for noindex and read the production robots.txt in a browser. Build-time environment flags are the usual culprit — a rule written to keep the preview hostname out of search that was never scoped to exclude production. Google's documentation on blocking indexing is worth two minutes if you are not sure what you are looking at.
2. Check the canonical tags on the live domain. View source on three pages and confirm each rel="canonical" points at the live URL, not the staging host and not the homepage. A canonical pointing somewhere else is an instruction to Google to index the other page instead of this one.
3. Make one hostname win. http://, https://, www. and the bare domain should all end at a single canonical address with a 301. Four addresses serving the same content is the most common self-inflicted duplicate-content problem there is.
4. Confirm the 404 page returns a 404. Visit a URL that does not exist. A "page not found" design that returns a 200 status is a soft 404, and a site full of them reads to Google as a site full of thin pages.
5. Submit a sitemap that lists only indexable URLs. It should exclude anything noindexed, redirected or behind a login. A sitemap can hold 50,000 URLs or 50MB uncompressed, so a small business site will never need more than one.
6. Click the internal links on the live site. Hard-coded staging URLs survive a surprising number of reviews, and they are invisible until someone clicks one.
7. Check your image bytes. Oversized images are the most common cause of a slow first impression on a phone. Heroes under about 300KB and inline images under about 150KB is the standard we hold our own builds to, and every image needs explicit width and height so the page does not jump around while it loads.

Content and Metadata

Faster to check, and genuinely worth the pass.

• A unique title and description on every page. Google may rewrite the title it displays if yours is vague or keyword-stuffed, so write the one you actually want shown.
• One H1 per page, and it should say what the page is about rather than greet the visitor.
• Validate your structured data in Google's Rich Results Test. If the site ships Organization, LocalBusiness, Article or FAQ markup, confirm it parses and that the details inside it match what the page says — the rule that disqualifies markup is claiming something the page does not show, which is covered in schema markup for small business.
• Grep for placeholder text. lorem, TODO, the template's demo business name, "Your Company Here". If any copy was ported from an older site, also scan for run-together words where paragraphs were pasted — a search for a lowercase letter immediately followed by a capital catches most of them.
• Alt text on every meaningful image, and a contrast check on body text. WCAG 2.1 asks for a 4.5:1 contrast ratio on normal text and 3:1 on large text — the usual failures are gray-on-white captions and white text sitting over a photograph.
• A favicon and a social share image. Paste the homepage URL into any chat app and look at what comes back.

Forms, Email and the Phone Number

The checks nobody writes down, and the ones a lost lead comes from.

• Submit every form from an outside email address, not from the office network, and confirm the message arrives and is not in spam. Check again the day after DNS moves, because form email and website hosting often travel on different records.
• Confirm the reply-to address is an inbox somebody opens. A contact form that delivers to an unmonitored address is worse than no form at all, because it looks like it worked.
• Tap the phone number on a real phone. It should be a tel: link, and the number should match the one on your Google Business Profile exactly.
• Check the name, address and phone on the site against the Business Profile, character for character. Local search leans on that consistency, and the mismatch is usually an old suite number nobody remembered.
• Decide whether the person submitting the form gets a confirmation. Either answer is defensible; silence after a form submit is what makes people go call a competitor.

Launch Day, In Order

1. Take a final backup of whatever the new site is replacing, even if it is a one-page holding site. Keep it for a year.
2. Deploy to production while the live domain still points elsewhere, and click through the site on the production hostname.
3. Point DNS. Then wait for it, and resist the urge to keep re-checking from the one computer whose cache you have already poisoned.
4. Confirm the certificate is valid on the live hostname — the padlock, and no mixed-content warnings in the browser console.
5. Remove the indexing block. Separate step, separate line, because this is the one that gets missed.
6. Verify the property in Search Console and submit the sitemap.
7. Verify in Bing Webmaster Tools and submit there too. Bing supports IndexNow, which pushes new URLs rather than waiting to be crawled.
8. Run the homepage and three or four of your most important pages through URL Inspection, and request indexing on each.
9. Test the forms and the phone number from a phone on cellular data, not office wifi.
10. Turn on uptime monitoring. Hearing about downtime from a customer is a bad way to hear about it.

The First 30 Days

• Read the Pages report in Search Console weekly. You are looking for pages in the not-indexed group and the reason given for each. "Excluded by noindex" means step five did not take. "Discovered — currently not indexed" on a new site usually just means patience.
• Field performance data takes 28 days to exist. The Chrome User Experience Report that feeds Core Web Vitals in Search Console works on a rolling 28-day window, so a brand-new site has no field data at all for its first month. Lighthouse gives you a lab score immediately; treat that as a smoke test and judge the real numbers at day 30. The targets are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS, each at the 75th percentile of real visits — the detail is in our guide to Core Web Vitals for small business.
• Confirm your analytics events are firing, not just that pageviews are arriving. Submit your own form and check that the event lands.
• Do not rewrite your titles in the first month. Rankings on a new site are unsettled by definition, and changing the pages while they settle means you learn nothing from either version.
• Start publishing. A site that launches and then sits still stops earning new queries, which is the whole argument for a content cadence after launch rather than a one-time build. Scheduled updates and recurring content are what our website automation work exists to handle.

If You Are Launching an App or a Portal Too

A logged-in surface fails differently from a marketing site, and two checks belong to it specifically.

The first is indexing in reverse. An authenticated app should be disallowed in robots.txt and should not ship a sitemap or an llms.txt at all. The goal there is to be absent from search, not present in it.

The second is the database. A deploy succeeding does not mean the production database has the columns the new code expects, and that failure mode is ugly — the deploy reports healthy while every page returns a server error on first load. If your launch includes a schema change, running the migration against the production database has to be a deliberate, named step rather than something assumed to ride along with the deploy. We treat it as an explicit handoff on every custom business software and client portal launch for exactly that reason.

What We Check on Every Build

For the sake of being checkable, our own gates.

Every site we launch ships JSON-LD structured data, a generated sitemap, a robots.txt with explicit rules for the AI crawlers, and llms.txt plus llms-full.txt so AI search tools have a clean summary to read — the reasoning behind those last two is in our post on llms.txt and AI crawlers. After the deploy we run PageSpeed Insights three times per page on both mobile and desktop, and hold the build to a median CLS under 0.1, an LCP under 2.5 seconds and a performance score of at least 80 before we call anything launched. Search Console and Bing Webmaster Tools are both verified and submitted as part of the launch rather than as a follow-up task.

Builds run one to two weeks instead of the four to sixteen that is normal in this industry, which is mostly a function of there being no queue between the person selling and the person building. The build is $1,500 and the monthly plans start at $20, with 30 days' notice to cancel. The site, the content and the domain are yours — a distinction worth settling before you sign anything with anyone, and one we wrote up separately in do you own your website.

If You Only Do One Thing Today

Open yourdomain.com/robots.txt in a browser, then run your homepage through URL Inspection in Search Console.

Two minutes, no login you do not already have, and between them they catch the one launch failure that is both the most common and the most expensive: a finished site that search engines have been politely instructed to ignore.