A website launch is one of the highest-risk moments in a brand's digital life. Done well, it preserves ranking equity, establishes a clean technical foundation, and gives content the best possible conditions to perform. Done poorly, it can cost months of organic visibility that is genuinely difficult to recover.
The checklist below covers what a thorough pre-launch, launch-day, and post-launch process looks like. Several of these items are routinely skipped, not out of negligence, but because most agencies hand over a design, not a deployment plan.
Robots.txt and staging noindex. The most common pre-launch mistake is allowing a staging site to be indexed. If your staging environment is publicly accessible without a noindex directive, Google may crawl and index it before launch. Your staging server should either be behind authentication or carry a `Disallow: /` in its robots.txt, with meta robots set to `noindex` across all staging pages.
Canonical setup. Every page should have a self-referencing canonical tag before launch. This is particularly important for e-commerce and content sites where URL parameter variations can generate near-duplicate pages. Decide your preferred URL format (with or without trailing slash, HTTPS, www or non-www) and implement it consistently from day one.
Redirect mapping. If you are migrating from an existing site, every URL that currently receives traffic or has inbound links needs a 301 redirect mapped to its new destination. This is where the majority of ranking equity is preserved or lost. Use Screaming Frog to crawl your existing site before launch and export a full URL inventory. Map redirects to the closest equivalent page, not the homepage.
Schema markup implementation. Implement and test structured data before launch, not as a post-launch task. At minimum, Organisation schema on the homepage, breadcrumb schema on all interior pages, and any content-type-specific schema should be validated using Google's Rich Results Test before the site goes live.
Internal linking structure. Confirm that all key pages are reachable within three clicks from the homepage. Orphaned pages with no internal links pointing to them will not be crawled or indexed efficiently.
Submit the XML sitemap. Once the site is live, submit the sitemap to Google Search Console immediately. Ensure the sitemap includes only canonical, indexable URLs, not redirect URLs, noindex pages, or pages returning non-200 status codes.
Verify Search Console properties. If you are migrating domains or launching under a new URL, verify both the HTTP and HTTPS versions, and both www and non-www variants, in Search Console. Use the property set feature to aggregate data across them.
Check for crawl errors. Run a full crawl of the live site using Screaming Frog within hours of launch. Look for 404 errors, broken internal links, and redirect chains of more than one hop. A 301 redirect chain (A redirects to B, which redirects to C) bleeds link equity with each additional hop; flatten all chains to direct redirects.
Verify analytics and conversion tracking. Confirm that Google Analytics is firing correctly on all pages and that goals and conversions are tracking. Launching without verified conversion tracking means you will have no reliable baseline data for the post-launch period.
Monitor crawl coverage. In Google Search Console, the Coverage report shows how many pages have been indexed versus submitted. A significant gap warrants investigation. Common causes include thin content, canonicalisation issues, or crawl budget consumed by parameter-generated URLs.
Core Web Vitals baseline. Establish your Core Web Vitals baseline as early as possible. Google's documentation on Core Web Vitals specifies that LCP (Largest Contentful Paint) should occur within 2.5 seconds, INP (Interaction to Next Paint) should be under 200 milliseconds, and CLS (Cumulative Layout Shift) should be below 0.1. These are confirmed ranking factors, and post-launch benchmarks are much easier to set when you measure early.
Watch for coverage drops. A sudden drop in indexed pages a few weeks after launch often signals that Google has encountered quality issues. This can be caused by duplicate content from parameter URLs, thin pages discovered during deeper crawl rounds, or misconfigured canonicals.
Hreflang on multilingual sites. If the new site serves content in more than one language or for more than one geographic region, hreflang tags must be implemented and cross-referenced correctly from day one. A missing or incorrect hreflang annotation means Google may serve the wrong language variant to users, or treat variants as duplicate content.
Duplicate content from URL parameters. Tracking parameters, session IDs, and filter combinations can generate hundreds of near-duplicate URLs within days of launch. These need to be handled at launch via robots.txt disallow rules, canonical tags, or parameter handling settings in Search Console.
Canonical on paginated pages. Paginated content (/page/2, /page/3, etc.) should use self-referencing canonicals, not canonicals pointing back to page one. Pointing all paginated pages to page one effectively removes them from the index.
Schema testing on the live URL. Many teams implement schema correctly in staging but find that the live deployment breaks it due to CMS rendering issues. Testing with the Rich Results Test on the live URL within hours of launch is not redundant; it is essential.
For brands that want ongoing technical oversight beyond the launch phase, Viaduct Generation's optimisation service covers continuous technical monitoring, crawl management, and performance improvements. A successful launch is a starting point, not a destination.
If you are planning a new site launch and want a structured pre-launch review, get in touch with the team before the build phase is complete.
