Website Launch SEO Checklist: Protect Discovery, Speed and Enquiries

A website is not launch-ready just because the homepage looks finished. A useful release check verifies that people can find the right pages, read them on their devices and complete the intended action. Technical SEO belongs in that check, alongside accessibility, performance and enquiry delivery.

This checklist is for a new business website or a redesign. It is not a promise of rankings. If an existing site already has search traffic, treat URL changes and content removal as a migration project rather than a cosmetic update.

Website launch SEO checklist: three release stages

A new website SEO checklist should make the launch decision easier, not just list technical terms. Assign a person to each check and record a pass, fail or not-applicable result alongside the evidence. For a redesign, include the existing site’s important URLs; a first website will not have an old-to-new URL migration to test.

Missing essential service content, broken important redirects, an unintended staging noindex or a failed enquiry journey should block sign-off until resolved. After launch, investigate unexpected exclusions or canonical selections before expanding content. A single day’s ranking fluctuation is not a reason to reverse an otherwise working release.

Use this website launch checklist alongside a content and delivery brief. The website development cost and brief guide explains how to agree page scope and responsibilities before development; the checks below explain what to verify when that website goes live.

Before development: record what must survive

Inventory important URLs, their purpose, incoming links where known, search performance and the customer action each supports. Keep a baseline export from Search Console before launch. This makes it possible to investigate later changes instead of relying on memory.

For a redesign, agree which URLs stay, move or disappear. Map an old service page to its closest relevant replacement rather than redirecting every old URL to the homepage. Google’s site-move guidance explains how to manage URL changes and monitoring during a migration.

Verify public-page discovery and metadata

For every important template, check the actual production response, not just the editor preview:

• The page returns the intended HTTP status and is accessible without login.
• The title and main heading describe the page’s specific subject.
• The canonical URL identifies the intended public version.
• Public content has no accidental staging noindex instruction.
• Important pages have crawlable internal links from relevant parts of the site.
• Private account, admin and customer data remain protected independently of indexing rules.

These are different controls. A robots instruction is not authentication. Hiding a confidential page from search results does not make it safe for public access.

Worked example: a redesign redirect and canonical check

Suppose a fictional company replaces /old-services/ with /services/office-cleaning/ because the new page serves the same purpose. A permanent server-side redirect, such as HTTP 301 or 308, should send the old URL directly to that relevant replacement. Then check that the destination returns HTTP 200, contains the intended service content and has a canonical identifying its final public URL. This is an illustration, not a Studio client result.

Update navigation and contextual links to the final URL rather than leaving visitors and crawlers to follow redirects. Include that final URL in the sitemap. If the old URL can stay and its purpose has not changed, keeping it is usually simpler than creating a migration unnecessarily. Follow Google’s redirect guidance when choosing the correct redirect type.

For the destination page, inspect the production response headers and rendered page head. A fictional example would be:

<title>Office Cleaning Services | Example Company</title>
<link rel="canonical" href="https://example.com/services/office-cleaning/">

The title describes the page, while the canonical points to its intended public version, not a preview host, another service or a tracking URL. Confirm there is no unintended noindex in a robots meta tag or an X-Robots-Tag response header. Google’s noindex guidance explains these controls. Also verify that robots.txt permits crawling of the public page; these checks are not interchangeable. Google’s canonical guidance explains how redirects, internal links and sitemap URLs should support a consistent preferred version.

Publish a sitemap that matches the site

A sitemap should identify the canonical URLs you actually want discovered. Avoid staging domains, broken routes and invented translations. If you include modification dates, keep them tied to real substantive changes rather than updating every page’s date on every build.

Submit or verify the sitemap in Search Console after deployment, then monitor processing. A successful sitemap response is a discovery aid, not confirmation that every page is indexed. See Google’s sitemap documentation.

For an English-only article on a bilingual site, do not invent an Arabic alternate URL simply because other pages have translations. Each language version needs real equivalent content before being declared as an alternate.

If a new website page does not appear in Google

Use Search Console URL Inspection for the exact production URL. First read the indexed result, its last crawl and the Google-selected canonical. Then use a live test to investigate what Google can fetch now. A successful live test is not confirmation that the current page is already indexed or that Google has selected your declared canonical.

For example, if an indexed result reports an old staging noindex but the production page no longer contains it, check the last crawl date and the current live response before making more changes. Confirm that both HTML and response headers permit indexing, that the page is linked internally and that the sitemap contains the correct URL. If an unintended duplicate is selected instead, investigate conflicting canonical signals and whether the preferred page provides distinct, useful content.

After correcting a real problem, request indexing where appropriate and monitor subsequent processing. A page absent from a small performance export is not by itself an indexing error. Search Console performance measures search appearances and clicks; URL Inspection answers a different question about a particular URL.

Test mobile usability and loading behavior

Check a narrow phone viewport as well as a desktop screen. Headings, tables, navigation and consent notices should fit without covering actions or forcing the whole page to scroll sideways. Test touch controls and keyboard focus, not just screenshots.

Google’s Core Web Vitals focus on loading, responsiveness and visual stability through LCP, INP and CLS. Lab tests help find problems before launch; field measurements describe real-user conditions and may not be available for a low-traffic page. Do not label one fast desktop test as a site-wide real-user performance result. The Web Vitals guidance explains the distinction.

Keep images appropriately sized, reserve their layout space and avoid shipping heavy scripts that do not support the customer journey. A compact business website does not need every feature of a large marketing platform.

Verify the enquiry path without confusing tests with leads

A form can look successful while email delivery or CRM creation fails. Test required fields, useful error messages, spam controls, server-side validation and the final destination. Use a clearly marked authorized test and remove it from business reporting.

If measurement is included, distinguish a form start, an attempted submission, a server-confirmed result and a genuine received enquiry. Check applicable consent and privacy requirements. Do not collect sensitive form contents in analytics simply to make reporting more detailed.

Release with a recovery plan

Keep the previous build and a documented rollback route. After deployment, verify key pages, redirects, sitemap, images and contact routes against the public domain. Review indexing and query data over time; short-term search fluctuations do not identify a root cause on their own.

AIUNSEEN Studio can scope these foundations into website development. Include your existing domain, important pages and enquiry workflow in the project brief so launch verification is part of the agreed deliverable, not an afterthought.