Resources

The Ecommerce Store Launch Checklist: 52 Things to Do Before You Go Live

om ·

Most ecommerce launches fail quietly. Not from broken code — from the boring stuff: a missing GA4 tag that costs three weeks of conversion data, a 5MB hero image that tanks LCP and pushes the page out of Google’s “Good” Core Web Vitals threshold, a Stripe integration left in test mode that silently rejects every order on launch day, a forgotten noindex tag that makes the entire site invisible to search for two weeks before anyone notices.

This is the actual checklist we run before a store goes live. Fifty-two items, organized by phase. The technical and legal sections are non-negotiable; the design ones can flex if you’re under deadline. None of this is exciting. All of it matters.

Key takeaways

  • Performance has measurable thresholds, not vibes. LCP under 2.5s, INP under 200ms, CLS under 0.1 — these are Google’s published Core Web Vitals targets, and the field data correlates strongly with both rankings and conversion. “Feels fast” is not a metric.
  • Compliance is a sales accelerator, not paperwork. Procurement teams at any company over 200 people will check your privacy policy, security posture, and accessibility statement before they sign. Doing this badly adds weeks to the deal cycle.
  • SEO has shifted toward structured data and topical authority. Schema.org JSON-LD is how Perplexity, ChatGPT, Google AI Overviews, and traditional SERPs all parse your pages. Skip it and you’re invisible to half the discovery surface that exists in 2026.
  • Don’t launch on a Friday. The weekend is when you’ll need the engineering team available, not when you’ll have them.

I. Planning & strategy

1. Define the primary goal — and pick exactly one

Lead capture, direct ecommerce sales, or content authority. Pick one for the homepage and the global navigation; the others are secondary surfaces. The pattern that fails: a hero with three competing CTAs (“Buy now” + “Book a demo” + “Read the blog”), each of which dilutes the others. Decision attention is a fixed resource — split it three ways and you get a third of the conversion rate of any single focused CTA. The exception is multi-funnel SaaS where audiences segment cleanly by entry point; for everyone else, one primary CTA above the fold, secondary CTAs at logical breaks.

2. Competitor research — feature parity vs differentiation

The useful frame is Jobs-to-be-Done: not “what features do they have,” but “what job is the buyer hiring this product to do.” Catalog your top three competitors on a 2×2 grid: features they ship that are table stakes (you must match), features they ship that are weak (your opening), the price they charge, and where their reviews complain. The trap is feature-copying without understanding the underlying job. If a competitor has a “team collaboration” feature and your buyers are solo operators, copying it adds complexity for no conversion lift.

3. Sitemap and information architecture

Flat is better than nested. Critical pages should be reachable in two or three clicks from the homepage. The reason is partly UX (users don’t dig) and partly SEO — internal link equity flows down the tree, and pages buried four levels deep get a fraction of the authority of pages one click off the homepage. For Next.js or similar, plan your route structure for any multi-tenant or subdomain logic before you start building; retrofitting subdomains for white-labeled instances or regional storefronts after launch is a multi-week migration. Card-sort with five real users to validate the navigation before you write a single component.

4. Content mapped to the buyer journey

By launch day you should have bottom-of-funnel content ready: comparison pages (“vs Shopify”), “alternatives to” pages targeting your competitors’ brand searches, integration documentation, pricing rationale (a page that explains why you charge what you charge), and case studies if you have them. Top-of-funnel SEO content can wait three months. The buyer-ready content cannot — it’s what closes deals from your first wave of traffic. The mistake teams make: 30 thin top-of-funnel posts and zero of the comparison pages that actually convert.

5. Domain and DNS hygiene

