Practical launch control

The Complete New Website Launch Checklist

A comprehensive, plainspoken checklist for the details teams forget between a finished build and a reliable public website.

Open the checklist Download the skill

Need one portable file? Download the complete Markdown checklist.

Why this exists

A launch can look finished and still fail at the edges.

The missing detail is often the one that breaks trust: a form that never arrives, a mobile CTA that covers the page, a staging noindex left behind, or analytics that never records the action.

This checklist turns every item into something observable. Each check includes a verification method and a pass criterion so the team can record evidence, fix defects, and name real blockers before traffic reaches the site.

Launch rule

A successful build is one checkpoint. The release is ready only after the intended public URLs, content, interactions, downloads, tracking, and recovery path are verified.

Release sequence

Run it twice: before release and on production.

01
Define the release
Freeze the route and asset inventory, owners, supported devices, conversion path, policy decisions, performance budget, and rollback trigger.
02
Verify the candidate
Run every applicable check on the final staging candidate. Fix failures and record blockers instead of assuming they will resolve after launch.
03
Release through the approved path
Confirm the dated backup or last known good release, then publish only through the workflow the project owner authorized.
04
Verify the public edge
Use fresh sessions on the bare production URLs. Repeat priority desktop, mobile, conversion, metadata, header, link, download, console, and network checks.
05
Watch the first window
Start the named monitoring period for uptime, forms, analytics, indexing, performance, and feedback. Keep an owner and decision threshold for each signal.

01Page-level

Give every page a clear job and a complete head section.

Confirm that each indexable page explains itself to visitors, browsers, search systems, and sharing platforms.

01meta-title-every-page

Meta title on every page

Verification method: Crawl every public HTML page and extract the title element. Review titles beside the visible H1 and page purpose.
Pass criterion: Every page has one non-empty, descriptive title that is distinct where the page intent is distinct.

02meta-description-every-page

Meta description on every page

Verification method: Crawl every public HTML page and extract meta[name=description]. Compare each description with the actual page content.
Pass criterion: Every indexable page has one accurate, useful description. Important pages do not reuse boilerplate descriptions.

03canonical-url

Canonical URL per indexable page

Verification method: Inspect the rendered head and compare the absolute canonical with the preferred production URL, sitemap entry, and redirect behavior.
Pass criterion: Each indexable page has one absolute canonical pointing to its preferred live URL, with no staging host or conflicting signal.

04heading-hierarchy

Heading hierarchy

Verification method: Generate a heading outline for each template and inspect the rendered page without relying on visual size alone.
Pass criterion: The page has a clear H1 and meaningful section headings in a logical hierarchy without using headings only for styling.

05open-graph-image

Open Graph image

Verification method: Inspect og:image, request the absolute image URL, and preview a representative page in a sharing debugger where available.
Pass criterion: The image URL is public, secure, decodes successfully, represents the page, and has useful og:image:alt text when an image is supplied.

07structured-data

Structured data where applicable

Verification method: Parse every JSON-LD block, validate the selected type, and compare marked-up facts with visible content and approved business data.
Pass criterion: Only relevant supported types are used, markup parses, visible facts agree, and no reviews, ratings, locations, offers, or claims are invented.

08search-indexing-controls

Search indexing controls

Verification method: Compare meta robots, X-Robots-Tag, robots.txt access, canonicals, authentication, and sitemap inclusion for public, private, staging, and utility routes.
Pass criterion: Indexable pages are crawlable and self-consistent. Private, staging, duplicate, and utility routes use the correct protection or noindex method for their purpose.

02Site-wide technical

Make the whole site predictable before traffic arrives.

Check the shared files, routing, security baseline, and failure paths that affect more than one page.

01custom-404

Custom 404 page

Verification method: Request a clearly nonexistent URL in production and inspect the raw status, content, navigation, and recovery links.
Pass criterion: The server returns HTTP 404, the page matches the site, and visitors can return to a useful destination without a broken loop.

02favicon-set

Favicon set

Verification method: Inspect favicon declarations and request the declared files plus the common /favicon.ico fallback.
Pass criterion: Declared icons return successfully with correct image types and display in representative desktop and mobile browser tabs or shortcuts.

03robots-txt

