# Complete New Website Launch Checklist | Markethink > Use a practical website launch checklist with verification methods and pass criteria for technical setup, conversion, accessibility, analytics, trust, performance, and post-launch ownership. Canonical page: https://markethink.ai/ai-marketing-strategies/new-website-launch-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. - 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. 01 `meta-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. 02 `meta-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. 03 `canonical-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. 04 `heading-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. 05 `open-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. 06 `complete-social-metadata` ### Complete social metadata Verification method Extract og:title, og:description, og:url, og:type, and Twitter card metadata from representative page types. Pass criterion Required Open Graph fields are present and accurate, the Twitter card is intentional, and URLs and copy match the canonical page. 07 `structured-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. 08 `search-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. 01 `custom-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. 02 `favicon-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. 03 `robots-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. 04 `sitemap-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. 05 `https-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. 06 `redirect-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. 07 `broken-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. 08 `security-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. 01 `cta-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. 02 `sticky-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. 03 `loading-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. 04 `form-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. 05 `form-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. 06 `thank-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. 07 `lead-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. 01 `alt-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. 02 `mobile-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. 03 `keyboard-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. 04 `color-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. 05 `overflow-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. 06 `accessibility-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. 01 `compressed-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. 02 `image-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. 03 `core-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. 01 `analytics-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. 02 `analytics-event-consent` ### Analytics event verification and consent-aware operation Verification method Exercise primary CTA clicks, form starts, validation errors, successful submissions, downloads, and consent states while inspecting network payloads and the analytics debugger. Pass criterion 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. 01 `privacy-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. 02 `terms-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. 03 `real-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. 04 `cookie-consent` ### Cookie and consent behavior where legally applicable Verification method 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 criterion 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. 01 `backup-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. 02 `device-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. 03 `production-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. 04 `post-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. - 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. ### 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 [Download Markdown](https://markethink.ai/downloads/markethink-new-website-launch-checklist.md) - Google Search Central [Influencing your title links in search results](https://developers.google.com/search/docs/appearance/title-link) 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](https://developers.google.com/search/docs/appearance/snippet) 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](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) 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](https://developers.google.com/search/docs/crawling-indexing/robots/intro) 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](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-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](https://www.w3.org/WAI/test-evaluate/preliminary/) 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](https://www.w3.org/WAI/tutorials/forms/) Labels, validation, error notification, success notification, and form simplicity. https://www.w3.org/WAI/tutorials/forms/ - web.dev [Web Vitals](https://web.dev/articles/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](https://web.dev/articles/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://developer.mozilla.org/en-US/docs/Web/Security/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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) 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](https://ogp.me/) og:title, og:type, og:image, og:url, descriptions, and image alternatives. https://ogp.me/ - Schema.org [Getting started with Schema.org](https://schema.org/docs/gs.html) Applicable structured-data types, visible fact alignment, and validation. https://schema.org/docs/gs.html