Short, brandable, .com if you can get it — second-tier TLDs (.io, .co, .app) are fine but you’ll be correcting people who type .com forever. The technical setup that matters: CAA records restricting which certificate authorities can issue for your domain (prevents an attacker who breaches a CA from issuing a fraudulent cert); DMARC with p=reject after a quarantine warm-up period (prevents spoofing of your domain in phishing); SPF with the right include records and within the 10-DNS-lookup limit (use a flattening service if you exceed it); DKIM on every sending source. Get this right at launch — fixing email deliverability after a phishing attack uses your domain is painful.

6. Hosting that auto-scales

“99.9% uptime” is the floor; the real question is what happens at 100× normal traffic. For a Product Hunt or Hacker News spike, you want a host that scales horizontally without manual intervention — Vercel, Cloudflare Pages, Netlify, or a properly configured ECS Fargate / Cloud Run setup behind a CDN. The failure mode on cheap shared hosting: PHP-FPM workers exhaust, the database connection pool saturates, the homepage starts returning 502s, and your launch moment is dead. The threshold where shared hosting stops being viable is around 50k sessions/month for static-heavy sites and 10k–20k for dynamic stores; budget for the next tier before you need it.

7. CMS choice — and the integration cost no one talks about

Headless (Sanity, Storyblok, Contentful, WordPress as a backend) gives the marketing team autonomy from engineering. The trade-off is integration cost: you’re now maintaining a frontend repo, a content-modeling layer, webhooks for revalidation, and a preview environment. For a marketing team shipping landing pages weekly, that cost is repaid in days saved. For a team shipping pages monthly, monolithic (WordPress with a block theme, or a managed platform) ships faster and costs less to maintain. Pick based on how often non-engineers ship pages, not on framework hype.

8. Pick a launch date that gives you cover

Tuesday or Wednesday morning. Never Friday. Never the day before a holiday. The reason isn’t superstition — it’s that bugs surface within the first 24–48 hours of real traffic, and you want the engineering team available when they do. Schedule “hyper-care” coverage for 48–72 hours post-launch: someone on-call for production issues, someone monitoring error rates, someone watching GSC for indexation problems. The “Friday 5pm deploy then weekend” anti-pattern produces Monday-morning disasters that should have been caught Tuesday afternoon.

9. Staging environment with real parity

A staging environment is only useful if it actually mirrors production. That means the same Postgres major version, the same CDN configuration, the same environment variable structure, the same third-party integrations (with sandbox credentials), the same edge cache rules. Differences between staging and production are where bugs hide — most “it works on staging” production failures trace back to a config drift no one tracked. Run your CI/CD pipeline through staging on every merge. Use feature flags for staging-only experiments. If you cannot afford parity, at least document where staging diverges, so post-mortems start faster.

II. Design & UX

10. Design system with real tokens, not just a Figma file

A design system is tokens you can point both Figma and code at — colors, type scale, spacing, radius, shadow elevation. Either Tailwind’s config (inline tokens), a Style Dictionary setup (cross-platform), or a CSS custom-properties layer. The functional test: changing a brand color should mean editing one source of truth, not chasing it across 80 components. Without this, your “rebrand from blue to green” is a six-week project. With it, it’s an afternoon.

11. Mobile-first, on real devices

Mobile is roughly 60–65% of ecommerce traffic in 2026. Browser DevTools emulators lie about touch targets (Apple’s HIG sets 44×44 points minimum, often violated), about iOS Safari rendering quirks (form auto-zoom on input fields under 16px font-size), and about real network conditions. Test on at least one real iPhone (iOS Safari is the source of most mobile bugs) and one real Android device. The hover effects that work on desktop become accidental triggers on touch — :hover styles need :focus-visible counterparts, and dropdown menus need explicit click-to-open patterns rather than hover-to-open.

12. Logo, favicon, and the full icon set

SVG for the logo where possible — scales infinitely, smaller file size, themeable via CSS variables. PNG fallback for older email clients. Generate the full favicon set, not just favicon.ico: 32×32 standard, 180×180 Apple touch icon, 192×192 and 512×512 for the web app manifest, and a maskable icon if you support PWA install. realfavicongenerator.net handles the lot. A missing or pixelated favicon is the cheapest “amateur hour” signal you can send.

