Checklistify

Website Pre-Launch

The structured pre-launch pass that catches what developers miss — a robots.txt still blocking crawlers, staging URLs baked into production links, forms silently swallowing submissions, and Core Web Vitals scores that will suppress rankings from day one. For more background and examples, see the guidance below; for built-in tools and options, use the quick tools guide.

Author
Checklistify Editorial Team
Last Updated

Checklist

0 done•31 left•5 of 6 sections collapsed

0%

🔬 Why Developers Miss What First-Time Visitors Find Immediately

There is a structural reason developers miss obvious launch problems: they test in the browser they built with. That browser already has the site cached, has set cookies, may be authenticated, and has visited every page. A broken navigation link goes unnoticed because muscle memory takes the developer directly to the right page. A font loading failure isn't visible because the font is already cached from the last development session. A 404 on a linked resource doesn't appear because it was loaded during testing and cached by the browser.

The structural fix: for each category of checks, use a private (incognito) window on a device that has never visited the site. This removes every cached asset and simulates the clean slate of a genuine first-time visitor. Then, for UX testing, hand the site to someone who has never seen it and observe without guiding — the pages where they pause, backtrack, or ask questions are the places where the site fails in production. The goal is to stop testing the site as someone who built it and start testing it as someone who just arrived via a search result.

📖 The Six-Week Blind Spot

A marketing agency launched a client site in November. The contact form appeared to work perfectly — the confirmation message displayed, no errors were thrown, every visible signal indicated success. What the launch checklist didn't verify: the email notification was routing to a development inbox that nobody monitored after go-live. For six weeks, 34 inquiries went completely unanswered. The client estimated the value of the missed work at roughly $4,200. The cause had nothing to do with the form itself — it was a single misconfigured email address in the notification settings that was never updated during the staging-to-production move. Every visual test passed. The invisible test — does the email actually reach the right person — was never run.

💡 Choose Your Launch Window Deliberately

DNS changes propagate across the global internet over a window of 0–48 hours, depending on the TTL (Time To Live) value set on your DNS records. During this window, some visitors are routed to the new server and others to the old one. Lower the DNS TTL to 300 seconds (5 minutes) at least 24 hours before the planned cutover — this dramatically compresses the propagation window so nearly all traffic shifts to the new server within minutes of the DNS change. For timing: schedule the actual cutover for a Tuesday through Thursday morning in your local time zone. Traffic is lowest for most business sites mid-week mornings, your team is available for the full business day if something needs immediate fixing, and you avoid the Friday-afternoon launch that leaves problems unaddressed for a full weekend.

🧠 Why Staging Environments Create a Specific Category of Error That Doesn't Exist Elsewhere

A web application built on a database-driven CMS is fundamentally different from desktop software in one way: the domain name is literally embedded inside the database. Image URLs, internal links, site configuration, and serialized settings objects all contain the full URL of wherever the site was when they were saved. When the site is migrated to a new domain, these database-resident references don't automatically update — they continue pointing at the original staging domain until something explicitly changes them.

This is what makes staging-to-production migration errors so insidious: they're invisible. The pages load. The images appear. Nothing throws an error. The broken references work fine as long as the staging server remains online — often weeks after launch. The failure only becomes visible when the staging server is eventually decommissioned and dozens of internal links and media references across the live site start returning 404s. Understanding this mechanism helps explain why the staging URL search-and-replace is one of the few pre-launch steps where automated checking (not manual spot review) is genuinely essential.

📋 A Three-Phase Launch Sequence

24 Hours Before
  • Complete full checklist on staging environment
  • Lower DNS TTL to 300 seconds
  • Take a manual database backup
  • Confirm team availability for launch window
  • Draft the launch announcement — don't send yet
Launch Day
  • Point DNS records to production server
  • Wait 15–30 minutes for propagation
  • Re-run the full checklist on production
  • Confirm analytics show live traffic
  • Monitor for the first 2 hours before announcing
  • Send the launch announcement once all checks pass
First 48 Hours
  • Review analytics for unexpected drop-off pages
  • Check form submissions arrived correctly
  • Review Google Search Console for crawl errors
  • Check server error logs for 500-level errors
  • Raise DNS TTL back to standard (3600 seconds)

🚨 What Launch Failures Actually Cost — After the Fact

Most pre-launch failures are invisible on the day of launch. Their cost accumulates in the days and weeks that follow.

Blocked robots.txt Pages don't appear in search results. Re-indexing after correcting the robots.txt takes 2–8 weeks depending on the domain's crawl budget. For a launch timed around a campaign, product release, or seasonal event, this window is often entirely unrecoverable.
Missing SSL Browsers display prominent security warnings on insecure pages, and certificate errors can trigger a full-page security interstitial before visitors reach the site. The overwhelming majority of users abandon immediately — the site is functionally inaccessible to anyone using a modern browser with default settings.
No analytics Day-one launch traffic data is permanently gone. For a new site with an active campaign, the launch window generates the highest-quality traffic data — the audience most motivated to convert. That baseline cannot be reconstructed retroactively.
Poor Core Web Vitals on mobile A 'Poor' LCP score doesn't prevent indexing, but it applies a ranking handicap via Google's page experience signal. Every piece of content on the site competes at a disadvantage until performance is improved and field data reflects the fix — which takes weeks of real user measurements to accumulate.

🧮 If You're Running Out of Time — A Triage Priority Order

Not every item on this list carries equal urgency. If a hard launch date is immovable and time is short, work through the categories in this order:

P0 — Launch blockers SSL certificate active, robots.txt not blocking crawlers, forms delivering to the right inbox, no sensitive files (.env, .git) publicly accessible. Any one of these can make the site effectively unusable or insecure from the moment it goes live.
P1 — Fix within 24 hours Analytics installed and verified, staging URLs replaced, staging environment locked, custom 404 page active, uptime monitoring configured. These don't block the launch but cause data loss or instability if left unresolved after go-live.
P2 — First week Core Web Vitals scores improved, all images optimized, security headers configured, Open Graph tags added, canonical tags and structured data in place. These affect long-term performance and SEO but don't cause an immediate incident.

Website Launch Readiness Sources

These official references verify the search, performance, and HTTP configuration checks this pre-launch checklist depends on.

Master This Checklist Quickly

Every important button and option for this pre-made checklist, shown in a glance-friendly format.

Start Here

  1. 1

    Click any item row to mark it complete.

  2. 2

    Use the note row under each item for quick notes.

  3. 3

    Use the tool row for undo, redo, reset, and check all.

  4. 4

    Use Save Progress when you want to continue later.

Checklist Row Tools

UndoRedoResetCheck allCollapse/Expand sectionsShow/Hide detailsInline notes

Top Action Buttons

Share

Open all sharing and export options in one menu.

Email DraftContinue on another devicePrint or Save as PDFPlain Text (.txt)Word (.docx)Excel (.xlsx)

Add & Ask

Open one menu for apps and AI guidance.

NotionTodoist CSVChatGPTClaude

Copy and customize

Create a new editable checklist pre-filled with your chosen content.

Save Progress

Adds this checklist to My Checklists and keeps your progress in this browser.

Most Natural Usage

Track over time

Check items -> Add notes where needed -> Save Progress

Send or export

Open Share -> Choose format -> Continue

Make your own version

Copy and customize -> Open create page -> Edit freely