Website Launch SEO Checklist: Before and After Go-Live

The HTTP Archive’s Web Almanac 2024 found that 83.9 per cent of mobile sites returned a 200 status for robots.txt, a reminder to verify crawl settings after launch.

A new website can look perfect on launch day and still be invisible to Google because of one forgotten setting. This checklist walks you through every SEO task to finish before you switch the site on, the order to do them in, and what to watch during the first month so small problems never become expensive ones.

A staging site that was blocked from search engines goes live with the block still in place. Old URLs that earned links for years start returning errors. A contact form quietly stops sending emails. None of these are hard to fix, but each one costs you time and trust if nobody spots it. Work through the sections below in order and tick each item off.

Why launch day is the riskiest day for SEO

If you are still at the planning stage, start with how to plan your site architecture and URLs instead, because structure is cheaper to fix before design. Before launch, your site lives on a staging server where it is meant to be hidden. After launch, it needs to be fully open to search engines and users. That switch from hidden to visible touches several settings at once, and developers often change them in a rush on the final afternoon.

If you are replacing an old site, the stakes are higher. Google has already indexed your old pages, other websites link to them, and some of them probably bring in steady traffic. A redesign that changes URLs without a plan throws that history away. If you are building from scratch, the risk is lower, but a poor launch still delays the point at which Google discovers and trusts your pages.

Stage one: open the site to search engines

These are the settings that decide whether Google can see your site at all. Check them first, and check them again after the site is live, because some hosting setups and plugins reset them during migration.

• Remove any sitewide noindex. Most platforms have a setting that discourages search engines while a site is in development. In WordPress it is a single checkbox in the reading settings. Make sure it is off, then view the source of a few live pages and confirm there is no noindex in the robots meta tag.
• Remove password protection. Staging sites are often locked behind a login or server-level password. Visit the live site in a private browser window to confirm it loads without credentials.
• Check robots.txt. Open yoursite.com/robots.txt. A line reading Disallow: / under User-agent: * blocks the entire site. Remove it. Only block areas that genuinely should not be crawled, such as admin or cart pages.
• Confirm the canonical domain. Decide on one version: with or without www, and always on https. Every other version should redirect to it with a single permanent redirect.
• Check canonical tags. Each page should point its canonical tag at its own live URL, not at the staging domain. This is a common leftover when a database is copied from staging to production.

Stage two: protect what the old site earned

Skip this stage if your domain is brand new. If you are replacing a site, this is the most important section in the whole checklist.

1. Export every old URL. Pull a list from a crawl of the old site, your old XML sitemap, and your analytics landing pages report. Search Console’s page indexing and performance reports will show URLs Google knows about that a crawl might miss.
2. Map each old URL to its closest new equivalent. Put them side by side in a spreadsheet. A page about kitchen renovations should redirect to the new kitchen renovation page, not to the homepage.
3. Use permanent 301 redirects. Temporary redirects send the wrong signal for a permanent move. Redirect each old URL directly to its final destination, without chains of redirect after redirect.
4. Decide what to do with pages that have no equivalent. If the content is gone for good and nothing similar exists, a 404 or 410 response is honest and acceptable. Do not dump hundreds of unrelated pages onto the homepage.
5. Test the redirects before launch. Run your old URL list through a crawler or a bulk redirect checker once the new site is live and confirm every one returns a single 301 to the right page.

Changing URL formats during a redesign is fine as long as the redirects are in place. If you are deciding on the new format, the principles in this guide to SEO-friendly URLs will help you pick a pattern you will not want to change again.

Stage three: on-page basics on every template

Launch is a good moment to catch content issues, because you can review every page type in one pass. Rather than checking hundreds of pages one by one, check each template and then spot-check a sample of pages built from it.

• Unique title tags on every page, written for the searcher, with the main topic near the start. Watch for templates that output the same title on every page or just the site name.
• Meta descriptions that describe the page accurately. Google may rewrite them, but a good one still helps your result look relevant.
• One clear H1 per page that matches the page’s purpose. Logos and decorative text should not be marked up as headings.
• Image alt text on meaningful images, and sensible file names. Remove placeholder images and dummy text left over from the design stage.
• Structured data where it fits: Organization or LocalBusiness on the homepage or contact page, Article on blog posts, Product on product pages, BreadcrumbList if you use breadcrumbs. Test it with Google’s Rich Results Test and fix any errors.
• Internal links that work. Click through the main navigation, footer and in-content links. Any link still pointing at the staging domain or a test page needs fixing.

Stage four: speed, mobile and the pages users rarely see

Search engines and users judge a site on how it behaves, not just what it says. These checks cover performance and the parts of the site that only show up when something goes wrong.

Speed

Run your homepage and one example of each main template through PageSpeed Insights. Look at the Core Web Vitals assessment and the specific opportunities listed underneath. Common launch-day culprits are uncompressed hero images, too many web fonts, and scripts from page builders or tracking tools that load on every page whether needed or not. Fix the biggest items first; perfection is not the goal on day one.

Mobile

Google primarily uses the mobile version of your pages for indexing and ranking, so the mobile experience is the real site. Open every template on an actual phone, not just a resized desktop browser. Check that menus open, buttons are easy to tap, text is readable without zooming, and nothing spills off the side of the screen. Make sure no content or internal links are hidden on mobile that exist on desktop. For a fuller picture, read what mobile SEO optimisation involves.

The 404 page

Type a nonsense URL on your domain. You should see a helpful page with navigation and a search box or links to key sections, and the server should return a genuine 404 status code. A “not found” page that returns a 200 status is called a soft 404 and confuses search engines.

Forms and conversions

Submit every form on the site, including contact, quote and newsletter forms. Confirm the email arrives, lands in the right inbox, and does not go to spam. Test any booking widget or checkout with a real transaction if you can.

Stage five: measurement set up before the first visitor

If you do not record data from day one, you cannot tell later whether the launch helped or hurt. Set these up before you announce the site.

Check the sitemap carefully. Many plugins include tag archives, author pages, attachment pages or test pages by default. Your sitemap should be a list of pages you actually want people to find. If you are still choosing a platform, how easily it handles sitemaps, redirects and canonical tags is a big part of choosing a CMS for SEO.

The first month after launch: what to monitor

Launch is not the finish line. The first few weeks show you how search engines are reacting, and most problems are easy to fix if you catch them early. Here is a simple monitoring routine.

Days one to three

• Recheck noindex, robots.txt and password protection on the live site.
• Use the URL Inspection tool in Search Console on the homepage and a few key pages to confirm Google can fetch and render them.
• Run a full crawl of the live site and look for broken links, redirect chains and pages accidentally set to noindex.
• Confirm analytics is recording visits and form submissions.

Week one to two

• Check the page indexing report in Search Console. Look at the reasons pages are not indexed and decide whether each reason is expected.
• If you migrated, watch for old URLs appearing as 404 errors. Each one is a missing redirect.

Weeks three to four

• Compare impressions and clicks in Search Console against the same period before launch. Some movement during a migration is normal while Google processes the changes.
• Look for pages that used to perform and have dropped. Check their redirects, content and internal links first.
• Review Core Web Vitals data as field data starts to build up for the new pages.

Questions people ask about launching a site

A clean launch is much easier when SEO is part of the build from the first wireframe rather than a list of fixes at the end. That is the thinking behind my SEO web design and development service. If you are about to launch or have just launched and want a second pair of eyes, request a free audit and I will tell you what needs attention first.