lineharo

The Complete Website Launch Checklist

A successful website needs more than clean code or attractive design. It must be easy to use, discoverable in search, fast on real devices, accessible to different audiences, secure, measurable, and reliable after launch.

Use this checklist for a new release, a redesign, a migration, or a technical audit of an existing website. Not every item applies to every project, so mark irrelevant checks as not applicable instead of implementing features without a clear purpose. Automated tools are useful, but they should complement manual testing rather than replace it.

HTML and Document Structure

Every page uses the HTML5 doctype and declares the correct document language. The text direction is set when it differs from the default.
UTF-8 is declared near the beginning of the document and used consistently by the server, templates, and data sources.
Semantic elements such as header, nav, main, article, and footer describe the page structure.
Each page has one clear primary heading, and the remaining headings form a meaningful hierarchy without being chosen for their visual size.
Links use anchor elements with valid destinations; controls that perform actions use buttons.
The important content is present in the HTML and is not available only through images, CSS, or inaccessible JavaScript widgets.
Forms, tables, lists, quotations, dates, addresses, and code samples use elements that match their meaning.
IDs are unique, nesting is valid, and serious errors reported by an HTML validator have been resolved.
Production HTML is compressed in transit. Minification is optional when it provides no meaningful additional saving.
The page remains understandable if styles or images fail to load.

CSS, Responsive Design, and Browser Support

The viewport meta tag is configured for responsive layouts.
Pages reflow at narrow viewport widths and when zoomed; ordinary content does not force horizontal scrolling.
Text can be enlarged without being clipped, overlapping other content, or hiding controls.
Layouts work with long headings, translated text, empty states, validation messages, and user-generated content.
Hover effects have equivalent focus and touch behavior; essential information is never available only on hover.
Motion respects the user’s reduced-motion preference, and nonessential animation can be paused or disabled.
The website has been tested in the current versions of the browsers and on the device types supported by the project.
Production CSS is minified, cacheable, and divided according to actual loading needs instead of being forced into one large file.
Unused styles and render-blocking resources have been reduced without breaking progressive rendering.
A print stylesheet is available when users are expected to print invoices, tickets, articles, or other documents.

Images and Media

Images are compressed and delivered in an efficient format appropriate to the content and browser support requirements.
Responsive images use suitable source sizes so that small screens do not download unnecessarily large files.
Image width and height or an aspect ratio are reserved to prevent layout shifts while files load.
Informative images have concise, contextual alternative text; decorative images use an empty alternative.
Images below the initial viewport are lazy-loaded, while the main above-the-fold image is discovered and prioritized early.
Important text and instructions are available as real text rather than being embedded only in an image.
Favicons and application icons are available in the formats and sizes required by the supported browsers and devices.
Video and audio do not start unexpectedly with sound and include user controls.
Prerecorded video has accurate captions; transcripts and audio descriptions are provided when the content requires them.
Posters, thumbnails, and media files are optimized and do not block the rest of the page from loading.
PDFs and downloadable documents are optimized, accessible, clearly labeled with their format and size, and accompanied by an HTML alternative when practical.

JavaScript and Application Behavior

The production console is free of uncaught errors, failed network requests, and avoidable warnings.
Noncritical scripts are deferred, loaded asynchronously, or imported only when the relevant feature is needed.
Bundles are minified and split by actual usage; unused code, development tools, and unnecessary polyfills are excluded from production.
Core content and navigation do not depend on a large client-side bundle before they become usable.
Search-critical content and links are present in rendered HTML; JavaScript-heavy applications use rendering or pre-rendering appropriate to their architecture.
Forms and essential actions have a useful fallback or a clear error when scripts, APIs, or third-party services fail.
Browser Back and Forward buttons, refresh, deep links, and shareable URLs preserve the expected application state.
Loading, success, empty, offline, timeout, and error states have all been designed and tested.
Third-party scripts are limited, reviewed, and prevented from blocking or breaking the main experience.
Dependencies are maintained, licensed appropriately, and checked for known vulnerabilities.

Performance and Core Web Vitals

Performance is tested on representative mobile hardware and network conditions, not only on a fast development computer.
At the 75th percentile of real visits, Largest Contentful Paint is at most 2.5 seconds, Interaction to Next Paint is at most 200 milliseconds, and Cumulative Layout Shift is at most 0.1.
Real-user data is monitored where traffic volume permits, and laboratory tests are used to diagnose regressions before release.
HTML, CSS, JavaScript, SVG, and other text resources use Brotli or gzip compression where supported.
Versioned static assets have long-lived cache headers; HTML and frequently changing data use an intentional revalidation policy.
Web fonts use efficient files, sensible subsets, and an appropriate display strategy. Only critical fonts and assets are preloaded.
Render-blocking requests, request chains, redirects, and unnecessary third-party connections have been reduced.
A performance budget limits page weight, request count, JavaScript execution, and key user-experience metrics.
The origin and database respond reliably under expected traffic, and important pages are tested under realistic load.
A CDN or edge cache is used when it materially improves delivery to the intended audience.

