Website launch checklist for developers

A website launch checklist should follow the path a first-time visitor takes: open the public URL, understand the page, complete its main task, and return later without losing the route. It should also leave enough evidence for another developer to reproduce the checks after release.

Use this checklist for a public marketing page, documentation site, portfolio, or student project. It is intentionally about the deployed website, not only the local build. A green build can still ship a wrong redirect, missing canonical, broken form, inaccessible control, or mobile layout that blocks the first task.

Set the release contract first

Write these values in the release issue before checking individual pages:

• The production hostname and preferred protocol: normally one HTTPS URL.
• The representative URLs that must work, including the homepage, pricing or signup path, documentation, contact, and any campaign landing page.
• The primary visitor task for each URL and its expected destination or success state.
• The release identifier, deployment time, owner, rollback method, and support contact.
• The browsers, mobile width, and network conditions that make up the minimum manual pass.

This contract prevents “the site is live” from becoming an untestable statement. It also gives regression checks a reviewed baseline. The website regression testing checklist explains how to preserve the same URLs and expectations after later releases.

1. Confirm DNS, HTTPS, and redirects

Start with the URL people will actually receive, not a preview hostname or a logged-in browser tab.

• Confirm DNS points to the intended production service and that the certificate covers the public hostname.
• Request the HTTP, www, non-www, trailing-slash, and known legacy paths you support.
• Make each variant redirect directly to the chosen HTTPS canonical URL with one permanent redirect.
• Preserve meaningful paths and query parameters used by campaigns; do not send every old page to the homepage.
• Confirm the final response is the expected status and content type, not an HTML error page with a 200 status.
• Check that internal links, canonical tags, Open Graph URLs, and the sitemap use the same URL convention.

Use curl or a redirect-aware browser and record the complete response chain. Google's canonical URL guidance describes how redirects, canonical links, and consistent internal references reinforce one preferred page version. The companion canonical URL and redirects guide has a focused implementation example.

2. Check crawl controls and search metadata

Inspect the rendered HTML and response headers for every representative public page:

• A unique, descriptive <title> that matches the visible page subject.
• A useful meta description that explains the audience and outcome without a keyword list.
• One clear <h1> and a logical heading outline.
• A self-referencing canonical URL that matches the final public URL.
• An intentional robots policy. Remove accidental noindex values from pages meant to be found.
• Open Graph title, description, URL, and image values that describe the page when shared.
• A valid language declaration and a meaningful favicon.
• robots.txt at the origin root that does not block the page or its required assets.
• A sitemap containing stable canonical URLs, not preview routes, redirects, or private application screens.

robots.txt and a sitemap have different jobs: one controls crawler access while the other helps discovery. Keep them aligned and check the actual response, not only a source template. Google's robots.txt documentation and sitemap guidance are useful references. The robots.txt versus sitemap.xml guide shows a practical comparison.

3. Read the first screen as a visitor

Before checking details, ask a new visitor to answer these questions without explanation:

1. What is this page or product?
2. Who is it for?
3. What can I do next?

The opening heading and paragraph should answer the first two. The primary action should name its outcome, such as “Start a free audit” or “Download the template,” instead of relying on a vague “Get started.” Check that the destination explains what happens next and that the page does not make a claim the rest of the site cannot support.

Review visible proof, pricing or plan facts, support links, ownership information, privacy links, and any limits that affect the decision. The website content audit checklist covers placeholders, generic claims, proof paths, and language that should be resolved before publishing.

4. Test the mobile task and accessibility basics

Use a narrow viewport before polishing desktop spacing. At minimum, check the primary page at a representative phone width and repeat the main task:

• Navigation opens, closes, and remains usable with a keyboard.
• No text, cards, controls, or forms cause horizontal scrolling.
• Fixed headers, banners, and dialogs do not cover the main action.
• Focus is visible and moves in a sensible order.
• Buttons and links have names that describe their result.
• Inputs have associated labels, useful types, and understandable error messages.
• Images have appropriate alternative text, or are marked decorative when they add no information.
• Text remains readable when zoomed and does not depend on color alone.

Automated rules are evidence, not a complete accessibility review. The accessibility checks before launch and mobile website testing routine cover the manual states that a single page load cannot prove. W3C's Web Content Accessibility Guidelines provide the normative reference for teams that need a formal accessibility process.

