Website launch SEO checklist for new sites and redesigns

This is the checklist I work through when a UK business launches a new website or replaces an old one. It follows the order the work happens in: planning, the private build, redirects, the final week, launch day and the month after. Most items take minutes to check. Skipping them is how a site that looked finished on Friday ends up missing from Google, or quietly loses the enquiries the old site used to bring in.

It is not a guide to deciding whether you need a new site at all. If you are still weighing that up, start with whether to build a new website or fix the one you have, then come back here once the decision is made.

How to use this checklist

• A brand-new site on a new domain: nothing ranks yet, so there is no traffic to lose. Skip section 3 and give sections 2, 4 and 5 your full attention, because one forgotten setting there can keep the site out of Google until someone notices.
• A redesign on the same domain: every section applies. URLs, page copy and templates usually change together, and each change can cost visibility the old site had earned.
• A move to a new domain or platform (Wix to WordPress, say, or a .co.uk to a .com): every section applies, and section 3 decides how it goes.
• Give each line an owner. On a typical launch the designer, developer, marketer and business owner each assume someone else checked robots.txt. Put a name next to every item.

1. Before design starts

The cheapest SEO decisions are made before anyone opens a design tool. Changing a page plan in a spreadsheet costs nothing; changing it once templates are built costs developer time.

• Plan pages from what people search for, not from the old menu. Each page should serve one search intent, and no two pages should compete for the same one. Keyword research and a page-by-page keyword map belong here, before the sitemap is signed off.
• Agree the URL pattern. Short, lower case, hyphenated and stable. If an existing page is staying and its URL already works, keep that URL exactly as it is: an unchanged URL needs no redirect.
• Inventory the current site if there is one: every URL, its organic visits and enquiries over the last 12 months from GA4, its clicks from Search Console, and which pages have links from other websites. This list tells you which content has to survive, and it becomes the starting point for the redirect map.
• Record a baseline. Export Search Console performance by query and by page for the full 16 months it keeps, note organic enquiries per month, and save a crawl of the old site. Without one you cannot tell after launch whether anything was lost, or where.
• Confirm who owns what. The domain registrar account, DNS, hosting, Google Search Console, GA4, Google Tag Manager and Google Business Profile should sit in the business’s own name, with the agency or freelancer added as a user. Launches stall when the only person with DNS access has moved on.
• Put SEO requirements in the developer’s brief: an editable title and meta description per page, one H1 per template, real heading tags rather than styled text, an XML sitemap, editable canonical tags, alt text fields on images, and no important content that disappears on mobile.

2. While the site is on staging

A staging site is the private copy where the new site is built and tested. Two things go wrong at this stage: Google finds and indexes the staging copy, or the settings that kept it hidden are carried across to the live site.

• Protect staging with a password Using HTTP authentication on the server or your host’s built-in protection. A Disallow rule in robots.txt stops crawling but does not stop a linked URL being indexed, and a noindex tag only works if Google is allowed to crawl the page and see it. A password deals with both.
• Write down every block you add: the password, noindex settings, Disallow rules, and WordPress’s search engine visibility setting. Each one must come off on launch day, and this list becomes your launch-day script.
• Build with the final copy, not placeholder text. Layouts that look tidy with three lines of dummy text often break with real headings, real prices and real FAQs.
• Give every page a unique title tag and meta description. Run them through the title tag and meta description checker so they are not cut short in search results.
• Check internal links. Every important page should be reachable from the menu or from related pages, with link text that describes where it goes. A page nothing links to is hard for Google to find and rarely ranks.
• Find out how canonical tags are generated. If they come from the site address setting, they will switch to the live domain at launch. If a developer has typed the staging address into a template or plugin setting, find it now.
• Add structured data where it fits: Organisation or LocalBusiness markup on the home or contact page, with the address written the same way it appears on your Google Business Profile, postcode included.
• Test on a real phone over mobile data Not only on office Wi-Fi. Google indexes the mobile version of each page, so anything missing on mobile is, as far as Google is concerned, missing.
• Check speed on the main templates (home, a service page, a blog post, a product page) with Google’s PageSpeed Insights. Oversized images and piles of third-party scripts are the usual culprits, and both are easier to fix before launch than after.
• Build the cookie banner now. Under PECR, cookies that are not strictly necessary generally need consent before they are set, and the ICO expects rejecting to be as easy as accepting. The Data (Use and Access) Act 2025 relaxes the rule for some analytics cookies, so read the ICO’s current guidance before deciding what your banner covers. Advertising and remarketing tags still need consent. Test that they stay silent until the visitor agrees.
• Write the privacy and cookie policies from what the new site actually does: which forms collect what, which tools receive the data, which cookies are set. A policy copied from the old site rarely matches a rebuilt one.
• If you trade as a limited company Your website must show the company’s registered name, registered number, place of registration and registered office address. These usually sit in the footer, and they are easy to lose in a redesign.

3. The redirect map (redesigns and moves only)

When a page’s URL changes, a permanent 301 redirect from the old address to the new one tells Google where the page has gone and carries across the signals it had built up, including links from other sites. Without one, visitors and Google land on an error page, and the ranking the old URL held usually goes with it.

