Website Launch Checklist: What to Test Before You Go Live

Before you announce a launch, verify that people can reach the site, key pages work on the production setup, important journeys succeed, and you can respond if something breaks. For Google Search eligibility, Google says a page must be accessible to Googlebot, return HTTP 200, and contain indexable content; meeting those conditions does not guarantee that Google will crawl or index it. Use the checklist below as a release gate, recording the result, owner, and fix for every failed check.

1. Define what is launching

Write down the launch scope before testing. Include the production domain and any subdomains, page types, forms, downloads, integrations, payment flows, and the time of the release. Mark which pages should be public, which should remain private, and which should be excluded from search. This prevents a successful homepage check from masking a broken product page or an accidentally public staging site.

List critical URLs: homepage, representative landing pages, content pages, product or service pages, contact pages, and error pages.
List critical journeys: account creation, sign-in, search, contact, checkout, booking, file download, or other actions the site supports.
Identify the production host, DNS changes, redirects, analytics or other integrations, and the person responsible for rollback or incident decisions.
Set a launch decision rule: unresolved failures in critical journeys, access, or data handling block the release; lower-priority cosmetic issues have an owner and follow-up date.

2. Check domain, HTTPS, and public access

Open the canonical production URL in a private browser window and confirm it loads without a login or staging password.
Test both the preferred hostname and common alternatives, such as www and non-www. Confirm each redirects to the intended canonical host and protocol.
Check that HTTP requests reach the HTTPS version and that the browser shows no certificate warning or mixed-content error. Google recommends HTTPS for site and user security.
Open a sample of important URLs directly, including a deep link. A route that works only after navigating from the homepage may fail on refresh or when shared.
Check the site from a network outside the office or VPN if access rules, firewalls, or allowlists could affect visitors.

Confirm DNS points to the intended environment and that the production site does not expose a temporary preview hostname as its primary link. If the website intentionally restricts some pages, document which audiences can access them and whether they should be indexed.

3. Test HTTP responses and search access

For pages intended to appear in search, check Google’s three technical requirements: Googlebot is not blocked, the page returns HTTP 200, and the page has indexable content. These are eligibility checks, not a promise of indexing.

Review robots.txt for accidental blocks of the site, important paths, CSS, or JavaScript resources needed to render pages.
Inspect page-level indexing controls, including robots meta directives and response headers. Make sure a staging noindex setting has not carried into production on pages that should be indexed.
Check that intended public pages do not require authentication. A page behind a login is not crawlable by Googlebot.
Use Google Search Console URL Inspection to test representative URLs. Use the Page Indexing and Crawl Stats reports to investigate site-level access or indexing issues.
Verify that canonical URLs point to the preferred production address and do not accidentally point to staging or another page.
Check that missing pages return a real not-found response rather than a misleading success page, and that redirects lead to relevant destinations.

Search engines may take time to crawl a new or changed site. Do not use immediate appearance in results as the only launch success criterion.

4. Review pages, content, and links

Check the launch-critical pages for missing content, placeholder copy, broken layout, incorrect prices or dates, and outdated contact information.
Follow navigation, footer, breadcrumb, and in-content links. Confirm internal links use the production domain and external links go to the intended destinations.
Check images, fonts, downloads, and embedded media on a few representative pages. Confirm assets load at their intended size and do not point to a private staging host.
Check page titles and descriptions for obvious template errors, duplication, or missing page identity where search presentation matters.
Verify that forms show useful success and error states and that submitted data reaches the intended inbox or system.

Automated screenshots can help compare important pages and catch missing sections or visual regressions. For repeatable checks, use the same viewport, URL, wait condition, and browser state before and after a change. A screenshot reveals visual output; it does not prove that a form submission, payment, or other backend action succeeded.

5. Test user journeys and integrations

Run each important journey from a clean session and, where applicable, from both desktop and mobile layouts. Use test accounts and payment sandboxes where available so launch checks do not create unintended real transactions.

Start at the page where a visitor would naturally enter, not only from an internal admin link.
Complete the full journey, including validation failures and recovery paths such as a forgotten password or a rejected form.
Confirm the expected confirmation appears and the relevant system receives the event: email, CRM, booking system, analytics, payment provider, or other integration.
Repeat once after signing out or clearing site data to catch session-dependent behavior.

Check integrations using their production configuration. A green indicator in a dashboard is not a substitute for completing the visitor-facing action. For payment, verify the intended currency, tax and shipping behavior where applicable, receipt flow, and cancellation or failure handling with the provider’s supported test process.

