Website launch SEO checklist: what to check when a new site goes live

A new website can lose its first weeks in Google to one leftover line of code: a noindex tag, or a robots.txt file that still says "Disallow: /". This website launch SEO checklist takes you through the jobs in order, from two weeks before launch to the first week after, each with the Google Search Central page behind it and a free tool that checks it.

The example is a made-up business, Greenleaf Interiors in Gachibowli, Hyderabad, which is replacing its old website with a new one on the same domain.

Before launch: keep the test site private

Your developer builds the new site on a test address, such as staging.greenleaf.example. Keep it out of Google with a password, not with robots.txt alone. Google's page on controlling what you share says Googlebot and other crawlers cannot reach content in password-protected directories. Its robots.txt introduction is just as clear the other way: robots.txt is not a mechanism for keeping a page out of Google, and a blocked URL can still appear in results if other pages link to it.

A noindex tag is not enough on its own either. Google's guide to blocking indexing with noindex says the rule works only when the crawler can reach the page; if robots.txt blocks it, Google never sees the noindex.

There is a second reason to prefer a password. Google's robots.txt specification says the file must sit in the top-level directory, and its rules apply only to the host, protocol and port where it is hosted. The test site's robots.txt protects only the test site, and when the files are copied across at launch, the "Disallow: /" line can travel with them. A forgotten password, by contrast, is obvious the moment anyone tries to open the live site.

Replacing an old site? Build the redirect map first

If the new site replaces an old one, every old address that changes needs a redirect. Build the map before launch, not after the complaints start.

1. List every old URL: the old XML sitemap, the pages in Search Console's Performance report, your most visited pages in analytics, and the pages other sites link to.
2. Match each old URL to its closest new page. Greenleaf's old /services.php?id=3 becomes /services/modular-kitchens, and /gallery.html becomes /projects.
3. Decide what to do with pages that have no new equivalent, rather than sending them all to the home page.

Google's guide to site moves with URL changes asks for server-side permanent redirects from each old URL to its new one, pointing straight at the final address rather than through a chain. It warns that redirecting many old URLs to one unrelated page, such as the home page, can confuse users and may be treated as a soft 404. Keep the redirects as long as possible, generally at least one year, so Google can pass the old pages' signals to the new ones. Google's page on redirects lists 301 and 308 as the permanent status codes.

Our guide to website migration SEO covers the full move, including a change of domain.

Launch day, step 1: remove the blocks

Start the morning by taking down everything that kept the test site private:

• The password. Remove it from the live server.
• Every noindex rule. Take it out of the page code itself. Google's JavaScript SEO basics say that when Google finds noindex, it may skip rendering and running JavaScript, so a script that removes the tag later may never run for Google.
• robots.txt. Replace the test file with one that allows crawling, and add a Sitemap: line with the full address of your sitemap.

Then check a handful of pages: the home page, two service pages, a blog post and the contact page. Our Indexability Checker follows a page's redirects, then checks the status code, robots.txt for Googlebot, noindex in the robots meta tag and the X-Robots-Tag header, and the canonical link. Our Robots.txt Tester fetches the live robots.txt, tests any path for Googlebot or another crawler, shows which line decides, and warns if the whole site, CSS or JavaScript is blocked. Both are our own tools, not Googlebot, so treat them as a first check and confirm with URL Inspection in Search Console.

Launch day, step 2: one address, over HTTPS

Most sites can be reached at four addresses: http and https, with and without www. Choose one, for example https://www.greenleaf.example, and send the other three to it with a single permanent redirect each.

Google's page on URL canonicalisation says Google prefers the HTTPS version of a page as the main one, unless something conflicts, such as an invalid certificate or a redirect from HTTPS back to HTTP. Its guide to consolidating duplicate URLs calls redirects and rel="canonical" tags strong signals of the main address, and listing a URL in a sitemap a weak one. So make all three agree: every page's canonical tag and every sitemap entry should use the same version you redirect to. A canonical tag is a hint, not a rule, which is one more reason to keep the signals consistent.

Put the four versions of your home page, and a sample of old URLs from your redirect map, into our Redirect Checker. It shows each hop with its status code and the final address, tests all four versions of the domain, and flags chains, temporary redirects, loops and a missing HTTPS redirect. You can check up to 10 URLs at once.

Launch day, step 3: tell Google

With the blocks gone and the addresses settled, introduce the site to Google.

Search Console. Search Console Help on adding a property describes two kinds. A Domain property covers every subdomain and both http and https, and is verified with a DNS record. A URL-prefix property covers one exact address, including the protocol, and offers other ways to verify, such as an HTML file or tag.

The sitemap. List the final, canonical address of every page you want in Google. Google's guide to building a sitemap limits one file to 50,000 URLs or 50 MB uncompressed, and lets you submit it in the Sitemaps report in Search Console or list it in robots.txt. Run it through our Sitemap Validator first. It checks the XML, the URL limit, that every URL is a full address on your own site, the lastmod dates and repeats, then opens up to 15 listed pages to find any that redirect, fail, carry noindex or point their canonical elsewhere.

Key pages. In Search Console's URL Inspection tool, test the live home page and your main service pages, then request indexing. Google's page on asking Google to recrawl says there is a quota, that requesting the same URL again does not make it faster, and that crawling can take from a few days to a few weeks. Nothing guarantees that a page will be indexed.

Here is how launch day went for Greenleaf, in this made-up example:

The first week: indexing, 404s and speed

Launch day is not the end. In the first week, open the Page indexing report in Search Console every couple of days and read the reasons pages are not indexed. Some are expected, such as old URLs that now redirect. Others point to a leftover from launch.

For 404 errors, Search Console Help recommends fixing only the ones for URLs you link to yourself or list in a sitemap, and returning a redirect when a page has moved. A 404 for a page you removed on purpose, with no replacement, is not necessarily a problem. Our guide to why Google is not indexing your pages goes through every reason in the report.

Speed needs patience. Search Console's Core Web Vitals report uses data from real Chrome users over the last 28 days, so a new or quiet site may show no data for weeks. Use the lab test in PageSpeed Insights meanwhile, and judge the field data against web.dev's Core Web Vitals thresholds once it appears: a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, for at least 75% of visits. Our post on five speed checks you can do yourself shows how to read both.

Mistakes to avoid, and your next step

• Relying on robots.txt to hide the test site. Use a password, and remove it on launch morning.
• Removing noindex with a script or plugin setting you have not checked. Confirm in the page source and with URL Inspection that the tag has gone.
• Sending every old page to the home page. Redirect each one to its closest new page.
• Listing redirected, noindex or test URLs in the sitemap. List only the final addresses you want in Google.
• Requesting indexing over and over. It does not speed anything up. Fix what is blocking the page, request once and wait.
• Forgetting the links you control. If addresses changed, update your Business Profile, social profiles and ads so they point straight to the new pages.

Your next step: open our Website Launch SEO Checklist before your launch date. It lists every job in three groups, before, at and after launch, marks each one as coming from Google's documentation or from our checklist, and links to the tool that checks it. Your ticks stay in your browser, and you can copy the list as a to-do list for your developer. For a wider review after launch, use our technical SEO audit checklist, run a free SEO audit, or ask our technical SEO team to check the launch with you.