Website launch checklist: what to check before you go live

This guide is for launching any site. If you are replacing an existing site and its addresses will change, the address map and redirects are covered in redesigning without losing search traffic, and this guide does not repeat them.

Say a landscape design firm launches a new fifteen-page site on a Friday afternoon. By Monday it has learned four things. The contact form still sends to the inbox of a person who left the company. The home page title still reads “Home”. Google Analytics was installed on the old site but never on the new template. And the test site's setting that hides it from search came across with the files, so Google was told to ignore the new site.

Each one is cheap to find before launch and slow to notice after, because a quiet inbox looks like a quiet month. A launch checklist exists to turn those into questions you ask while you can still change the answer.

Decide this before the last week. Write down what "done" means in one page: which pages must exist, which actions must work (an enquiry arrives, an order is paid, a booking is confirmed), and which standards the site is tested against. Name the person who can say "go" and the person who can say "stop".

When we launch a site, the checks run through a written list that belongs to the project, and before any go-live the site has been reviewed through nine lenses: functional, design and UX, code, accessibility, performance, SEO, content integrity, a definition-of-done rehearsal, and copy and media integrity. You do not need our list. You do need one list, with an owner for each line.

Choose the launch moment on purpose. Launch when the people who can fix a problem are available to do it, and not before a weekend nobody is watching.

Test as a visitor would, on the live address if you can, and not as an administrator.

• Forms. Fill in every form with real details and confirm the message arrives in the right inbox. Check the confirmation message the visitor sees, and whether the notification lands in a spam folder.
• Payments and bookings. Place a real test order or booking through to the end, and confirm what the customer receives and what you receive.
• Every menu item, button and link. Click through. A wrong destination looks like a design choice until a customer reaches it.
• Downloads and embedded tools: price lists, maps, booking widgets, video.
• The error page. An address that does not exist should show a helpful page and return a real “not found” status. Google flags a page that shows an error message but returns a normal success status as a soft 404, because the message and the status disagree.
• Different browsers and devices, including at least one phone running a different system from yours.

Search the whole site for placeholder text ("lorem ipsum", "your text here", "TBC"), for dummy names and for sample images. Then check the facts a visitor will act on: phone numbers, addresses, opening hours, prices, delivery terms and email addresses. A single wrong digit in a phone number is the most expensive typo on a website.

Check your legal and policy pages are present and say what is true of your business. We do not give legal advice, and the requirements depend on where you operate and what you sell, so ask someone qualified to confirm them.

Test sites are usually hidden from search on purpose, and the settings that hide them can survive the move to the live site. Check these on the live site, not the test copy:

• Public pages intended for search have no noindex rule or robots.txt block. A noindex rule tells search engines not to list a page. Google notes that robots.txt controls crawling, that it is not a way to keep a page out of search, and that a page blocked in robots.txt can never have its noindex seen, so check the two separately.
• Every page has its own title and description. Google advises a distinct, descriptive title on each page and warns against repeated boilerplate. It may rewrite titles and use its own snippets, so treat yours as the best suggestion you can make.
• Links are real links. Google discovers links only when they are <a> elements with an href. Menus built from clickable scripts may not be followed.
• The phone version has the same content. Google uses the mobile version for indexing, so anything missing on the phone is missing for search.
• Check each page's preferred canonical address. The preferred page should name itself; duplicate versions should name that preferred page. Use a full address rather than a relative one.
• A sitemap exists and is submitted in Search Console. It should list the canonical addresses you want indexed. Google calls submitting one “merely a hint”, so it helps and it guarantees nothing.

Our own pre-launch search checks are a longer list than this one, and part of why is that every page already has a written brief naming the search it owns. If you want the thinking behind that, see what SEO does for a business.

Open your most important pages on a real phone and use them. Can you read the text without zooming? Can you tap each button without hitting its neighbor? Does a form work with the on-screen keyboard open? We build to body text and form inputs at 16px or larger, and the reason is simple: smaller text is hard to read on a phone.

For speed, Google's Core Web Vitals give three targets: the main content within 2.5 seconds, a response to a tap within 200 milliseconds, and layout shift of 0.1 or less, measured at the 75th percentile of visits on mobile and desktop separately. There is a limit on what you can check before launch. web.dev explains that field data from real visitors gives the complete picture. A page-load-only lab test cannot measure Interaction to Next Paint (INP), because it includes no interactions; Chrome DevTools can measure local INP while you interact with the page. That controlled test helps diagnose problems, but does not establish the real-user result. So use a lab tool to catch obvious problems before launch, such as an oversized image, and plan to read real-visitor data in Search Console a few weeks after.

Our guide to why a website is slow goes further if the numbers disappoint.

The Web Content Accessibility Guidelines (WCAG) 2.2 are the current W3C recommendation, with levels A, AA and AAA; W3C encourages using the latest version. We build to Level AA. Before launch, run three checks that need no special software:

• Use the whole site with the keyboard only, using the Tab key, Shift plus Tab, Enter and Escape. Can you reach every link, menu and form? Can you see where you are?
• Read a page at a larger text size. Does anything overlap or disappear?
• Check that every image that carries information has a text description, and that every form field has a visible label.

An automated scanner finds some problems and misses others. Treat it as a first pass, not as a pass mark. Our guide to website accessibility for business owners covers more.

A launch with broken tracking looks like a launch with no visitors. Browse the live site and watch the Realtime report in Google Analytics. Google notes it can take up to 30 minutes for data to begin appearing in a new property. Then trigger each action you care about (a form, a click-to-call, a purchase) and confirm it is recorded. Also confirm that the site is verified in Search Console. A domain-level property needs verification by a DNS record, so whoever controls your domain settings has to be involved. Our guide to Google Analytics and Search Console explains what each tool shows.