Search Indexing and Technical SEO

Search engines can recommend a page only after they discover, crawl, render, and index it. Technical SEO creates the conditions for that process, but it cannot compensate for weak content or an unhelpful product.

Public pages return a successful HTTP status and are accessible to visitors and search crawlers without authentication.
The production robots.txt file is reachable and does not accidentally block important pages or required resources.
Pages that should appear in search do not contain an unintended noindex directive. Private content is protected by authentication rather than robots.txt alone.
The XML sitemap contains absolute, canonical, indexable URLs that return successful responses, and its update process is automated when appropriate.
The website is verified in Google Search Console and other webmaster tools relevant to its target markets; the sitemap has been submitted.
Important URLs are inspected after launch to confirm that search engines can crawl, render, and index them.
One preferred HTTPS hostname is used consistently. Other protocol, host, and legacy index-file variants redirect to it in as few hops as possible.
Retired or changed URLs use a tested redirect map; permanently removed content returns 404 or 410 instead of a soft 404.
Duplicate and parameterized URLs have an intentional indexing strategy. Canonical annotations point to genuine equivalents and do not hide useful filter or pagination pages by accident.
Canonical pages use a consistent self-referencing canonical URL, and the same preferred URLs appear in internal links, sitemaps, structured data, and alternate-language annotations.
URLs are short, descriptive, stable, and readable. Words are normally separated with hyphens, and tracking parameters are not used in permanent internal links.
Every indexable page has a concise, descriptive, and distinct title element and a useful meta description written for that page.
Each page has a clear search intent and original, people-first content that answers the visitor’s question without padding or a fixed word-count target.
Relevant search terms, entities, and synonyms appear naturally in the title, main heading, body, link text, and image alternatives where they improve clarity; no keyword-density target is used.
Pages targeting the same intent have been consolidated or differentiated to prevent unnecessary competition and duplication.
Important pages receive crawlable internal links with descriptive anchor text and are not orphaned or buried unnecessarily deep in the site.
Breadcrumbs reflect the information architecture and link to useful parent pages.
Paginated collections have crawlable URLs and sequential links; later pages are not all canonicalized to the first page.
Multilingual or multi-regional equivalents use valid, reciprocal hreflang annotations and send users to the corresponding page rather than a generic home page.
Mobile and desktop visitors receive equivalent primary content, headings, metadata, structured data, and image alternatives.
Structured data describes visible page content, uses a supported type, and passes the relevant validation tools.
Open Graph and other social metadata produce an accurate title, description, image, and canonical URL when a page is shared.
Internal links do not lead through avoidable redirects or to broken, blocked, or noncanonical destinations.
Staging domains, preview URLs, search results, and low-value generated pages cannot leak into the production search index.

Content Quality and Search Appearance

The headline accurately describes the page and is compelling without clickbait or unsupported promises.
The introduction confirms the page’s purpose quickly, and the main answer is not hidden behind a long preamble.
Content is accurate, current, proofread, and reviewed by a person with appropriate subject knowledge.
Claims, quotations, statistics, and recommendations are supported by primary or trustworthy sources where necessary.
Dates, authorship, organization details, and update information are shown when they help readers assess the content.
Headings, summaries, lists, tables, and examples make long content easy to scan without fragmenting it into thin pages.
The title and meta description set expectations that the visible page fulfills; they are not stuffed with repeated terms.
Search-result enhancements such as Article, Product, LocalBusiness, Video, or Breadcrumb markup are used only when the page meets their requirements.
A relevant, high-quality sharing image is available and remains legible when cropped on different platforms.
Existing content has an owner and review schedule so that obsolete instructions, prices, links, and screenshots can be updated or removed.

Usability and Conversion

