What does a launch checklist cover?
A launch checklist is a release plan for the details that affect discoverability, trust and essential tasks. It should cover the approved build before production, the changeover itself and the live site after the new version is available.
| Phase | Purpose | Evidence to keep |
|---|---|---|
| Pre-launch | Find defects while the team can still change the build. | Approved staging crawl, test results, URL map and release decision. |
| Launch day | Confirm that production has the intended access, content and measurement. | Live checks, deployment time, owners and rollback decision. |
| Post-launch | Catch regressions and compare the live result with the old baseline. | Fresh crawl, monitoring notes, fixes and accepted exceptions. |
A launch is complete when the important journeys work in production and the team can explain what changed. A green deployment alone is not enough.
Assign owners and prepare the release
Give each check an owner who can make or request the repair. Include development, content, SEO, analytics, design, accessibility and the people responsible for customer or commercial journeys.
- write down the release scope, date, dependencies and success conditions;
- record who can pause, roll back or escalate the release;
- save the old production crawl, sitemap and important URL list;
- agree which production checks can run immediately and who will run them;
- keep a copy of the approved build settings so staging and production differences are deliberate.
Rehearse the release when the risk is high. A rollback plan that exists only in someone's memory is not a plan.
How to securely check staging
Staging should be protected from unintended visitors and search discovery. Use authentication, network restrictions or another access control where possible. If a staging environment is publicly reachable, verify its noindex and robots protections as an additional safeguard.
You may crawl a staging site only when you are authorised to do so. Check the environment's host, credentials, rate limits and data handling before starting.
Check search access and production signals
Compare the staging and production signals for important pages. On the live host, confirm that:
- important pages return the intended successful status;
- robots.txt allows the crawling that production needs;
- the accidental staging
noindexdirective is gone; - canonicals use the live preferred URLs and agree with internal links;
- the XML sitemap is reachable, valid and contains the right production URLs;
- the live host, protocol and language versions are consistent;
- important content is present in rendered output where JavaScript is involved.
Check production directly. A staging site can look perfect while DNS, caching, headers, redirects or environment variables make the live result different.
Check content, metadata and structured data
Compare representative pages with the approved copy and design. Look for missing text, placeholder content, broken images, wrong prices, outdated contact details and links that still point at the test environment.
Review title tags, headings, meta descriptions, canonical URLs, language attributes and structured data. Markup should describe visible production content, not the staging version or a template example.
Run structured-data tests for important templates and inspect warnings that could affect the intended feature. Do not add markup simply to make the report look complete; it must be accurate. Before launch, verify how crawlers find the sitemap and where moved URLs should lead. A final crawl with technical SEO software can catch issues across templates.
Test accessibility, mobile and performance
Run representative checks at the sizes and conditions people actually use. Confirm that the main navigation, forms, dialogs and content can be operated with a keyboard and that focus remains visible.
Check mobile layouts, text wrapping, touch targets, zoom and reflow. Measure important templates under realistic network and device conditions, then investigate changes in loading, layout stability and interaction readiness.
Use automated tools to find patterns, but manually test high-value tasks. A page can pass a scan and still leave someone unable to understand an error or complete the next step.
Map redirects for redesigns and migrations
For a redesign or migration, inventory the old URLs before launch and map each one to the closest useful destination. Include URLs from the old crawl, sitemap, analytics, Search Console and backlink evidence.
| Old URL outcome | Recommended treatment |
|---|---|
| Content has a close new home | Use one direct permanent redirect and update internal links. |
| Several pages become one useful resource | Choose the preferred destination and redirect each close equivalent directly to it. |
| Content has no relevant replacement | Return an honest 404 or 410 and repair important incoming links. |
| URL remains valid but its template changes | Keep the URL and verify content, canonical, links and measurement on the live page. |
Avoid redirect chains, loops and blanket homepage redirects. A redirect preserves a useful route; it should not hide the fact that an unrelated page was removed.
Launch-day checks
Run a short, high-value list immediately after the change:
- 01Open the live host.
Confirm DNS, HTTPS, the expected deployment and the main templates.
- 02Check search access.
Review robots, noindex, canonicals, sitemap and a sample of important URLs.
- 03Test key journeys.
Submit the important forms and follow the main conversion or support route.
- 04Check measurement.
Confirm analytics, consent, events and error monitoring are using production settings.
- 05Save the result.
Record the time, checks, defects, decisions and rollback status.
Monitor the following weeks
Crawl production immediately, then repeat checks as data accumulates. Compare important pages with the old baseline and investigate changes in status, indexing, redirects, organic visibility, conversions, errors and performance. Re-run structured-data tests after template changes.
Keep the release checklist open until the owner has verified the fixes. Review Search Console messages, analytics anomalies and customer reports. A page can appear healthy at launch and fail later when caches expire, content is imported or a dependent service changes.
Run a launch checklist with Clearcrawl
- 01Save the old production crawl.
Retain the URL, status, metadata, links and indexability baseline before the release.
- 02Crawl staging where authorised.
Check the approved build without exposing private credentials or test data.
- 03Compare important signals.
Look at URL counts, status, canonicals, titles, headings, links and sitemap membership.
- 04Crawl live production immediately.
Verify the real host rather than assuming the staging result carried over.
- 05Filter differences to critical pages.
Start with priority templates and essential journeys before widening the review.
- 06Repair and recrawl.
Confirm the fix, check side effects and retain the new production baseline.
Common website launch mistakes
Production can differ through DNS, headers, caching and environment settings.
A noindex or disallow rule that survives launch can hide the entire site.
Map each old URL to its closest useful destination or return an honest gone response.
Without the previous crawl and URL inventory, important losses are harder to spot.
Post-launch crawling and monitoring catch regressions that release checks cannot predict.
Frequently asked questions
What should be included in a website launch checklist?
Include search access, robots and noindex rules, canonicals, sitemaps, content and metadata, redirects, analytics, structured data, navigation, forms, essential journeys, accessibility, mobile behaviour, performance, launch-day checks, rollback ownership and post-launch monitoring.
When should I start website launch QA?
Start when the important templates and journeys are stable enough to test, not on launch day. Test the staging build in phases, compare it with the approved baseline, rehearse the release and leave time to fix shared causes before production access changes.
Should a staging website be blocked from search engines?
Yes, staging should normally be protected from public access and search discovery through authentication, network controls or an appropriate noindex and robots setup. These protections must be checked and removed or changed deliberately when the production site goes live.
Do I need redirects for a completely new website?
Redirects are needed whenever old URLs have a useful replacement or must preserve an existing route, even if the visual design is new. If a URL has no relevant replacement, a clear 404 or 410 may be more honest than sending everyone to the homepage.
How long should I monitor a site after launch?
Monitor closely for the first few days, then continue checking search access, errors, important journeys, analytics and performance over the following weeks. The right period depends on traffic, release risk and how quickly meaningful search and conversion data accumulates.
ClearcrawlLaunch with evidence, not hope
Compare the approved build with the live site, crawl before and after launch, test essential journeys and keep the result as the maintenance baseline.
7 free days. See what Clearcrawl can find, then choose the plan that fits your site.