Website Launch Checklist for the Day You Switch

IDFS AI 2026-10-02

On the day a new site replaces the old one, a website launch checklist is five live checks: the DNS cutover, a redirect spot-check, one real form submission, analytics that record that action, and Search Console on the URL people will actually use. It is not a legal review, an accessibility audit, or a maintenance plan. Those belong before the switch, or after it, and they do not tell you whether today worked. When the public address stays the same and only the server changes, Google describes the DNS update itself as the step that starts the move [2]. When the URLs change, the move starts with permanent redirects, then Search Console [1].

What this checklist covers

The pages, the copy, and the new host should already be ready. Today you are proving the switch, not revisiting the design. If the honest answer to any of the five checks is "we think so," the launch is not finished.

The checklist splits on what changed. If the name in the browser stays the same and you are only moving hosts, follow Google's hosting guide: change DNS, watch traffic, and turn the old host off only after it is idle [2]. If the domain, the www choice, or important paths change, follow the site-move guide: map old URLs to new ones, turn on server-side permanent redirects, test them, and use Search Console where that tool applies [1]. A redesign often does both. Run both halves.

One gate sits in front of either shape. If the new copy was hidden with a robots.txt disallow-all rule, or with noindex tags, remove those blocks before you send the public at it [2]. A name that resolves and then asks Google not to index the site is still a staging site.

Confirm the DNS cutover, then watch both hosts

The record you publish tells resolvers which address to use, and those resolvers may remember the old answer. RFC 9499, published in March 2024, restates the definition from RFC 1035 (1987): the TTL specifies the time interval that the resource record may be cached before the source of the information should again be consulted [8]. The same March 2024 document notes that some servers ignore the TTL on some record sets, such as when the authoritative data has a very short TTL, even though that goes against the 1987 specification [8]. A fixed wait is a weak plan.

Ignore the old "wait 48 hours" line. Lower the TTL to a conservative value, for example a few hours, at least a week before the move, so caches refresh faster [2]. A resolver that already stored the old record keeps that copy until the timer it received runs out, which is why the lower TTL has to be in place early.

On the day, a hosting move starts when you update the DNS records so the domain points at the new host [2]. Edit the records the live name actually uses. An address record and a nameserver delegation are different records, and each has its own TTL. Confirm the edit where the zone is authoritative, then check a public resolver that is not your office router. Google recommends different public DNS checking tools, because one network can lag behind another [2].

A split audience is normal while caches expire, if the authoritative answer is already the new address. It is a failure if that authoritative answer is still old, or if it points at a machine that does not have the new files. Watch both servers. Google says traffic on the old host should fall and traffic on the new host should rise as the settings spread [2]. Googlebot's crawl rate may also dip right after a hosting change and then climb over the following days, sometimes above the old rate, as long as the new server does not stall or block the crawler [2]. A quiet hour is not proof the old host is unused. Turn the old infrastructure off when traffic to it reaches zero [2].

Whoever runs the cutover has to open the DNS account for the live zone. If that login is still with a previous vendor, stop. This is a launch-day access check, not a claim about who owns the website.

Spot-check redirects before you trust the homepage

If every public URL stayed the same, still open the homepage, one interior page, and one file such as a PDF, on the public name over HTTPS, without a certificate warning. Paths or a domain change are where redirects matter.

Google recommends a permanent server-side redirect when a page's URL changes. The 301 and 308 status codes mean the page has permanently moved, and a permanent redirect is the signal to show the new URL in search results [3]. A temporary redirect does the opposite: Google keeps the source URL as the one to show [3]. A 302 left from staging is the wrong code on launch day.

The June 2022 HTTP standard, RFC 9110, defines 301 (Moved Permanently) as the status that means the target resource has a new permanent URI [7]. For historical reasons, a user agent may change POST to GET when it follows a 301. If that is not what you want, the standard points to 308 instead [7]. A 301 is also heuristically cacheable unless cache controls say otherwise, so a bad redirect can stick in a browser that already followed it [7]. Test with a command-line request, or a browser that has not visited the old URL today.

Send each old URL to its final new URL in one server-side hop. Googlebot can follow a chain of up to 10 hops, but Google advises a direct redirect, ideally no more than three hops and fewer than five [1]. Do not point unrelated old URLs at the new homepage. Google warns that this can be treated as a soft 404 [1]. If two old pages became one new page, both may redirect there. If a page is gone and nothing replaces it, use 404 or 410 rather than a bounce home.

Once redirects are on, each new URL needs a self-referencing canonical on the new URL, and development noindex tags should be gone [1]. Spot-check the old homepage, a URL that already gets visits, one changed path, the http version, and the host name you are not keeping. Use URL Inspection for a single URL, or a command-line request for a list, and confirm one hop to the right page [1].

Two timeframes look like they conflict. They do not. Keep redirects for as long as possible, generally at least one year, so Google can recrawl and reassign signals, including links that still point at old URLs [1]. The Change of Address tool, which applies only to some moves, says to maintain redirects for at least 180 days, and longer if old URLs still get search traffic [4]. Redirects add delay, so once the final addresses are stable, update your own navigation and any high-volume links you control [1].

Google states that 301 redirects and other permanent redirects do not cause a loss in PageRank [1]. The same guide says a significant change can still bring ranking fluctuation while Google recrawls, and a medium-sized site can take a few weeks or more before new URLs replace old ones [1].

