Website Launch Checklist 2026: 150+ Items to Cover

Pre-launch SEO foundations

The pre-launch SEO track is about making sure search engines can crawl, render, and understand your site the moment DNS flips. Launches that skip this track routinely lose 20 to 40 percent of baseline organic traffic in the first month because canonicals, robots directives, or schema were misconfigured at cutover. Work through these items during the final two weeks before launch, not the day of.

Pair this section with our deeper technical SEO audit checklist if you inherited a legacy site with significant debt. For new builds, the items below are the minimum bar.

1. Verify robots.txt allows crawling. Remove any staging-era Disallow: / rule and confirm the file is served at /robots.txt with a 200 status.
2. Publish a valid XML sitemap. Include only canonical, indexable URLs, reference it from robots.txt, and submit to Google Search Console and Bing Webmaster Tools on launch day.
3. Set canonical tags on every indexable page. Use absolute URLs on the production domain and confirm self-referencing canonicals for unique content.
4. Audit noindex directives. Search the codebase for any lingering noindex meta tags or X-Robots-Tag headers carried over from staging.
5. Confirm hreflang tags (if multilingual). Each language variant must reference all others, including a self-reference and an x-default.
6. Validate structured data. Run every template through Google's Rich Results Test and the Schema.org validator. Fix errors before launch; warnings can be triaged post-launch.
7. Set up Google Search Console. Verify the new domain via DNS TXT record well before launch so you can submit the sitemap immediately on cutover.
8. Set up Bing Webmaster Tools. Bing remains the back-end for ChatGPT search and other AI assistants, so indexation here matters more in 2026 than it did three years ago.
9. Build a 301 redirect map for URL changes. Map every old URL with organic traffic or backlinks to the closest new equivalent, and deploy redirects server-side.
10. Test redirects with a crawler. Use Screaming Frog or Sitebulb to confirm chains do not exceed one hop and that no redirect returns 302.
11. Check internal link graph. No orphaned pages, no links to staging URLs, and every primary nav link resolves to a 200.
12. Set up 404 monitoring. Route 404s to a helpful page and log them so you can identify broken inbound links within the first week.
13. Configure preferred domain. Pick www or apex, redirect the other permanently, and make sure canonicals, sitemap, and internal links all use the chosen version.
14. Verify HTTPS is enforced. HTTP URLs must 301 to HTTPS, and HSTS should be enabled with at least a six-month max-age.
15. Check image alt text coverage. Every content image needs descriptive alt text; decorative images get alt="".
16. Audit title tag uniqueness. No two indexable pages should share a title. Length stays between 30 and 60 characters.
17. Audit meta description uniqueness. Aim for 140 to 160 characters, avoid duplication, and write for click-through, not keyword stuffing.
18. Confirm Open Graph and Twitter card coverage. Every template renders a correct OG image, title, description, and URL.
19. Set up analytics before launch. GA4, Search Console, and a server-side log source should all be capturing data from minute zero.
20. Run a full site crawl. The final pre-launch crawl should report zero broken internal links, zero redirect chains, and zero missing canonicals.
21. Snapshot current rankings and backlinks. Export from Ahrefs or Semrush one week before launch so you have a baseline for post-launch comparison.

Performance and Core Web Vitals

In 2026, Core Web Vitals are not a tiebreaker, they are a threshold. Google's March 2026 core update reinforced that pages failing LCP, INP, or CLS targets lose eligibility for top rankings on competitive queries. The targets remain LCP ≤2.5s, INP ≤200ms, and CLS ≤0.1, measured on 75th-percentile field data. Treat every item below as a blocker for launch, not a nice-to-have.

For a deeper look at how pages actually render and where the bottlenecks hide, read our browser rendering performance guide, and cross-reference the revenue data in our page speed statistics roundup.