13. Navigation that actually works

Keyboard-navigable, semantic HTML (<nav>, <ul>, <a>, not <div onClick>), screen-reader friendly, and touch-friendly. Skip links at the top of the page for screen-reader users. Hover-only dropdowns are a bug — they fail on touch devices and on keyboard. The mobile hamburger pattern: trap focus inside the menu when open, return focus to the trigger when closed, hide background content from screen readers via aria-hidden. Every menu item should be reachable via Tab without traps.

14. CTAs with copy that earns the click

“Start free trial” outperforms “Get started” because the user knows what happens next — there’s a free trial, no immediate cost. Copy specificity beats generic action verbs. Place the primary CTA above the fold and at every logical content break. High contrast against the surrounding container (WCAG AA at minimum, AAA when you can). One primary CTA color used only for primary CTAs — secondary actions use a different style. The button color budget is finite; don’t dilute it on tertiary actions.

15. Whitespace, line length, and cognitive load

Optimal measure (line length) is 60–80 characters of body prose. Wider than that and the eye loses its place between lines; narrower and the text feels choppy. Line height of 1.5–1.7 for body text. Generous padding around content blocks — clutter is a conversion killer. The pattern: the “above the fold” feels spacious, the “below” sections breathe, and the user’s eye flows. Density isn’t a virtue. Compare a Stripe landing page to a typical WordPress theme to see the difference.

16. Self-hosted fonts with the right loading strategy

Use next/font, fontsource, or equivalent to self-host. Skip third-party font CDNs (Google Fonts, Adobe Fonts) for production — they add a DNS lookup, a TLS handshake, and a request to a server you don’t control. Serve woff2 only (universal browser support in 2026). Use font-display: swap or optional to avoid blocking text render. Subset your fonts to only the glyphs you need; the default Google Font weight package is 30–60KB more than you’ll use. Layout shifts from late-loading fonts hurt CLS and feel unprofessional.

17. Cross-browser testing, not just Chrome

Chrome, Safari (iOS and macOS), Firefox at minimum. Edge inherits Chromium so it’s usually fine. Test in Incognito to catch issues with cached assets and cookies. Safari on iOS is where most “works on my machine” bugs hide — date inputs render differently, position:sticky has subtle quirks, vh units behaved differently for years. BrowserStack or LambdaTest for the device matrix you don’t own. Run a final pre-launch pass on Safari iOS specifically — it’s the highest-volume platform after Chrome desktop and the most likely to surface a launch-blocker.

18. Accessibility — WCAG 2.2 as a floor

Color contrast at AA minimum (4.5:1 for body text, 3:1 for large text and UI components), ARIA attributes only where they add value (most native elements don’t need ARIA), keyboard navigation through every interactive element, alt text on all meaningful images. Run automated checks via axe-core or Pa11y in CI. Manual screen-reader testing with NVDA (Windows) or VoiceOver (Mac/iOS) — automated tools catch about 30% of issues. WCAG 2.2 AA is increasingly contractual for enterprise procurement; failing it can block a deal regardless of your product quality.

III. Content & media

19. Final proofread, with the AI voice removed

Read every page aloud. A typo on the pricing page can cost a five-figure deal. If you used AI to draft copy, the proofread is where you remove the AI voice — the “in today’s fast-paced world” framings, the “ultimate guide” headlines, the over-bolded phrases, the em-dashes everywhere, the “it’s not just X — it’s Y” rhythm. Hemingway Editor flags passive voice and over-long sentences; Grammarly catches the obvious typos; the human read-aloud catches the cadence. Sites that read AI-written lose trust on the first paragraph.

20. No placeholders left in production

Search the codebase for lorem, ipsum, TODO, FIXME, FPO, placeholder image filenames (placeholder.png, image-1.jpg), and any phone number or email that was a stand-in. Find them before Google does. The classic failure: a Slack screenshot used as a “team chat” mockup, with real internal messages still visible. Audit the static assets directory before launch — it accumulates orphaned drafts.

