New Website SEO Checklist: Launch Day and the First Month

This new website SEO checklist covers the fortnight before a site goes live, launch day itself and the first month afterwards, which is the window where most of the avoidable damage happens. It is a launch checklist, not a general SEO guide.

Why a new website needs its own SEO checklist

A brand new site and a rebuild of an existing site are different problems, and most new website SEO checklists quietly assume the first while most readers are doing the second. If you are replacing a site that already gets traffic, your priority is not to gain rankings, it is to keep the ones you have, and that is a redirect and continuity problem before it is anything else. Our guide to website migration SEO covers that case in full, and you should work through it alongside this list rather than instead of it.

If the site is genuinely new, with no predecessor and no existing rankings, the risk is different: launching with the settings that were sensible on staging and never changing them. The classic version is a staging site that was hidden from search engines in two ways at once, a robots.txt disallow and a noindex tag, and only one of them gets removed. Google's own documentation explains why that matters: a noindex rule only works if the page is not blocked by robots.txt, because a crawler that is blocked never sees the noindex. Get the pair wrong in either direction and the site is either invisible or indexed in a state you did not intend.

Both failure modes are entirely preventable, both are extremely common, and neither produces any visible symptom on the site itself. That is the case for a written checklist rather than a mental one.

The six things to get right at launch

These are the items where getting it wrong on launch day costs weeks to undo.

Indexability switched on

The staging noindex and the robots.txt disallow both need to come off, and both need to be checked on the live domain rather than assumed. On WordPress that includes the "Discourage search engines from indexing this site" box under Settings, Reading, which is a separate switch from your SEO plugin.

A complete redirect map

On a rebuild, every old URL that had traffic, a link or a ranking needs a single-hop 301 to its closest equivalent. Not to the homepage. Mapped before launch, tested after.

Search Console, Bing and analytics live

Google Search Console and Bing Webmaster Tools verified, analytics installed and firing on the live domain, conversions defined. Without this you cannot tell whether the launch went well, only whether it felt like it did.

Titles and descriptions written

Not generated from the template, not left as the theme default, and not duplicated across the whole site. Every page that matters gets its own title tag and meta description, written for the search it should win.

One canonical version of the site

One protocol, one host, one trailing slash convention, with everything else redirecting to it in a single hop. Settle this before launch, not after links start pointing at three versions of the same page.

A sitemap submitted on day one

Generated from live canonical URLs, listed in robots.txt and submitted in Search Console and Bing Webmaster Tools. It is the fastest way to tell search engines which pages exist and which ones matter.

Before launch: the pre-launch SEO checklist

Do all of this while the site is still on staging. Every item here is cheaper now than it will be in a week.

• Take a baseline. On a rebuild, export the full URL list from the old site with the last twelve months of clicks, impressions and inbound links against each, plus your positions for the top twenty queries. You cannot judge the launch later without it.
• Build the redirect map from that export (the method is set out further down). Every URL with traffic, a ranking or a link gets a specific destination.
• Freeze the URL structure. Match it to how the site is organised, then stop changing it. Every later change is another redirect.
• Protect staging properly. Google's introduction to robots.txt says it is not a mechanism for keeping a page out of Google, and recommends noindex or password protection instead. Password-protect staging, and a blocked staging URL that somebody links to cannot turn up in results.
• Write unique title tags and meta descriptions for every page that matters. Templates are fine for large catalogues; theme defaults are not.
• Check the heading hierarchy on every template: one H1 per page, H2 for sections, no skipped levels for styling reasons.
• Test speed against Google's thresholds. The Core Web Vitals targets are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less. Compressing and correctly sizing images is almost always the biggest win available before launch.
• Add the structured data the site actually needs: Organization site-wide, plus Article, Product or LocalBusiness where they apply. Validate it on staging.
• Check internal links in the new content point at the new URL structure, not at old paths that will immediately redirect.
• Decide your AI crawler policy. Look at the robots.txt rules for AI crawlers before launch rather than inheriting a default. OpenAI, for example, documents separate robots.txt controls for OAI-SearchBot (which governs whether you can appear in ChatGPT search results) and GPTBot (training), and lets you allow one while blocking the other.
• Set up the tools on the live domain in advance. A Search Console domain property verified by DNS and a Bing Webmaster Tools account can be ready before the site switches over, so data starts on day one.
• Keep the old site accessible somewhere you can reference it. You will want to check something.

