Free tool
Website Launch Checklist with Owners
Use a website launch checklist to record manual checks, owners, evidence and remaining decisions. Export Markdown or CSV locally, with untested work visible.
Record launch checks, evidence and unresolved decisions
A website launch checklist ties a named release and scope to the checks your team performed, their owners and the evidence behind each status. Start with the 14 checks below, record Passed, Failed, Blocked or N/A only after review, and keep unknowns visible. Copy or download a Markdown or CSV worksheet without signup.
Every check starts as Not tested. This is a manual record, not an automated scan, readiness score or launch approval. Your team decides whether the remaining risks and work are acceptable.
Up to 200 characters. Blank exports as Unknown. Apply context before recording results.
Up to 2,000 characters. Name the site/pages, environments and limits of this review. Blank exports as Not provided.
Changing release or scope starts a fresh checklist. You will be asked before any existing statuses, owners, notes or remaining decisions are cleared.
Recorded statuses and gaps
14 Not tested; 0 Passed; 0 Failed; 0 Blocked; 0 N/A. 14 without an owner; 14 without evidence or notes.
Up to 2,000 characters. Record open questions, who decides and the next review action. This does not approve a launch.
Each check has an owner (up to 200 characters) and evidence or notes (up to 2,000). Oversized fields block export until corrected. References are text only; review private details before sharing.
QA
Critical journeys
Run the main tasks with valid and invalid test input; record expected and actual outcomes on the named build.
Supported environments
Check agreed browsers and real devices, narrow layouts and enlarged text; name the environments and untested limits.
Content
Content and contact details
Review public copy, contact routes, dates and claims against the intended release; remove placeholders.
Page and sharing metadata
Review page titles, descriptions, intended canonical URLs and sharing previews for the pages in scope.
Privacy
Private content access
Check private pages require the intended authentication and permissions. Robots rules do not make content private.
Forms and shared data
Review what forms and third-party tools collect and who receives it. Check exports and evidence for private details; record unanswered questions.
Links
Navigation and destinations
Follow navigation, primary actions and contact links; confirm the destination and a useful missing-page response.
Changed URLs and redirects
Check old URLs that changed reach the intended new pages without loops; explain N/A when no routes changed.
Indexability
Crawl rules
Review robots.txt against intended public crawl access. Crawl blocking is not a privacy control and does not guarantee exclusion from search.
Indexing directives
Inspect intended public-page indexing directives. A crawler must fetch a page to see noindex; protect private content with access controls.
Accessibility
Keyboard and form checks
Try keyboard navigation, visible focus, labels and error messages on key tasks. Record barriers; this preliminary check is not a conformance audit.
Text and media checks
Review headings, image alternatives, enlarged text and contrast using appropriate checks. Record limits; this does not establish accessibility conformance.
Recovery
Recovery route and owner
Name a recovery owner and a known prior version or restore route. Rehearse the procedure in a suitable test environment and record limitations.
Post-launch checks and contact
Assign who checks critical journeys and failure signals after launch, how issues reach them, and which unresolved decisions need review.
Review and export the checklist
Blank and partial drafts are exportable. Markdown escapes pasted formatting and HTML. CSV quotes every cell and visibly prefixes formula-like values with Text: . Spreadsheet import and re-save behavior varies; inspect the resulting cells. Neither format redacts secrets or certifies the launch.
Read-only output. Edit the fields above to change it; select preview text to copy manually.
Read-only output. Edit the fields above to change it; select preview text to copy manually.
A fictional launch review with work still open
The loadable example concerns a made-up brochure site on a staging build. Its statuses and evidence references are invented for explanation; they are not customer results.
A failed journey stays visible
The example tester finds that correcting a missing-email error clears the contact-form message. Critical journeys is marked Failed, with an owner and a fictional screenshot reference. Passing a content review does not cancel that failure.
The remaining decision is who reviews the form fix and when to repeat the check before choosing a launch date. A status count cannot make that decision.
N/A needs a reason; untested stays untested
The example site changes no existing public URLs, so the owner marks Changed URLs and redirects as N/A and records that limited scope. Recovery still has no rehearsal evidence, so it stays Not tested.
A different release or scope needs a fresh record. Applying a changed context resets statuses, owners, notes and remaining decisions after confirmation when work would be lost.
Resolve a search-visibility conflict before launch
A crawl block can hide a noindex directive
For a page intended to stay out of search, review the actual response and access rules in the release environment. Google’s robots.txt guidance describes crawl control: if it blocks the URL, a crawler may never see a page-level noindex. Google’s noindex guidance requires crawl access for that directive to be found. If the page contains private data, require authentication instead of treating either search control as a privacy boundary.
Record the exact page, observed directive, owner and unresolved decision in the checklist. A generic “SEO passed” note cannot show which environment or URL was checked.
Use the checklist as a review record
- Name the context first. Record the build, pages, environments and limits. Blank context stays Unknown or Not provided. Apply context before entering observations so later changes cannot silently relabel old results.
- Record an owner and evidence. Use reviewed references and concise notes: what was checked, what happened and what remains uncertain. The tool does not open attachments or inspect the website.
- Keep exceptions explicit. Explain Failed, Blocked and N/A statuses. A checklist with no recorded failures may still contain untested work, incomplete coverage or mistaken observations.
- Agree recovery and remaining decisions. Name a recovery owner, review a restore route in an appropriate test environment and decide who checks the release after launch. These prompts do not guarantee a recovery outcome.
The accessibility prompts are preliminary. W3C's Easy Checks can identify some barriers but do not determine full accessibility conformance. Microsoft's testing strategy guidance provides context for planning tests, responsibilities and evidence; this checklist is an original, smaller workflow rather than a complete test strategy.
Plan device coverage with the cross-browser matrix, then use the mobile website testing guide and responsive design checks. Turn failures into a reviewable handoff with the triage worksheet and sample bug reports.
Published October 9, 2026. Updated October 10, 2026. Method: 14 curated manual checks across QA, content, privacy, links, indexability, accessibility and recovery, with bounded local text exports. This tool keeps fields in the current tab, without saving or uploading them. Existing site analytics may record tool use without checklist contents.
Examples for your team
Builder example
Fictional builder example: a maintainer records a failed contact-form journey and assigns its review before choosing a launch date.
Start your 14-day free trialAgency / QA example
Fictional agency / QA example: a tester marks unchanged URLs as N/A with a reason while recovery checks remain explicitly Not tested.
Start your 14-day free trial