Website Launch Checklist: 30 Pre-Launch Checks

A website launch checklist is a short list of checks you complete before and just after a new site goes public, and the most useful version covers search settings (indexing, redirects, sitemaps and crawler access) as well as design and forms. This one has 30 checks in six groups. Run them in order and you will catch the mistakes that cost sites traffic: a leftover noindex tag, a missing redirect, a robots.txt written for staging.

It is for owners, marketers and developers shipping a new site or a full rebuild. Existing URLs changing hands? Read the deeper website migration SEO checklist as well. This page is the launch-day layer that sits on top of it.

On this page

• What does a website launch checklist need to cover?
• Content and design QA
• Which indexing settings must change at launch?
• How do you handle redirects at launch?
• Should AI crawlers be able to reach your new site?
• Performance, forms and tracking
• What should you check after launch?
• Running your website launch checklist without surprises

What does a website launch checklist need to cover?

It needs to cover everything a visitor sees and everything a crawler decides, because a site can look perfect and still be invisible. The pages that rank for this query mostly stress the visible half: proofreading, links, forms, browser testing, legal pages. Those matter. The invisible half is where launches quietly fail.

The diagram below shows how the 30 checks in this post divide up. Notice that more than half sit in the indexing, redirect and crawler groups.

Scroll the diagram sideways to see all of it.

If you want the printable version of these steps, the new website launch checklist on this site covers the same ground in tick-box form.

Content and design QA

Start here because these are the checks everyone already expects, and they are cheap to finish. Do them on the final build, not on a mock-up.

1. Proofread every page, including headings, button labels and the footer. Search the site for “lorem”, “TODO” and “test”.
2. Check every image for size, quality and alt text. Compress before upload.
3. Match the brand: logo, fonts, colors and favicon the same on every template.
4. Publish the legal pages you need: privacy policy, terms, and a cookie banner where your audience requires one.
5. Test on real devices: a phone, a tablet and a laptop, in at least Chrome and Safari.
6. Click every link in the navigation, footer and body, internal and external, and make sure a custom 404 page appears for broken ones.

A habit that saves time: keep one person responsible for sign-off, and have them review the site as a visitor with a goal, such as “find the price” or “book a call”, rather than as an editor reading pages in order.

Which indexing settings must change at launch?

Every staging setting that hides the site must be reversed, and every production setting that helps search must be confirmed. Staging sites are usually blocked on purpose. The failure is forgetting to unblock them.

Google’s documentation on blocking indexing draws a distinction that trips up many teams. A page blocked in robots.txt can still end up indexed if other pages link to it, and a noindex rule only works if Google can crawl the page to see it. Its site move guidance adds a direct instruction: remove any noindex or robots.txt blocks that were only needed for the migration.

7. Remove the noindex meta tag and any X-Robots-Tag header from production templates.
8. Replace the staging robots.txt with the production file. A blanket Disallow: / is the classic leftover.
9. Confirm each page has a self-referencing canonical, which Google recommends for new URLs, pointing to the live domain and not to staging.
10. Generate the XML sitemap with only live, indexable, 200-status URLs. See our XML sitemap guide for what belongs in it.
11. Submit the sitemap in Search Console and add a Sitemap: line to robots.txt. Google describes sitemap submission as a hint, so do not treat it as a guarantee.
12. Inspect three key URLs with the URL Inspection tool and confirm Google can fetch and render them.

If your site is built on a static framework, the same checks apply but a layout file usually controls them, as in our Astro SEO guide.

How do you handle redirects at launch?

Map every old URL that has traffic or links to its closest new equivalent, and redirect it permanently on the server. Google recommends server-side permanent redirects, such as 301 and 308, and states that permanent redirects do not cause a loss in PageRank. It also says to keep them for as long as possible, generally at least one year.

Even if you are redesigning and keeping the same domain, URLs often change by accident: a trailing slash, a renamed category, a dropped date folder. Our redesign SEO guide covers how to keep URLs stable, and the redirects guide explains the status codes in depth.