robots.txt

Verification method: Request /robots.txt as plain text, review syntax, and test important allowed and disallowed paths against the intended crawl policy.
Pass criterion: The file returns HTTP 200, does not block required rendered assets or indexable pages, and points to the preferred sitemap when that is the site policy.

04sitemap-xml

sitemap.xml

Verification method: Request and parse /sitemap.xml, deduplicate locations, and resolve every listed URL without fragments.
Pass criterion: The sitemap is valid XML, contains only preferred indexable canonical URLs, and every location returns a successful final response.

05https-mixed-content

HTTPS and mixed-content checks

Verification method: Load representative production pages over HTTPS, review the certificate, inspect all requested resource URLs, and check browser security warnings.
Pass criterion: The certificate is valid for the production host, every active resource and download uses a secure request, and no mixed content is blocked or upgraded unexpectedly.

06redirect-normalization

Redirects and www/http normalization

Verification method: Request http, https, www, non-www, trailing-slash, known legacy, and campaign URL variants at the raw HTTP layer.
Pass criterion: Every variant reaches one preferred HTTPS URL through an intentional redirect chain with no loops, accidental 200 duplicates, or lost path and query values.

07broken-links-fragments

Broken internal links and fragments

Verification method: Crawl internal anchors, remove duplicate requests, resolve destination pages, and confirm every fragment ID exists in the rendered target.
Pass criterion: All unique internal destinations return the intended successful response and every in-page fragment reaches an existing unique target.

08security-headers

Security headers

Verification method: Inspect production response headers on HTML and sensitive endpoints, then review the policy with the application owner before enforcement changes.
Pass criterion: The approved baseline is present, such as HSTS on HTTPS, MIME sniffing protection, a suitable referrer policy, framing controls, and a tested Content Security Policy where appropriate.

03Conversion

Test the next step, not just the page around it.

Prove that a visitor can understand the offer, act, recover from errors, and reach the intended follow-up path.

01cta-above-fold

CTA above the fold

Verification method: Load priority landing pages at representative desktop and mobile sizes and inspect the initial viewport before scrolling.
Pass criterion: The primary next step is visible, understandable, and usable without scrolling, while the offer and audience context remain clear.

02sticky-mobile-cta

Sticky mobile CTA

Verification method: Scroll the full page on a real or accurately emulated phone and interact with the sticky control near the top, middle, and bottom.
Pass criterion: The CTA stays reachable without covering content, form controls, consent controls, or browser safe areas, and its destination works.

03loading-states

Loading states

Verification method: Throttle the network and exercise forms, search, booking, checkout, and other asynchronous actions.
Pass criterion: The interface acknowledges the action, prevents accidental duplicate work, remains understandable, and recovers if the request fails or times out.

04form-error-states

Form error states

Verification method: Submit empty, malformed, rejected, offline, and server-error cases with keyboard and screen-reader-oriented inspection.
Pass criterion: Errors are specific, associated with the relevant fields, announced accessibly, preserve entered data where safe, and explain how to recover.

05form-labels-validation-success

Form labels, validation, and success behavior

Verification method: Inspect label-control associations, required indicators, client and server validation, focus movement, and the successful submission response.
Pass criterion: Every control has a persistent accessible label, validation works on both sides, success is clearly announced, and repeated submissions are controlled.

06thank-you-page

Thank-you page

Verification method: Complete a test submission with approved test data and follow the exact redirect or success state.
Pass criterion: The confirmation loads, states what happens next without making an unsupported promise, preserves attribution where required, and is not treated as an acquisition landing page.

07lead-delivery-follow-up

Lead delivery and follow-up ownership

Verification method: Trace one approved test lead from the form through notification, CRM or inbox, source fields, owner assignment, and the next-step process.
Pass criterion: The lead arrives once with useful source context, has an accountable owner and response path, and no sensitive test data is left in public systems.

04Accessibility and responsive behavior

Make the release usable without assuming one device or input method.

Verify essential content and actions across assistive technology basics, keyboard use, touch, zoom, and narrow screens.

01alt-text-every-image

Alt text on every image