21. Image compression, with a real budget

Hard cap: 200KB per content image, 500KB for hero images that are the LCP element. Use Sharp at the build pipeline (Next.js does this via next/image), or an image CDN — Cloudflare Images, imgix, ImageKit, Vercel Image Optimization — that handles format negotiation and resizing per request. Generate a responsive srcset so mobile devices don’t download desktop-resolution files. The single biggest LCP win on most stores is replacing one bloated hero image; check the LCP element in PageSpeed Insights and start there.

22. Modern formats: WebP and AVIF

WebP is roughly 25–30% smaller than equivalent JPEG at the same perceived quality, with universal browser support in 2026. AVIF is roughly 50% smaller than JPEG and now ships in Safari 16.4+, Chrome, Firefox, and Edge — but the encoder is slower at build time. Serve AVIF first via the <picture> element with WebP and JPEG fallbacks, or let your image CDN negotiate via the Accept header. The build cost of AVIF is repaid the first day a thousand users load the page on slow mobile.

23. Video hosting and the facade pattern

Don’t self-host video. YouTube, Vimeo, Mux, or Cloudflare Stream. Use the facade pattern for the player: load a poster image initially, swap in the iframe player on click. The default YouTube embed adds 600KB+ of JavaScript to your page on initial load, even if no one plays the video — facades cut that to a 30KB image. Lite YouTube Embed (lite-youtube) is the standard implementation. For autoplay hero videos, host the file directly (under 2MB, muted, preload="metadata") — never an embedded player.

24. Alt text that earns its place

Three categories: descriptive for content images (“Black leather handbag with brass clasp on white background”), functional for images-as-links (“Email Sarah Chen, Head of Sales”), decorative for ornamental images (empty alt="" so screen readers skip them). Don’t begin with “image of” or “picture of” — screen readers announce the image type already. Don’t keyword-stuff. The point is an accurate description for users who can’t see the image; the SEO benefit is a side effect, not the goal.

25. NAP consistency for local visibility

Name, Address, Phone consistent across the website footer, contact page, Google Business Profile, Apple Business Connect, Bing Places, and any directory you’ve claimed. Inconsistencies (e.g., “Suite 300” vs “Ste 300”) confuse Google’s local algorithm and hurt local-pack rankings. Add Schema.org LocalBusiness JSON-LD with the same NAP, plus opening hours, geo coordinates, and price range. For multi-location, separate LocalBusiness blocks per location with a parent Organization.

26. Open Graph and Twitter Card tags

At minimum: og:title, og:description, og:image, og:type, og:url, plus twitter:card set to summary_large_image. Image dimensions: 1200×630, under 5MB, served over HTTPS. Generate dynamically per page — Next.js opengraph-image.tsx or Vercel OG handles this, generating a fresh image per blog post or product page. Validate with the LinkedIn Post Inspector, the Twitter/X Card Validator, and the Facebook Sharing Debugger before launch. A page with bad OG cards looks broken when shared, and shares are a meaningful traffic source.

IV. Technical & security

27. SSL/HTTPS and HSTS

Auto-renewing SSL via Let’s Encrypt (90-day certs), Cloudflare, or your hosting provider. Force HTTPS via Strict-Transport-Security header with max-age=31536000; includeSubDomains; preload. Submit the domain to the HSTS preload list at hstspreload.org — this means even first-time visitors are forced to HTTPS, with no opportunity for a man-in-the-middle downgrade. The mixed-content gotcha: a single http:// resource (often a third-party widget or an old image URL) blocks the page from being “fully secure.” Audit with the browser DevTools security panel before launch.

28. Backups with tested restore (RPO and RTO)

