Technical SEO Checklist for a New Website Launch
A launch-focused technical SEO checklist covering crawlability, canonicals, redirects, structured data, performance, and post-launch monitoring.
Technical SEO at launch is largely a problem of control: search engines need one clear, accessible version of each valuable page, while retired and duplicate URLs need predictable handling. The work spans content, application code, infrastructure, analytics, and release operations, so it cannot be delegated to a last-minute metadata review.
This checklist is designed for new builds and substantial migrations. It focuses on decisions a team can verify directly and avoids treating rankings as a launch-day acceptance test. Search performance develops over time, but crawlability, status codes, canonical signals, and content integrity can all be checked before release.
Establish the indexable URL inventory
Create a source-of-truth list of pages intended for organic discovery. Include the preferred URL, page purpose, primary topic, template, language, canonical target, and expected status. Compare this list with the application routes, CMS entries, legacy crawl, and XML sitemap so hidden or orphaned pages are found before launch.
Define URL conventions for casing, trailing slashes, parameters, pagination, filters, print views, and alternate formats. The application, internal links, sitemap, canonical tags, and redirects should agree. When several URL forms resolve with a successful response, crawlers must spend time interpreting duplicates that the team could have prevented.
- Return a genuine 404 or 410 for missing content rather than a soft-404 success page.
- Keep staging, preview, account, and utility routes out of the public index.
- Confirm every indexable page is reachable through normal internal links.
Control crawling and indexing deliberately
Review robots.txt, page-level robots directives, HTTP headers, authentication, and environment controls together. A permissive robots file cannot override a noindex tag, and a blocked URL may prevent a crawler from seeing the directive you intended it to read. Production should not inherit staging restrictions, while non-production environments should remain protected.
Generate an XML sitemap containing only canonical, indexable, successful URLs and use accurate modification dates only when content materially changes. Large or multilingual sites may need sitemap indexes and language alternates, but the basic rule remains the same: the sitemap should describe the preferred site, not expose every route the application can render.
Validate rendering, metadata, and semantics
Inspect the initial HTML and the rendered result for each representative template. Critical titles, descriptions, canonical links, headings, body copy, internal links, and structured data should be available consistently. Client rendering can work for search, but avoid making essential discovery dependent on fragile browser-only behavior or delayed third-party requests.
Give every page a specific title and description aligned with its actual content. Use one descriptive H1, then organize sections with meaningful heading levels. Canonical tags must be absolute in the final output and self-reference the preferred URL unless a deliberate consolidation rule applies.
- Check social metadata separately; it does not replace search metadata.
- Ensure image alternatives describe purpose rather than repeating file names or keywords.
- Validate structured data against visible content and remove unsupported properties.
Engineer redirects and migration mappings
For a replacement website, map each valuable old URL to the closest relevant new page. Preserve path intent where possible and avoid routing every retired page to the homepage. Test redirects for status, final destination, chains, loops, query handling, protocol, host, and slash variants.
Update internal links to point directly at final destinations, even when redirects exist. Redirects are a safety net for old references, not a substitute for clean navigation. Preserve the mapping as an operational artifact because support teams, campaign owners, and future developers will need to understand why a route behaves as it does.
Check performance and mobile usability
Measure representative pages under realistic network and device conditions. Prioritize stable layout, responsive images, efficient fonts, lean client-side JavaScript, prompt server responses, and fast rendering of the main content. Lab tools help find causes, while field data later shows how real visitors experience the site.
Test navigation, dialogs, forms, cookie controls, embedded media, and content at narrow widths and high zoom. Mobile usability problems often emerge from interaction code rather than the article body: fixed overlays, inaccessible menus, delayed hydration, and controls without enough space can block both users and automated discovery.
- Set performance budgets per template and enforce them before content volume grows.
- Reserve media dimensions to prevent avoidable layout movement.
- Load third-party scripts according to demonstrated user and business value.
Monitor the release and investigate changes
Immediately after launch, crawl the production host, submit the preferred sitemap, inspect important URLs, and monitor server logs, analytics, conversions, index coverage, and error reporting. Compare results with the launch inventory rather than checking a handful of high-profile pages.
Expect search engines to recrawl at their own pace. Investigate material losses by separating technical availability, changed content, redirect quality, internal linking, canonical signals, and external demand. A disciplined record of the release makes diagnosis faster and prevents teams from responding to normal volatility with broad, risky changes.