Verification method: Crawl every img element, then review each alternative in its visible context rather than checking attribute presence alone.
Pass criterion: Every image has an alt attribute. Informative images have concise purpose-based alternatives, decorative images use empty alt text, and linked images communicate the destination or action.

02mobile-breakpoints

Mobile breakpoints

Verification method: Resize continuously and test narrow, representative, and wide phone widths plus tablet and desktop, including orientation changes.
Pass criterion: Layouts reflow when content needs it, essential content is not removed, and no breakpoint creates overlap, clipping, or unusable controls.

03keyboard-focus

Keyboard and focus accessibility

Verification method: Use Tab, Shift+Tab, Enter, Space, and Escape through navigation, dialogs, forms, menus, and disclosures without using a mouse.
Pass criterion: Every interactive element is reachable in a logical order, focus is clearly visible, controls operate from the keyboard, and focus is not trapped or lost.

04color-contrast

Color contrast

Verification method: Measure text, icons, control boundaries, and focus indicators in default, hover, focus, disabled, error, and success states.
Pass criterion: The approved accessibility target is met across states, with at least 4.5:1 for normal text under the common WCAG AA check unless a valid exception applies.

05overflow-tap-targets

Responsive overflow and tap targets

Verification method: Compare document scroll width with viewport width and measure repeated controls at 320px and other supported phone sizes.
Pass criterion: There is no unintended horizontal page scroll, content remains readable without two-dimensional scrolling, and pointer targets meet the chosen accessible size or spacing criterion.

06accessibility-semantics

Accessibility semantics

Verification method: Inspect landmarks, link and button roles, names, lists, tables, language, dialog semantics, status messages, and the accessibility tree.
Pass criterion: Native elements express the correct purpose, every control has an accessible name, page language is set, and dynamic status changes are communicated without visual-only cues.

05Performance

Protect speed and visual stability before the site becomes harder to change.

Set practical release limits for images, page weight, responsiveness, and layout movement.

01compressed-images

Compressed images

Verification method: Inventory raster assets, compare delivered dimensions with rendered size, inspect formats, and review visual quality after compression.
Pass criterion: Images use an appropriate modern format and quality, oversized originals are not shipped to small slots, and visible quality remains acceptable.

02image-dimensions-lazy-loading

Image dimensions and lazy loading

Verification method: Inspect width, height, aspect-ratio, loading, fetch priority, and decode behavior while progressively scrolling the full page.
Pass criterion: Space is reserved before images load, above-the-fold priority images are not delayed, off-screen images defer where useful, and every requested image decodes with non-zero dimensions.

03core-web-vitals-budget

Core Web Vitals and performance budget

Verification method: Run repeatable lab tests on key templates under agreed conditions, record page-weight and request budgets, and establish field monitoring for supported traffic levels.
Pass criterion: The release stays within the project budget and has no known blocker to the current good Core Web Vitals targets: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile in field data when available.

06Analytics

Prove measurement with observed events, not tag presence.

Make sure analytics can answer the launch questions without collecting or sending data outside the approved policy.

01analytics-installed

Analytics installed

Verification method: Inspect the production tag or first-party collector, confirm the expected environment and property, and observe a test page view in the receiving system.
Pass criterion: The approved production analytics setup loads once, sends to the correct destination, excludes obvious development hosts, and receives a dated test event.

07Trust and legal

Publish real business information and route legal text through the right owner.

Give visitors credible contact and policy information without turning a checklist into legal advice or a compliance claim.

01privacy-policy

Privacy policy page

Verification method: Confirm the live URL, footer or form access, business identity, data practices, contact path, and approval record with the responsible reviewer.
Pass criterion: The page uses current business-provided or counsel-approved text for the applicable operation and is reachable wherever the approved policy requires it.

02terms-conditions

Terms and conditions

Verification method: Confirm the live URL, business identity, applicable transaction or service context, and approval record with the responsible reviewer.
Pass criterion: The page uses current business-provided or counsel-approved text where applicable. The checklist does not claim that generic terms are universally required or sufficient.

03real-contact-address

Real contact address

Verification method: Compare the published postal or service address and contact channels with the business-approved source of truth and applicable structured data.
Pass criterion: The contact information is real, current, consistently formatted, appropriate for public use, and does not expose a private address by mistake.

08Launch verification