• Collect every old URL Not just the ones in the menu: a crawl of the old site, its XML sitemap, every page with clicks in Search Console, landing pages in GA4, and pages with backlinks according to a link tool. Old PDFs and image URLs that still get visits count too.
• Map each old URL to its closest new equivalent One to one. An old service page goes to the new page for the same service, not to the home page. Google tends to treat a mass redirect to the home page as a soft 404, which wastes whatever those pages had earned.
• Let pages with no equivalent and no value return a 404 or 410 instead of forcing them onto something unrelated.
• Avoid chains and loops. If an old URL already redirects somewhere, point the original straight at the final new address. Every extra hop in a redirect chain slows the response and adds another place for a mistake.
• Set the site-wide rules: http to https, non-www to www (or the reverse), trailing slashes and capital letters should each reach the single version you have chosen in one hop.
• Turn the spreadsheet into server rules with my redirect map builder, which also flags chains and loops before they go live.
• Test the map on staging if your setup allows it, and straight after launch at the latest: every old URL should return a single 301 to a page that returns a 200.

A domain or platform move carries more risk than a redesign, because everything changes at once. If you would rather not run one yourself, this is the work I cover in website migration SEO.

4. The week before launch

• Crawl the staging site with a crawler such as Screaming Frog, whose free version handles up to 500 URLs. Look for broken links, missing or duplicate titles, pages without an H1, and links that still point at the old domain or at staging.
• Compare the crawl with your inventory. Every page you decided to keep should exist on the new site with its substance intact. Copy that is quietly dropped in a redesign is one of the most avoidable causes of lost rankings.
• Test every form on a phone and a laptop. Confirm each enquiry reaches the right inbox, the automatic reply goes out, and the thank-you page loads.
• Test tracking from end to end: GA4 receives page views and key events, Tag Manager fires the right tags at the right time, and nothing fires before consent where consent is needed. My guide to checking your conversion tracking works sets out the tests step by step.
• Prepare the XML sitemap so it lists only live, indexable URLs that return a 200: no redirected URLs, no noindexed pages and no staging addresses.
• Lower the DNS TTL (time to live) on the records you will change a day or two ahead, so the switch to the new server spreads quickly once you make it.
• Take a full backup of the old site and keep the old hosting running for a few weeks, so you can roll back or recover anything that was missed.
• Pick the launch day with care. Early in the week, with the developer free for the days that follow. Avoid Friday afternoons and the run-up to a bank holiday, when nobody is around to fix what breaks, and keep clear of your busiest trading weeks if the business is seasonal.

5. Launch day

Work through these on the live domain, in this order, as soon as DNS has switched over. On a small site they take about an hour.

1. Remove every staging block on your list. On WordPress, open Settings, then Reading, untick “Discourage search engines from indexing this site” and save. Left ticked, that one box is enough to keep a finished site out of Google indefinitely, and it is easy to miss because nothing on the site looks any different.
2. Fetch robots.txt by typing your domain followed by /robots.txt into a browser. Under “User-agent: *” there should be no line that reads “Disallow: /” on its own. Depending on the WordPress version, the visibility setting adds that line, a noindex tag on every page, or both, so check for both.
3. Look for stray noindex tags on every template Not just the home page: a service page, a blog post, a category page, a product page and the contact page. View the page source and search for “noindex”, and check the response headers for an X-Robots-Tag. SEO plugins often hold a noindex setting per post type that was switched on during the build.
4. Check canonical tags on the same templates point at the live https address of the page itself.
5. Test the redirects: run the list of old URLs through a crawler in list mode and confirm each one returns a single 301 to a live page. Then try the http, non-www and no-trailing-slash versions of the home page.
6. Check the SSL certificate covers both the www and non-www addresses, and that no page loads images or scripts over plain http.
7. Submit the XML sitemap in Google Search Console and in Bing Webmaster Tools, which can import the sites you already have in Search Console. If the domain has changed, use Search Console’s Change of Address tool once the redirects are working.
8. Inspect your key pages with Search Console’s URL Inspection tool, run the live test to confirm each is indexable, and request indexing for the home page and your main service pages.
9. Send a real enquiry through each live form and confirm it arrives and appears in GA4’s Realtime or DebugView report. Check the cookie banner again on the live domain, since consent tools sometimes behave differently once the domain changes.
10. Update the website link on your Google Business Profile and main social profiles if the URL has changed.

If the site still does not appear in Google a few weeks later, my article on why a website is not showing on Google works through the possible causes in order.

6. The first four weeks

• Read the Page indexing report in Search Console twice a week. Look for important pages listed as excluded by a noindex tag, not found (404) or page with redirect, and fix the cause rather than the symptom.
• Watch for 404s in Search Console and in your server or plugin logs. Any old URL with visits or links that turns up there needs adding to the redirect map.
• Compare against the baseline every week: clicks and impressions by page in Search Console, and organic enquiries in GA4. Some movement in the first weeks is normal while Google recrawls the site. A steady fall on particular pages points to a missing redirect, lost content or a template fault on those pages.
• Crawl the live site again about a week after launch, once the late fixes have settled, and deal with anything that has crept in.
• Update the links you control: directory and citation listings such as Yell, Bing Places, Apple Business Connect and trade bodies, email signatures and social profiles. Ask the sites that send your most valuable links to update them to the new addresses.
• Check Core Web Vitals in Search Console once there is enough real-visitor data, which can take several weeks on a quieter site.
• Keep the redirects in place for at least a year And in practice for good. Google’s guidance on site moves with URL changes recommends keeping them as long as possible, and removing them throws away links that still point at old addresses.

After the first month the new site needs the same ongoing care as any other. My SEO audit checklist covers that regular review, which is a different job from these launch checks.

Where launches usually go wrong

When a launch loses traffic, the cause is rarely technically difficult. It is nearly always a step that nobody owned.

Updated 6 October 2026