Daily automated backups stored in a separate region or account. Two metrics matter: RPO (recovery point objective — how much data can you lose?) and RTO (recovery time objective — how fast can you restore?). For an ecommerce store, RPO under 1 hour and RTO under 4 hours is reasonable. The 3-2-1 rule: three copies, two media types, one off-site. Use immutable storage (S3 Object Lock, Backblaze B2 with object lock) so ransomware can’t encrypt your backups. Run a full restore drill before launch and quarterly after — most teams discover their backup is corrupted only when they need it.

29. Broken link audit

Run a full crawl with Screaming Frog (free up to 500 URLs) or Ahrefs Site Audit. Categorize: internal 404s (fix or redirect), external 404s (find new sources or remove the link), soft 404s (pages returning 200 with empty content — Google penalizes these), redirect chains longer than one hop (collapse to single redirects, each hop loses link equity). Fix every internal 404 with a 301 to a relevant live page, not the homepage — homepage redirects are treated as soft 404s.

30. Form testing end-to-end

Submit every form with real data and verify the data lands where it should: CRM (HubSpot, Salesforce), email (your inbox, not spam), database (the row appears), Slack (the notification fires). Confirm the GA4 conversion event registers (use DebugView). Confirm the autoresponder sends and isn’t trapped in spam. Test on mobile, where field validation and autocomplete behave differently. Add a honeypot field for spam (a hidden input that bots fill but humans don’t) and reCAPTCHA v3 invisible mode if needed. Server-side validation always — never trust the client.

31. Custom 404 page and React error boundaries

Custom 404 page with a search bar, links to the most-visited pages, and a clear path back to the homepage. Track 404 hits in GA4 to find broken inbound links. React error boundary at the app root (global-error.tsx in Next.js App Router) so a single component failure doesn’t blank the entire page — render a recovery UI with a “reload” action and log the error to Sentry. Without this, an exception in a third-party widget can take down the entire user session.

32. Caching strategy across the hierarchy

Three layers: browser cache (Cache-Control: max-age), CDN edge cache (s-maxage), origin cache. Pattern for static assets: Cache-Control: public, max-age=31536000, immutable with a hashed filename. Pattern for HTML: Cache-Control: public, max-age=0, s-maxage=3600, stale-while-revalidate=86400 — fresh from the edge for an hour, served stale while revalidating for a day. ISR (Incremental Static Regeneration) for pages that change infrequently. Cache invalidation strategy: tag-based (Next.js revalidateTag), path-based (Vercel revalidatePath), or webhook-driven from the CMS.

33. Bundle size audit and tree-shaking

Run @next/bundle-analyzer or webpack-bundle-analyzer. The first thing you’ll find: a 200KB library imported for one function (Lodash, Moment.js are the classics — replace with native JS or date-fns). Polyfill bloat for browsers you don’t actually support — set your browserslist conservatively. Code-split aggressively: routes the homepage doesn’t need shouldn’t be in the main bundle. Target: under 200KB JavaScript on the homepage initial load (gzipped). Every additional 100KB measurably hurts INP on mid-tier mobile.

34. Global CDN with high cache hit ratio

Static assets and pre-rendered HTML served from edge nodes. Vercel, Cloudflare Pages, and Netlify do this automatically; if you’re rolling your own, configure CloudFront / Fastly / Cloudflare in front of your origin. Target a cache hit ratio above 95% — every miss is a round trip to origin. Use Cache-Control headers, not just CDN-level rules; let the edge cache for hours and the browser cache for shorter periods. Origin shield (a single regional cache between edge and origin) reduces origin load on cache stampedes.

35. Admin security, MFA, and audit logs

Multi-factor authentication on every admin account: hosting dashboard, CMS, payment processor, domain registrar, GitHub, email provider. Hardware keys (YubiKey, Touch ID) where supported — TOTP via authenticator app where not — SMS as a last resort and only because the alternative is no MFA. Remove every guest account and every contractor account from the previous project. Audit team permissions on a quarterly schedule — the principle of least privilege applies to ops too. Enable audit logs on every admin surface so a breach can be reconstructed.