1. Set a performance budget. Agree on JS bundle size, total page weight, and TTFB caps before development starts, then enforce in CI.
2. Measure LCP element on every template. Identify the largest above-the-fold element (usually a hero image or headline) and optimize it explicitly.
3. Preload the LCP image. Use <link rel="preload" as="image"> with correct imagesrcset for responsive LCP assets.
4. Use modern image formats. Serve AVIF with a WebP fallback for hero imagery; PNG and JPEG only where transparency or compatibility demands it.
5. Set explicit width and height on every image. Missing dimensions are the top cause of CLS regressions at launch.
6. Lazy-load below-the-fold images. Use loading="lazy" or the framework's Image component, but never lazy-load the LCP image.
7. Eliminate render-blocking resources. Inline critical CSS, defer non-critical JS, and load third-party scripts asynchronously.
8. Audit third-party scripts. Every tag (analytics, chat, A/B testing) adds to INP. Remove anything not actively used.
9. Self-host critical fonts. Preload one weight of the primary font, use font-display: swap, and subset to reduce file size.
10. Enable HTTP/2 or HTTP/3. Confirm via your CDN that multiplexed connections are serving all static assets.
11. Configure CDN caching. Static assets should have long-lived cache headers (1 year with hashed filenames); HTML should cache for minutes, not hours.
12. Verify Brotli compression. Text assets (HTML, CSS, JS, SVG) should be compressed with Brotli at level 4 or higher.
13. Run Lighthouse on five representative templates. Home, category, detail, article, and conversion pages must each score 90+ on performance.
14. Run PageSpeed Insights with field data. If the site has existing traffic, check the CrUX report; if not, commit to re-checking weekly post-launch.
15. Test INP with real interactions. Click every primary CTA, open every dropdown, and confirm interaction latency stays under 200ms in the 95th percentile.
16. Check CLS on slow connections. Throttle to Slow 4G in DevTools and watch for late-loading ads, embeds, or cookie banners shifting layout.
17. Audit JS bundle size. Use webpack-bundle-analyzer or the framework's equivalent; flag any single chunk over 150KB gzipped.
18. Confirm server response time. TTFB should stay under 600ms globally for cached HTML and under 1.2s for dynamic routes.

Accessibility and WCAG 2.2 AA

Accessibility is both a legal requirement and a quality signal. In the US, the DOJ's 2024 Title II rule and ongoing ADA litigation make WCAG 2.2 AA the de facto compliance bar for commercial sites. In the EU, the European Accessibility Act took effect in June 2025. Beyond compliance, accessible sites consistently show lower bounce rates, higher conversion, and better indexation.

Our web development team treats the items below as launch blockers, and no build leaves our pipeline with outstanding axe or Lighthouse accessibility violations.

1. Run axe DevTools on every template. Zero critical or serious violations is the bar; moderate issues should have a remediation ticket.
2. Check color contrast. Body text needs 4.5:1 against its background; large text (18pt+ or 14pt bold) needs 3:1.
3. Verify keyboard navigation. Tab through every interactive element; focus order must be logical and every control reachable.
4. Show visible focus states. Default browser focus rings are acceptable; if you customize, maintain a 3:1 contrast ratio against the background.
5. Add skip links. A "Skip to main content" link at the top of every page saves keyboard users from tabbing through the nav.
6. Use semantic HTML. button for buttons, a for links, nav/main/footer landmarks on every page.
7. Label every form field. Every input needs a visible or aria-labelled label; placeholder text alone does not count.
8. Announce form errors. Use aria-invalid and aria-describedby to connect error messages to their fields for screen reader users.
9. Write descriptive alt text. Describe the image's purpose in context, not just its visual contents; decorative images use empty alt.
10. Caption video content. Auto-generated captions are a starting point; hand-correct them before launch.
11. Test with a screen reader. VoiceOver (macOS/iOS) or NVDA (Windows) on the top five templates catches what axe misses.
12. Avoid color-only meaning. Status indicators, required-field markers, and error states need a non-color cue (icon, text, pattern).
13. Respect reduced motion. Honor prefers-reduced-motion to disable parallax, auto-playing video, and large animated transitions.
14. Make targets large enough. WCAG 2.2 AA requires touch targets of 24×24 CSS pixels minimum; 44×44 is the iOS and Android recommendation.
15. Do not trap focus. Modals must return focus to the trigger on close; no element should capture tabbing indefinitely.

Security hardening

Security work at launch is about reducing attack surface and making sure the boring defaults are correct. The items below focus on what a site owner controls: transport encryption, headers, secret handling, and basic abuse prevention. Deeper application security (pen testing, threat modeling) sits upstream of this checklist but should have completed before you reach launch-day.