Each important page has a clear purpose and an obvious next step that can be completed without unnecessary assistance.
Navigation, terminology, component behavior, and visual hierarchy are consistent throughout the website.
Buttons and links have clear labels and sufficiently large click or touch targets; destructive actions require confirmation when appropriate.
Contact details are easy to find, and telephone numbers and email addresses use appropriate links.
Forms request only necessary information and use visible labels, suitable input types, autocomplete attributes, and clear required-field indicators.
Validation occurs at a helpful time, explains how to fix each problem, preserves entered data, and moves focus to an error summary when appropriate.
Submitting a form shows progress, prevents accidental duplicates, and provides an unambiguous success or failure message with a recovery path.
Important tasks can be completed without creating an account unless registration is genuinely required; password and sign-in flows support password managers.
Pop-ups, consent prompts, sticky controls, and advertisements do not cover essential content or interrupt a task unnecessarily.
Localization uses the correct language, currency, units, addresses, date formats, and contact information for the selected market.
A useful 404 page helps visitors recover through navigation, search, or relevant links while the server still returns a real 404 status.
Representative users have tested the main journeys on phones and computers, including slow networks and failure scenarios.

Accessibility

Aim for WCAG 2.2 Level AA unless the project has a stricter legal or contractual requirement. Automated scans catch only part of the issues, so include keyboard, screen-reader, zoom, contrast, and real-user testing.

Every function can be completed with a keyboard alone, focus moves in a logical order, and no component creates a keyboard trap.
Keyboard focus is clearly visible and is not hidden behind sticky headers, dialogs, cookie banners, or other content.
A skip link and semantic landmarks let assistive-technology users bypass repeated navigation.
Text and meaningful interface elements meet the required contrast, and color is never the only way information or status is communicated.
Controls have accessible names, states, roles, and instructions that match their visible labels and behavior.
Dynamic status messages, validation errors, dialogs, menus, tabs, and custom widgets work with screen readers and other assistive technology.
Content remains usable at 200% text zoom and in reflow layouts without loss of information or functionality.
Touch targets have adequate size or spacing, and actions that require dragging also provide a simple pointer alternative.
Time limits can be extended where possible, moving content can be paused, and flashing content stays below safety thresholds.
Page titles, headings, labels, link purposes, and language changes are programmatically identifiable.
Accessibility is tested after third-party widgets, payment flows, chat tools, and consent managers are integrated.
An accessibility statement and a working method for reporting barriers are provided when appropriate.

Privacy and Legal Requirements

Legal obligations vary by country, audience, and business model. Treat this section as a prompt for review, not as legal advice.

The privacy notice accurately explains what data is collected, why it is processed, how long it is retained, and who receives it.
Nonessential analytics, advertising, and personalization technologies wait for valid consent where required.
Consent choices are specific, equally easy to accept or reject, recorded when necessary, and easy to change later.
Forms collect only the data required for their purpose and do not send sensitive information to analytics or advertising tools.
Data retention, deletion, export, correction, and user-request procedures are documented and tested.
Terms of service, returns, refunds, shipping, warranties, company details, and age restrictions are published when relevant.
Copyright notices, asset licenses, font licenses, and permissions for testimonials or user-generated content are in order.
Regional requirements have been reviewed by a qualified professional before launch.

Analytics and Monitoring

A measurement plan connects business questions to events, conversions, and reports instead of tracking every possible interaction.
Page views, forms, calls, registrations, purchases, refunds, and other key events are recorded once and with the correct values.
Analytics respects consent choices, excludes sensitive or personally identifiable data, and filters internal or test traffic where practical.
Campaign parameters follow a documented naming convention and are never added to permanent internal links.
Search Console, uptime, error logging, Core Web Vitals, and application health are monitored alongside traffic analytics.
Session-replay and heat-map tools mask private fields and are enabled only after a privacy and performance review.
Dashboards and alerts have owners, useful thresholds, and a response process.
Tracking has been verified in production with browser privacy settings, consent states, ad blockers, and common purchase or lead journeys.

Domain, DNS, and Email

Domain registration uses current ownership details, renewal is protected, and more than one authorized person can recover the account.
DNS records are documented, monitored, and free of obsolete hosts or conflicting values.
TLS certificates cover every public hostname, renew automatically, and are monitored for expiry and configuration errors.
DNSSEC and CAA records are considered when they fit the organization’s infrastructure and operational capability.
Mail-sending domains have valid SPF, DKIM, and DMARC policies that are monitored before enforcement is tightened.
Transactional messages and contact-form notifications are authenticated, delivered reliably, and do not expose recipient addresses.
The canonical domain, analytics properties, webmaster tools, CDN, and email services are owned by organizational accounts rather than a former contractor’s personal account.

Server and HTTP Configuration

