Website launch readiness checklist: a complete guide

Use this checklist before publishing a new site, redesign, major content update, or new feature that changes what visitors can do. Each item opens to explain why the check matters. Mark the checkbox when you have reviewed the item and recorded the result; checked items are saved in this browser on this device.

This is a broad operational checklist, not a claim that every website needs every feature or that completing it establishes legal compliance. Mark items “not applicable” in your project notes when a site does not collect personal information, sell products, create accounts, or use the feature described. Requirements depend on the business, its visitors, the data and vendors involved, and the jurisdictions where it operates. Ask qualified legal, privacy, security, or accessibility professionals to review questions within their expertise.

1. Scope, owners, and launch decision

• Name the person accountable for the launch decision.

  One accountable owner can resolve conflicting feedback, approve the final scope, and decide whether an unresolved issue blocks launch. Without that owner, important defects can fall between teams.

• Write down what is changing and what is explicitly out of scope.

  A launch may include new forms, tracking, payment flows, or integrations even when the visible redesign seems small. A written scope helps reviewers test the parts whose behavior or risk has changed.

• Define the primary audience and the most important visitor tasks.

  Reviewers need a concrete way to judge whether navigation, content, and calls to action work. “Looks finished” is not a test of whether a visitor can find a service, get an answer, or place an order.

• Set acceptance criteria for the critical journeys.

  A journey such as “find a service and send an inquiry” can be tested from beginning to end. Criteria help the team distinguish launch blockers from polish that can be scheduled later.

• Create an issue list with severity, owner, and decision for each open item.

  An issue log makes risk visible. It lets the launch owner defer low-impact changes deliberately while preventing security, payment, accessibility, or broken-contact issues from being lost in chat.

• Confirm who can approve copy, images, pricing, claims, and legal pages.

  A developer may not be authorized to verify a price, promise, privacy statement, or return policy. Assigning reviewers ensures the published information has a knowledgeable owner.

2. Pages, navigation, and content

• Inventory every page, route, landing page, and downloadable file.

  An inventory exposes missing pages, forgotten campaign URLs, duplicate content, and resources that need redirects or access restrictions. Include pages that are not linked in the main navigation.

• Confirm that each page has one clear purpose and an intended audience.

  Pages that mix unrelated tasks are harder to navigate and maintain. A clear purpose helps authors decide what belongs on the page and what should link elsewhere.

• Check that the home page explains what the business offers and where relevant.

  Visitors should be able to tell quickly whether they are in the right place. Local or service-area claims should match the business’s actual ability to serve those locations.

• Review every service or product page for accurate scope and limitations.

  Clear inclusions, exclusions, prerequisites, and next steps reduce mismatched inquiries and prevent marketing language from promising work the business does not provide.

• Confirm that About, team, and company details are current and supportable.

  Outdated staff, credentials, years-in-business claims, and locations can mislead visitors and damage trust. Use only qualifications and experience the business can substantiate.

• Review contact details, business hours, service area, and holiday notices.

  Customers may make decisions based on hours and availability. Incorrect details can cause missed calls, wasted visits, and inconsistent information across search listings.

• Check testimonials, reviews, logos, awards, statistics, and case-study claims.

  These claims influence purchase decisions. Verify that quotations are authentic, permissions are in place, relationships or incentives are disclosed where required, and results are not presented as typical without support.

• Remove placeholder text, sample data, broken draft links, and unfinished labels.

  Placeholder content can make a live site appear untrustworthy or expose information intended only for the team. A systematic content pass catches these details across routes.

• Check spelling, grammar, names, dates, prices, units, and terminology.

  Small errors can change meaning in a price, address, deadline, or instruction. A second reader often catches issues the original author has become accustomed to seeing.

• Make headings, button labels, and link text describe their destination or action.

  Descriptive labels help visitors scan pages and understand controls, including people navigating with assistive technology. Avoid vague labels such as “click here” when a specific action is possible.

• Check page titles, visible headings, and summaries for consistency.

  The visible page should match the title shown in browser tabs, shared previews, and search results. Consistent descriptions set accurate expectations before a visitor opens the page.