V. SEO & analytics

36. GA4 with the events that matter

Measurement ID active and verified. Don’t rely on the default automatic events alone — add custom events for the actions tied to your business: add_to_cart, begin_checkout, purchase (with revenue), generate_lead for B2B, view_item for product pages. Mark conversion events explicitly. Configure cross-domain tracking if your checkout is on a separate domain. Set up custom dimensions for SaaS-specific data (plan tier, user role). For cookieless tracking, configure server-side GTM via a custom subdomain (sgtm.example.com) — this also reduces ad-blocker impact on first-party data.

37. Google Search Console verified and monitored

Verify the property via DNS TXT record (works for both root and subdomains). Submit your sitemap. Watch the Coverage report for the first 30 days post-launch — new sites take time to index, but if you’re seeing thousands of “Discovered, not indexed” pages after a month, you have a quality or canonicalization problem. GSC is also where you’ll see manual penalties, security issues, and the actual queries driving impressions (which inform your meta titles and content updates). The “Performance” report data starts thin and gets useful around week 4.

38. Sitemap and robots.txt

XML sitemap auto-generated from your routes. For large sites, sitemap index files (sitemap_index.xml) referencing per-section sitemaps — Google’s per-file limit is 50k URLs / 50MB uncompressed. priority and changefreq are largely ignored by Google in 2026 — don’t bother tuning them. robots.txt: Allow by default, explicitly Disallow staging paths, admin paths, parameter URLs that produce duplicate content. Decide your AI crawler policy (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) — block them or allow them, but make the choice explicitly.

39. Schema.org markup as JSON-LD

JSON-LD on every page that warrants it. Product schema on product pages (name, image, description, brand, offers with price, availability, AggregateRating if you have reviews). Organization on the homepage. FAQPage on FAQ-style content (this is what gets cited by AI Overviews). Article on blog posts (with author and datePublished). BreadcrumbList on every deep page. Validate with the Schema Markup Validator (validator.schema.org) and the Rich Results Test. The payoff: rich snippets in SERPs and direct citations in Perplexity / ChatGPT / Google AI Overviews.

40. Meta titles by pixel width, not character count

Google truncates titles at roughly 580 pixels on desktop, not 60 characters — narrow letters fit more, wide letters fit fewer. Write a unique title per page with the primary keyword toward the front. Brand name at the end (or omit on conversion-focused pages). Avoid auto-generating titles from H1 unless your H1 is already optimized; the H1 and meta title can serve different purposes (H1 for users, meta for SERP click-through). Test in the SERP Snippet Optimizer or Mangools’ SERP Simulator.

41. Meta descriptions Google might rewrite anyway

Under 160 characters. Lead with the value, end with an action verb. Google rewrites meta descriptions in roughly 60% of SERP appearances based on the query — write one good description anyway, because the other 40% is your shot at click-through. Specificity beats generic phrasing: “14-day free trial, no credit card required” outperforms “Try our solution today.” Numbers help. Don’t keyword-stuff — modern Google ranks click-through behavior as much as keyword presence.

42. URL structure

Lowercase, hyphenated (not underscored — Google treats underscores as part of the word), descriptive of the page content. /blog/ecommerce-launch-checklist, not /post?id=52 or /blog/2026/05/some-post-title-with-the-date. Trailing slash consistency: pick one (with or without) and 301-redirect the other. Keep URLs stable — once a URL is indexed and earning links, changing it costs you the link equity unless every redirect is in place.

43. Internal linking, not over-engineered

Pillar pages link to topical clusters, clusters link back to the pillar — this is how you build topical authority signals to Google. Anchor text varied and natural (“the cart abandonment data” beats “click here”). Don’t link from every page to every other page — that dilutes the signal. Audit for orphan pages (pages with no internal links pointing to them) before launch — they get crawled rarely and rank poorly. Tools: Ahrefs Site Audit, Screaming Frog with link analysis enabled.