Valid pages return the intended 2xx response, redirects return the appropriate 3xx response, and missing or removed resources return a genuine 404 or 410 response.
Redirects preserve useful paths and query data, avoid loops and long chains, and do not send every missing page to the home page.
Content types, character sets, language information, cache rules, and content-disposition headers are correct for each resource.
HTTPS is enforced without mixed content. HSTS is enabled only after every required subdomain is ready for permanent HTTPS use.
Security headers such as Content Security Policy, frame restrictions, MIME sniffing protection, and referrer policy are configured for the application.
Compression, caching, and the Vary header correctly reflect content negotiation and do not fragment caches unnecessarily.
Server, application, CDN, and database logs use synchronized timestamps and contain enough context for diagnosis without recording secrets or excessive personal data.
Health checks, uptime monitoring, capacity alerts, and service-level targets match the project’s actual business requirements.
Error pages do not reveal stack traces, framework versions, file paths, database details, or other sensitive implementation information.

Security and Recovery

Operating systems, frameworks, packages, plugins, and build images are patched and scanned on a documented schedule.
Administrative access requires multi-factor authentication and follows least privilege; unused accounts and permissions are removed promptly.
Secrets are stored in an approved secrets manager or protected environment, never in source control, client-side bundles, or shared text files.
Passwords are hashed with a modern password-hashing algorithm, and authentication flows resist enumeration, brute force, and session fixation.
Inputs are validated, outputs are encoded for their context, database queries are parameterized, and state-changing requests have appropriate CSRF protection.
File uploads restrict type and size, use generated storage names, are scanned when necessary, and cannot execute as application code.
Rate limits and abuse controls protect sign-in, registration, password reset, search, forms, APIs, and expensive operations.
Backups are encrypted, isolated from the production account, retained according to recovery objectives, and restored in a scheduled test.
Malware, integrity, authentication, dependency, and application-error alerts reach someone who can respond.
Staging, preview, monitoring, storage, and administrative systems are not publicly exposed without appropriate access controls.
The incident-response plan defines contacts, containment, recovery, customer communication, and credential-rotation procedures.
Deployments are reproducible, tested, reviewed, and reversible without relying on an unverified backup.

E-commerce, Services, and Local Businesses

These checks apply only when the website sells products or services or represents a location-based organization.

Prices, currencies, taxes, stock, delivery times, payment methods, returns, and offer conditions are complete and consistent across the page, checkout, feed, and structured data.
Product and service pages contain original descriptions, specifications, images, availability, and a visible path to purchase or enquire.
Out-of-stock and discontinued pages have an intentional strategy: preserve useful pages, explain availability, and suggest genuine alternatives instead of returning a misleading error.
Checkout supports guest purchase where appropriate, shows the total cost before payment, and allows customers to review and correct the order.
Payment data is handled by a compliant payment provider, and successful, failed, cancelled, duplicate, and delayed payment states are tested.
Product feeds match landing pages and are validated in the merchant platforms used by the business.
Business name, address, phone number, hours, service area, and website URL are accurate and consistent across the site and official business profiles.
Regional landing pages provide genuinely useful local information rather than near-duplicate text with place names replaced.
Reviews, ratings, certifications, licenses, guarantees, and scarcity claims are authentic, current, and presented without manipulation.

Promotion and Off-Page SEO

Launch communication and ongoing promotion reach communities, customers, partners, and publications that genuinely care about the topic or product.
Important organization and author profiles are complete, accurate, and linked to the correct website.
Relevant editorial links are earned through useful resources, expertise, partnerships, and public relations rather than bought or automated link schemes.
Broken links and unlinked brand mentions are reviewed for legitimate opportunities to restore or clarify references.
Backlink growth, referral traffic, spam patterns, and manual actions are monitored without trying to control every anchor phrase.

Final Pre-Launch Checks

A content freeze or migration plan identifies the final source of truth, owners, timing, and rollback decision.
The redirect map, canonical URLs, robots directives, sitemap, analytics, consent settings, and production environment variables have been checked on the live hostname.
Temporary passwords, test accounts, sample orders, placeholder copy, debugging tools, and staging integrations have been removed or replaced safely.
Navigation, search, forms, authentication, email, downloads, checkout, payments, and third-party integrations pass an end-to-end production smoke test.
The website has been crawled for broken links, redirect chains, duplicate metadata, orphan pages, and accidental indexing restrictions.
Key pages have been checked manually on representative browsers, screen sizes, input methods, and network conditions.
A current backup or deployment artifact exists, the rollback procedure is documented, and the person authorized to use it is available.
DNS, certificate, uptime, application errors, server capacity, conversions, and search indexing are monitored closely after release.
Ownership of post-launch fixes, content updates, security patches, accessibility issues, and analytics review is assigned before the project is considered complete.

After Launch

A checklist is a release baseline, not a one-time guarantee of quality. Browsers, search systems, dependencies, laws, content, and user expectations change. Schedule recurring reviews, monitor real behavior, fix regressions, and keep the checklist aligned with the risks and goals of the website.