• Check copyright, image, font, video, and icon licenses and permissions.

  Having a file does not necessarily grant permission to publish it. Record the source, license, attribution rules, and any expiration or territory restrictions for third-party assets.

• Review every language version and translated page as a complete experience.

  A translated home page linked to untranslated checkout, forms, or terms creates an incomplete journey. Verify language switching, content parity, and any language-specific legal review.

3. Navigation, links, and interaction states

• Test the main navigation, mobile menu, footer links, and in-page anchors.

  Shared navigation appears across many pages, so one broken menu item affects the whole site. Test both pointer and keyboard interaction, including opening and closing mobile menus.

• Check every internal link and external destination.

  Broken links interrupt tasks and can make important pages difficult for visitors and crawlers to discover. Confirm destinations, redirects, and whether external links should open in the same tab.

• Verify that visible buttons perform the action their labels promise.

  A button labeled “Book a consultation” should reach a working booking path, not a generic page. Test actions on mobile and desktop and verify the final result.

• Review loading, empty, success, error, disabled, and offline states.

  Visitors often encounter the interface while data is delayed or an action fails. Clear states prevent duplicate submissions and explain what the person can do next.

• Check that dialogs, popovers, and menus can be dismissed and do not trap users unexpectedly.

  Overlays can block the underlying page or keyboard focus. Confirm Escape behavior, focus placement, return of focus, and that important content is not hidden behind another layer.

• Test back, refresh, and repeated-submission behavior on important flows.

  People may refresh after a slow response or return to edit a previous answer. Make sure this does not create duplicate orders, lose form content, or expose an unclear state.

4. Accessibility and inclusive use

• Choose an accessibility target and review applicable obligations with qualified help.

  WCAG 2.2 provides testable accessibility criteria, but the legal standard applicable to a business depends on its context. The W3C recommends WCAG 2.2 as a current conformance target; a checklist or automated scan alone cannot establish conformance.

• Navigate every key journey using only a keyboard.

  Some visitors cannot use a mouse or touch screen. Keyboard testing reveals unreachable controls, illogical focus order, keyboard traps, and interactions that only work on hover.

• Confirm that focus is visible and remains unobscured.

  Keyboard users need to see which control will activate. Sticky headers, dialogs, and floating widgets can cover the focused element and make it difficult to continue.

• Check headings and landmarks for a meaningful page structure.

  Screen-reader users can navigate by headings and landmarks. A logical hierarchy also helps all readers understand how the page is organized.

• Provide useful alternative text for informative images and empty alt text for decoration.

  Alternative text communicates the information an image contributes. Describing a decorative flourish adds noise, while omitting an informative diagram can remove necessary context.

• Check text and control contrast, including hover, focus, and disabled states.

  Insufficient contrast can make content difficult to perceive. Check the actual rendered combinations rather than assuming that a color passes in every theme or state.

• Do not use color alone to communicate errors, status, or required fields.

  Visitors who cannot distinguish a color still need to understand the message. Pair color with text, icons, patterns, or other clear cues.

• Check zoom, text resizing, narrow screens, and orientation changes.

  Users may enlarge content or use a narrow viewport. Important text and actions should remain available without clipped controls or unnecessary two-direction scrolling.

• Check accessible names, roles, and states for custom controls.

  A custom dropdown, tab, accordion, or carousel must communicate what it is and whether it is expanded or selected. Native controls are often more reliable when they meet the design need.

• Review forms for visible labels, instructions, grouping, and programmatic associations.

  A placeholder alone is not a persistent label. Clear associations help people identify what each field requests and make controls easier to use with assistive technology.

• Test form errors with keyboard and screen-reader feedback.

  An error that appears visually but is not announced can leave users unaware that the submission failed. Explain the problem, link to the field where appropriate, and preserve valid answers.

• Provide captions or transcripts for meaningful audio and video.

  Captions and transcripts make spoken information available to people who are deaf or hard of hearing and to visitors who cannot play audio in their setting.

• Respect reduced-motion preferences and avoid flashing content.

  Motion can cause discomfort, distraction, or barriers for some visitors. Essential information should not depend on animation, and motion should respond to system preferences.