13. Export the old URL list from your sitemap, analytics and Search Console before you touch anything.
14. Write the redirect map: old URL, new URL, one-to-one wherever possible. Do not send everything to the homepage.
15. Test the map on staging with a script that follows each redirect and records the final status.
16. Check for chains and loops. Each old URL should reach its destination in one hop.
17. Re-test on production within minutes of launch, because staging and production servers often handle redirects differently.

The diagram below shows the order of operations on launch day. The point is that the redirect test happens after the deploy, not only before it.

Scroll the diagram sideways to see all of it.

Should AI crawlers be able to reach your new site?

Decide it on purpose, per bot, because a launch robots.txt is where an accidental block happens. AI assistants can only recommend pages they can retrieve, and the major vendors now run separate crawlers for training, search and user requests.

OpenAI’s bot documentation says OAI-SearchBot is used to surface websites in ChatGPT’s search features, GPTBot is for content that may be used to train its models, and ChatGPT-User handles user-initiated actions. It also notes that for search results it can take about 24 hours after a robots.txt update for its systems to adjust. Anthropic’s crawler help article describes the same split: ClaudeBot for training, Claude-User for user requests, and Claude-SearchBot for improving search results.

Scroll the diagram sideways to see all of it.

18. Read your production robots.txt line by line and confirm it names the AI crawlers you intend to allow or block. Our robots.txt for AI crawlers guide has the patterns.
19. Separate search access from training access if your policy differs. Blocking a training bot does not hide you from a search bot, and the reverse.
20. Check the firewall and CDN, since bot protection can block crawlers that robots.txt allows.
21. View the page source and confirm the main content is in the HTML, not only added by JavaScript. See JavaScript rendering and AI crawlers for why this matters.
22. Confirm key pages carry a plain-text answer near the top, such as who you are, what you do and where. That is Ambeltek’s advice, not a documented requirement.

Performance, forms and tracking

Test the things that earn you money: speed on a phone, forms that deliver, and analytics that record. Web.dev defines the Core Web Vitals thresholds as 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint, and 0.1 or less for Cumulative Layout Shift, measured at the 75th percentile of page loads. Our Core Web Vitals explainer covers how to read the reports.

A lab test on staging gives a preview. Real-user data only arrives after launch, so treat the pre-launch number as a guide.

23. Run a mobile speed test on the homepage and the two heaviest templates.
24. Submit every form and confirm the notification email arrives and is not in spam.
25. Test the confirmation or thank-you page, and make sure it is a real URL your analytics can track.
26. Install analytics and Search Console verification, then trigger a test event and see it recorded.
27. Take a backup of files and database right after publishing, and note who can restore it.

What should you check after launch?

Check the live site within the hour, again after a day, and then weekly, because the problems that matter appear in crawl data rather than on the page. Google’s own migration advice includes using the URL Inspection tool for individual URLs and scripts for large batches.

28. Hour one: fetch /robots.txt and the sitemap on the live domain, spot-check ten redirects and submit a real form.
29. Day one to week one: watch Search Console for new indexing errors, soft 404s and server errors, using the Search Console guide as a reference.
30. Weeks two to four: compare clicks and impressions with your pre-launch baseline, and fix any lost URL with a redirect.

Expect some movement. A new design or structure can shift rankings for a while, and no source gives a reliable recovery date, so judge by trend, not by day.

Running your website launch checklist without surprises

The checks only work if someone owns them and runs them in the same order each time. Print the 30, assign a name beside each group, and do the indexing and redirect checks on the live domain, not just on staging. Then keep the list for the next launch, because every site you ship eventually gets a redesign.

If you would rather have the launch handled alongside the build, Ambeltek’s web development service includes search and AI crawler setup as part of delivery. For the wider technical review that follows a launch, work through the technical SEO checklist for AI search.