Launch day: the go-live checks

Work through these in order, in the first hour after the site goes live. Do not leave them to the end of the day.

1. Remove the noindex. Check the live page source for a robots meta tag, check the SEO plugin's site-wide setting and, on WordPress, the search engine visibility box under Settings, Reading. They are separate switches and any one of them will keep you out of the index.
2. Check robots.txt on the live domain. A staging disallow that gets deployed with the site is the classic version of this failure.
3. Spot-check twenty redirects by hand. Pick your highest-traffic old URLs and confirm each returns a single 301 to the right page, with no chain and no loop.
4. Confirm HTTPS across the whole site, including images, scripts and fonts. Mixed content warnings on launch day are avoidable.
5. Verify analytics is firing on the live domain, in a private window, after accepting the cookie banner, and check that a test conversion is recorded.
6. Submit the sitemap in Search Console and Bing Webmaster Tools. If your CMS or host supports IndexNow, switch it on: it notifies participating search engines, Bing included, when URLs are added or changed.
7. Request indexing for the homepage and your most important pages with the URL Inspection tool in Search Console.
8. Check the site on a real phone on mobile data, not the responsive preview in a desktop browser.

How to get a new website on Google

"How do I get my website on Google?" is one of the most common questions after launch, and the honest answer has two halves: what you control, and what you have to wait for.

What you control is discovery. A sitemap submitted in Search Console, a handful of links from places Google already crawls (your Google Business Profile, your social profiles, any directory or partner listing) and a URL Inspection request for your key pages are the whole toolkit. There is no paid route into organic results and no submission service that does more than those three things.

What you wait for is the crawl and the indexing decision. Google's guidance on asking it to recrawl your URLs says crawling can take anywhere from a few days to a few weeks, and that a request does not guarantee inclusion quickly or at all. Use the URL Inspection tool to see the real state of a page rather than a site: search, which is a rough sample rather than a report. If an important page still reads "Discovered" or "Crawled, currently not indexed" after a few weeks, look at its content and internal links before resubmitting it.

Indexed is not the same as ranking. A new domain with no history and no links takes months, not weeks, to compete for anything contested. Google's SEO Starter Guide says some changes take effect in hours and others in several months, and suggests waiting a few weeks before judging whether a change worked. Build that expectation into the plan before launch, so nobody makes panic changes in week two.

The first month after launch

The work after launch is monitoring, and it is the part people skip because the project feels finished. It is not finished for about four weeks.

• Check the Page indexing report in Search Console weekly. Pages newly listed under "Why pages aren't indexed" are the early warning for a redirect, canonical or noindex problem.
• Watch for a rise in 404s and server errors. A small rise is normal as old URLs are re-crawled; a sustained one means the redirect map has gaps.
• Compare impressions and positions for your top twenty queries against the pre-launch baseline. A modest dip for two to three weeks is normal on a rebuild. A cliff is not.
• Find and fix any redirect chains that emerged once the old rules met the new ones.
• Update your Google Business Profile, social profiles and directory listings with the new URLs, especially if the structure changed.
• Re-check Core Web Vitals once real visitor data starts to appear in Search Console, because lab tests on staging do not always match what visitors on real phones experience.
• Re-run a full crawl at the end of week four and compare it against the pre-launch crawl.

Building the redirect map in practice

This is the part that decides whether a rebuild keeps its traffic, so it is worth doing properly rather than from memory. Start with three exports and combine them: every URL Search Console has served an impression for in the last twelve months, every URL in your analytics with a session in the same window, and a full crawl of the old site. The three overlap heavily, but none of them is complete on its own. Search Console misses pages that never ranked but carry links, analytics misses pages nobody visited, and a crawl misses orphan pages that are still linked from elsewhere on the internet.