• Check touch target size and spacing for frequently used controls.

  Small or crowded targets are difficult to activate accurately, especially on mobile or for people with limited dexterity. WCAG 2.2 includes a minimum target-size criterion with defined exceptions.

• Test the whole site with at least one automated scanner and manual review.

  Automated tools can find some detectable issues but miss many barriers involving meaning, task completion, focus, and screen-reader behavior. Use scans to support, not replace, manual checks.

5. Responsive behavior, browsers, and device coverage

• Review representative pages at small, medium, and wide viewport sizes.

  Responsive layouts can fail on page types that were not included in a single home-page check. Inspect long headings, cards, tables, menus, forms, and embedded media at multiple widths.

• Test the most important flows on real iOS and Android devices.

  Device simulators do not reproduce every keyboard, browser, viewport, and payment behavior. Test the devices and browsers your audience is likely to use, based on available analytics.

• Check supported browsers and operating systems against a documented policy.

  Teams cannot test every browser configuration. A support policy makes coverage deliberate and helps avoid relying on features unavailable to a meaningful share of customers.

• Verify sticky elements do not cover content, focus, or form controls.

  Fixed navigation, banners, and floating buttons can obstruct page content at small screen sizes. Check them during scroll and when the on-screen keyboard is open.

• Check that tables, charts, and long content remain readable on narrow screens.

  A layout that clips data can hide decisions or prices. Use a responsive table treatment or a clear alternate presentation rather than shrinking text beyond comfortable reading.

6. Forms, contact, booking, and commerce

• Submit every form with valid, invalid, incomplete, and boundary-case data.

  Happy-path checks miss common failures such as long names, punctuation, international addresses, missing optional values, and validation that rejects reasonable input.

• Confirm required fields are necessary and optional fields are labeled.

  Each extra request costs visitors time and creates data-handling work. Explain why sensitive or unusual information is needed, and avoid collecting information “just in case.”

• Verify form confirmation, notification routing, spam handling, and reply ownership.

  A success message is not enough if nobody receives the inquiry. Confirm the recipient, delivery, backup handling, and the person responsible for responding.

• Check email links, phone links, contact details, and contextual message defaults.

  Visitors may prefer their own email or calling app to a web form. Ensure links work on mobile and any generated subject or message contains the correct page context without unwanted characters.

• Verify booking availability, time zone, confirmation, and cancellation behavior.

  A booking flow can create real commitments. Test the full lifecycle, including time-zone display, confirmation delivery, rescheduling, cancellation, and what happens when a slot is taken.

• Test payment success, declines, cancellation, refund information, and order confirmation.

  Payment failures and duplicate charges have direct customer and financial impact. Use the provider’s test mode and confirm the store records the final payment state correctly.

• Check the full cost, shipping or delivery options, taxes, and return information before purchase.

  Customers need to understand the transaction before committing. The amount and policies shown should match what the business can actually provide.

• Confirm transactional emails are accurate and do not expose unnecessary personal information.

  Receipts and confirmations help customers understand what happened, but emails can be forwarded or seen on shared devices. Include what is useful and protect sensitive details.

7. Cookies, analytics, pixels, and other tracking

• Inventory cookies, local storage, pixels, SDKs, tags, and embedded third-party content.

  Tracking may be introduced by analytics, maps, video players, chat, advertising, or a tag manager. You cannot describe or control collection accurately without knowing what actually runs.

• Classify each technology by purpose, provider, data collected, and retention.

  A practical inventory supports privacy disclosures, consent choices where required, and removal of tools that are no longer needed. Vendor labels such as “analytics” do not explain the full data flow.

• Decide whether a cookie notice or consent mechanism is required for the actual audience and technologies.

  Cookie rules differ by jurisdiction and by technology. For example, the UK ICO's current storage and access technologies guidance covers cookies, tracking pixels, and similar technologies. Do not assume every U.S. site always needs the same banner, or that a banner by itself makes tracking compliant; obtain advice for the markets you serve.

• Where prior consent is required, prevent optional tracking from firing before consent.

  A banner that records a choice after advertising or analytics tags have already run does not provide the control it appears to offer. Test network requests and storage before and after each choice.

• Offer meaningful choices and make rejection or withdrawal as usable as acceptance.

  A control should let visitors make the choice the interface describes. Dark patterns can undermine trust and may conflict with legal requirements in some jurisdictions.

