Website Launch Checklist: 20 Checks Before You Go Live
A new website can look finished and still fail the moment a real visitor uses it. A quote form sends nowhere. A staging setting keeps every page out of Google. The mobile menu covers the booking button. A website launch checklist catches those quiet failures before they cost you traffic, trust, or leads. This guide gives business owners, marketers, and developers a practical 20-point review for the final days before go-live. Each check has a clear pass condition, so the launch decision is based on evidence rather than whether the home page looks ready.
The short version
Test the complete customer journey on the real domain and a real phone. Confirm that search engines can crawl the right pages, every lead reaches the right person, analytics records the action, and a rollback is ready. A site is launch-ready only when its important paths work from first visit through confirmation and follow-up.
What a website launch checklist is really for
Launch QA is not a last look for typos. It is a controlled attempt to break the site before customers do. The visual review matters, but it sits beside technical checks, search visibility, accessibility, lead routing, legal accuracy, and measurement. If any one of those systems fails, the site can appear healthy while producing no useful result.
Give every check an owner and a simple status: pass, fail, or blocked. Record the page, device, and steps needed to reproduce each failure. That turns a vague launch discussion into a short queue of verifiable fixes. It also creates a reusable acceptance test for later redesigns, platform migrations, and major feature releases.
Organize the launch into four passes
Running checks in passes makes ownership clear and keeps obvious content defects from hiding deeper technical problems.
Content and trust
Verify offers, names, contact details, policies, claims, reviews, photos, and calls to action. Read each important page as a customer who has never heard of the business.
Experience and accessibility
Use real phones, a keyboard, and multiple browsers. Check that layouts, menus, forms, contrast, focus, and media still work outside the ideal desktop setup used during design.
Search and measurement
Inspect titles, headings, canonicals, indexing rules, structured data, the sitemap, analytics, and conversion events. Confirm what search engines and reporting tools receive, not just what users see.
Operations and recovery
Test notifications, ownership, monitoring, backups, and rollback. The team should know who responds when a customer or automated alert finds a problem after launch.
The 20-point website launch checklist
Run this table against the production build. A preview URL is useful for early review, but DNS, HTTPS, redirects, analytics, forms, and search controls can behave differently on the live domain.
| No. | Check | Pass condition |
|---|---|---|
| 01 | Domain, DNS, and HTTPS | The preferred domain loads securely, redirects are correct, and there are no certificate warnings. |
| 02 | Production content | No placeholder copy, test accounts, draft labels, or sample images remain on public pages. |
| 03 | Essential pages | Home, service or product, about, contact, and required policy pages are published and accurate. |
| 04 | Navigation and 404 page | Menus work on every screen size, every key page is reachable, and invalid URLs show a useful 404 page. |
| 05 | Mobile layout | Text, buttons, forms, tables, and menus work without clipping or horizontal scrolling on real phones. |
| 06 | Browser coverage | Core pages and actions work in current Chrome, Safari, Firefox, and Edge browsers. |
| 07 | Images and media | Images are compressed, correctly sized, described with useful alt text, and do not shift the layout while loading. |
| 08 | Accessibility basics | Keyboard navigation, focus states, labels, headings, and color contrast all pass a manual review. |
| 09 | Forms and validation | Every form accepts valid input, explains errors clearly, blocks obvious spam, and delivers the submission. |
| 10 | Confirmations and notifications | Visitors see a clear success state, and the correct team member receives a useful notification. |
| 11 | Calls, email, and buttons | Phone, email, map, social, download, and call-to-action links open the intended destination. |
| 12 | Chat and booking flow | Chat, calendar availability, time zones, reminders, and human handoffs work from start to finish. |
| 13 | Titles and descriptions | Every indexable page has a unique, accurate title and meta description that match its search intent. |
| 14 | Headings and on-page copy | Each page has one clear main heading, logical subheadings, useful copy, and no accidental keyword stuffing. |
| 15 | Canonicals and indexing | Canonical URLs point to the preferred pages, and no staging noindex rule blocks the live site. |
| 16 | Sitemap and robots rules | The XML sitemap lists preferred public URLs, and robots.txt does not block pages or assets needed for search. |
| 17 | Analytics and conversions | Analytics records real visits, while form, call, chat, purchase, or booking events fire only when completed. |
| 18 | Performance | Key pages load quickly on a typical mobile connection, with no oversized media or unnecessary blocking scripts. |
| 19 | Privacy and trust | Policies, consent choices, business details, claims, reviews, and third-party assets are accurate and authorized. |
| 20 | Backup and monitoring | A restorable backup or rollback exists, uptime checks are active, and one person owns launch-day issues. |
Test the customer journey, not just the page
A form that displays correctly has not passed. Submit it with valid and invalid data. Confirm the success message. Check the notification from the perspective of the person who must reply. Make sure the lead source, page, message, and contact details arrive intact. Then reply and verify that the customer receives it. Use an address and phone number that are not tied to an administrator account, because permissions can hide real delivery problems.
Repeat the same end-to-end test for click-to-call buttons, email links, live chat, checkout, downloads, and appointment scheduling. If Intellure will answer website questions or book appointments, include it in the production test: ask a common question, an unusual question, and one that should reach a human. The reply, calendar entry, confirmation, and handoff all need to land in the right place.
Use one test lead to verify the entire chain:
- Arrive from a trackable campaign or search link.
- Complete the main inquiry or booking action on a phone.
- Confirm the visitor message and internal notification.
- Verify the analytics event and lead source.
- Complete the reply, handoff, or appointment confirmation.
Make the site findable from day one
Search readiness starts with intent. Each important page should answer a distinct question and use a title, main heading, description, and body copy that agree on that purpose. Unique titles are useful because they help search engines and people distinguish one service page from another. A meta tag generator can speed up drafting, but the final text still needs to match what the page actually delivers.
Next, inspect the technical signals on the live URL. Confirm the canonical address, status code, robots rules, and index setting. Publish an XML sitemap containing only preferred public pages, add the property to Search Console, and submit the sitemap. Do not assume a green page in the browser means Google can index it. A staging-wide noindex tag copied into production can make an otherwise polished launch invisible.
Internal links matter too. Every service or product page should be reachable through normal navigation or contextual links, without relying on the sitemap alone. Check old URLs before a redesign goes live and map valuable ones to the closest relevant new page. Redirecting everything to the home page creates a poor experience and discards useful context.
Do not ship accessibility and speed bugs
Automated audits catch missing labels, weak color contrast, oversized images, and some structural mistakes. They do not replace manual use. Navigate the header, menu, forms, modal windows, and footer with only a keyboard. Zoom the page. Trigger every error state. Check that focus is visible and moves in a sensible order. A color contrast checker is a fast companion, but the final test is whether the interface remains understandable in context.
For performance, begin with the pages that attract traffic or capture leads. Compress and size images for where they appear, avoid loading heavy media before it is needed, and remove scripts that serve no clear business purpose. Test on a normal phone connection instead of relying only on a fast office network. The goal is not a perfect score. It is a stable page that becomes useful quickly and responds without frustrating delays.
A practical launch timeline
Several days before launch, freeze major layout changes and run all 20 checks on the release candidate. Fix anything that affects security, accuracy, accessibility, search visibility, lead capture, or recovery. Record lower-risk polish items for a later release so they do not create new launch-day defects.
On launch day, verify DNS and HTTPS first, then repeat the highest-value customer journey on the production domain. Check analytics, indexing controls, redirects, and monitoring. If Intellure is part of the lead flow, send a fresh conversation through website chat and confirm that the same lead can continue on the connected channels without losing context.
During the first week, review real behavior every day. Look for form starts without submissions, visits to missing pages, failed bookings, mobile exits, unanswered conversations, and traffic that is missing from reporting. Intellure can cover immediate answers and follow-up around the clock, but the team should still review early conversations for new questions that the launch research did not anticipate.
Common website launch mistakes
Testing only while logged in
Administrator sessions can bypass consent prompts, caching, permissions, and customer-only errors. Always run a final pass in a private window with an ordinary visitor account.
Treating mobile as a resized desktop
A responsive preview cannot reproduce every real keyboard, browser bar, tap target, or network condition. Test priority journeys on physical phones before approving them.
Confirming the click but not the outcome
A button opening is only the first step. The form must deliver, the calendar must reserve the right slot, and a person or system must complete the response.
Launching without a recovery owner
Monitoring is useful only when an alert reaches someone who can act. Name the decision-maker, document rollback steps, and define which failures justify using them.
Frequently asked questions
When should I start using a website launch checklist?+
What are the most important checks before launching a website?+
Should I wait until every page is perfect before going live?+
How do I tell Google that a new website is live?+
What should I monitor after a website launch?+
The bottom line
A successful launch is not the moment a page becomes public. It is the moment a visitor can find the right page, understand it, take action, and receive the promised response without a hidden break in the chain. The checklist protects that path. Once the site is live, an Intellure AI employee can keep the last mile working by answering customers, following up with leads, and booking appointments while the team focuses on improving the business behind the site.