1. Enforce HTTPS site-wide. Redirect all HTTP traffic to HTTPS with a 301 and serve HSTS with at least a six-month max-age and includeSubDomains.
2. Use modern TLS. TLS 1.2 minimum, TLS 1.3 preferred; disable SSL 3, TLS 1.0, and TLS 1.1 at the load balancer or CDN.
3. Renew certificates automatically. Confirm Let's Encrypt or your CA's auto-renewal is wired up; a manual renewal is a post-launch incident waiting to happen.
4. Set a Content Security Policy. Start with Report-Only, log violations for a week, then enforce. Disallow unsafe-eval and scope script sources tightly.
5. Add X-Content-Type-Options: nosniff. Prevents browsers from MIME-sniffing and opening up XSS vectors.
6. Add Referrer-Policy. strict-origin-when-cross-origin is a reasonable default for marketing sites.
7. Add Permissions-Policy. Explicitly deny camera, microphone, geolocation, and other APIs you do not need.
8. Protect against CSRF. Every state-changing form or API route needs a CSRF token or SameSite cookie protection.
9. Sanitize all user input. Never interpolate user-supplied strings into HTML without escaping; prefer framework-native templating over manual string concatenation.
10. Keep secrets out of the client bundle. Audit the production JS bundle for any API keys, database URLs, or tokens; rotate any that leaked.
11. Rotate all staging credentials. Assume every key used during development could be compromised; rotate before production traffic hits.
12. Rate-limit public endpoints. Contact forms, search, auth, and any write API need per-IP rate limits; 60 requests per minute is a reasonable starting point.
13. Add bot protection to high-value endpoints. Cloudflare Turnstile, hCaptcha, or reCAPTCHA v3 on login, signup, and contact forms.
14. Enable secure cookie flags. Secure, HttpOnly, and SameSite=Lax (or Strict) on every cookie.
15. Run a final dependency audit. npm audit, Snyk, or Dependabot should show zero high or critical vulnerabilities in production dependencies.

Analytics and tracking

Analytics verification is the most commonly botched part of a launch. The day-one goal is simple: every pageview, every conversion, and every consent state should be landing in GA4 with the correct parameters. Our analytics team runs the items below on every launch, and treats any gap as a go/no-go blocker.

1. Install GA4 via server-side GTM if possible. First-party data collection survives ad blockers and reduces reliance on third-party cookies.
2. Configure consent mode v2. Required for EEA traffic and increasingly enforced by Google; set default state to denied and unlock on user consent.
3. Set up the cookie banner. Granular categories (necessary, analytics, marketing), clear decline option, and no pre-ticked boxes.
4. Define conversion events. Every primary goal (form submit, signup, purchase, phone click) needs a named event with the correct parameters.
5. Test in GA4 DebugView. Walk every conversion path on the production domain; confirm each event fires with expected params.
6. Configure GTM preview mode. Use the Tag Assistant to verify every tag fires on the correct trigger with no duplicates.
7. Link GA4 to Google Ads. Import conversions into Ads within 24 hours of launch if you are running paid traffic.
8. Link GA4 to Search Console. Enables the organic search queries report inside GA4's Acquisition overview.
9. Set up audiences. Define remarketing audiences in GA4 on day one so the lookback window starts accumulating immediately.
10. Configure cross-domain tracking. If the site spans subdomains or connects to a booking/checkout tool, set up cross-domain measurement in GTM.
11. Filter internal traffic. Exclude office IPs and VPN ranges so team QA does not inflate numbers.
12. Set the correct data retention. GA4 defaults to 2 months; change to 14 months unless you have a specific reason not to.
13. Set up conversion value tracking. Pass monetary value on every purchase, lead, or booking event for ROAS analysis.
14. Create a baseline dashboard. Looker Studio or GA4 Explorations showing traffic, conversions, and CWV in one view; review weekly post-launch.
15. Document the measurement plan. Write down every event, parameter, and conversion, plus who owns each, so team turnover does not lose institutional knowledge.

Content quality and legal

Content quality is the easiest section to rush and the most visible when it breaks. A single typo on the homepage or a missing privacy policy link can undo months of design and engineering work. The items below are quick to verify but frequently overlooked in the final week.

1. Final proofread every page. Two pairs of eyes, one of whom did not write the copy; read every word aloud.
2. Verify contact information. Phone, email, and physical address match your Google Business Profile and other directory listings.
3. Publish a privacy policy. Must address cookies, analytics, third-party processors, and user rights; link from the footer of every page.
4. Publish terms of service. Required for any site that collects data or sells a product; link from the footer.
5. Publish a cookie policy. Can be combined with the privacy policy; must list every cookie by name and purpose.
6. Add an accessibility statement. Declare your WCAG conformance level, testing methodology, and a contact for accessibility issues.
7. Credit image licensing. Stock photo attribution where required by license; avoid using any image you do not have rights to.
8. Design a branded 404 page. Offer search, primary nav, and a clear path back to the homepage.
9. Design a branded 500 page. Even static servers occasionally return errors; a styled page preserves trust during an incident.
10. Check every CTA copy. Action-oriented, specific, and consistent across the site (not "Submit" on one form and "Send" on another).
11. Verify social proof claims. Client logos, testimonials, and statistics all need documented permission and accuracy checks.
12. Confirm copyright year. Footer year should reflect the current year and auto-update in code, not be hardcoded.