• Record consent state and honor later changes across relevant pages and sessions.

  Consent is not a one-time decoration. Verify that preferences persist appropriately, that a visitor can revise them, and that revoked choices stop the associated optional technology.

• Check whether California Global Privacy Control (GPC) signals need to be honored.

  California privacy rules provide an opt-out preference signal for covered businesses in relevant circumstances. The California Attorney General's CCPA overview describes consumer opt-out rights, including via GPC. Applicability and implementation depend on the business and processing, so verify the current rules rather than relying on a generic cookie banner.

• Review analytics configuration for URL parameters, form fields, and sensitive data.

  URLs and event payloads can accidentally contain names, emails, search terms, or other personal details. Remove sensitive values before they reach analytics systems or logs.

• Re-test the site after adding or updating any third-party script.

  A tag can change cookies, page performance, security exposure, or user interface behavior. A launch review is only accurate for the integrations currently loaded on the site.

8. Personal data, privacy notices, and retention

• Map what personal information is collected, where it enters, and why it is needed.

  Data may arrive through forms, checkout, analytics, support, booking, email, or vendors. A data map helps the business avoid collecting information without a purpose and respond to requests accurately.

• Document where each data type is stored and which systems or vendors receive it.

  A website may send form details to email, a CRM, a scheduling platform, and analytics at once. Knowing each destination helps assess access, retention, security, and vendor obligations.

• Set a retention period and deletion process for each category of personal data.

  Keeping information indefinitely increases exposure and makes privacy requests harder to fulfill. The FTC's data-protection guide recommends a retention policy that identifies what to keep, for how long, and how to dispose of it securely.

• Limit access to personal data to people and vendors who need it for their role.

  Fewer unnecessary copies and permissions reduce the number of accounts or devices that could expose customer information. Review access when staff responsibilities change.

• Write a privacy notice that matches current data practices and vendor use.

  A copied template can omit real tracking or promise practices the business does not follow. Describe categories, purposes, sharing, choices, retention, and contact routes as applicable to the business.

• Provide a clear notice at collection where applicable.

  Privacy rules may require information at or near the point data is collected, not only in a policy footer. The California CCPA text effective January 1, 2026 includes notice-at-collection requirements for covered businesses; confirm applicability and current details with qualified counsel.

• Determine whether privacy rights requests apply and establish a monitored intake process.

  Applicable laws may require businesses to receive, verify, track, and answer requests to access, correct, delete, or opt out of certain processing. A working contact route and assigned owner prevent requests from being missed.

• Review the privacy policy when tools, data uses, or laws change.

  The notice becomes inaccurate when a new analytics provider, advertising pixel, form field, or retention practice is added. Set a named owner and review trigger rather than relying on a policy’s publication date alone.

• Assess whether children or sensitive data are in scope.

  Child-directed services, health, financial, location, and other sensitive information can trigger additional requirements and risks. If a site targets children or knowingly collects children’s personal information, obtain specialist review before launch.

• Check data processing, confidentiality, and deletion terms with vendors.

  A vendor that receives personal information may have contractual and security responsibilities. Confirm roles, permitted uses, subprocessors, breach notice, retention, and return or deletion provisions as relevant.

9. Terms, policies, claims, and business disclosures

• Decide whether the site needs Terms of Use or Terms of Service and have them reviewed.

  Terms may explain acceptable use, intellectual property, accounts, service limits, and dispute processes, but their contents and enforceability depend on the business and applicable law. A template is not legal review.

• Publish accurate sales, payment, cancellation, refund, shipping, and return policies where relevant.

  Customers need these terms before they buy or book. The policy displayed must match the actual operational process and any promises made in product or service copy.

• Review subscription, renewal, trial, and cancellation flows with qualified counsel.

  Recurring charges and cancellation requirements are regulated and can change. Make material terms clear before enrollment and ensure the cancellation process works as described.

• Check that advertising, discounts, guarantees, and outcome claims are supportable.

  A disclaimer cannot rescue a misleading main claim. The FTC's advertising guidance explains substantiation and endorsement expectations; reviews and testimonials should reflect genuine experiences and disclose material connections where required.