Submit one real form and read the inbox

A thank-you page only proves the browser got a response. Open the contact page on the public hostname, not the staging host and not a hosts-file trick that only your laptop obeys. Submit once, with a subject you can search, from an address you control. Then find that message in the inbox, shared mailbox, text alert, or lead tool the business will actually use. If the form posts to a third party, confirm the endpoint is the production one.

Check the form action before you celebrate. If that URL returns a 301, a browser is allowed to follow it with a GET and drop the POST body [7]. You want a direct success response from the URL the form posts to, and the message in a destination you opened yourself.

Analytics is a second witness, not a substitute. With enhanced measurement on, Google Analytics can collect form_submit, including form_destination, when the user submits a form [5]. That records the browser's submit, not a mail-server receipt. Do not put the email, phone, or message text into the event, because collection must exclude personally identifiable information [5]. Put the test marker in the subject line. Turning enhanced measurement on takes Editor access or above [5].

If nobody on the call can open the inbox or lead tool, the form is not proved. Our team does not mark this done until someone other than the developer finds the test message.

Make analytics record that same action

The measurement ID in the live page source has to match a property you can open. Compare view-source on the public URL with the property on your screen. Staging IDs and tags that exist only in a preview are how a launch ends with an empty report. If Search Console verification depends on the analytics tag or a meta tag, that snippet has to be on the new copy or verification fails when the old host stops [2].

Use real-time reporting during the first phase of the move. Google points to it because you want to see traffic leave the old site and appear on the new one [1]. A page view is still not the conversion. In current Google Analytics, business results are key events: you identify the event, then mark it as a key event, which takes Marketer access or above [6]. New events may not show in the list right away, but you can mark the name ahead of time so later hits count [6]. For a lead form, that may be form_submit, or a more specific event for that form. Mark it before the window opens.

Submit once and look for that event. DebugView lists events as they are collected, including a seconds stream of the last 60 seconds, but only after you enable debug mode [10]. If you skip debug mode, real-time still has to show the hit in the correct property [1]. A page view without the form event means the tag is present and the conversion is not. One recorded test is enough.

Put Search Console on the URL you are keeping

Open the property that matches the final site: https, and the host you chose between www and non-www. Verify the variants, not only your favorite. Google says to verify all variants of the old and new sites, including www and non-www, and both http and https if you serve HTTPS [1]. The verification file, meta tag, or analytics tag has to be on the new copy [1]. Remove disallow-all robots rules and template noindex in the same pass, or the index report stays empty on purpose [2].

Skip Change of Address when the user-visible URL did not change. Google says the tool is wrong for a hosting or CDN move, for http-to-https, and for a www switch on the same domain [4]. In those cases, watch logs and index coverage instead [2].

Use the tool when you moved from one domain or subdomain to another, and only after redirects are live [4]. The same Google account must own both properties [4]. The tool checks for 301s on sample pages, and a failed critical check blocks the request [4]. File it for every old variant, including www and names you do not use, because a request for the bare domain does not move www or other subdomains [4]. Google then emphasizes the new site and forwards signals for 180 days [4]. Old URLs can remain in the index if they are still available and have no equivalent [4].

Submit a sitemap of the new URLs. Google calls a sitemap an important way to discover URLs, and says it can be very helpful when you just launched or just moved [9]. Requesting indexing on individual URLs requires an owner or full user, there is a quota, and repeating a URL does not speed it up [9]. Crawling can take a few days to a few weeks, and a request does not guarantee inclusion in search results [9]. On a medium-sized move, expect a few weeks or more before most new URLs replace the old ones [1].

A workable order for the launch window

The TTL should already be lowered, the key event already marked, and the redirect list already written [2][6]. When the window opens:

Remove noindex and any disallow-all robots rule on the new copy [2].
Change the DNS records for the live name [2].
Read the authoritative answer, then a public resolver outside your own cache.
Load the public URL and spot-check redirects, including http and the host you are not keeping [1].
Submit one form on that public URL and find it in the real inbox.
Confirm that same action as the key event in the analytics property [6].
Open Search Console on the final property, submit the new sitemap, and use Change of Address only if the domain or subdomain changed [4][9].
Leave the old host up until its logs go quiet [2].
Write down the DNS answer, three redirect status codes, the form subject and where it landed, the analytics event and property ID, and the Search Console property.

Our team treats that note as the close of the launch. If a redirect or the form fails, the short TTL from last week is what lets you reverse the DNS change [2].

Practical takeaways

Lower DNS TTLs to a few hours at least a week ahead, then trust the authoritative answer and the logs [2][8].
Use one server-side 301 or 308 to the final URL, and do not send unrelated old URLs to the homepage [1][3].
A 301 may turn a form POST into a GET. Prove the lead in the inbox, not on a thank-you screen [7].
Mark the form event as a key event before the test, in the property whose ID is on the live page [5][6].
Use Change of Address only for a domain or subdomain move, on every verified variant, after redirects work [4].
Keep redirects for at least a year. On a medium site, search results can take a few weeks or more to settle [1].

How we can help

Have more questions or want to get in touch? Our team can run this website launch checklist with you, from the DNS change through the redirect spot-check, a real form, the analytics event, and Search Console on the URL you are keeping. See how a launch fits our web design work, or contact us and we will walk the cutover with you.