Technical SEO checklist for a website launch
A relaunch changes URLs, content and structure at the same time. This checklist shows what to check before, during and after launch so search visibility survives the move.
- Published
- Reading time
- 5 min

A technical SEO checklist for a website launch has three jobs: make sure search engines can crawl and index the new site, make sure every old URL redirects to its closest new equivalent, and make sure you can measure what happens next. When rankings fall after a relaunch, the cause is often a small, avoidable mistake — a noindex tag left over from staging, missing redirects, or a sitemap full of old addresses.
The checklist below is grouped by phase: before launch, launch day and the weeks after. It applies to a new site, a redesign and a migration to a new platform or domain.
Why a website launch puts rankings at risk
Search engines know your site as a set of URLs, each with its own content, links and history. A relaunch often changes all three at once: the addresses, the content on the pages and the way they link to each other. If the connection between old and new is not made explicit, search engines treat the new pages as unknown and the old ones as gone.
A brand-new site has no rankings to lose, but the same checks decide how quickly it is indexed. For a relaunch, start the SEO work while the structure is still being designed, not in the week before going live. Planning URLs and redirects during design and development is far easier than repairing visibility afterwards.
Before launch: the pre-launch SEO checklist
Record what you have today
You cannot protect what you have not measured. Before anything changes, take a snapshot of the current site.
- Crawl the existing site and export every URL with its title, description, canonical tag and status code.
- Export from Search Console the pages that receive organic traffic and the queries they appear for.
- List the pages that other websites link to. These carry the most value and need the most care.
- Note the current Core Web Vitals, so you have something to compare against.
Build the redirect map
The redirect map is the most important document in a website migration. It is a plain table: every old URL in one column, its closest new equivalent in the other.
- Map page to page. Sending every old address to the home page tells search engines the old content no longer exists.
- Use permanent, server-side redirects (301 or 308), not temporary ones.
- Redirect straight to the final address. Avoid chains where one redirect leads to another.
- Let retired pages go. Where nothing comparable exists, return a 404 or 410 rather than redirecting to something unrelated.
Check the staging site
Protect staging with a password rather than relying on robots.txt. It keeps the test site out of search results and leaves fewer blocking rules to forget on launch day.
- Every indexable page has a unique title and meta description. Keep the wording of pages that already perform well.
- Each page has a canonical tag that points to itself on the live domain, not to the staging address.
- Internal links point to final URLs, not to redirected or staging addresses.
- Structured data passes Google’s Rich Results Test and describes content that is visible on the page.
- The main content and links are present in the rendered HTML, not only after a visitor interacts with the page.
- If the site serves several countries, hreflang is in place — see our guide to international SEO.
Core Web Vitals and mobile rendering
Core Web Vitals are Google’s measures of how a page feels to use: how fast the main content appears, how quickly the page responds and how stable the layout is. Google publishes a threshold for a “good” result on each.
Test each page template, not only the home page: a product page, a category page, an article. Results measured on staging are an indication. Data from real visitors only builds up after launch, so check again then.
Google predominantly uses the mobile version of a page for indexing and ranking. Content, links or structured data that are missing on a phone are, for search purposes, missing.
Launch day: a checklist in order
Launch day is about sequence. Work through these steps in order and make one person responsible for ticking them off.
- Remove the password protection and check that robots.txt on the live domain allows crawling and names the XML sitemap.
- Confirm that no page carries a noindex tag or header from staging. Check every template.
- Activate the redirects and test the full list of old URLs. Each should reach its new address in one step.
- Check that the http, https, www and non-www versions of the domain all lead to one preferred version.
- Publish an XML sitemap containing only live, canonical, indexable URLs and submit it in Search Console.
- Verify the site in Google Search Console. If the domain has changed, use the Change of Address tool.
- Place a test enquiry or order to confirm that analytics, conversion tracking and the consent banner work.
- Inspect a few key pages with the URL Inspection tool to see them as Google renders them.
A page blocked in robots.txt cannot be read, so search engines never see the noindex tag on it. Use robots.txt to manage crawling and noindex to manage indexing — not both on the same page.
After launch: what to monitor
Some movement in rankings is normal while search engines process the changes. The task is to tell fluctuation from a fault, which is where the pre-launch snapshot earns its keep.
- Page indexing report in Search Console: watch for growing numbers of pages that are not found, excluded by noindex or caught in redirect errors.
- Not-found errors in server logs: old URLs that still receive visits but were missing from the redirect map. Add them.
- Organic traffic and enquiries by page, compared with the snapshot. A drop across one page type points to a template problem.
- Core Web Vitals from real visitors, once enough data has built up.
- External links: ask the owners of the most valuable ones to update them to the new address.
Keep the redirects in place for as long as possible. Removing them soon after launch discards the value that old links and bookmarks still pass on.
Common website migration SEO mistakes
- Staging settings go live. A noindex tag, a crawl block or canonical tags that still point to the staging address.
- Redirects are added afterwards. By then search engines have already met the errors.
- Content is quietly removed. Pages merged or shortened in a redesign lose the text they ranked for.
- Tracking breaks. Without reliable data you cannot say whether the launch went well.
None of this is complicated, but it depends on order and ownership. We treat technical SEO as part of the build rather than a task for the final week. If you are planning a relaunch and would like a second pair of eyes on the redirect map, start a conversation.
FAQs
Questions people ask.
Not necessarily. Some short-term fluctuation is normal, but lasting losses usually come from missing redirects, removed content or blocked indexing — all of which can be prevented with planning.
The redirect map. Every old URL should lead, with a permanent redirect, to the closest matching page on the new site, so visitors and search engines can follow the move.
For as long as possible. Old links and bookmarks keep sending visitors for a long time, and the redirect is the only thing connecting them to the new page.
Password protection is the safer choice. It keeps the staging site out of search results reliably and means there is no blocking rule that could be carried over to the live site by mistake.
Related serviceSEO & search visibility
Explore the service