Release with a way back and a named owner for what happens next.

Confirm the public edge, preserve recovery options, and assign the first monitoring window.

01backup-rollback

Backup and rollback

Verification method: Create or confirm a dated pre-launch backup or immutable release, document the rollback trigger, and dry-run the recovery procedure in a safe environment where feasible.
Pass criterion: The team can identify the last known good release, restore it without guessing, and knows who can authorize and execute rollback.

02device-browser-smoke

Real-device and browser smoke tests

Verification method: Test priority pages and one full conversion path on the agreed browser and device matrix, including at least one real phone when available.
Pass criterion: Navigation, content, media, sticky elements, forms, downloads, and key interactions work with no critical layout or input defect across the supported matrix.

03production-errors

Production console and network health

Verification method: Open fresh production sessions, scroll and interact through key routes, then record console errors, failed requests, blocked resources, and HTTP error responses.
Pass criterion: No release-related page error, uncaught exception, failed required request, mixed-content warning, or unexpected 4xx or 5xx response remains.

04post-launch-ownership

Post-launch monitoring ownership

Verification method: Record owners, alert channels, review times, and decision thresholds for uptime, forms, analytics, search indexing, performance, and business feedback.
Pass criterion: Each critical signal has a named owner, first review time, escalation path, and rollback or correction trigger. Unavailable monitoring is recorded, not assumed.

Operating boundaries

Keep the checklist useful without turning it into a promise.

01
Treat launch as a verified release, not a file handoff or a successful build.
02
Record evidence for each check. Use Not applicable only with a short reason and an owner who accepts it.
03
Test the real production URL after release. A staging pass does not prove the public site is healthy.
04
Keep business facts, claims, contact details, legal text, and consent choices owned by the business and approved reviewers.
05
Do not imply that a privacy policy, terms page, cookie banner, structured-data type, or security header is universally sufficient for every jurisdiction or system.
06
Separate launch readiness from post-launch outcomes. A passed checklist does not promise rankings, traffic, leads, or conversions.

Use with an AI or team

Copy one brief that preserves the checks and the evidence standard.

Use it with a capable AI assistant, a launch owner, or a cross-functional team. The brief asks for owners, statuses, evidence, blockers, and a production verification record.

Copy and paste

Paste the complete standalone brief into any capable agent and keep your business context with it.

Attach Markdown

Download one self-contained Markdown file when an agent handles attachments or long context more reliably.

Import the skill

Use the ZIP only where the agent or product supports the Agent Skills specification and skill import.

View or manually copy the complete launch brief

Complete new website launch brief

NEW WEBSITE LAUNCH: VERIFICATION BRIEF
Version: 1.0.0
Reviewed: 2026-09-13
Source: https://markethink.ai/ai-marketing-strategies/new-website-launch-checklist/

ROLE
Act as a website launch verifier. Inspect the real staging candidate and, only when separately authorized, the production release. Do not publish, spend, change accounts, or submit real personal data unless that action is explicitly authorized. Never report a pass from source presence alone.

CONTEXT TO COLLECT
- Business name, approved public contact details, and production domain
- Launch owner, technical owner, analytics owner, form or CRM owner, and legal or policy reviewer
- Priority pages, supported browsers and devices, primary conversion action, forms, downloads, integrations, and legacy URLs
- Indexable, noindex, private, staging, utility, and retired route classes
- Analytics property, approved event names, consent decision, performance budget, backup location, rollback trigger, and monitoring window
Reuse supplied context and ask once for material gaps. Do not invent business facts, legal requirements, compliance status, tracking permission, or performance evidence.

OUTPUT
Return one table with: Category | ID | Check | Owner | Verification method | Pass criterion | Status | Evidence | Blocker or next action.
Use only Pass, Fail, Blocked, or Not applicable. Explain every Not applicable result. Keep launch readiness separate from post-launch outcomes.

CHECKLIST
1. [Page-level] Meta title on every page
   ID: meta-title-every-page
   Verify: Crawl every public HTML page and extract the title element. Review titles beside the visible H1 and page purpose.
   Pass: Every page has one non-empty, descriptive title that is distinct where the page intent is distinct.
