My technical SEO launch checklist: a step-by-step guide

I've launched enough production platforms to know that shipping fast means nothing if search engines can't find you. After five years building e-commerce, SaaS, and travel products, I've learned that a single misconfiguration on launch day can set your organic visibility back months. That's why I never push code live without running through My technical SEO launch checklist—a systematic verification process that takes about an hour and catches the mistakes that break indexing.

Crawlability — Making Sure Search Engines Can Actually See Your Site

Before anything else, I verify that Googlebot and other crawlers can reach your content. This sounds basic, but I've seen staging servers accidentally left accessible to public crawlers, and I've watched production sites go live with overly restrictive robots.txt rules that blocked critical pages.

The first thing I check is your robots.txt file. It should be at the root of your domain and explicitly allow crawlers to your main content while blocking only what you actually want hidden—staging environments, admin panels, duplicate utility pages.

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /staging/
Disallow: /temp/
Disallow: /*.pdf$

Sitemap: https://yourdomain.com/sitemap.xml

I always verify this file exists and returns a 200 status code. If you're using Next.js or a modern framework, generate it during build time rather than manually maintaining it. Same for Nuxt, NestJS static file serving, or whatever your stack is.

Next, I grep through the HTML head tags on key pages to make sure there's no accidental noindex meta tag lurking in your template. I've seen this happen in Next.js when a global layout component was testing with noindex and the developer forgot to remove it before production deployment.

<!-- WRONG - this kills all indexing -->
<meta name="robots" content="noindex">

<!-- RIGHT - only nofollow if you need it -->
<meta name="robots" content="nofollow">

<!-- EVEN BETTER - just omit it if you want full indexing -->

For staging environments, I add an X-Robots-Tag header at the reverse proxy or load balancer level:

X-Robots-Tag: noindex, nofollow

This catches any crawler that ignores robots.txt and prevents staging from polluting your production index.

Indexability — Ensuring Search Engines Keep Your Pages in Results

Crawlability gets you in the door. Indexability keeps you there. I verify three things here: canonicals are correct, HTTP status codes are proper, and redirects form a clean chain.

Canonical tags tell Google which version of a page is the authoritative one. For e-commerce sites, this is critical—you might have the same product under different filter combinations, and you need Google to treat only one URL as the primary source.

<link rel="canonical" href="https://yourdomain.com/products/blue-shirt">

I check that:

• Every page has exactly one canonical tag
• Canonicals point to HTTPS, not HTTP
• Canonicals use your primary domain (not staging or alternate versions)
• Self-referential canonicals exist on unique pages (a product page points to itself)
• Canonicals are absolute URLs, never relative

For status codes, I run a quick crawl on every major route and verify all responses are either 200 (success) or 301/302 (redirects). Anything returning 404 on a page you intended to publish is a ship-blocker.

Redirects deserve their own attention. If you're migrating content or restructuring URLs, build a clean redirect map and test it end-to-end. I use a simple script to verify the redirect chain doesn't loop or create cycles:

Old URL → 301 → Intermediate URL → 301 → Final URL (200 OK)

# Don't do this:
URL A → 301 → URL B
URL B → 301 → URL A  # LOOP - kills indexing

Search Console (more on that below) will surface indexation issues, but waiting for that report means you've already launched with problems. I catch this locally before pushing live.

Metadata — Titles, Descriptions, OG Images, and Structured Data on Every Template

Metadata is what shows up in search results and social media shares. I verify it's present and distinct on every page template, not just your homepage.

For titles and descriptions, I check:

• Every page has a unique title tag between 50-60 characters
• Primary keyword appears early in the title
• Meta description is 150-160 characters and compelling
• No title or description is duplicated across multiple pages
• No generic fallback text like "Untitled" or "Page" in production

In a Next.js app, this looks like:

export const metadata = {
  title: 'Blue Cotton Shirts | Fast Shipping',
  description: 'Shop premium blue cotton shirts. Free shipping on orders over $50. Next-day delivery in major cities.',
  openGraph: {
    title: 'Blue Cotton Shirts | Fast Shipping',
    description: 'Shop premium blue cotton shirts. Free shipping on orders over $50.',
    image: 'https://yourdomain.com/images/blue-shirt-og.jpg',
    url: 'https://yourdomain.com/products/blue-shirt'
  }
};

Open Graph (OG) tags control how your pages look when shared on social platforms. I verify OG images exist, are at least 1200x630px, and are actually hosted on your CDN (not a local file path). This is especially important for e-commerce product pages—a bad OG image tanks click-through rate from social traffic.

Structured data (JSON-LD) is what makes your content eligible for rich snippets and special SERP features. For e-commerce:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Blue Cotton Shirt",
  "description": "Premium cotton shirt",
  "image": "https://yourdomain.com/images/shirt.jpg",
  "brand": {
    "@type": "Brand",
    "name": "YourBrand"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://yourdomain.com/products/blue-shirt",
    "priceCurrency": "USD",
    "price": "49.99",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "128"
  }
}
</script>

I validate this JSON-LD with Google's Structured Data Testing Tool. If it's malformed, it won't just fail to generate rich snippets—it can confuse crawlers about your page content.

Performance — Core Web Vitals on Real Mobile Devices

Search engines weigh performance in ranking algorithms, and users abandon slow sites before Google even crawls them. I never ship without checking Core Web Vitals on actual mobile hardware, not just in DevTools simulations.

The three metrics that matter are:

• Largest Contentful Paint (LCP): Time for the largest visible element to render. Target under 2.5 seconds.
• Cumulative Layout Shift (CLS): Visual instability as elements move around. Target under 0.1.
• First Input Delay (FID) or Interaction to Next Paint (INP): Responsiveness to user input. Target under 100ms.

I use PageSpeed Insights and WebPageTest with real Chrome browsers on 4G throttling. Lighthouse scores in DevTools are useful but overly optimistic because your development machine is fast and connected.

Common performance killers I watch for:

• Unoptimized images (images over 100KB that could be WebP)
• Synchronous third-party scripts (analytics, ads, chat widgets blocking page load)
• Unused JavaScript bundles shipped to the client
• Render-blocking CSS or fonts
• Large DOM trees that slow down rendering

For my own projects, I configure image optimization in Next.js (automatic WebP conversion and srcset generation), lazy-load third-party scripts via next/script with the afterInteractive strategy, and enable code splitting so each route only loads what it needs.

Monitoring — Search Console, Sitemaps, and Alerts Configured

Launch day isn't the end—it's when real monitoring starts. I ensure Search Console is connected, sitemaps are submitted, and alerts will notify me if something breaks.

First, I verify Search Console is linked to the production domain (not staging) and the site ownership is validated. This takes 10 minutes and unlocks real data about how Google sees your site.

Next, I generate and submit a sitemap. For most sites, this is straightforward:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://yourdomain.com/products/blue-shirt</loc>
    <lastmod>2024-01-15</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
  </url>
  <url>
    <loc>https://yourdomain.com/blog/how-to-care-for-cotton</loc>
    <lastmod>2024-01-10</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.6</priority>
  </url>
</urlset>

For large sites, I generate this dynamically during build time. For e-commerce platforms, I include product pages but exclude filter variations and sort parameters.

Finally, I configure monitoring and alerts. I use Google Search Console notifications and set up a basic uptime monitor that checks the homepage daily and alerts me if it returns non-200 status. I also configure CloudWatch or equivalent to alert on 5xx errors spiking.

Common Mistakes

I've seen teams ship and then scramble to fix these:

• Forgetting to update the robots.txt Sitemap URL: If your sitemap is at a different path, robots.txt won't point to it and discovery is slower.
• Using relative canonicals: A canonical of /products/shirt instead of https://yourdomain.com/products/shirt can confuse crawlers if your site is accessible under multiple domains.
• Noindex on category or filter pages that you actually want indexed: I've seen filter pages marked as noindex in one template but not another, creating inconsistency.
• Heavy JavaScript that blocks rendering: If your React or Vue app has 500KB of unminified JS, LCP suffers and users bounce before Google crawls.
• Forgetting to add JSON-LD for rich snippets: You'll still rank, but you won't show star ratings or other visual differentiators that increase click-through rate.
• OG images on CDN without proper caching headers: Social platforms cache OG images, so if you update a product photo, it won't show the new image when reshared.

Key Takeaways

• Verify robots.txt blocks staging and admin routes, not your public content.
• Check for accidental noindex tags and ensure canonicals are absolute, HTTPS URLs pointing to your primary domain.
• Test every page's title, description, OG image, and structured data before launch.
• Run Core Web Vitals tests on real mobile hardware under 4G throttling, not just in DevTools.
• Link Search Console, generate and submit a sitemap, and configure monitoring to catch indexation problems early.
• Spend an hour on this checklist before launch. Fixing SEO issues post-launch costs ten times more in lost traffic and manual remediation.