Launch week feels simple until one missing DNS record, one untested form, or one forgotten tracking tag turns a neat calendar into a long afternoon. A day-by-day plan keeps the boring parts boring, which is exactly what you want on launch week.
Most teams start with the same nervous questions. Are we launching a brand-new site or replacing an existing one? Is the domain staying the same? Will email addresses change? When should DNS switch? And how do we make sure forms, analytics, and SEO basics still work when the site is finally public?
Those questions matter because website launches are not only design projects. They are coordination projects. ICANN explains the role DNS plays in helping internet traffic reach the right destination, while Let’s Encrypt’s getting-started guide is a practical reminder that HTTPS only works smoothly when certificate setup and renewal are planned before go-live. In plain language: a site can look finished and still be operationally unready.
This guide maps the short version first, then the full checklist. I will walk through what to confirm two weeks before launch, what to do each day during launch week, how to handle SPF, DKIM, and DMARC without turning them into a mythology unit, what to test before the DNS cutover, and what to monitor during the first week after launch. If you are comparing hosting decisions as part of the move, our hosting and domain guidance page is a useful companion, and if the launch also includes new layouts or templates, the web design services page helps frame where build work stops and launch work begins.
Terminology: The Short Plain-Version Map
Before the timeline, let us make the terms less slippery. Launch planning gets much easier when everyone uses the same words for the same task.
- Domain: the web address people type, such as yoursite.com.
- Registrar: the company where the domain is registered and renewed.
- DNS: the records that point the website, email, and verification services to the right place.
- Nameservers: the DNS host that controls the zone file for the domain.
- Hosting: the server environment where the website files, application, and database live.
- SSL certificate: the certificate that enables HTTPS and secure browser connections.
- SPF, DKIM, DMARC: email authentication records that help receiving mail servers decide whether messages from your domain are legitimate. DMARC.org’s overview is useful if you want the formal version after the plain version.
- Tracking: analytics, pixels, tags, and conversion events that tell you whether visits, leads, and campaigns are being measured correctly.
- Rollback plan: the documented way to return to the previous setup if something critical fails after cutover.
The short answer: launch week is rarely blocked by one giant mystery. It is usually slowed down by small dependencies that nobody wrote down. Domain access, email routing, analytics, redirects, and certificates have a talent for hiding until the worst possible hour.
Step 1: Define the Launch Scope Before You Touch the Calendar
Start here, because “website launch” can mean a few very different things:
| Launch type | What stays the same | What changes | Main risk |
|---|---|---|---|
| New site on a new domain | No legacy URLs or existing email setup to preserve | Everything: hosting, DNS, forms, indexing, branding, tracking | Missing first-time setup steps such as DNS, SSL, or Search Console |
| New site on an existing domain | Brand recognition, existing email addresses, some SEO history | Templates, content structure, hosting, redirects, tracking | Breaking old URLs, forms, or measurement during switchover |
| Redesign on the same hosting | Registrar, nameservers, server environment | Pages, code, assets, maybe CMS configuration | Assuming “same server” means “low risk” and skipping QA |
| Redesign plus hosting move | Usually the domain and public brand stay the same | Design, platform, hosting, DNS, SSL, forms, email settings, tracking | Too many moving parts arriving on the same day |
Also decide one very practical thing early: will anyone’s email address or mailbox provider change? If the answer is yes, email becomes a first-class launch dependency, not a side note. If the answer is no, you still need to protect existing MX, SPF, DKIM, and DMARC records during any DNS update.
If your project includes service pages, campaign landing pages, and portfolio content at the same time, it helps to separate them by business priority. For example, a brochure-style homepage can wait an hour longer than a quote form tied to active ad traffic. That is where a quick review of the site’s main pages, including the homepage, online advertising support, and references, becomes useful: it shows which routes are business-critical on day one.
T-14 to T-7 Days: Pre-Launch Dependencies to Confirm Early
Two weeks before launch, do not worry about the color of a button yet. Worry about access, ownership, and recovery. Those are the pieces that actually delay launches.
| Dependency | What to confirm | Why it matters |
|---|---|---|
| Domain access | Registrar login, domain owner, renewal status, nameserver control | No domain access means no controlled launch window. |
| DNS records | A, CNAME, MX, TXT, SPF, DKIM, DMARC, verification records, TTL values | The website can launch while email quietly breaks if these are missed. |
| Hosting credentials | Panel login, SFTP or SSH access, database access, admin user roles | You need real access to stage, test, and fix issues quickly. |
| Staging environment | Restricted access URL, test domain or host file method, content freeze timing | Testing on staging reduces surprises after the public switch. |
| Backup and rollback | Fresh backup, database export, media backup, who can restore what, how fast | A rollback plan is the thing that turns risk into a manageable decision. |
| Redirect map | Old URLs, priority landing pages, file downloads, campaign pages | Redirects protect user journeys and existing search visibility. |
This is also the right time to reduce DNS TTL on records that will change, if your provider allows it. Lower TTL does not make the internet obey instantly, but it can shorten the “some people see old, some see new” window.
A small but important habit: put this inventory into one shared document. Not half in email, one screenshot in chat, and one password in somebody’s browser profile from 2022. Launches tend to expose whatever the team was already hand-waving.
T-6 Days: Lock the Hosting Setup
Six days out, the goal is stable infrastructure. The site does not need final polish yet, but the environment should be configured enough to stop changing underneath the build.
- Confirm the live domain and any staging hostname are pointed where you expect.
- Create or verify the database, server version, caching layer, and backup schedule.
- Check write permissions for uploads, forms, logs, and cache directories.
- List every third-party integration that depends on the server: SMTP, CRM webhooks, payment callbacks, booking tools, file uploads, or API connectors.
Example: if a redesign is moving from a basic shared host to a managed environment, this is the day to verify the PHP version, database size limits, cron jobs, and backup timing. None of that is glamorous copywriting material, but it is the difference between “launch complete” and “launch complete except the quote request form never writes to the database.”
T-5 Days: Prepare SSL, Redirects, and Technical Drafts
Five days out, build the technical guardrails:
- Make sure the SSL certificate can be issued or activated for the live domain.
- Prepare the redirect rules for old URLs that need to remain reachable.
- Draft the robots.txt and sitemap behavior for production.
- Check canonical URLs, preferred www or non-www version, and HTTP-to-HTTPS behavior.
This is where teams often discover that staging rules were written for convenience, not launch readiness. If your staging site blocks crawlers or uses a temporary domain, good. That is normal. Just make sure those settings do not travel to production like an uninvited houseguest.
You do not need a full SEO campaign here. You do need a launch-safe technical base. For sitemap submission after go-live, Google’s sitemap guidance is a reliable reference for format and submission basics.
T-4 Days: Freeze Content Risk and Build a QA Route List
Four days before launch, decide what content is still allowed to change. This matters more than it sounds. Endless “just one more edit” cycles are how tracking snippets vanish, buttons point to the wrong page, and the form nobody retested becomes the form a real lead uses first.
Create a route list for QA with at least these items:
- Homepage
- Main service pages
- Contact or quote request page
- Thank-you or success page
- Any ad landing page
- Privacy or consent page if forms or analytics depend on it
If you are replacing an existing site, add the top legacy URLs and downloads to that list. A redesign does not erase old bookmarks or search results just because everybody is excited about the new header.
T-3 Days: Create Test Accounts and Rehearse the Contact Path
Three days out, use realistic test data:
- Create one or two test email accounts for form submissions and user notifications.
- Submit every important form on staging.
- Test autoresponders, admin notifications, spam filtering, and file uploads.
- Check where failed submissions are logged, if they are logged at all.
A very common launch mistake is assuming form success messages equal successful delivery. They do not. A thank-you message only proves the browser saw a success state. It does not prove the message arrived, the mailbox accepted it, or the sales team can reply.
T-2 Days: Email Deliverability Basics Before Go-Live
This is the day for the email layer. The short version is simple: website email is not just about whether a message sends. It is about whether receiving servers trust it enough to deliver it properly.
Check these items before launch:
- SPF: confirms which servers are allowed to send mail for your domain.
- DKIM: adds a signature so receiving servers can verify the message was authorized.
- DMARC: tells receiving servers what to do when SPF or DKIM checks fail.
- From address consistency: the form plugin, SMTP service, and mailbox should use a setup that makes technical sense together.
- Reply-to logic: if forms send “from” a domain mailbox and “reply-to” the visitor, test that the sales team can answer cleanly.
Then run a plain-language test:
- Send from the website form to the real destination inbox.
- Reply from that inbox to confirm the return path behaves as expected.
- Check spam, promotions, or quarantine folders.
- Repeat from both desktop and mobile.
Example: if the site sends from [email protected] but the SMTP service is not included in SPF, messages may still appear to send successfully while landing in spam or getting rejected later. That is why this check belongs before launch, not after someone says, “Strange, leads feel quiet today.”
T-1 Day: Tracking, Measurement, and the Rehearsal Pass
The day before launch is measurement day. Resist the temptation to keep redesigning small visual details. Use that energy to prove the site can be measured.
- Install and verify analytics tags.
- Confirm conversion events for calls, forms, purchases, or lead submissions.
- Check any tag manager container, consent flow, and event triggers.
- Run one full rehearsal: visit the page, submit the form, reach the thank-you step, and confirm the event fires.
If the site is tied to paid traffic, this is where online advertising planning overlaps with technical launch work. Your ads do not care that the design sign-off was stressful. They will keep sending traffic, and the landing path needs to record conversions correctly from the first real click.
My practical rule is this: if you would be embarrassed to discover the issue with your first paid visitor, test it the day before launch. Forms, thank-you URLs, phone tracking, and checkout events all belong in that category.
Launch Day: DNS Cutover and Final QA
Launch day works best when it feels almost anticlimactic.
Recommended order of operations:
- Take or confirm the final backup.
- Pause high-risk content edits.
- Update DNS or nameservers at the planned time.
- Verify the SSL certificate on the live domain.
- Run the QA route list on desktop and mobile.
- Submit a real form test and confirm inbox delivery.
- Check analytics and conversion signals again on the live domain.
- Submit or verify the sitemap in Search Console once the live version is stable.
Final QA should include:
- Speed: enough to load normally on mobile, not just on your office Wi-Fi.
- Forms: submission, delivery, thank-you state, spam handling.
- Mobile layout: navigation, tap targets, hero sections, sticky elements, and inline forms.
- Broken links: especially older service URLs, downloads, and footer links.
- Mixed content warnings: old HTTP asset calls are a classic post-cutover nuisance.
One practical note: if DNS propagation takes time, avoid declaring a problem too early. Some launch-day weirdness is just caching. The real question is whether the behavior improves predictably or whether a critical service truly failed.
Day 1 to Day 7 After Launch: Stabilize, Do Not Wander
The first week after launch is not the time for random new features. It is the time for observation, cleanup, and confirming that traffic, leads, and indexing are behaving as expected.
| Window | Main checks | What to watch for |
|---|---|---|
| Day 1 | Forms, inbox delivery, SSL, redirects, analytics real-time checks | Silent form failures, certificate issues, missing redirects |
| Day 2-3 | 404 logs, crawl behavior, key page rendering, mobile QA | Unexpected broken links, mixed content, caching oddities |
| Day 4-5 | Search Console alerts, sitemap status, campaign landing page checks | Coverage warnings, event mismatch, landing page drop-offs |
| Day 6-7 | Support handoff notes, minor fixes, page performance review | Recurring issues that need process fixes rather than one-off patches |
This is also where a calm support note helps. Write down what changed, what is still being monitored, and who owns follow-up items. Boring documentation is underrated on website projects because it prevents the “I thought somebody else checked that” genre of sequel.
Common Delays and How to Prevent Them
Most launch delays fall into a short list:
- DNS propagation confusion: lower TTL in advance, document which records will change, and test from multiple networks.
- SSL not ready: confirm certificate issuance before cutover instead of assuming hosting will magically sort it out.
- Mixed content after HTTPS: search for old HTTP asset paths and update them before launch day.
- Email misconfiguration: preserve MX and authentication records, then test sending and receiving with real inboxes.
- Missing redirects: map priority legacy URLs before launch, not after analytics starts showing 404 traffic.
- Tracking gaps: rehearse the real conversion path and verify events on the live domain.
Notice the pattern: almost all of these are preventable with earlier rehearsal, not more heroics on the day itself.
Printable Summary: Launch Day and First Week Checklist
If you want the quick map without the explanations, use this version.
Launch Day Checklist
- Backup confirmed
- DNS update window agreed
- SSL active on the live domain
- Main pages checked on desktop and mobile
- Contact and quote forms tested
- Email delivery confirmed
- Analytics and conversion events verified
- Sitemap submitted or rechecked
- Rollback owner identified
First Week Checklist
- Monitor 404s and redirect misses
- Review Search Console messages and indexation basics
- Spot-check high-value pages daily
- Retest forms after any urgent fixes
- Watch campaign landing pages and lead flow
- Document lessons before the project memory evaporates
Conclusion: A Smooth Launch Is Mostly Good Sequencing
The main lesson is not complicated: a website launch is easier when domain access, hosting setup, email authentication, tracking, and SEO basics are handled in the right order instead of all at once in somebody’s head. New site or redesign, same domain or new domain, the pattern holds. Decide the scope, document the dependencies, rehearse the lead path, and keep launch day focused on verification rather than improvisation.
If your next question is “which part should we sort first for our setup?” start with ownership and access. That answer usually tells you whether the real blocker is hosting, DNS, email, redirects, or launch coordination itself. From there, the rest of the week becomes much more manageable.