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

Choose one preferred URL for each piece of indexable content. The canonical, internal links, XML sitemap and redirects should all reinforce that choice. Avoid using canonical tags as a substitute for fixing a messy architecture. If two pages satisfy the same intent, decide whether they should be merged, differentiated or deliberately excluded.

For a redesign or migration, create the redirect map before launch. Redirect an old URL only when the destination is a genuine replacement. Do not send every removed page to the homepage. Avoid redirect chains by updating internal links and legacy redirects to point directly to the final destination. Google’s site-move guidance recommends preserving consistent signals and maintaining redirects long enough for users and search engines to adapt.

Normalise trailing slashes, protocol and hostname consistently. A site that mixes HTTP/HTTPS, www/non-www or parameterised duplicates can dilute signals and make debugging harder. Canonical URLs should be absolute and use the permanent production domain.

The XML sitemap is an indexation inventory, not a list of every route the application can render. Include canonical, indexable URLs that are intended to return useful public content. Exclude drafts, noindex pages, filters, login routes, internal search, staging pages and duplicate states. If a content hub has no useful published content, there is no need to promote it through the sitemap yet.

Internal links should make the commercial and topical hierarchy obvious. Service hubs link to services. Service pages link to related services, proof and useful guides. Editorial content links back to the relevant commercial pages. Breadcrumbs help users and crawlers understand hierarchy. Avoid orphan pages that exist only because they were inserted into the sitemap.

Check links after the production build, not only in the editor. Broken anchors, relative path mistakes and legacy URLs often appear during template or routing changes. Prioritise links on navigation, footer, high-traffic pages, service clusters and conversion journeys.

Every priority page should have a descriptive title, a useful meta description, one clear H1 and a heading hierarchy that reflects the information structure. Titles and descriptions should be unique to the page purpose rather than generated by swapping a city or service term into a template.

Structured data should match visible facts. Use Organization and WebSite entities consistently, Service markup for genuine services, Article or BlogPosting for editorial content, Person for real authors, and BreadcrumbList where the breadcrumb is visible. Do not invent reviews, aggregate ratings, offices, prices or awards simply because schema supports those properties.

Validate JSON-LD and inspect the rendered page for duplicate entity IDs. When both global and page-level components emit schema, they should refer to the same organisation and website IDs instead of accidentally creating multiple versions of the business.

Core Web Vitals are useful user-experience thresholds rather than a standalone ranking strategy. Pay particular attention to the largest element above the fold, interaction responsiveness and layout shifts caused by late-loading images, fonts, banners or injected components. Optimise images to the rendered size, preserve dimensions, defer non-critical code and split admin or heavy application features away from marketing routes.

On JavaScript applications, reduce the amount of work required before meaningful content appears. Google can render JavaScript, but other bots may not, and users still pay the performance cost. If the hosting platform cannot provide server or static rendering, document that constraint and test live rendering regularly rather than claiming it has been solved.

Mobile QA needs to be intentional. Check navigation, forms, long headings, tables, accordions, consent controls, sticky elements, focus behaviour and tap targets on real viewport sizes. Do not assume desktop components automatically become usable when stacked.

Before launch, confirm that analytics and advertising tags respect consent choices and that conversion events represent actions that matter. Growth-review completions, qualified contact submissions, phone clicks and meaningful CTA interactions are more useful than a large collection of low-value events.

After launch, submit or confirm the sitemap in Search Console and Bing Webmaster Tools, inspect the most important pages, monitor indexing and crawl errors, review structured-data reports, and compare traffic and conversions with the pre-launch baseline. If the site moved domains or changed large numbers of URLs, watch redirect coverage and legacy landing pages closely.

The first month should have a defined monitoring cadence. Check blockers immediately, indexation weekly, Core Web Vitals and technical health after material releases, and commercial performance often enough to spot a broken form or tracking gap before a month of data is lost.