2. [Page-level] Meta description on every page
   ID: meta-description-every-page
   Verify: Crawl every public HTML page and extract meta[name=description]. Compare each description with the actual page content.
   Pass: Every indexable page has one accurate, useful description. Important pages do not reuse boilerplate descriptions.
3. [Page-level] Canonical URL per indexable page
   ID: canonical-url
   Verify: Inspect the rendered head and compare the absolute canonical with the preferred production URL, sitemap entry, and redirect behavior.
   Pass: Each indexable page has one absolute canonical pointing to its preferred live URL, with no staging host or conflicting signal.
4. [Page-level] Heading hierarchy
   ID: heading-hierarchy
   Verify: Generate a heading outline for each template and inspect the rendered page without relying on visual size alone.
   Pass: The page has a clear H1 and meaningful section headings in a logical hierarchy without using headings only for styling.
5. [Page-level] Open Graph image
   ID: open-graph-image
   Verify: Inspect og:image, request the absolute image URL, and preview a representative page in a sharing debugger where available.
   Pass: The image URL is public, secure, decodes successfully, represents the page, and has useful og:image:alt text when an image is supplied.
6. [Page-level] Complete social metadata
   ID: complete-social-metadata
   Verify: Extract og:title, og:description, og:url, og:type, and Twitter card metadata from representative page types.
   Pass: Required Open Graph fields are present and accurate, the Twitter card is intentional, and URLs and copy match the canonical page.
7. [Page-level] Structured data where applicable
   ID: structured-data
   Verify: Parse every JSON-LD block, validate the selected type, and compare marked-up facts with visible content and approved business data.
   Pass: Only relevant supported types are used, markup parses, visible facts agree, and no reviews, ratings, locations, offers, or claims are invented.
8. [Page-level] Search indexing controls
   ID: search-indexing-controls
   Verify: Compare meta robots, X-Robots-Tag, robots.txt access, canonicals, authentication, and sitemap inclusion for public, private, staging, and utility routes.
   Pass: Indexable pages are crawlable and self-consistent. Private, staging, duplicate, and utility routes use the correct protection or noindex method for their purpose.
9. [Site-wide technical] Custom 404 page
   ID: custom-404
   Verify: Request a clearly nonexistent URL in production and inspect the raw status, content, navigation, and recovery links.
   Pass: The server returns HTTP 404, the page matches the site, and visitors can return to a useful destination without a broken loop.
10. [Site-wide technical] Favicon set
   ID: favicon-set
   Verify: Inspect favicon declarations and request the declared files plus the common /favicon.ico fallback.
   Pass: Declared icons return successfully with correct image types and display in representative desktop and mobile browser tabs or shortcuts.
11. [Site-wide technical] robots.txt
   ID: robots-txt
   Verify: Request /robots.txt as plain text, review syntax, and test important allowed and disallowed paths against the intended crawl policy.
   Pass: The file returns HTTP 200, does not block required rendered assets or indexable pages, and points to the preferred sitemap when that is the site policy.
12. [Site-wide technical] sitemap.xml
   ID: sitemap-xml
   Verify: Request and parse /sitemap.xml, deduplicate locations, and resolve every listed URL without fragments.
   Pass: The sitemap is valid XML, contains only preferred indexable canonical URLs, and every location returns a successful final response.
13. [Site-wide technical] HTTPS and mixed-content checks
   ID: https-mixed-content
   Verify: Load representative production pages over HTTPS, review the certificate, inspect all requested resource URLs, and check browser security warnings.
   Pass: The certificate is valid for the production host, every active resource and download uses a secure request, and no mixed content is blocked or upgraded unexpectedly.
14. [Site-wide technical] Redirects and www/http normalization
   ID: redirect-normalization
   Verify: Request http, https, www, non-www, trailing-slash, known legacy, and campaign URL variants at the raw HTTP layer.
   Pass: Every variant reaches one preferred HTTPS URL through an intentional redirect chain with no loops, accidental 200 duplicates, or lost path and query values.
15. [Site-wide technical] Broken internal links and fragments
   ID: broken-links-fragments
   Verify: Crawl internal anchors, remove duplicate requests, resolve destination pages, and confirm every fragment ID exists in the rendered target.
   Pass: All unique internal destinations return the intended successful response and every in-page fragment reaches an existing unique target.
