Technical SEO launch checklist: what to verify before a new site goes live

First decide: new site or migration?

A new domain and a migration share many checks, but a migration adds a critical dependency: every valuable old URL needs an intentional destination.

For a migration, export the old URL inventory from the CMS, XML sitemaps, analytics, Search Console, backlink data, and a crawl. Map each old URL to the closest equivalent new URL. Do not redirect every retired page to the homepage; that erases the relationship between the old resource and its replacement.

For a site move, Google recommends testing redirects, submitting the new sitemap, monitoring both properties, and keeping redirects in place generally for at least one year. Keep the old domain under your control for longer when practical.

Release gate 1: response and redirect behavior

• Preferred pages return 200, not a soft error.
• Retired or moved URLs return a permanent redirect to the mapped destination.
• Redirect chains and loops are removed.
• HTTP, HTTPS, www, non-www, case, and trailing-slash variants resolve consistently.
• Real missing URLs return an appropriate 404 or 410.

Test a sample from every template and redirect rule, plus edge cases such as query strings and encoded characters. A single homepage check says little about a large rule set.

Release gate 2: robots, canonicals, and sitemaps

Check production robots controls in both the HTTP response and HTML. Staging often uses authentication, robots rules, or noindex; the release process must remove only the controls that should not ship.

Confirm that each indexable page points to its preferred canonical URL. Canonicals should agree with redirects, internal links, hreflang annotations, and sitemap entries. Conflicting signals make consolidation harder to interpret.

Generate an XML sitemap from the final canonical URL set. Exclude redirects, errors, parameter variants, and pages intentionally marked noindex. Submit the sitemap after launch, then inspect it for unexpected additions.

Release gate 3: rendered content and links

View the rendered page, not only the source response. The main content, title, description, canonical, structured data, and important links should remain available when the page is rendered by a browser.

Google recommends crawlable links in standard anchor elements with an href. Test navigation, breadcrumbs, pagination, contextual article links, and links produced by interactive components. Confirm that mobile menus and accordions remain usable by keyboard and touch.

Release gate 4: template metadata and structured data

Inspect at least one normal and one edge-case page from every public template. Confirm:

• a unique, accurate page title and useful meta description;
• one visible main heading that matches the page job;
• correct language and direction attributes;
• Open Graph and social-image values that resolve;
• Article, Breadcrumb, Organization, or other structured data only where it matches visible content;
• valid author, publication, and modification information for editorial pages.

Test structured data with the relevant validator, but review the page manually too. Syntactic validity does not make a misleading property accurate.

Release gate 5: media and performance

Resize and compress featured images before upload. Provide dimensions so the browser can reserve space. Use meaningful alternative text when the image conveys information; use an empty alternative for decoration.

Run Lighthouse or equivalent lab diagnostics on the homepage and key templates. Investigate slow server response, render-blocking assets, oversized media, layout shifts, and long-running JavaScript. The current Core Web Vitals targets are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 at the 75th percentile. Lab results are diagnostic; field data is the outcome.

Release gate 6: analytics and search verification

Confirm that the production analytics property—not a staging property—receives a clean page view. Test conversions or important events, referral preservation, consent states, internal traffic rules, and cross-domain behavior where applicable.

Verify the preferred Search Console property before launch. After release, inspect a representative URL, submit the canonical sitemap, and save the launch time in an annotation log. Search Console reports can lag, omit anonymized queries, and aggregate data under canonical URLs, so avoid declaring success or failure from the first few hours.

Release gate 7: rollback and first-72-hour monitoring

A rollback plan should identify the person who can invoke it, the files and database backup, the trigger, and the maximum decision time. Test that the backup can be located before launch.

During the first 72 hours, monitor server errors, redirect failures, unexpected noindex pages, sitemap changes, analytics continuity, and critical user journeys. For a migration, compare old and new URL behavior and watch both Search Console properties.

The release record

Store the exact crawl date, test URLs, discovered blockers, accepted exceptions, redirect-map version, analytics evidence, sitemap URL, backup location, and final approval. If the release record is incomplete, the launch is not ready. That record makes later diagnosis possible; memory does not.

Use the printable technical SEO pre-publish checklist during the release, and run the broader priority-first new-site audit before sign-off.

Primary documentation

• Google site moves with URL changes
• Robots meta and X-Robots-Tag specifications
• Google link best practices
• Article structured data guidance
• Google URL Inspection tool