• Include business identity and contact information appropriate to the transaction.

  Visitors need to know who operates the site and how to reach them. Commercial email, ecommerce, professional services, and regulated offerings can have different disclosure requirements.

• Review accessibility statements and compliance claims for accuracy.

  Do not claim a site is “fully accessible” or WCAG-conformant unless that claim is supported by a complete evaluation and maintained. A useful accessibility contact path is more credible than an unsupported guarantee.

• Check copyright notices, acceptable-use statements, and third-party terms where relevant.

  The site may display licensed assets or use APIs with attribution or use restrictions. Confirm the business has the rights and operational permissions needed for publication.

• Have a qualified professional review regulated content and jurisdiction-specific requirements.

  Legal, medical, financial, privacy, and accessibility obligations vary by activity and jurisdiction. This general checklist cannot determine which rules apply to an individual business.

10. Security, accounts, and infrastructure

• Confirm HTTPS works everywhere and HTTP redirects to the preferred HTTPS host.

  HTTPS protects data in transit and is essential for modern site integrity. Check every hostname, redirect, certificate chain, and mixed-content warning.

• Remove test accounts, default passwords, debug routes, and temporary access.

  Development shortcuts left in production can expose data or privileged functions. Remove what is no longer needed and rotate any credential that may have been shared.

• Use unique credentials and multifactor authentication for domain, hosting, email, and admin accounts.

  These accounts can control the website, customer data, or recovery path. A compromised shared password can let an attacker change content, redirect traffic, or lock out the business.

• Assign least-privilege roles and remove access for former team members.

  People should have only the access needed for their work. Reviewing permissions lowers the impact of a compromised or unused account.

• Keep frameworks, plugins, themes, dependencies, and integrations updated.

  Old dependencies may contain known vulnerabilities or incompatibilities. Establish who tracks updates and how changes are reviewed and deployed.

• Review admin routes, authorization rules, and private data access.

  Hiding a link is not access control. Confirm that unauthorized users cannot reach protected routes or retrieve another user’s data by changing an identifier.

• Protect secrets and API keys from browser bundles, source control, and public logs.

  Client-side code and public repositories can be inspected by anyone. Use server-side secret storage, rotate exposed keys, and grant each credential only the permissions it needs.

• Check form and API inputs for validation, rate limits, and abuse controls.

  Public endpoints can receive malformed data, spam, or automated abuse. Validate on the server, limit abusive traffic where appropriate, and avoid relying only on browser-side checks.

• Review security headers, content security policy, and third-party script permissions.

  Browser security controls can reduce the impact of some attacks, but an incorrect policy can also break site features. Test the actual production configuration and monitor changes.

• Confirm logs, error reports, and backups do not expose unnecessary personal data.

  Logs and backups can become overlooked copies of sensitive information. Limit access, define retention, redact secrets, and protect recovery data with appropriate controls.

• Document an incident contact and first-response procedure.

  A short plan helps the team preserve evidence, limit exposure, contact the right provider, and assess notification obligations instead of improvising during an incident.

11. Performance, media, and reliability

• Compress and size images for their actual display dimensions.

  Oversized images consume bandwidth and delay meaningful content, particularly on mobile networks. Keep suitable source quality and verify the rendered asset is not needlessly large.

• Check font loading, layout shift, and text visibility before fonts arrive.

  Late font swaps can move content or make text temporarily invisible. Use a sensible fallback and test the loading behavior under constrained conditions.

• Review third-party scripts and remove tools that do not serve a clear need.

  External scripts can slow pages, add tracking, introduce failures, and expand the attack surface. Each script needs an owner and a reason to remain.

• Test key routes on a slower connection and a lower-powered device.

  Fast development machines can hide delays and heavy interactions. Test whether main content and essential controls remain usable when loading takes longer.

• Measure Core Web Vitals with field data when available and lab tools during review.

  Field metrics reflect real visits, while lab measurements help diagnose controlled scenarios. Google’s current metrics include LCP, INP, and CLS; a single synthetic score is not the whole user experience.

• Check error rates, uptime monitoring, and integration failure alerts.

  A site can appear available while forms, booking, search, or payment integrations silently fail. Monitor the tasks that matter to the business, not only whether the home page returns a response.

