Staging, DNS, and the week before launch

A website launch DNS checklist is unglamorous on purpose: a staging URL, a content freeze, DNS with a written rollback, and a person watching the first hour.

By
A hand pinning string between printed mobile screens on a wall. The string and the screens fit a piece about the sequence that connects staging to the live domain.
A hand pinning string between printed phone screens. Photograph via Unsplash.

A website launch DNS checklist is a short sequence, and the sequence is dull on purpose. Stand up a staging address that matches what you intend to ship. Freeze the content. Change DNS in a way you can undo. Watch the first hour with a named person. Teams that skip to the nameserver change are the teams that debug a live site in public.

Nothing in that list is a visual decision. By launch week the design should already be approved. The week is for truth: the real copy, the real domain, the real inbox, and a way back if the real domain serves the wrong thing.

A staging address that tells the truth

Staging is a URL that is not the production domain. It runs the same build you intend to launch, with the real pages, the real images, and the real form. A staging site full of placeholder headlines is a demo. It will not catch the broken biography or the button that points at the old site.

Protect it from being indexed if it lives on a public host, and share it with the people who must approve it. Click every primary path on a phone: home, the offer, the proof, the contact, and one article or product if those exist. Open the menu. Submit the form to a test inbox you control. Look at the title that would appear in a browser tab and the description under it.

Check speed on that same URL before you touch DNS. web.dev's good thresholds are the ones to use. Largest Contentful Paint within 2.5 seconds of the page starting to load. Interaction to Next Paint of 200 milliseconds or less. Cumulative Layout Shift of 0.1 or less. A staging site that jumps or stalls will not become calm because the domain changed. Fix the image, the script, or the late banner now, while the audience is still just you.

Write down the differences that are allowed to remain. Staging may block search engines. Staging may use test payment keys. Those differences should be a list of three lines, not a feeling that "it's basically the same."

A content freeze

An OPEN sign hanging in a shop window, with the word SHOP printed on the glass. It accompanies an article about Staging, DNS, and the week before launch.

Pick an hour and call it the freeze. After that hour, copy changes wait for a follow-up, unless the error is factual and would be embarrassing on the live domain. Endless "one last sentence" edits during DNS are how the wrong version launches, because someone deployed a newer branch than the one you approved.

The freeze is also a list of owners. Who may lift it. Which inbox receives form messages. Which phone number is on the page. Which logo file is final. The person who can approve is named, and they are reachable during the window. A freeze with no approver is a pause that anyone can break.

Put the approved build number, or the git revision, in the launch note. If a question comes up on launch day about whether a sentence was supposed to change, you have a reference. Memory is a poor deploy log.

The fuller pass over links, alt text, and the words themselves belongs before this week. A checklist before you publish a company site is that pass. Launch week assumes it happened. DNS does not fix a sentence that was never reviewed.

DNS with a way back

DNS points the domain at the new host. Before you change it, copy the current records somewhere durable: the apex, the www host, mail records, and any verification records for search or the email provider. That copy is the rollback. If the new site is wrong, you put the old records back.

Shorten the cache time on the records you will change, if the registrar lets you, a day or so ahead. A long cache means a correction takes longer to spread, which is the opposite of what you want during a launch. Lengthen it again once the new site has been calm. Do this in the company's registrar account. A launch that requires the studio's private login is a launch you cannot undo at midnight.

Decide the canonical host before you flip. Either the bare domain or the www host should be the one you promote, and the other should redirect to it with a single hop. Certificates should already be ready on the new host, so the first visitor does not meet a browser warning. Redirects from old paths, if this is a replatform, should be in place on the new host before the domain arrives. A domain switch with no redirects throws away every link you have already earned.

Mail records deserve a second look. Teams have launched a website and silently broken email by replacing a whole zone instead of the web records. Change the records that point at the site. Leave the mail records as they were unless email was part of the project and you have tested sending and receiving.

Lower the drama of the flip. Do it when the named person can watch, on a day the company can answer a stray question. Avoid a Friday evening unless you enjoy a weekend of guesswork.

The first hour

A pale room with an arched opening onto a dark sofa, a low table, and a glass vase of dried stems. It accompanies an article about Staging, DNS, and the week before launch.

When the domain serves the new site, one person watches for an hour. Their job is not to redesign. Their job is to try the public site the way a stranger will, and to keep the rollback note open.

Walk this list.

  1. The homepage on a phone not connected to the office Wi-Fi. The offer is the approved offer, and the certificate is valid.
  2. One interior page, reached from the homepage, plus a direct visit to that URL.
  3. The old host name, if you changed www or the apex, to confirm the redirect.
  4. The form, submitted once, and the inbox that was supposed to receive it.
  5. A shared link that existed before launch, to confirm it still lands somewhere sensible.

If the homepage is the old site for you and the new site for someone else, caches and propagation are still in progress. That is a reason to watch, not a reason to panic and edit DNS every five minutes. If the form fails or the certificate fails, use the rollback you wrote down, then diagnose on staging.

The first hour is also when analytics should show the new property receiving the visit you just made. If the tag is missing, note it and fix it without holding the domain hostage. Measurement can be repaired. A site that shows the wrong company cannot.

Hanabi's services include this week as part of building the site, not as an afterthought once the visuals are approved. If you are launching with another partner, ask them to walk the same sequence out loud: staging, freeze, DNS with a written rollback, and a person on the first hour. A studio that cannot describe the rollback does not have a launch plan. It has a hope that the records are right.

Frequently asked questions

What should staging show before DNS changes?

Staging should run the build you intend to launch, with real copy, real images, and the form pointed at a test inbox. Placeholder headlines will not catch the mistakes a visitor will see. Check loading, responsiveness, and layout stability there, because a new domain will not calm a page that jumps.

How do we undo a bad DNS change?

Copy the current records before you edit them, including mail records, and keep that copy with the company. If the new site is wrong, put the old records back from the registrar account you own. Shorten the cache time ahead of the change when the registrar allows it, so a correction can spread sooner.

Who should watch the first hour?

Name one person. They open the homepage on a phone off the office network, follow one interior page, submit the form, and confirm mail still works. Their job is to see that the domain serves the approved site, and to use the written rollback if it does not.

Sources and further reading

  1. Web Vitals, web.dev

Written by

Hanabi

Hanabi is a product design and web development studio. The studio writes about clear websites, brand systems, and product interfaces for founders.

Keep reading

All articles