These are the settings with the biggest consequences and the smallest margin for error.

• Who owns the domain and the accounts? Confirm the domain, hosting, analytics and Search Console accounts are in your name. Our guide to who owns your website explains what a handover should include.
• Lower the DNS TTL early. Google's guidance for a hosting move says to lower the DNS time-to-live value at least a week before the switch, to a conservative low value such as a few hours, so the change spreads to providers faster.
• Expect propagation. One platform, Shopify, says a connected domain usually updates within two hours and can take up to two days. Other hosts differ, so ask yours.
• Have a certificate ready. Google's guide to moving a site lists setting up an SSL certificate on the new site as part of the preparation, if the site uses HTTPS.
• Protect email. If your email runs on the same domain, write down the current mail settings before anything changes, and send and receive a test message after the switch. A website move that quietly breaks email is a common and avoidable launch problem.
• Keep the old hosting for now. Google advises shutting down the old setup only when traffic to it reaches zero.
• Expect a crawl dip. After a hosting change, Google notes it is normal to see a temporary drop in how often Googlebot crawls, followed by a steady increase over the next few days.

1. Take a backup or snapshot of the old site, and know how to restore it.
2. Freeze content changes, so nothing is edited during the switch.
3. Make the switch.
4. Check the live site against this guide: forms, key pages, tracking, search blocks.
5. Send a test email in both directions.
6. Tell people last: announce, update social links and email signatures only after step 4 passes.

If something fails and you cannot fix it quickly, a rollback you planned is better than a repair you improvise.

• Forms and orders, daily, with a test submission on the first day and again later in the week.
• Search Console, for pages Google cannot reach, using the Page indexing report.
• The error log or "not found" report, for addresses real visitors are hitting that do not work.
• Analytics, to confirm visits and actions keep being recorded.
• Your inbox and phone, for anyone reporting something broken. Customers find problems your checks missed.

Do not judge search performance in the first week. Google says some changes take effect in a few days and others take months. If traffic from search falls and you changed addresses, our guide to what to check when traffic drops after a redesign gives the order to work in.

It will not make a weak site strong, and it will not guarantee a result in search. A checklist also finds only what someone looks for, so have a person who did not build the site run through it. If your site is a Shopify store, the platform has its own settings (payments, shipping, taxes) that this guide does not cover, and our guide to moving to Shopify covers the search side.

• Write one page defining "done", with a named person who can say go or stop.
• Submit every form with real details and confirm it arrives in the right inbox.
• Complete a test order or booking from start to finish.
• Click every menu item, button and link.
• Check the error page shows a real "not found" status.
• Search the site for placeholder text and sample images.
• Verify phone numbers, addresses, hours, prices and email addresses.
• Check policy pages are present and accurate.
• Confirm public pages intended for search have no noindex rule or robots.txt block; preserve intentional exclusions.
• Check public pages intended for search have suitable titles and descriptions, and that preferred pages and duplicate versions identify the correct canonical address.
• Confirm links are real links, and phone content matches desktop.
• Prepare a sitemap and verify the site in Search Console.
• Use the site on a real phone, with the keyboard only, and at a larger text size.
• Test speed in a lab tool, and plan to read real-visitor data later.
• Confirm tracking records visits and key actions.
• Confirm the domain, hosting, analytics and Search Console accounts are in your name.
• Lower the DNS TTL at least a week ahead.
• Record the current email settings.
• Make a backup, and write down how to restore it.

If the new site replaces an old one, the next risk is in the move, and redesigning without losing search traffic covers it. After launch, the two tools you will rely on are explained in Google Analytics and Search Console. To see how a launch fits into a whole project, read how we run a project, where redirects, tracking and final checks are part of the launch and handover.

Google Search Central, “Block search indexing with noindex”: https://developers.google.com/search/docs/crawling-indexing/block-indexing

Google Search Central, “Introduction to robots.txt”: https://developers.google.com/search/docs/crawling-indexing/robots/intro

Google Search Central, “Influencing your title links in search results”: https://developers.google.com/search/docs/appearance/title-link

Google Search Central, “Understand the JavaScript SEO basics”: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

Google Search Central, “Mobile-first indexing best practices”: https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing

Google Search Central, “How to specify a canonical URL”: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls

Google Search Central, “Build and submit a sitemap”: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap

Google Search Central, “How HTTP status codes, and network and DNS errors affect Google Search” (soft 404): https://developers.google.com/search/docs/crawling-indexing/http-network-errors

Google Search Central, “Site moves without URL changes” (DNS TTL, crawl dip, shutting down old hosting): https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes

Google Search Central, “Site moves with URL changes” (SSL certificate in preparation): https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes

Google Search Central, “Debugging drops in Google Search traffic”: https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops

web.dev, “Web Vitals”: https://web.dev/articles/vitals

W3C Web Accessibility Initiative, “WCAG 2 Overview”: https://www.w3.org/WAI/standards-guidelines/wcag/

Google Analytics Help, “Verify data collection”: https://support.google.com/analytics/answer/9744165

Search Console Help, “Add a website property” (domain property, DNS verification): https://support.google.com/webmasters/answer/34592

Search Console Help, “Page indexing report”: https://support.google.com/webmasters/answer/7440203

Shopify Help Center, “Connecting a third-party domain” (propagation example): https://help.shopify.com/en/manual/domains/add-a-domain/connecting-domains