6. Check mobile, browser, and accessibility behavior

Review key pages at narrow and wide viewport sizes. Look for clipped content, horizontal scrolling, overlapping controls, and menus that cannot be opened or closed.
Try the main journeys in the browsers and devices your audience uses. Check touch targets, form fields, date pickers, file uploads, and sticky elements.
Navigate with a keyboard through menus, dialogs, forms, and primary actions. Check visible focus and that focus does not become trapped unexpectedly.
Check that images have appropriate alternative text where they convey information, form controls have understandable labels, and error messages identify what needs correction.
Review text contrast and zoom behavior. Treat this as a practical launch review, not a substitute for a site-specific accessibility audit.

7. Check performance and page rendering

Load representative high-value pages on production infrastructure, including one content-heavy page and one page with major interactive elements. Look for unusually slow loading, layout shifts, missing images, and scripts that prevent the main content from appearing.

Use Google PageSpeed Insights for individual page analysis and the Core Web Vitals report for site-wide reporting when available.
Check the first visit and a repeat visit, since caching can change what a visitor sees.
Inspect the page at typical mobile dimensions and on a slower connection when possible.
Confirm that consent banners, chat, and other overlays do not obscure the main call to action or make the page unusable.

Performance reports help identify issues; no particular score guarantees a search ranking or a good experience for every visitor. Fix the problems that block content or critical actions first, then prioritize measured bottlenecks.

8. Verify privacy, security, and operational readiness

Review privacy notices, consent behavior, security controls, and data handling against the requirements that apply to this specific site and audience. The right checks depend on what information the site collects and which services it uses; this checklist does not establish legal compliance or security assurance.

Confirm forms and integrations send data only to intended destinations and that production credentials are configured through the appropriate secure mechanism.
Check access to administrative and preview areas. Ensure temporary test accounts, sample data, and debug pages are not exposed unintentionally.
Know who receives alerts and who can change DNS, hosting, or application configuration during launch.
Identify how to restore the previous version or recover from a failed deployment. If restoration is part of your plan, rehearse it in an appropriate environment and record the result.

9. Plan a hosting move or infrastructure cutover

If launch includes a host or infrastructure change, test a copy of the site on the destination setup before changing production traffic. Google’s site-move guidance recommends creating a testing environment on the new infrastructure and reviewing pages, images, forms, and downloads in a browser before the move.

Copy the site and configure the destination environment to resemble production, including relevant redirects and integrations.
Review representative pages, images, forms, downloads, and the user journeys that depend on external services.
Check that production URLs, certificates, and host configuration are ready for cutover.
Record the current state and the rollback steps, then make the traffic or DNS change according to the release plan.
After cutover, repeat the critical URL and journey checks against the public domain.

Do not assume a site works on the destination host because its files copied successfully. Runtime configuration, permissions, environment variables, DNS, and integrations can differ.

10. Choose an ecommerce launch sequence

There is no single launch sequence for every store. Google describes several approaches; compare them by when the catalog becomes public, when Google can crawl it, and how closely the release lines up with marketing.

Approach	When it can fit	Trade-off to check
Reveal the whole site at once	The catalog and purchase journey are ready together.	All launch-critical pages and transactions need to be ready at the same time.
Launch the homepage first	You want a public starting point while the full catalog is still being prepared.	Product discovery and search visibility for unreleased pages wait until those pages are available.
Launch the full site with products unavailable	You want the catalog pages accessible before inventory or sales are ready.	Make availability clear and confirm the purchase path behaves as intended.
Soft-launch the full site	You want the complete experience public before a larger campaign.	Public access also means customers and crawlers can encounter it before the campaign date.

A password-protected grand reveal can delay when Google and customers can access the catalog. Pick the sequence that matches readiness and campaign needs, and verify the visibility and availability state of each product before launch.

11. Use screenshots to review production pages

A page screenshot is useful for checking what a visitor can see: missing images, unexpected overlays, layout differences, or a page that never reaches its expected state. It complements browser and functional checks; it cannot validate server responses, accessibility by itself, or a successful backend transaction.

DIY: capture a page with a browser

For a one-off visual check, open the production page in a browser, set the target viewport, wait until the main content is visible, and capture the viewport or full page. For repeatable checks, use a browser automation tool and pin its version and viewport in your project. The exact APIs vary by library, so consult its official documentation for installation and launch options. Add assertions for page readiness and expected content rather than treating the existence of an image as a pass.