5. Exercise forms and critical actions

Click every action that appears important in the release contract. For each form or workflow, check:

• The action has a specific accessible name and a real destination.
• Required fields, invalid values, and server errors are announced clearly.
• The submit control shows a pending state and prevents accidental duplicate submissions.
• Success and failure states are visible without relying on a console message.
• Back, refresh, and retry behavior do not lose the user's work unexpectedly.
• The confirmation or next page has a canonical URL and useful title.
• Analytics events fire once with the intended name and do not include secrets or sensitive form values.

The website form testing checklist covers validation and recovery states. Keep an integration or end-to-end test for business logic; a public URL audit can observe the page and the first task, but it cannot prove payment settlement or every backend branch.

6. Verify security and production headers

Review the response headers on the final HTTPS route and important static assets:

• Strict transport security after all intended subdomains are HTTPS-ready.
• A reviewed Content Security Policy appropriate for the scripts, styles, images, fonts, and frames the page uses.
• X-Content-Type-Options: nosniff.
• A deliberate Referrer-Policy.
• Frame protection or an equivalent CSP frame-ancestors policy.
• Cache controls that do not expose private responses or serve stale release-critical HTML. Use the Cache-Control header testing guide to separate HTML and asset policies and verify returning-browser behavior.

A present header is not proof that its policy is safe. Review the actual directive values and test the routes that matter. Use the website security headers checklist for a focused pass.

7. Check performance under stated conditions

Record the conditions instead of presenting one lab number as a universal result:

• Browser and version.
• Viewport and device emulation.
• Connection profile, cache state, and geographic test location.
• Build or release identifier.

Then check the largest visible element, long main-thread tasks, layout movement, transfer size, and request count. Look for oversized images, blocking JavaScript, missing dimensions, and third-party scripts that are not needed for the first task. Compare the same route and conditions after future releases. The Core Web Vitals guide for developers explains why lab observations and field data should remain separate.

8. Prepare monitoring and rollback

Before announcing the release, decide how you will detect a later failure:

• Save the passing URL, metadata, crawl, browser, accessibility, and performance evidence with the release ID.
• Schedule a public-URL check for the highest-value page and primary action.
• Alert on a confirmed new finding, a worsened finding, a meaningful readiness drop, or lost measurement coverage.
• Keep measurement loss separate from a confirmed regression.
• Know who owns DNS, deployment, content, forms, analytics, and third-party incidents.
• Test the rollback or hotfix path before the launch window closes.

The point is not to alert on every pixel change. It is to make a later failure actionable: identify the changed signal, link the evidence, name the owner, and define the rerun that verifies the fix.

Copyable website launch checklist template

Paste this into a release issue and attach the URLs and evidence as you complete each section:

[ ] Production hostname, HTTPS policy, owners, and rollback are recorded
[ ] Representative URLs return the intended status and content type
[ ] HTTP, www, legacy, and trailing-slash variants resolve to one canonical URL
[ ] Title, description, H1, canonical, Open Graph, language, and favicon are reviewed
[ ] robots.txt permits intended pages and the sitemap lists canonical URLs
[ ] First screen explains the page, audience, outcome, and next action
[ ] Mobile navigation, focus, overflow, overlays, and tap targets pass
[ ] Forms pass labels, validation, pending, error, success, retry, and back behavior
[ ] Security headers and cache policy are reviewed on HTTPS responses
[ ] Performance conditions, measurements, and release identifier are recorded
[ ] Analytics and consent behavior is tested without leaking sensitive values
[ ] Monitoring, support contact, and rollback path are ready
[ ] Passing evidence is attached to the release and a follow-up owner is assigned

Run the checklist with evidence

A checklist is only useful when it records what was observed and what could not be tested. Attach response headers, final URLs, screenshots, browser notes, and the release identifier to the items that matter. “Unable to test” is a valid result when a browser run or external provider is unavailable; it should not silently become a pass.

For a compact evidence-to-fix handoff, review the website audit report example. Then run a Slop Audit against the public URL. Slop Audit reports reachable-page, metadata, crawler, browser, accessibility, content, and selected performance evidence with coverage and limitations. It does not certify security, WCAG conformance, analytics attribution, or search placement.

The launch decision should be clear: ship, fix then ship, or accept a named risk with an owner and review date. That is what turns a website launch checklist into a repeatable engineering practice.