16. [Site-wide technical] Security headers
   ID: security-headers
   Verify: Inspect production response headers on HTML and sensitive endpoints, then review the policy with the application owner before enforcement changes.
   Pass: The approved baseline is present, such as HSTS on HTTPS, MIME sniffing protection, a suitable referrer policy, framing controls, and a tested Content Security Policy where appropriate.
17. [Conversion] CTA above the fold
   ID: cta-above-fold
   Verify: Load priority landing pages at representative desktop and mobile sizes and inspect the initial viewport before scrolling.
   Pass: The primary next step is visible, understandable, and usable without scrolling, while the offer and audience context remain clear.
18. [Conversion] Sticky mobile CTA
   ID: sticky-mobile-cta
   Verify: Scroll the full page on a real or accurately emulated phone and interact with the sticky control near the top, middle, and bottom.
   Pass: The CTA stays reachable without covering content, form controls, consent controls, or browser safe areas, and its destination works.
19. [Conversion] Loading states
   ID: loading-states
   Verify: Throttle the network and exercise forms, search, booking, checkout, and other asynchronous actions.
   Pass: The interface acknowledges the action, prevents accidental duplicate work, remains understandable, and recovers if the request fails or times out.
20. [Conversion] Form error states
   ID: form-error-states
   Verify: Submit empty, malformed, rejected, offline, and server-error cases with keyboard and screen-reader-oriented inspection.
   Pass: Errors are specific, associated with the relevant fields, announced accessibly, preserve entered data where safe, and explain how to recover.
21. [Conversion] Form labels, validation, and success behavior
   ID: form-labels-validation-success
   Verify: Inspect label-control associations, required indicators, client and server validation, focus movement, and the successful submission response.
   Pass: Every control has a persistent accessible label, validation works on both sides, success is clearly announced, and repeated submissions are controlled.
22. [Conversion] Thank-you page
   ID: thank-you-page
   Verify: Complete a test submission with approved test data and follow the exact redirect or success state.
   Pass: The confirmation loads, states what happens next without making an unsupported promise, preserves attribution where required, and is not treated as an acquisition landing page.
23. [Conversion] Lead delivery and follow-up ownership
   ID: lead-delivery-follow-up
   Verify: Trace one approved test lead from the form through notification, CRM or inbox, source fields, owner assignment, and the next-step process.
   Pass: The lead arrives once with useful source context, has an accountable owner and response path, and no sensitive test data is left in public systems.
24. [Accessibility and responsive behavior] Alt text on every image
   ID: alt-text-every-image
   Verify: Crawl every img element, then review each alternative in its visible context rather than checking attribute presence alone.
   Pass: Every image has an alt attribute. Informative images have concise purpose-based alternatives, decorative images use empty alt text, and linked images communicate the destination or action.
25. [Accessibility and responsive behavior] Mobile breakpoints
   ID: mobile-breakpoints
   Verify: Resize continuously and test narrow, representative, and wide phone widths plus tablet and desktop, including orientation changes.
   Pass: Layouts reflow when content needs it, essential content is not removed, and no breakpoint creates overlap, clipping, or unusable controls.
26. [Accessibility and responsive behavior] Keyboard and focus accessibility
   ID: keyboard-focus
   Verify: Use Tab, Shift+Tab, Enter, Space, and Escape through navigation, dialogs, forms, menus, and disclosures without using a mouse.
   Pass: Every interactive element is reachable in a logical order, focus is clearly visible, controls operate from the keyboard, and focus is not trapped or lost.
27. [Accessibility and responsive behavior] Color contrast
   ID: color-contrast
   Verify: Measure text, icons, control boundaries, and focus indicators in default, hover, focus, disabled, error, and success states.
   Pass: The approved accessibility target is met across states, with at least 4.5:1 for normal text under the common WCAG AA check unless a valid exception applies.
28. [Accessibility and responsive behavior] Responsive overflow and tap targets
   ID: overflow-tap-targets
   Verify: Compare document scroll width with viewport width and measure repeated controls at 320px and other supported phone sizes.
   Pass: There is no unintended horizontal page scroll, content remains readable without two-dimensional scrolling, and pointer targets meet the chosen accessible size or spacing criterion.
