A smooth website launch is usually quiet. That is the goal. If the day feels dramatic, something was left too late.
On launch day, most small teams are asking the same practical questions: Is the site actually live? Do the important URLs resolve correctly? Are forms working? Can we trust the analytics signal enough to announce the launch without crossing our fingers? Those are the right questions. “Growth” can wait a few hours.
The goal of this runbook is straightforward: reduce risk through sequence. Launch-day success is not a perfect score screenshot or a heroic all-hands scramble. It is a live site with the right URLs, working forms, and enough measurement signal to know what is happening.
If you want the broader planning context behind this checklist, start with the home page, review the operating perspective on the about page, and keep the contact page and the blog in your key-page test set. For related reading, this site’s guides on backup-to-launch planning and SEO-safe updates are useful companions.
What Launch-Day Success Looks Like
Before you start the clock, define success in operational terms. That keeps the team focused on verification instead of improvisation.
- DNS and hosting are live: the public domain resolves to the intended environment and staging-only restrictions are gone.
- HTTPS works everywhere that matters: the canonical version loads cleanly, certificates are valid, and mixed-content warnings are absent.
- Key pages render correctly: the homepage, primary service or landing pages, About, Contact, and at least one post from Blog all load as expected.
- Important redirects behave: old URLs reach the correct final destination without chains or loops.
- Forms and CTAs work end to end: the form validates, submits, confirms success, and routes the lead or message to the intended destination.
- Analytics signals fire: pageviews and critical events are visible in a controlled test session, without duplicate firing.
What launch-day success is not: it is not a promise that every performance metric is fully optimized by noon. If the site is correct, reachable, measurable, and usable, you have the right basis for go-live. Tune later. Diagnose now.
| Priority | Launch requirement | Why it matters |
|---|---|---|
| Critical | Correct URLs, HTTPS, forms, analytics signal | These determine whether visitors can use the site and whether you can trust early launch feedback. |
| High | Redirects, navigation, canonical output, robots.txt, sitemap.xml | These protect discoverability and reduce the cost of cleanup after launch. |
| Secondary | Fine-tuning scores, cosmetic refinements, non-critical content polish | Important, but not a reason to ship broken forms or unclear redirects. |
Pre-Launch: Make Launch Day Boring
The best launch day is mostly verification. Discovery is for the day before.
Confirm the rollback plan
- Know what can be reverted quickly: content, theme or plugin changes, redirect rules, DNS adjustments, and any environment flags.
- Store the latest backup where the person on duty can actually reach it.
- Write down the go-back trigger. For example: forms fail, HTTPS breaks, or analytics stop firing on key pages.
Check staging parity
- Match core theme and plugin versions between staging and production.
- Verify form endpoints, SMTP or mail routing, API keys, and environment-specific settings are set for production.
- Confirm the robots behavior is different where it should be different. A staging noindex rule is good on staging and a bad surprise on production.
Prepare the redirect map
- List the old URLs that matter most: top pages, linked resources, campaign URLs, and anything in navigation or email templates.
- Assign a final destination for each one before launch.
- Mark intentionally removed URLs so the team does not argue about them under pressure.
Gather access before anyone needs it
- DNS and hosting access
- Analytics and tag manager access
- Form or CRM access
- Cache or CDN controls
- Who approves a go/no-go decision if a critical check fails
If this launch sits inside a broader rebuild or platform handoff, a neutral scope reference can help you see what is missing from the operational plan. This overview of custom web development services is one example of the kind of checklist-oriented reference worth comparing against. Use it to prompt questions, not to outsource judgment.
Terms That Matter Before You Start the Clock
Launch conversations get slower when teams use the same word for different problems. Define a few terms up front.
| Term | Meaning in this runbook | What to verify |
|---|---|---|
| Canonical URL | The preferred URL that page markup declares as the primary version | The tag points to the intended live URL, not to staging, HTTP, or a redirecting version. |
| Redirect chain | An old URL that hops through one or more intermediate URLs before the final destination | The chain ends in one step where possible. |
| Cache/CDN issue | Old content or headers are still being served after launch | Fresh requests show the current page, status code, and assets. |
| Conversion signal | The event that tells you a meaningful user action happened | A test pageview and a test conversion event both fire once in the expected environment. |
The 60-Minute Launch Runbook
Decide what matters most, then verify it in order. That sequence is your margin for error.
| Time | Focus | Decision point |
|---|---|---|
| 0-5 minutes | DNS, hosting, maintenance mode | Public traffic reaches the intended environment. |
| 5-10 minutes | HTTPS, canonical tags, robots.txt, sitemap.xml | Core technical signals are reachable and correct. |
| 10-20 minutes | Key pages and internal links | Main visitor journeys render normally. |
| 20-30 minutes | Redirect behavior | Legacy or changed URLs end at the right place without loops. |
| 30-40 minutes | Caching and CDN behavior | Fresh content is actually being served. |
| 40-50 minutes | Analytics and event tracking | Signals fire once and can be trusted. |
| 50-55 minutes | Forms, buttons, error states | Users can complete the main action without friction. |
| 55-60 minutes | Final QA and go/no-go | Critical blockers are either cleared or cause a pause. |
Minute 0-5: Confirm DNS, Hosting, and Maintenance Mode Behavior
- Open the public domain in an incognito window and a second browser. Confirm you are seeing production, not a cached local session.
- Check that maintenance mode is off for public visitors and any temporary password wall or IP restriction has been removed.
- Confirm the canonical domain is resolving the way you intend, including the preferred www or non-www version.
- If mail routing or transactional mail changed with the launch, send a quick internal message through the site or form stack as an early sanity check.
If this first step fails, stop. There is no benefit in validating analytics on a site the public cannot reliably reach.
Minute 5-10: Verify HTTPS, Canonical Tags, robots.txt, and sitemap.xml
- Load the homepage over HTTPS and confirm there are no certificate warnings.
- Inspect page source or your preferred browser tools and confirm the canonical tag points to the intended live URL.
- Open
/robots.txtand confirm it returns successfully, with rules that match your production intent. - Open
/sitemap.xmlor the sitemap index your setup uses and confirm it is reachable, current, and not returning a 404 or server error. - Spot-check one inner page, such as About or a recent Blog post, to make sure canonical behavior is consistent outside the homepage.
Minute 10-20: Test Key Pages and Internal Links
This is where you confirm the public experience instead of admiring the deployment log.
- Open the homepage, a primary service or landing page, About, Contact, and one post from Blog.
- Check page titles, headings, hero copy, calls to action, and any critical trust or contact details.
- Click through the main navigation and footer links. Broken navigation creates support load immediately.
- Verify that images load, layout blocks render correctly, and obvious assets are not missing.
- If the site includes search, test one obvious search query and verify the result page behaves like a real page, not an empty placeholder.
A small team does not need a hundred-page script here. It needs a short list of pages that matter to visitors and to the business.
Minute 20-30: Check Redirects for Old URLs
- Spot-check multiple changed or legacy URLs from different sections of the site.
- Confirm each old URL resolves to the correct final destination, not simply to the homepage because someone got tired.
- Watch for chains and loops. Old URL to interim URL to final URL is not a strategy. It is a future cleanup ticket you are writing for yourself.
- Confirm the final destination page is the right topical match, not just technically reachable.
Keep a short log as you test: old URL, expected destination, actual destination, status. That gives you a fix list immediately if something is wrong.
Minute 30-40: Validate Caching and CDN Rules
- Open key pages in a private browser window after the launch and check that you are seeing the current version, not stale content.
- Verify recently fixed 404s are no longer being cached as failures.
- Check that core assets such as stylesheets, scripts, and hero images are loading from the expected URLs.
- If you can inspect headers, confirm that cache behavior looks intentional for HTML and static assets.
- Re-test a redirect after any purge so you do not cache the wrong rule and then argue with the browser.
The practical test is simple: does a fresh visitor get the current site behavior on the first try? If not, the cache layer still owns part of the launch.
Minute 40-50: Confirm Analytics and Event Tracking
- Use a test session, test account, or clearly identifiable internal visit so you know which visit should appear.
- Confirm a pageview is recorded when you load the homepage and one key landing page.
- Trigger at least one critical event, such as a form start, CTA click, or confirmation page view, depending on your setup.
- Check for duplicate firing if both an old tag and a new tag could still be active during the transition window.
- Do not guess from a delayed aggregate dashboard alone. Verify using the closest thing your setup provides to real-time or debug visibility.
If analytics are silent, treat that as a real issue. You can survive a minor spacing bug for a few hours. Flying without signal is more expensive.
What to Record During the Hour
A launch runbook works better when someone writes things down in real time. Memory becomes suspiciously optimistic once the pressure rises.
| Field | What to capture | Why it helps |
|---|---|---|
| Check name | The exact item tested, such as homepage HTTPS or contact form submission | Prevents vague status updates like “looks fine to me.” |
| Tester and time | Who ran the check and when | Useful when behavior changes after a cache purge or config adjustment. |
| Expected result | The intended destination, status, or event | Keeps the team aligned on what “working” means. |
| Actual result | What happened in the browser or tracking tool | Makes triage faster because the symptom is already documented. |
| Decision | Pass, fix now, or monitor | Turns the runbook into an operational record instead of a loose discussion. |
Keep this log short and boring. If a redirect fails, write the old URL, the expected destination, and the actual destination. If a form fails, note whether the problem is validation, server acceptance, notification routing, or the success message. Short notes save time because they separate evidence from commentary.
This also helps when more than one person is testing. One person can work through URLs while another checks forms and analytics. A shared log prevents duplicate effort and shows whether a problem is isolated or systemic.
Minute 50-55: Forms, Buttons, and Error States
- Submit a real test through the main form on the Contact flow.
- Confirm client-side validation behaves correctly for empty or malformed fields.
- Confirm server acceptance, notification email or CRM capture, and the success message the visitor sees.
- Trigger an expected error state as well. Generic failure text is easy to ignore until a customer sends you a screenshot.
- Check that spam protection is not blocking the legitimate test submission.
Forms are where launch-day optimism usually meets reality. Better that it happens while the team is still at the keyboard.
Minute 55-60: Final QA Sweep and the Go/No-Go Decision
The last five minutes are for a short, disciplined sweep. Not a fresh brainstorm.
- Check the site on desktop and one mobile device or mobile browser view.
- Run the header, footer, and primary CTA paths once more.
- Confirm the most important page templates still look correct after cache clears and tracking checks.
- Ask one direct question: if a new visitor arrived right now, would they get the intended experience?
Go live only if all critical checks pass. If forms, HTTPS, redirects, or analytics signal fail, pause the announcement and fix the issue first. A delayed announcement is cheaper than a public launch that sends users into a broken funnel.
A Simple Go/No-Go Matrix
Teams often know something is wrong and still push ahead because nobody translated that problem into a decision rule. Use a simple matrix before launch day so the final call is faster.
| Issue type | Example | Decision |
|---|---|---|
| Stop-the-launch issue | Form submissions fail, HTTPS breaks, redirect loops appear, analytics do not fire at all | Pause the announcement and fix before public promotion. |
| Fix immediately if possible | Broken primary CTA, key image asset missing on a high-traffic page, blog index template behaving incorrectly | Repair quickly, re-test, then proceed if the main journey is sound. |
| Monitor after launch | Minor spacing issues, non-critical copy edits, secondary page polish | Log the issue and schedule it for the first post-launch pass. |
The point is not to create bureaucracy. The point is to stop the familiar mistake of treating every issue as either catastrophic or irrelevant. Most launch-day problems fit into a smaller, calmer system than that.
If you are the person making the final call, ask three questions in order:
- Can visitors reach the correct URLs securely?
- Can they complete the primary action without friction?
- Can we measure that traffic and those actions reliably enough to respond?
If the answer is no to any of those, the decision is usually obvious. It may not be enjoyable, but it is obvious.
Post-Launch: The First 24 Hours
Launch is not over when the banner goes up. It is over when the first day stays calm.
- Monitor error logs, form submissions, and support messages for early anomalies.
- Watch redirect behavior, especially on URLs that had the most change.
- Confirm analytics events continue to fire after the first wave of real traffic.
- Keep a short known-issues list and sort it by business impact, not by who noticed it first.
- Schedule one follow-up review the next morning to decide which fixes are urgent and which can wait.
Final Checklist
If you want the shortest possible version, use this:
- Verify production is live and reachable.
- Confirm HTTPS, canonical tags,
robots.txt, andsitemap.xml. - Test the homepage, About, Contact, Blog, and one primary landing page.
- Spot-check redirects for old or changed URLs and remove chains.
- Check cache and CDN behavior with a fresh session.
- Validate analytics pageviews and key events with a test session.
- Submit a real test form and review both success and error states.
- Make a calm go/no-go call based on correctness, not on vibes.
That is the business case for a launch-day runbook. It protects attention. It reduces support cost. It gives a small team a defensible sequence when the pressure rises. And when the day ends quietly, take the win. Quiet is expensive to earn.