VI. Legal & final launch prep

44. Privacy policy that actually applies to you

Required if you collect any personal data, including email. The legal minimums (GDPR Article 13, CCPA §1798.100) require disclosing: what data you collect, why you collect it, the legal basis for processing (consent, contract, legitimate interest), retention periods, third parties you share with (every analytics vendor, every ad pixel, every ESP), and how users exercise their rights (access, deletion, portability). Plain language. Templates from Termly or iubenda are starting points — customize them, because a generic template that mentions services you don’t use is worse than no template.

45. Terms of service that protect you

Defines the rules for using your platform. For ecommerce: payment terms, shipping and return policies, intellectual property of user-generated content (reviews, photos), warranty disclaimers. For SaaS: uptime expectations (most don’t promise SLAs at launch), data ownership (the customer owns their data), limitation of liability (capped at fees paid in the past 12 months is standard), governing law, arbitration vs court (arbitration is enforceable in most US jurisdictions). Click-wrap acceptance (“I agree” checkbox required to checkout) is more enforceable than browse-wrap (“by using this site you agree”). Get a lawyer to review.

46. Cookie consent that meets ePrivacy

For EU users, you need consent before non-essential cookies fire — that’s analytics, advertising, A/B testing, anything that isn’t strictly necessary for the service. The “reject all” button must be as prominent as “accept all” (regulators are now fining sites that bury rejection). Use Complianz, CookieYes, OneTrust, or similar — and verify that consent actually gates the analytics scripts (test by rejecting cookies and watching Network tab — no GA4, no Meta pixel, no third-party trackers should fire). Implement Google Consent Mode v2 if you run Google Ads — required for measurement in the EEA since March 2024.

47. 301 redirects from the old site

If you’re replacing an existing site, map every old URL to a new one. Lost redirects mean lost rankings, lost rankings mean lost traffic, and there is no faster way to undo years of SEO work than a rebuild without redirect mapping. Crawl the old site with Screaming Frog, export the URL list, map each to its new equivalent, and implement at the server or CDN level (faster than application-level). One-hop redirects only — don’t chain. Test the top 100 URLs by traffic after launch and watch GSC for spikes in 404s.

48. Lighthouse audit on mobile, not desktop

LCP under 2.5s, INP under 200ms, CLS under 0.1. Run Lighthouse on the “Mobile” preset, not “Desktop” — desktop scores are misleadingly generous (4× CPU and 3G network throttling on mobile reflects real-world conditions). Use the simulated throttling, then verify with PageSpeed Insights’ field data (CrUX) once you have real users — lab data and field data often diverge, and field data is what Google ranks on. Identify the LCP element first, optimize that one, re-run, and iterate. The biggest wins are usually image optimization, font loading, and bundle size.

49. Remove “noindex” from production — verify, don’t trust

The single most common launch mistake: noindex set during development to keep search engines out of staging, never removed before launch. Search the codebase for “noindex” across HTML, meta tags, HTTP headers (X-Robots-Tag), and your CMS settings. Verify production pages return index, follow in their meta robots tag, no X-Robots-Tag noindex header, and a 200 status to actual crawler user agents. Test with curl -A "Googlebot" https://yoursite.com and check the response. Verify Bing too — many teams check Google and forget Bing has a separate index.

50. Switch payment integrations to live mode

Stripe, Braintree, WooPayments, PayPal — verify production keys, not test keys, are loaded in your environment variables. Use a clear key naming convention (STRIPE_SECRET_LIVE vs STRIPE_SECRET_TEST). Run a real $1 transaction with a real card and refund it. Confirm webhooks fire to your production endpoint (Stripe CLI’s stripe trigger doesn’t substitute — you need a real event). Verify webhook signature verification is enabled (otherwise an attacker can fake order completion events). Test 3D Secure flow with a European card — many sandbox setups skip 3DS by default and break in production.