29. [Accessibility and responsive behavior] Accessibility semantics
   ID: accessibility-semantics
   Verify: Inspect landmarks, link and button roles, names, lists, tables, language, dialog semantics, status messages, and the accessibility tree.
   Pass: Native elements express the correct purpose, every control has an accessible name, page language is set, and dynamic status changes are communicated without visual-only cues.
30. [Performance] Compressed images
   ID: compressed-images
   Verify: Inventory raster assets, compare delivered dimensions with rendered size, inspect formats, and review visual quality after compression.
   Pass: Images use an appropriate modern format and quality, oversized originals are not shipped to small slots, and visible quality remains acceptable.
31. [Performance] Image dimensions and lazy loading
   ID: image-dimensions-lazy-loading
   Verify: Inspect width, height, aspect-ratio, loading, fetch priority, and decode behavior while progressively scrolling the full page.
   Pass: Space is reserved before images load, above-the-fold priority images are not delayed, off-screen images defer where useful, and every requested image decodes with non-zero dimensions.
32. [Performance] Core Web Vitals and performance budget
   ID: core-web-vitals-budget
   Verify: Run repeatable lab tests on key templates under agreed conditions, record page-weight and request budgets, and establish field monitoring for supported traffic levels.
   Pass: The release stays within the project budget and has no known blocker to the current good Core Web Vitals targets: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile in field data when available.
33. [Analytics] Analytics installed
   ID: analytics-installed
   Verify: Inspect the production tag or first-party collector, confirm the expected environment and property, and observe a test page view in the receiving system.
   Pass: The approved production analytics setup loads once, sends to the correct destination, excludes obvious development hosts, and receives a dated test event.
34. [Analytics] Analytics event verification and consent-aware operation
   ID: analytics-event-consent
   Verify: Exercise primary CTA clicks, form starts, validation errors, successful submissions, downloads, and consent states while inspecting network payloads and the analytics debugger.
   Pass: Named events fire once with approved parameters, sensitive form values are excluded, consent choices are respected where applicable, and the team can distinguish view, click, submit, qualified lead, and downstream outcome.
35. [Trust and legal] Privacy policy page
   ID: privacy-policy
   Verify: Confirm the live URL, footer or form access, business identity, data practices, contact path, and approval record with the responsible reviewer.
   Pass: The page uses current business-provided or counsel-approved text for the applicable operation and is reachable wherever the approved policy requires it.
36. [Trust and legal] Terms and conditions
   ID: terms-conditions
   Verify: Confirm the live URL, business identity, applicable transaction or service context, and approval record with the responsible reviewer.
   Pass: The page uses current business-provided or counsel-approved text where applicable. The checklist does not claim that generic terms are universally required or sufficient.
37. [Trust and legal] Real contact address
   ID: real-contact-address
   Verify: Compare the published postal or service address and contact channels with the business-approved source of truth and applicable structured data.
   Pass: The contact information is real, current, consistently formatted, appropriate for public use, and does not expose a private address by mistake.
38. [Trust and legal] Cookie and consent behavior where legally applicable
   ID: cookie-consent
   Verify: Have the business or qualified counsel define the applicable requirement, then test default, accept, reject, granular choice, withdrawal, and return-visit behavior against that decision.
   Pass: The implemented behavior matches the approved jurisdiction and data-use policy, preserves user choice, and does not load restricted tags before the approved condition is met.
39. [Launch verification] Backup and rollback
   ID: backup-rollback
   Verify: Create or confirm a dated pre-launch backup or immutable release, document the rollback trigger, and dry-run the recovery procedure in a safe environment where feasible.
   Pass: The team can identify the last known good release, restore it without guessing, and knows who can authorize and execute rollback.
40. [Launch verification] Real-device and browser smoke tests
   ID: device-browser-smoke
   Verify: Test priority pages and one full conversion path on the agreed browser and device matrix, including at least one real phone when available.
   Pass: Navigation, content, media, sticky elements, forms, downloads, and key interactions work with no critical layout or input defect across the supported matrix.