• Verify backups and practice the recovery process for important site data.

  A backup is useful only if it can be restored within an acceptable time and includes the required data. Confirm what is backed up, how often, who can restore it, and how access is protected.

12. Search, sharing, and page metadata

• Set a unique, accurate title and description for each important page.

  Search systems and social platforms use page metadata as signals or presentation inputs. Google may generate its own title and snippet, so write accurate page content rather than promising a specific display.

• Choose a canonical URL and make internal links consistent with it.

  A page reachable at multiple hostnames or URL variants can create duplicate signals. Google treats canonicals as hints and considers redirects, internal links, and sitemaps together.

• Review sitemap entries and robots.txt against the pages intended for discovery.

  Sitemaps help discovery but do not guarantee indexing. Do not list private, duplicate, or unwanted pages, and ensure important content is not accidentally blocked from crawling.

• Check that important pages are reachable through ordinary links.

  Search crawlers and people use links to find content. A sitemap alone does not replace a useful internal linking structure.

• Verify redirects for changed or removed URLs.

  Redirects help visitors and search systems reach the replacement page and reduce broken bookmarks or inbound links. Avoid chains, loops, and blanket redirects to an unrelated page.

• Add accurate Open Graph and social preview information where sharing matters.

  A preview can help people understand a shared page before opening it. Check image crop, title, description, and canonical destination using platform preview tools when available.

• Validate structured data against visible page content and supported types.

  Structured data can help systems interpret content, but it must represent what visitors can see and does not guarantee a rich result. Remove markup for facts not actually present.

• Review image alt text and filenames for meaning, not keyword stuffing.

  Descriptive alternatives support visitors who cannot see an image and can provide context to search systems. Repeating keywords or describing irrelevant details reduces usefulness.

• Check analytics search-console properties and sitemap submission after launch.

  Verification gives the site owner a way to identify crawl, indexing, and performance issues. Submission is a discovery signal, not a promise that every URL will be indexed.

13. Analytics, email, and integrations

• Decide which measurements are necessary to answer business questions.

  Collecting fewer, more useful events can reduce privacy risk and make reports easier to interpret. Define what counts as an inquiry, booking, purchase, or other meaningful outcome.

• Check that consent and privacy settings match the analytics configuration.

  A policy that says one thing while tags collect something else damages trust and may create legal risk. Validate actual requests and account settings rather than relying on configuration labels.

• Test email delivery, sender authentication, replies, and unsubscribe handling where applicable.

  Customers may miss confirmations or marketing messages that fail authentication or land in spam. The FTC's CAN-SPAM guidance explains U.S. requirements for commercial email, including truthful headers and honoring opt-out requests.

• Test every CRM, calendar, map, payment, chat, and automation integration end to end.

  A connected tool may receive data in a different format than expected or fail without a visible message. Test realistic inputs, retries, duplicate events, and the path when the vendor is unavailable.

• Record vendor owners, account access, billing, and support contacts.

  Integrations can stop working when a subscription expires or an account owner leaves. An operational record makes recovery and routine maintenance faster.

14. Domain, hosting, deployment, and release

• Confirm the production domain, DNS, HTTPS certificate, and preferred hostname.

  DNS and certificates determine whether visitors reach the correct site securely. Check both apex and www behavior and remove records that point to old environments when safe.

• Search production content and assets for staging URLs and localhost references.

  A development URL in a button, canonical tag, email template, or API call can break the visitor journey or leak internal information. Search generated pages as well as source files.

• Verify production environment variables and provider settings.

  A release can build successfully while using test payment keys, a staging database, or a missing email service. Review each required configuration in the production environment.

• Confirm deployment rollback and database migration procedures.

  A release may expose a serious defect after launch. A practiced rollback and migration plan helps restore service without guessing under pressure.

• Check that the production build serves the expected routes and error pages.

  Local development may hide case-sensitive paths, missing files, or runtime errors. Review the deployed site using the actual production hostname and configuration.

• Confirm that staging is not publicly indexed or exposing real customer data.

  Test environments can reveal unfinished work or copies of production data. Restrict access and search visibility, and use anonymized data where practical.