SEO metadata and social previews

Metadata is what search and social platforms use to represent your site in other surfaces. A strong title and OG image can double click-through rate from the same ranking position. The items below focus on the details that most teams skip and regret later.

1. Write unique title tags for every page. 30 to 60 characters, primary keyword front-loaded, brand at the end if space allows.
2. Write unique meta descriptions. 140 to 160 characters, written for click-through, not keyword stuffing; each page unique.
3. Configure Open Graph tags. og:title, og:description, og:image, og:url, and og:type on every template.
4. Configure Twitter card tags. twitter:card set to summary_large_image for marketing pages and articles.
5. Generate high-quality OG images. 1200×630px, under 300KB, with readable text at thumbnail size.
6. Set canonical URL per page. Absolute URLs on the production domain; self-referencing on unique content.
7. Add a favicon set. ICO, 16×16 PNG, 32×32 PNG, 180×180 Apple touch icon, and 512×512 maskable PNG for PWA.
8. Add a web app manifest. manifest.json with name, short_name, theme_color, and icon set.
9. Set theme-color meta tag. Matches your brand primary; renders in mobile browser chrome and in Android home-screen shortcuts.
10. Preview in Facebook Sharing Debugger. Scrape the URL, confirm OG tags render, and clear cache if you updated tags recently.
11. Preview in Twitter Card Validator. (Or the X equivalent) to confirm Twitter-specific card rendering.
12. Preview in LinkedIn Post Inspector. LinkedIn aggressively caches OG images; clear the cache on any shared URL before launch.
13. Preview in iMessage and Slack. Share a URL in each to confirm unfurling works; most common place stakeholders first see launch links.
14. Add author metadata on articles. article:author OG tag and author schema for E-E-A-T signals on editorial content.
15. Confirm JSON-LD schema on every template. Organization on homepage, Article on posts, BreadcrumbList on deep pages, and WebSite with SearchAction at the root.

Technical QA across devices

Technical QA is where theoretical correctness meets the messy reality of real devices, browsers, and user behavior. Budget at least three full days for this track, and do not compress it. The items below are the minimum bar for a launch you can stand behind.

1. Test on Chrome, Safari, Firefox, and Edge. Current stable on each; Safari is the most likely to expose CSS bugs not caught elsewhere.
2. Test on iOS Safari and Android Chrome. Use real devices if possible, not just DevTools device mode.
3. Test on tablet viewports. iPad Pro and a mid-range Android tablet; check that navigation, forms, and hero sections work at 768 to 1024px widths.
4. Test responsive breakpoints. 320px, 375px, 414px, 768px, 1024px, 1280px, and 1920px minimum; confirm no horizontal scrolling at any width.
5. Submit every form with valid data. Confirm success state, confirmation email, and CRM/database record all land correctly.
6. Submit every form with invalid data. Every validation rule must show a clear, accessible error message.
7. Test form spam protection. Submit from Tor or a known spam IP; confirm the filter or rate limit triggers.
8. Check every link on every template. Automated crawler plus a manual pass on primary nav and footer; zero 404s on internal links.
9. Verify custom 404 page. Visit a known-bad URL and confirm the branded 404 renders with a 404 status (not a 200).
10. Verify all redirects. Spot-check 50 redirects from your URL map; confirm each returns 301 (not 302) to the correct target.
11. Test search functionality. If the site has search, confirm relevance, handling of zero-result queries, and analytics tracking on search events.
12. Test every interactive component. Accordions, modals, tabs, carousels, video players; all work with mouse, keyboard, and touch.
13. Test print styles (if applicable). Article pages, invoices, and any printable templates render legibly in print preview.
14. Test with JavaScript disabled. At minimum the homepage, nav, and contact form should degrade gracefully.
15. Run an end-to-end test on primary conversion paths. From a cold landing page through to form submission or purchase confirmation; record the flow for reference.

Launch day sequence