51. Tiered launch announcement

Soft launch to friends, family, and inner-circle customers first — they’ll find the bugs you missed without burning your reputation. Then your email list (segmented if you can — beta users first, full list second). Then organic social. Save Product Hunt, Hacker News, and press for after the obvious bugs are caught — those audiences are unforgiving of rough launches. Prepare a press kit: founder photos, logo files (SVG and PNG), product screenshots (high-res), a one-line description, a one-paragraph description, and the long-form story. Embargoed reviews to a few publications before public launch can compound the moment.

52. Post-launch monitoring with real alerting

Uptime monitoring (UptimeRobot, Better Uptime, Pingdom) checking the homepage and a few critical paths every minute. Error tracking (Sentry, Bugsnag, Rollbar) capturing both server errors and frontend exceptions, with alerting on error-rate spikes. APM (Datadog, New Relic, Honeycomb) for performance baselines. Real-User-Monitoring (RUM) via the web-vitals library reporting Core Web Vitals to GA4 — lab data tells you what could happen, RUM tells you what is happening. On-call rotation for the first two weeks: someone is responsible for production at any hour. Watch GSC for indexation errors over the first 72 hours.

FAQ

What’s the single most overlooked launch checklist item?

Removing noindex from production. It’s the easiest mistake to make (you set it during development to keep search engines out of staging) and the easiest to forget. We’ve seen sites go three weeks before someone notices traffic isn’t coming. Verify after you go live with curl -A "Googlebot" yoursite.com and check the meta robots tag and X-Robots-Tag header.

How important is Core Web Vitals for ecommerce conversion?

Substantial. Google has confirmed Core Web Vitals are a ranking signal, and the user-experience correlation is well-documented — slow LCP and high CLS both correlate with abandonment. Walmart’s published data showed a 1-second improvement in load time produced a 2% conversion increase. Hitting the green thresholds (LCP < 2.5s, INP < 200ms, CLS < 0.1) is table stakes for both rankings and conversion. The diminishing returns kick in below 1.5s LCP — past that, you’re spending engineering time for marginal gain.

Do I need SOC2 if I’m a small ecommerce store?

Probably not. SOC2 is procurement-driven for B2B SaaS selling to mid-market and enterprise companies. For B2C ecommerce, focus on PCI compliance (your payment processor handles most of it; you handle scoping and access control), GDPR if you sell to EU users, and CCPA if you sell to California users. SOC2 becomes relevant if you’re B2B and your customers’ procurement teams are asking. Don’t pursue it speculatively — the audit cost ($20k–$100k for a Type II) and the engineering time aren’t justified without specific deal pressure.

Should I launch on a Friday?

No. The weekend is when you have the least engineering coverage and the highest probability of bugs compounding before anyone notices. Launch Tuesday or Wednesday morning so you have the full work week for hyper-care. Avoid the day before holidays (US Thanksgiving Wednesday, December 23, etc.) for the same reason — the engineering team is mentally checked out, and bugs that surface go un-triaged until people return.

How long should the launch checklist actually take?

For a small store with standard integrations: 1–2 weeks of focused effort to work through the technical and legal items, assuming the design and content are already in place. For a larger store with custom integrations, multi-region content, and SOC2 requirements: 4–8 weeks. For a regulated industry (healthcare, finance) with HIPAA or PCI Level 1 in scope: budget 12+ weeks for the compliance work alone. Don’t compress this — the cost of fixing each item post-launch under traffic is several times the cost of doing it pre-launch in calm.

Want help running this checklist?

We’ve shipped enough launches to know which items get skipped under deadline pressure and which items quietly destroy rankings, conversions, or compliance. Most of the work is unglamorous and most of the value is in the unglamorous parts. If you’re approaching launch and want a second pair of eyes — or full implementation support on the technical and SEO sections — book a discovery call.

Written by Shadow, with input from the EtherLabz team.