15. Final user acceptance and first-day support

• Ask someone outside the build team to complete the top user journeys.

  Builders know where things are and may overlook confusing labels or missing context. A fresh observer can reveal failures before customers encounter them.

• Run a final accessibility pass on the deployed version, not only the design file.

  Implementation details, third-party widgets, and production content can introduce barriers not visible in a mockup. Recheck the actual page and its interactions.

• Check every critical journey with analytics and error monitoring enabled.

  The site needs to be observable after release. Confirm that success and failure events are recorded without sending sensitive values to the wrong system.

• Set a launch-day owner and a way to report urgent issues.

  A named person can triage a broken page, missed inquiry, or payment issue quickly. Publish an internal contact path and backup owner before launch.

• Verify that customer support knows what changed and how to escalate issues.

  Support staff may receive the first reports of confusing copy, failed integrations, or account problems. A short change note makes their response more accurate.

• Monitor forms, bookings, purchases, error logs, and uptime after release.

  Production behavior includes real devices, traffic, and vendor dependencies that staging cannot fully reproduce. Watch the critical paths closely during the initial release period.

• Schedule a post-launch review and assign ongoing content and technical owners.

  A website needs continued updates to remain accurate, secure, and useful. Review early feedback, unresolved defects, business measures, renewals, and maintenance responsibilities.

How to use the checklist

Open each item to read its rationale, then check it after reviewing evidence or recording a decision. A check means “reviewed and handled,” including a documented “not applicable” decision where appropriate. It does not certify legal compliance, accessibility conformance, security, or performance.

For a small brochure site, focus on accurate pages, accessibility, contact paths, tracking and data practices, security, and recovery. A site with accounts, payments, children’s features, sensitive data, subscriptions, or regulated services needs deeper specialist review. Keep a copy of decisions and owners in the project record; the browser saves checkmarks locally for convenience but is not a shared audit log or backup.

References and further reading

Accessibility standards

• W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Normative web accessibility standard; determine the applicable target with appropriate legal and accessibility advice.
• W3C Web Accessibility Initiative. WCAG 2.2 is a W3C Recommendation. Introduction to the standard’s status and updates.
• W3C Web Accessibility Initiative. Forms Tutorial. Practical guidance on labels, instructions, validation, and accessible interaction.

Privacy and data protection

• California Privacy Protection Agency. CCPA text effective January 1, 2026. Primary source for current statutory text; applicability and compliance should be assessed for the business’s circumstances.
• California Department of Justice. California Consumer Privacy Act. Consumer rights and high-level information about covered businesses.
• Federal Trade Commission. Protecting Personal Information: A Guide for Business. Practical guidance on inventory, minimization, access, retention, disposal, and incident planning.
• Federal Trade Commission. Complying with COPPA: Frequently Asked Questions. Guidance for websites and services that may collect personal information from children under 13.
• Information Commissioner's Office. Storage and access technologies guidance. UK guidance on cookies and similar technologies; relevant only where applicable to the site’s activities and audience.

Security and operational readiness

• Federal Trade Commission. Start with Security: A Guide for Business. Security practices for data minimization, protection, retention, and disposal.
• OWASP. Top 10:2025. Current awareness document covering common web application risk categories.
• OWASP Cheat Sheet Series. Session Management. Technical guidance for authenticated sessions, cookies, and secure transport.

Search, email, and performance

• Google Search Central. SEO Starter Guide. Official guidance on useful content, titles, links, and search discovery.
• Google Search Central. Sitemaps overview. How sitemaps support discovery and their limits.
• Google Search Central. Canonicalization and duplicate URLs. Official canonical URL guidance.
• Google web.dev. How Core Web Vitals metrics thresholds were defined. Background on real-user performance metrics and their thresholds.
• Federal Trade Commission. CAN-SPAM Act: A Compliance Guide for Business. U.S. commercial email requirements and opt-out handling.
• Federal Trade Commission. Consumer Reviews and Testimonials Rule: Questions and Answers. Guidance on reviews, testimonials, incentives, and disclosures.

Related Avisul guides

• Small-business website planning
• Accessibility review
• Application security review
• Software release readiness