Launch day itself should be boring. If the pre-launch tracks were done properly, cutover is a sequenced checklist executed by a named engineer while the rest of the team monitors. Schedule the cutover for a weekday morning (never Friday afternoon), keep traffic-heavy stakeholders informed, and have the rollback plan on-screen the entire time.

1. Freeze code. No non-critical commits to main in the 24 hours before cutover; only hotfixes with explicit approval.
2. Take a full database backup. Export and archive immediately before cutover; confirm it restores in a scratch environment.
3. Snapshot the current production build. Tag the prior artifact in your registry so rollback is a single command.
4. Record prior DNS values. Save a screenshot or export of the current DNS zone for fast revert.
5. Lower DNS TTL 48 hours before cutover. Drop to 300 seconds so propagation is fast; raise again 24 hours post-launch.
6. Deploy to production. Verify build success, check health endpoints, and smoke-test the homepage on the production domain before flipping DNS.
7. Flip DNS. Update A/AAAA records to point at the new infrastructure; confirm propagation with dig from multiple geographies.
8. Verify HTTPS resolves on the live domain. Check the certificate, confirm HSTS header, and walk through a few key URLs.
9. Submit the sitemap to Search Console. Immediately after DNS confirms; also submit to Bing.
10. Monitor error rates. Open Sentry, the CDN dashboard, and server logs; watch for spikes in 4xx or 5xx responses.
11. Monitor Core Web Vitals in real-time. Use Vercel Analytics, Cloudflare Web Analytics, or a RUM tool to catch LCP or INP regressions immediately.
12. Verify analytics on the live domain. Open GA4 DebugView, complete a conversion path, and confirm events land within two minutes.
13. Communicate the launch internally. Slack message to the company at cutover, with a link to the site, the point-of-contact engineer, and the rollback criteria.
14. Hold a 15-minute post-cutover check-in. 30 minutes after DNS flips, confirm analytics, error rates, and core pages; decide go/no-go for external announcement.
15. Announce externally only after check-in passes. Press release, social posts, and email campaigns wait until the site has been live and stable for at least 30 minutes.

Post-launch monitoring

The launch window extends 30 days past cutover. Traffic patterns, indexation, and user behavior all shift during this period, and a disciplined monitoring cadence is what separates successful launches from ones that silently underperform for a quarter before anyone notices. Pair this section with your ongoing SEO optimization work so the improvements compound.

1. Daily analytics review for the first week. Traffic volume, top pages, conversion rate, and bounce rate checked every morning; flag anomalies within 24 hours.
2. Search Console coverage review. Daily for the first two weeks; watch for indexation stalls, crawl errors, or "submitted URL not indexed" spikes.
3. Uptime monitoring. Pingdom, Better Stack, or similar with 1-minute checks from three geographies; alert on three consecutive failures.
4. Core Web Vitals field data weekly. Pull CrUX or RUM data weekly for the first 8 weeks; address any template dropping to "poor" immediately.
5. Broken link monitoring. Weekly crawler run for the first month to catch any newly broken internal or outbound links.
6. 404 log review. Server 404s reviewed weekly; add redirects for any URL receiving meaningful traffic.
7. Ranking tracking. Pull positions for your top 50 keywords weekly, compare against pre-launch baseline, and investigate drops greater than five positions.
8. Backlink monitoring. Confirm major backlinks still resolve to the correct new URL; outreach for any that redirect through chains.
9. Conversion funnel review. Weekly check that conversion rate has returned to or exceeded pre-launch baseline; investigate any step with a drop-off rate greater than expected.
10. User feedback loop. Route support tickets, contact form submissions, and session recordings into a weekly "what's broken" review for the first month.
11. Security scan. Re-run dependency and header scans 7 and 30 days post-launch; catch anything that regressed with a routine dependency update.
12. 30-day launch retrospective. Document what went well, what broke, and what to change for the next launch; update this checklist with your team's specific learnings.

Conclusion

A 150-item launch checklist looks intimidating on paper, but each section compresses hard lessons from launches that went wrong. The SEO, performance, accessibility, and security tracks are about making sure the site you built is the site that actually ships. The analytics and metadata tracks are about making sure you can see what happens next. The launch-day and post-launch tracks are about recovering quickly when something inevitably surprises you.

The teams that launch well in 2026 treat this as a shared document across engineering, design, marketing, and leadership rather than a handoff from one group to another. Walk the list together, assign owners, and agree on what is blocking versus noted-for-later. A disciplined launch compounds: you ship faster, regressions are rarer, and the site performs better from day one.

Frequently Asked Questions