Then sort the combined list by value rather than alphabetically, and work down. The top of that list, typically a few dozen URLs on a small business site, deserves an individually chosen destination. Below that, pattern rules are fine: an old blog path mapping to a new blog path, a service category mapping to its replacement. At the bottom sit genuinely dead pages, and those can go to the nearest relevant parent page, which is not the same thing as the homepage. Google's site move guidance is explicit: do not redirect many old URLs to one irrelevant destination such as the homepage, because it confuses users and might be treated as a soft 404.

Two checks catch most errors. First, no destination should itself be a redirect, or you have built a chain on day one. Second, every destination should return a 200 on the new site, which sounds obvious and is the single most common defect in a hand-built map, because destinations get renamed during the build after the map was written.

A two-week launch countdown

If you want the whole thing as a schedule rather than a list, this is the shape that works for a typical small business rebuild.

• Two weeks out. Pull the three exports, build the redirect map, freeze the new URL structure. Take the ranking and traffic baseline and save it somewhere you will find it again.
• One week out. Titles, descriptions and heading structure finalised. Images compressed. Structured data in place on staging. Crawl the staging site and fix what the crawl finds.
• Two days out. Load the redirect rules and test them against staging. Confirm Search Console, Bing Webmaster Tools and analytics are ready for the live domain.
• Launch day. The eight go-live checks above, within the first hour.
• Day two. Full crawl of the live site. Fix any chain, loop or 404 it surfaces.
• Weeks one to four. Weekly Page indexing and error review, then a comparison against the baseline at the end of week four.

What people get wrong at launch

Three mistakes cause most post-launch traffic losses, and none of them is subtle once you know to look.

The first is redirecting everything to the homepage. It is fast, it makes the 404 report look clean, and it throws away the accumulated value of every page you redirected. A redirect only carries value when the destination is a genuine equivalent of the source.

The second is launching without a baseline. If you did not record positions, impressions and conversions before launch, you cannot answer the only question that matters afterwards, which is whether this went well. Take the export before you start, not after somebody asks.

The third is treating the first fortnight's numbers as the verdict. Re-crawling takes time, and a rebuild usually dips before it recovers. Judging at day ten produces panic changes that make the recovery slower, not faster.

There is a fourth mistake that is less dramatic and more expensive over time: nobody owns the site after launch. The designer's involvement ends at go-live, the internal owner assumes it is done, and the four weeks of monitoring that would have caught the redirect gap simply do not happen. Agree before launch who checks the Page indexing report in week two and who fixes what they find. If you are still choosing who builds the site, put that question in the brief; our guide on how to hire a web designer covers what else to agree up front.

New website with no predecessor

If there is genuinely nothing to migrate, the list shortens considerably. You still need the indexability checks, the canonical decision, the titles and descriptions, the sitemap, Search Console, Bing Webmaster Tools and analytics. You do not need the redirect map. Set expectations accordingly: a new domain with no history takes months rather than weeks to establish itself, and no amount of launch-day diligence changes that. What launch-day diligence does is make sure that when the site does start to earn rankings, nothing technical is standing in the way.

On WordPress, the platform-specific settings (permalinks, the SEO plugin, the search visibility box) are covered in our guide to SEO on WordPress. If you are rebuilding an online shop, the ecommerce-specific risks (product URLs, faceted navigation, out-of-stock pages) are in our guide to ecommerce website redesign.

From there the work becomes ordinary optimisation. Our technical SEO checklist is the quarterly maintenance list, the local SEO checklist applies if you serve a specific area, and Google's SEO Starter Guide is a sound non-commercial reference for the fundamentals. If you would rather have the launch handled, our web design service builds the launch checks into the project, and our SEO service covers the monitoring and growth work after go-live.

FAQ