Technical SEO for Developers: The Pre-Launch Checklist

SEO has a reputation for being a marketing discipline, but the foundation of it is plumbing: can crawlers reach your pages, can they render them, and do they understand what each page is about. That part belongs to developers, and it is mostly a checklist, not a dark art. Here is the one we run before every launch.

Crawlability first

Before anything else, make sure search engines can actually get in:

robots.txt exists and doesn't block production. It sounds obvious, but staging configs copied to production with Disallow: / still happen constantly.
sitemap.xml is generated from the same source of truth as your routes — not hand-maintained. If a page isn't in the sitemap and has no internal links to it, it effectively doesn't exist.
Canonical URLs are set on every page, so http, https, www, and non-www variants all point at one address. Pick a single canonical host and redirect everything else with 301s.
No accidental noindex left in meta tags from staging.

One check catches most of this: view the page source as Google sees it on first load. If the content isn't in the HTML, you have a rendering problem (more on that below).

Rendering: don't ship a blank page

A client-side-only SPA renders an empty <div id="app"> on first load. Google can eventually execute JavaScript, but it costs crawl budget, delays indexing, and breaks things like structured data that assume server HTML.

The practical rule we follow: anything that needs to rank — landing pages, blog posts, product pages — is server-rendered or pre-rendered at build time. Nuxt and similar frameworks make this nearly free, and a statically generated marketing site is also faster and harder to break. Heavy client-side interactivity is fine, as long as the meaningful content and metadata arrive in the initial HTML.

Metadata and structured data

Every indexable page needs:

A unique <title> (roughly 50–60 characters, primary keyword first, brand last).
A unique meta description that reads like an ad, not a keyword dump — Google often shows it in results.
One <h1> per page, with a sane heading hierarchy below it. Not for a magic ranking boost, but because a clean outline helps both crawlers and screen readers.
JSON-LD structured data where it genuinely applies: Organization and WebSite sitewide, Article on blog posts, FAQPage on pages with actual question-and-answer content, BreadcrumbList where breadcrumbs exist. Only mark up what is visibly on the page — invented structured data is a violation, not a hack.

URLs and redirects

Boring, high-impact work:

URLs are lowercase, hyphen-separated, and describe the page (/pricing, not /page?id=3).
Every old URL from a migration has a 301 to its closest new equivalent — not blanket-redirected to the homepage. A sitemap of 200s hiding hundreds of soft-404s is a common launch-day miss.
Trailing-slash and case variants redirect to one canonical form, so you never split link equity across duplicates.

Performance is part of SEO

Core Web Vitals are a ranking input, but more importantly they're what users feel. The big levers are unglamorous: serve images in modern formats with explicit dimensions, ship minimal JavaScript, put CSS and fonts on fast paths, and cache aggressively at the CDN. Measure with real field data (PageSpeed Insights, Search Console's Core Web Vitals report), not just lab runs.

The checklist itself

Before every launch we verify:

robots.txt allows crawling; sitemap is live and submitted in Search Console.
Key pages render their content and metadata in raw HTML (view-source check).
Unique titles and descriptions on every indexable page.
Structured data validates (Rich Results test).
Canonical host enforced; all variants 301.
Migration redirects mapped one-to-one; no soft-404s.
Core Web Vitals pass on the templates that get the most traffic.

None of this is clever, and that's the point — it's a set of repeatable checks that prevent the launch-day surprises that actually cost rankings. Do the plumbing right, and content has a fair chance to do its job.