# The Complete New Website Launch Checklist > Use a practical website launch checklist with verification methods and pass criteria for technical setup, conversion, accessibility, analytics, trust, performance, and post-launch ownership. - Version: 1.0.0 - Reviewed: 2026-09-13 - Author: Markethink - Canonical page: https://markethink.ai/ai-marketing-strategies/new-website-launch-checklist/ - Portable skill: https://markethink.ai/downloads/markethink-new-website-launch-checklist.zip ## Purpose Use one evidence-led control to decide whether a new website is ready to release and whether the production release actually works. Every check includes a verification method and pass criterion. Project owners still define the supported browsers, devices, jurisdictions, security baseline, analytics policy, and performance budget. ## Operating principles - Treat launch as a verified release, not a file handoff or a successful build. - Record evidence for each check. Use Not applicable only with a short reason and an owner who accepts it. - Test the real production URL after release. A staging pass does not prove the public site is healthy. - Keep business facts, claims, contact details, legal text, and consent choices owned by the business and approved reviewers. - 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. - Separate launch readiness from post-launch outcomes. A passed checklist does not promise rankings, traffic, leads, or conversions. ## Complete checklist # New website launch checklist Version 1.0.0. Reviewed 2026-09-13. | Category | ID | Check | Verification method | Pass criterion | Status | Evidence or blocker | | --- | --- | --- | --- | --- | --- | --- | | Page-level | meta-title-every-page | Meta title on every page | Crawl every public HTML page and extract the title element. Review titles beside the visible H1 and page purpose. | Every page has one non-empty, descriptive title that is distinct where the page intent is distinct. | | | | Page-level | meta-description-every-page | Meta description on every page | Crawl every public HTML page and extract meta[name=description]. Compare each description with the actual page content. | Every indexable page has one accurate, useful description. Important pages do not reuse boilerplate descriptions. | | | | Page-level | canonical-url | Canonical URL per indexable page | Inspect the rendered head and compare the absolute canonical with the preferred production URL, sitemap entry, and redirect behavior. | Each indexable page has one absolute canonical pointing to its preferred live URL, with no staging host or conflicting signal. | | | | Page-level | heading-hierarchy | Heading hierarchy | Generate a heading outline for each template and inspect the rendered page without relying on visual size alone. | The page has a clear H1 and meaningful section headings in a logical hierarchy without using headings only for styling. | | | | Page-level | open-graph-image | Open Graph image | Inspect og:image, request the absolute image URL, and preview a representative page in a sharing debugger where available. | The image URL is public, secure, decodes successfully, represents the page, and has useful og:image:alt text when an image is supplied. | | | | Page-level | complete-social-metadata | Complete social metadata | Extract og:title, og:description, og:url, og:type, and Twitter card metadata from representative page types. | Required Open Graph fields are present and accurate, the Twitter card is intentional, and URLs and copy match the canonical page. | | | | Page-level | structured-data | Structured data where applicable | Parse every JSON-LD block, validate the selected type, and compare marked-up facts with visible content and approved business data. | Only relevant supported types are used, markup parses, visible facts agree, and no reviews, ratings, locations, offers, or claims are invented. | | | | Page-level | search-indexing-controls | Search indexing controls | Compare meta robots, X-Robots-Tag, robots.txt access, canonicals, authentication, and sitemap inclusion for public, private, staging, and utility routes. | Indexable pages are crawlable and self-consistent. Private, staging, duplicate, and utility routes use the correct protection or noindex method for their purpose. | | | | Site-wide technical | custom-404 | Custom 404 page | Request a clearly nonexistent URL in production and inspect the raw status, content, navigation, and recovery links. | The server returns HTTP 404, the page matches the site, and visitors can return to a useful destination without a broken loop. | | | | Site-wide technical | favicon-set | Favicon set | Inspect favicon declarations and request the declared files plus the common /favicon.ico fallback. | Declared icons return successfully with correct image types and display in representative desktop and mobile browser tabs or shortcuts. | | | | Site-wide technical | robots-txt | robots.txt | Request /robots.txt as plain text, review syntax, and test important allowed and disallowed paths against the intended crawl policy. | 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. | | | | Site-wide technical | sitemap-xml | sitemap.xml | Request and parse /sitemap.xml, deduplicate locations, and resolve every listed URL without fragments. | The sitemap is valid XML, contains only preferred indexable canonical URLs, and every location returns a successful final response. | | | | Site-wide technical | https-mixed-content | HTTPS and mixed-content checks | Load representative production pages over HTTPS, review the certificate, inspect all requested resource URLs, and check browser security warnings. | 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. | | | | Site-wide technical | redirect-normalization | Redirects and www/http normalization | Request http, https, www, non-www, trailing-slash, known legacy, and campaign URL variants at the raw HTTP layer. | Every variant reaches one preferred HTTPS URL through an intentional redirect chain with no loops, accidental 200 duplicates, or lost path and query values. | | | | Site-wide technical | broken-links-fragments | Broken internal links and fragments | Crawl internal anchors, remove duplicate requests, resolve destination pages, and confirm every fragment ID exists in the rendered target. | All unique internal destinations return the intended successful response and every in-page fragment reaches an existing unique target. | | | | Site-wide technical | security-headers | Security headers | Inspect production response headers on HTML and sensitive endpoints, then review the policy with the application owner before enforcement changes. | 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. | | | | Conversion | cta-above-fold | CTA above the fold | Load priority landing pages at representative desktop and mobile sizes and inspect the initial viewport before scrolling. | The primary next step is visible, understandable, and usable without scrolling, while the offer and audience context remain clear. | | | | Conversion | sticky-mobile-cta | Sticky mobile CTA | Scroll the full page on a real or accurately emulated phone and interact with the sticky control near the top, middle, and bottom. | The CTA stays reachable without covering content, form controls, consent controls, or browser safe areas, and its destination works. | | | | Conversion | loading-states | Loading states | Throttle the network and exercise forms, search, booking, checkout, and other asynchronous actions. | The interface acknowledges the action, prevents accidental duplicate work, remains understandable, and recovers if the request fails or times out. | | | | Conversion | form-error-states | Form error states | Submit empty, malformed, rejected, offline, and server-error cases with keyboard and screen-reader-oriented inspection. | Errors are specific, associated with the relevant fields, announced accessibly, preserve entered data where safe, and explain how to recover. | | | | Conversion | form-labels-validation-success | Form labels, validation, and success behavior | Inspect label-control associations, required indicators, client and server validation, focus movement, and the successful submission response. | Every control has a persistent accessible label, validation works on both sides, success is clearly announced, and repeated submissions are controlled. | | | | Conversion | thank-you-page | Thank-you page | Complete a test submission with approved test data and follow the exact redirect or success state. | 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. | | | | Conversion | lead-delivery-follow-up | Lead delivery and follow-up ownership | Trace one approved test lead from the form through notification, CRM or inbox, source fields, owner assignment, and the next-step process. | 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. | | | | Accessibility and responsive behavior | alt-text-every-image | Alt text on every image | Crawl every img element, then review each alternative in its visible context rather than checking attribute presence alone. | 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. | | | | Accessibility and responsive behavior | mobile-breakpoints | Mobile breakpoints | Resize continuously and test narrow, representative, and wide phone widths plus tablet and desktop, including orientation changes. | Layouts reflow when content needs it, essential content is not removed, and no breakpoint creates overlap, clipping, or unusable controls. | | | | Accessibility and responsive behavior | keyboard-focus | Keyboard and focus accessibility | Use Tab, Shift+Tab, Enter, Space, and Escape through navigation, dialogs, forms, menus, and disclosures without using a mouse. | 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. | | | | Accessibility and responsive behavior | color-contrast | Color contrast | Measure text, icons, control boundaries, and focus indicators in default, hover, focus, disabled, error, and success states. | 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. | | | | Accessibility and responsive behavior | overflow-tap-targets | Responsive overflow and tap targets | Compare document scroll width with viewport width and measure repeated controls at 320px and other supported phone sizes. | 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. | | | | Accessibility and responsive behavior | accessibility-semantics | Accessibility semantics | Inspect landmarks, link and button roles, names, lists, tables, language, dialog semantics, status messages, and the accessibility tree. | 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. | | | | Performance | compressed-images | Compressed images | Inventory raster assets, compare delivered dimensions with rendered size, inspect formats, and review visual quality after compression. | Images use an appropriate modern format and quality, oversized originals are not shipped to small slots, and visible quality remains acceptable. | | | | Performance | image-dimensions-lazy-loading | Image dimensions and lazy loading | Inspect width, height, aspect-ratio, loading, fetch priority, and decode behavior while progressively scrolling the full page. | 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. | | | | Performance | core-web-vitals-budget | Core Web Vitals and performance budget | Run repeatable lab tests on key templates under agreed conditions, record page-weight and request budgets, and establish field monitoring for supported traffic levels. | 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. | | | | Analytics | analytics-installed | Analytics installed | Inspect the production tag or first-party collector, confirm the expected environment and property, and observe a test page view in the receiving system. | The approved production analytics setup loads once, sends to the correct destination, excludes obvious development hosts, and receives a dated test event. | | | | Analytics | analytics-event-consent | Analytics event verification and consent-aware operation | Exercise primary CTA clicks, form starts, validation errors, successful submissions, downloads, and consent states while inspecting network payloads and the analytics debugger. | 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. | | | | Trust and legal | privacy-policy | Privacy policy page | Confirm the live URL, footer or form access, business identity, data practices, contact path, and approval record with the responsible reviewer. | The page uses current business-provided or counsel-approved text for the applicable operation and is reachable wherever the approved policy requires it. | | | | Trust and legal | terms-conditions | Terms and conditions | Confirm the live URL, business identity, applicable transaction or service context, and approval record with the responsible reviewer. | 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. | | | | Trust and legal | real-contact-address | Real contact address | Compare the published postal or service address and contact channels with the business-approved source of truth and applicable structured data. | The contact information is real, current, consistently formatted, appropriate for public use, and does not expose a private address by mistake. | | | | Trust and legal | cookie-consent | Cookie and consent behavior where legally applicable | 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. | 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. | | | | Launch verification | backup-rollback | Backup and rollback | 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. | The team can identify the last known good release, restore it without guessing, and knows who can authorize and execute rollback. | | | | Launch verification | device-browser-smoke | Real-device and browser smoke tests | Test priority pages and one full conversion path on the agreed browser and device matrix, including at least one real phone when available. | Navigation, content, media, sticky elements, forms, downloads, and key interactions work with no critical layout or input defect across the supported matrix. | | | | Launch verification | production-errors | Production console and network health | Open fresh production sessions, scroll and interact through key routes, then record console errors, failed requests, blocked resources, and HTTP error responses. | No release-related page error, uncaught exception, failed required request, mixed-content warning, or unexpected 4xx or 5xx response remains. | | | | Launch verification | post-launch-ownership | Post-launch monitoring ownership | Record owners, alert channels, review times, and decision thresholds for uptime, forms, analytics, search indexing, performance, and business feedback. | Each critical signal has a named owner, first review time, escalation path, and rollback or correction trigger. Unavailable monitoring is recorded, not assumed. | | | Use only Pass, Fail, Blocked, or Not applicable. Explain every Not applicable result and preserve dated evidence. ## Compact reusable 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. ## Source notes # Original guidance and scope notes Reviewed 2026-09-13. Recheck live guidance when a standard, platform, law, or project constraint may have changed. ## Influencing your title links in search results - Publisher: Google Search Central - URL: https://developers.google.com/search/docs/appearance/title-link - Used for: Unique descriptive page titles and clear main-title signals. ## Control your snippets in search results - Publisher: Google Search Central - URL: https://developers.google.com/search/docs/appearance/snippet - Used for: Accurate page-level meta descriptions and limits on how snippets are selected. ## How to specify a canonical URL - Publisher: Google Search Central - URL: https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls - Used for: Absolute canonical URLs, redirects, sitemap alignment, and duplicate URL handling. ## Introduction to robots.txt - Publisher: Google Search Central - URL: https://developers.google.com/search/docs/crawling-indexing/robots/intro - Used for: Crawler access controls and the distinction between crawl blocking and noindex. ## Build and submit a sitemap - Publisher: Google Search Central - URL: https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap - Used for: Valid sitemap structure, absolute canonical locations, and indexable URL selection. ## Easy Checks: A First Review of Web Accessibility - Publisher: W3C Web Accessibility Initiative - URL: https://www.w3.org/WAI/test-evaluate/preliminary/ - Used for: Page titles, image alternatives, headings, keyboard focus, contrast, and basic structure checks. ## Forms tutorials - Publisher: W3C Web Accessibility Initiative - URL: https://www.w3.org/WAI/tutorials/forms/ - Used for: Labels, validation, error notification, success notification, and form simplicity. ## Web Vitals - Publisher: web.dev - URL: https://web.dev/articles/vitals - Used for: Current Core Web Vitals definitions, good thresholds, field measurement, and lab-test limits. ## Responsive web design basics - Publisher: web.dev - URL: https://web.dev/articles/responsive-web-design-basics - Used for: Viewport configuration, content-led breakpoints, responsive overflow, and image dimensions. ## Mixed content - Publisher: MDN Web Docs - URL: https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content - Used for: HTTPS resource delivery and mixed-content risk. ## Content Security Policy - Publisher: MDN Web Docs - URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP - Used for: Tested security policy, resource restrictions, HTTPS upgrades, and defense in depth. ## Basic and structured metadata - Publisher: Open Graph protocol - URL: https://ogp.me/ - Used for: og:title, og:type, og:image, og:url, descriptions, and image alternatives. ## Getting started with Schema.org - Publisher: Schema.org - URL: https://schema.org/docs/gs.html - Used for: Applicable structured-data types, visible fact alignment, and validation. ## Limits This checklist is a practical launch control, not legal advice, a security certification, an accessibility conformance claim, or a promise of search or conversion results. Project owners must define the supported browsers, devices, jurisdictions, analytics policy, security baseline, and performance budget.