Before the screenshot, decide whether the check should include consent banners, chat widgets, or newsletter prompts. For a visitor-experience audit, inspect them; for a clean page-layout comparison, close or account for them consistently. Keep authentication state and test data controlled, and avoid capturing sensitive information.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Send one GET request with the page URL to receive an image or PDF. Its cookie and consent handling accepts the banner like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, with the outcome described in response headers. AI agents can use its MCP server tools: take_screenshot, get_page_info, and capture_pdf.

The examples below save a WebP response. Replace YOUR_API_KEY and the sample URL with your values. See the ScreenshotNeo API documentation for request options and response details.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await require('node:fs/promises').writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo also supports full-page capture with lazy images loaded, element capture by CSS selector, dark mode, 12 device presets and custom viewports, retina scale, PDF options, custom CSS and JavaScript, clicking an element, hiding selectors, wait conditions, request and resource blocking, custom headers, cookies, user agent and authorization, timezone and geolocation, transparent backgrounds, image resizing, configurable caching, signed public image links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, a usage API, and an OpenAPI specification. Its parameter names also work with the names other screenshot APIs use, which can make switching easier. Clean successful captures are billed; only clean shots are billed and cache hits are free.

Plans include 1,000 screenshots per month free with no card; Starter is $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. Sign up for 1,000 free screenshots a month with no card.

12. Launch-day checklist and follow-up

[ ] The production domain resolves to the intended site and HTTPS works.
[ ] Critical public pages load directly and return the expected response.
[ ] Search access and indexing controls match the intended visibility.
[ ] Representative pages, assets, links, forms, and downloads work.
[ ] Critical journeys and integrations complete using production configuration.
[ ] Mobile layouts and the browsers important to your audience have been reviewed.
[ ] Performance and rendering issues that block content or actions have been addressed or assigned.
[ ] Privacy, security, and operational checks have an owner appropriate to the site.
[ ] The team knows who monitors launch and how to respond or roll back.
[ ] Post-cutover checks are scheduled, with a person responsible for each follow-up.

After release, revisit the critical URLs and journeys from the public domain. Watch the site’s own monitoring and the relevant Search Console reports for access or indexing problems. Keep a dated record of failures and fixes so the next deployment can focus on changes rather than repeat every check manually.

13. Troubleshooting common launch failures

Symptom	Likely cause	What to check or fix
Production page asks for a password	A staging access control remained enabled.	Review host or application access rules; remove the gate only if the page is intended to be public.
Google cannot access an intended page	A robots.txt rule, authentication wall, firewall, or indexing control blocks access.	Check the URL with Search Console URL Inspection, inspect robots.txt and page directives, and review access rules.
Important page is missing from search	It may not yet have been crawled or indexed, or it may fail a technical requirement.	Check public access, HTTP status, indexable content, canonical and indexing controls. Eligibility does not guarantee indexing.
A deep link fails while the homepage works	Routing or rewrite rules are incomplete on the production host.	Open the URL directly and on refresh; configure the host to serve the application route or return the intended not-found response.
Images or styles are missing	Asset URLs still point to staging, a resource is blocked, or a deployment omitted files.	Inspect failed network requests and asset paths, then correct the production base URL or deployment manifest.
Form appears to submit but no one receives it	Production integration credentials, destination, or email delivery configuration is wrong.	Submit a controlled test and verify the receiving system, logs, and error handling.
Site works on desktop but not mobile	A narrow layout, touch interaction, or mobile-specific script is broken.	Reproduce at the affected viewport and device; inspect overflow, navigation, and the affected form or control.
Redirect loop or wrong canonical host	Conflicting protocol, hostname, proxy, or application redirect rules.	Trace redirects from HTTP and both hostname variants; keep one canonical destination and align proxy and app configuration.
Screenshot shows a blank or incomplete page	The capture happened before rendering, access was blocked, or a required script failed.	Check the page manually, wait for a meaningful selector or network idle, and verify the target URL and access conditions.

14. Frequently asked questions

Does passing this checklist guarantee Google will index the site?

No. Google’s technical requirements define eligibility conditions; Google explicitly says meeting them does not mean a page will be indexed.

Should every page be public on launch day?

No. Make public the pages that are ready and intended for visitors. Keep private, draft, or future campaign pages restricted according to the launch plan, and ensure search controls match that choice.

Should I wait until every cosmetic issue is fixed?

Use impact to decide. Block on issues that prevent access, break a critical journey, expose unintended content, or make the site unusable. Track lower-impact polish with an owner and a follow-up date.

Can screenshots replace functional testing?

No. A screenshot records visible output at a moment. Complete forms, payments, downloads, and integrations directly to confirm their behavior.