41. [Launch verification] Production console and network health
   ID: production-errors
   Verify: Open fresh production sessions, scroll and interact through key routes, then record console errors, failed requests, blocked resources, and HTTP error responses.
   Pass: No release-related page error, uncaught exception, failed required request, mixed-content warning, or unexpected 4xx or 5xx response remains.
42. [Launch verification] Post-launch monitoring ownership
   ID: post-launch-ownership
   Verify: Record owners, alert channels, review times, and decision thresholds for uptime, forms, analytics, search indexing, performance, and business feedback.
   Pass: Each critical signal has a named owner, first review time, escalation path, and rollback or correction trigger. Unavailable monitoring is recorded, not assumed.

RELEASE SEQUENCE
1. Freeze the intended route and asset inventory. Confirm content, business facts, legal or policy approvals, and conversion ownership.
2. Run the checklist on the final staging candidate. Fix every Fail or record a real Blocked dependency before release.
3. Confirm the dated backup or last known good release and the rollback owner.
4. Release only through the authorized workflow.
5. Re-run production-critical checks on bare production URLs in fresh sessions at the agreed desktop and mobile widths.
6. Exercise links, downloads, forms, analytics events, consent states where applicable, redirects, 404 behavior, and the supported device and browser matrix.
7. Record console, network, response-header, metadata, sitemap, accessibility, performance, and conversion evidence.
8. Start the named post-launch monitoring window and log the first review time, decision thresholds, and correction or rollback trigger.

BOUNDARIES
- robots.txt manages crawler access. It is not a reliable way to keep a public URL out of search results.
- Lab performance tests help catch regressions but do not replace field data.
- Automated accessibility checks are useful but do not prove full accessibility.
- Privacy, terms, consent, contact-address publication, and regulated claims require business-approved or qualified-counsel input as applicable.
- A successful build or HTTP 200 response does not prove the intended release, interaction, or tracking behavior is live.

FINAL SUMMARY
Report totals by status, release identifier, tested production URLs, device and browser matrix, rollback readiness, monitoring owner, unresolved blockers, and the next review time. Do not claim rankings, traffic, leads, or conversion outcomes from launch completion.

Download Markdown

Primary guidance

Use the source that matches the check.

Reviewed 2026-09-13. Standards, platform behavior, and legal requirements can change, so recheck the live source when the detail is material.

Google Search Central Influencing your title links in search results
Unique descriptive page titles and clear main-title signals.
https://developers.google.com/search/docs/appearance/title-link
Google Search Central Control your snippets in search results
Accurate page-level meta descriptions and limits on how snippets are selected.
https://developers.google.com/search/docs/appearance/snippet
Google Search Central How to specify a canonical URL
Absolute canonical URLs, redirects, sitemap alignment, and duplicate URL handling.
https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
Google Search Central Introduction to robots.txt
Crawler access controls and the distinction between crawl blocking and noindex.
https://developers.google.com/search/docs/crawling-indexing/robots/intro
Google Search Central Build and submit a sitemap
Valid sitemap structure, absolute canonical locations, and indexable URL selection.
https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
W3C Web Accessibility Initiative Easy Checks: A First Review of Web Accessibility
Page titles, image alternatives, headings, keyboard focus, contrast, and basic structure checks.
https://www.w3.org/WAI/test-evaluate/preliminary/
W3C Web Accessibility Initiative Forms tutorials
Labels, validation, error notification, success notification, and form simplicity.
https://www.w3.org/WAI/tutorials/forms/
web.dev Web Vitals
Current Core Web Vitals definitions, good thresholds, field measurement, and lab-test limits.
https://web.dev/articles/vitals
web.dev Responsive web design basics
Viewport configuration, content-led breakpoints, responsive overflow, and image dimensions.
https://web.dev/articles/responsive-web-design-basics
MDN Web Docs Mixed content
HTTPS resource delivery and mixed-content risk.
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content
MDN Web Docs Content Security Policy
Tested security policy, resource restrictions, HTTPS upgrades, and defense in depth.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
Open Graph protocol Basic and structured metadata
og:title, og:type, og:image, og:url, descriptions, and image alternatives.
https://ogp.me/
Schema.org Getting started with Schema.org
Applicable structured-data types, visible fact alignment, and validation.
https://schema.org/docs/gs.html