31 items

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 Items

0 done•31 left•5 of 6 sections collapsed

Proofread all content — run an automated tool first, then a human read-through by someone unfamiliar with the copy

Automated tools like Grammarly catch mechanical errors — spelling, repeated words, obvious grammar mistakes — but miss contextual inaccuracies, awkward phrasing, and factual errors. The most reliable workflow: run Grammarly first to clear the mechanical layer, then hand the page to someone who had no role in writing it. Fresh eyes consistently catch what authors read past. Pay extra attention to headings, navigation labels, and call-to-action buttons — these receive disproportionate user attention, and a typo in a CTA is more damaging than one buried in body copy.

Search for and remove all placeholder content — 'Lorem ipsum,' 'TBD,' '[Your Name Here],' and test copy in every area of the site

In WordPress, use the Better Search Replace plugin (free) to search across posts, pages, widgets, and custom fields for strings like 'lorem ipsum,' 'placeholder,' 'test,' and 'tbd.' Go beyond the main content areas: check widget zones, footer text, email notification templates (auto-responders, order confirmations, password reset emails), and error pages. Also check dynamically populated fields — if a field is left empty, the CMS may output a raw fallback string like 'Enter your tagline here' rather than leaving it blank. Placeholder text on a live site is among the most embarrassing launch failures, and it's extremely common precisely because those areas are tested last.

Verify every image has a descriptive alt attribute — not empty, not keyword-stuffed, not missing

Alt text serves two functions: accessibility (screen readers read it aloud to visually impaired users, and it's a legal requirement under WCAG 2.1 in many jurisdictions) and SEO (search engines use it to understand image content for image search and page relevance). Write alt text that describes what the image shows in plain language — 'Accountant reviewing a financial spreadsheet on a laptop' — not generic filler like 'image1' or keyword chains like 'accounting services CPA firm best tax advisor.' Purely decorative images (dividers, background patterns) should have an empty alt attribute (alt='') explicitly set, not a missing attribute — this signals to screen readers that the image is ornamental and can be skipped without losing meaning. WAVE and Lighthouse flag missing alt attributes as accessibility errors.

Confirm the favicon is configured for all contexts — browser tab, desktop bookmark, and iOS home screen

A favicon is the small icon in browser tabs, bookmarks, and mobile home screen shortcuts. A tab without a favicon displays a generic document icon that signals an unfinished site. Modern favicon implementation requires multiple formats: a 32×32 PNG or ICO file for browser tabs, a 180×180 PNG declared with rel='apple-touch-icon' for iOS home screen bookmarks, and optionally an SVG for scalable rendering in modern browsers. Use realfavicongenerator.net to produce all required sizes from a single source image and receive the exact HTML snippet. Test each context specifically: open the site in a new browser tab, add a bookmark in Chrome and Firefox, and on a real iPhone, use Share → Add to Home Screen — each renders a different format.

Crawl all links using Screaming Frog or a similar tool — identify and fix 404 errors and any URLs still referencing the staging domain

Manual link checking is impractical beyond 10 pages. Screaming Frog SEO Spider (free up to 500 URLs) crawls the entire site and produces a spreadsheet of every URL, its HTTP status code (200 = OK, 404 = broken, 301 = redirect), and the page it appears on. For a site recently migrated from staging to production, filter the results for any URLs containing the staging domain — each one is a baked-in reference that will break when the staging server is decommissioned. Also filter for internal links using HTTP on an HTTPS site (these generate mixed content warnings). Ahrefs Webmaster Tools is a free alternative for ongoing link monitoring post-launch.

Submit every form with real test data and verify the confirmation message, notification email, auto-responder, and error states

For each form on the site: submit using real (not blank) test data, verify the on-page confirmation message displays correctly, verify the notification email arrives in the correct inbox — not a staging or developer inbox — within a few minutes, and verify the auto-responder reaches the address used to submit. Then test failure states: submit with a required field blank and confirm the error message is specific ('Please enter a valid email address,' not just 'Error'). Also test spam filtering: send a legitimate message and confirm it isn't caught by the server's spam filter. Forms that display a confirmation page but silently fail to deliver email notifications are one of the most damaging launch issues — the business misses leads for days or weeks before anyone notices because every visible signal indicates success.

Test the site in Chrome, Firefox, Safari, and Edge — then on real iOS and Android devices

Browser priority reflects both market share and rendering engine diversity: Chrome (~65% desktop market share), Safari (the only permitted browser engine on iOS — it's required for any Apple device user), Firefox (significant share among developers and privacy-conscious users, with its own rendering engine quirks), and Edge (the Windows default). Issues to specifically verify across all browsers: custom web font loading and rendering, CSS animation and transition behavior, form field and dropdown styling (browsers apply very different default styles), video embed playback, and modal or overlay open/close behavior. For mobile, browser developer tool emulation misses actual touch interaction behavior, real font rendering, and performance characteristics. Use physical devices where available, or BrowserStack and LambdaTest for cloud-based real device testing.

Test all navigation menus and dropdowns on a real mobile touchscreen — not just desktop hover states

Desktop navigation often relies on CSS :hover to reveal dropdown sub-menus. On touchscreens, :hover doesn't function the same way — a tap on a parent navigation item may simultaneously open the dropdown and navigate to the parent URL, leaving the user immediately on a page they didn't intend to visit, or it may trigger the hover state without any navigation, making the parent item appear to be a non-functional button. Test each navigation level on a real touch device: tap every parent item with sub-menus and confirm the behavior is predictable and usable. Also verify the mobile hamburger menu: confirm it opens and closes reliably, all nested items are reachable, and the close affordance is discoverable. Broken mobile navigation directly drives bounce rate because users who can't find what they're looking for leave without trying alternatives.

Test all media embeds — confirm videos, maps, podcasts, and interactive players load and function

Embedded third-party content (YouTube, Vimeo, Google Maps, Spotify, podcast players) can break silently during staging-to-production migration if embed codes reference staging domains or if Content Security Policy headers block external sources. For each embed: actually play or interact with it — don't just check that the container renders. For YouTube and Vimeo: verify the video is set to public (not private, which shows a locked placeholder); for maps: zoom, pan, and click a marker to confirm interactivity; for podcast players: press play. Embeds that display a blank or grey container with no error message are particularly easy to miss — the page layout appears intact, but the functionality is completely absent.

Complete a full end-to-end test purchase on any e-commerce functionality — including payment processing, order confirmation, and email receipt

If the site has a store: complete a full test transaction using a sandbox payment method. Stripe provides test card numbers (4242 4242 4242 4242 works for most test scenarios); PayPal has a dedicated sandbox environment. Walk through the entire flow: product page, add to cart, cart review, checkout form entry, payment processing, order confirmation page, and confirmation email delivery. Common failure points that only surface in end-to-end testing: shipping rate calculation returning a blank or error, tax logic producing incorrect totals, the order confirmation email not triggering, and payment declines not showing helpful error messages. Perform this test on both desktop and on a real mobile device — mobile commerce accounts for over 70% of e-commerce traffic on many sites, and a checkout flow that breaks on mobile loses the transaction entirely.

#10

Run Google PageSpeed Insights and achieve 'Good' Core Web Vitals on mobile — LCP under 2.5s, INP under 200ms, CLS under 0.1

Core Web Vitals are the page experience metrics Google uses as ranking signals. The three thresholds and what they measure: LCP (Largest Contentful Paint) — how long the main visible content takes to appear; 'Good' is under 2.5 seconds, 'Poor' is over 4.0 seconds; the LCP element is almost always the hero image or largest above-the-fold text block. INP (Interaction to Next Paint) — how quickly the page responds to a user tap or click; 'Good' is under 200 milliseconds. CLS (Cumulative Layout Shift) — how much the page layout unexpectedly shifts while loading; 'Good' is under 0.1; the primary cause is images and ads loading without reserved space. Google uses mobile scores as the primary signal — mobile simulation uses throttled CPU and network conditions, so mobile scores are consistently lower than desktop. When PageSpeed Insights shows both 'Field Data' (real Chrome user measurements) and 'Lab Data' (simulated), field data carries more weight for ranking if available for the URL.

#11

Optimize all images before uploading — resize to display dimensions, compress, and convert to WebP format

Images are the single most common cause of slow-loading pages and poor LCP scores. Optimization in order of impact: (1) Resize — never upload a 4,000px image for a slot that displays at 800px; the extra pixels transfer across the network and accomplish nothing visually. (2) Compress — TinyPNG, Squoosh (browser-based and free), or ImageOptim (Mac) reduce file size without visible quality loss. (3) Convert to WebP — 30–50% smaller than equivalent-quality JPEG, with full support in all modern browsers. (4) Prioritize the LCP image — add fetchpriority='high' to the hero image so the browser downloads it immediately rather than queuing it behind other resources; never apply lazy-loading to the LCP image. For WordPress: ShortPixel or Imagify handle WebP conversion and compression automatically for new uploads and can batch-process the existing media library. For static sites: add image optimization to the build pipeline so unoptimized images can't reach production.

#12

Enable GZIP or Brotli compression and configure browser caching headers on the server

Server-side compression reduces the transfer size of HTML, CSS, and JavaScript files by 60–80% — these are text files that compress extremely efficiently, and the decompression time on the client side is negligible. GZIP is universally supported; Brotli (newer, slightly better compression ratio) is supported by all modern browsers and preferred when available. Verify compression is active by entering the site URL into giftofspeed.com, or by opening browser DevTools (F12 → Network tab → click any request → Headers) and checking for 'Content-Encoding: gzip' or 'Content-Encoding: br' in the response headers. Browser caching headers (Cache-Control, Expires) instruct browsers how long to store static assets locally — correctly set, a returning visitor loads JavaScript, CSS, and images from their local cache rather than re-downloading them. For WordPress: WP Rocket or W3 Total Cache configure both compression and caching automatically. For custom servers, Nginx and Apache configurations for both are straightforward and well-documented in each platform's official docs.

#13

Test load time from multiple geographic regions using WebPageTest or GTmetrix

PageSpeed Insights tests from Google's own servers, which may be geographically close to the hosting server and produce optimistic load time results that don't reflect global user experience. WebPageTest.org (free) lets you test from specific cities worldwide across different connection speeds, and provides a waterfall chart showing which individual resources cause the most delay. GTmetrix provides similar multi-location testing with a structured summary. Testing from a location geographically distant from the server — for example, testing a US-hosted site from Southeast Asia or Europe — reveals whether a CDN (Content Delivery Network) is necessary. A site that loads in 1.5 seconds from the same country as the server can load in 5–8 seconds for international visitors without a CDN, because every request must travel the full physical distance to the origin server.

#14

Verify every page has a unique, keyword-relevant title tag under 60 characters

Title tags appear in browser tabs and as the clickable blue headline in search results — they're the primary signal for what a page covers. Each page needs a unique title tag (duplicate titles across pages reduce Google's ability to distinguish pages from each other and often prompt rewrites). Standard patterns: home page — '[Brand Name] | [Primary Value Proposition]'; interior pages — '[Primary Keyword] | [Brand Name].' Keep under 60 characters to avoid truncation in search results (Google truncates at approximately 600px pixel width, which varies by character width but corresponds to roughly 55–65 characters). Screaming Frog's crawl export produces a spreadsheet of all title tags and their character counts in one pass — far faster than spot-checking individual pages.

#15

Verify every page has a unique meta description between 140–160 characters

Meta descriptions appear as the gray descriptive text beneath the title in search results — they don't directly affect rankings but significantly affect click-through rate. Write them as specific value propositions: what benefit does clicking this particular page deliver? Keep to 140–160 characters (shorter gets padded with surrounding page text; longer gets truncated mid-sentence). Include the primary keyword naturally within the first 100 characters. Note: Google rewrites meta descriptions approximately 60% of the time when its algorithm determines a different snippet better matches the search query — but a well-written description controls the snippet in the remaining cases and gives Google a quality starting point even when it rewrites.

#16

Confirm every page has exactly one H1 tag that reflects the page's primary topic

The H1 tag is the page's main heading — both a usability signal (users scan for it to confirm they've arrived at the right page) and an SEO signal for page topic relevance. Each page should have exactly one H1: multiple H1s dilute the topical signal; a missing H1 is a missed opportunity on both fronts. The H1 should include the primary keyword and be descriptive rather than generic — 'Contact Us' is weak; 'Book a Free 30-Minute Strategy Call' is specific and action-oriented. Screaming Frog's crawl report includes H1 extraction, letting you audit the entire site simultaneously and immediately flag pages with missing H1s, duplicate H1s, or H1s that are very short or don't match the title tag.

#17

Add Open Graph and Twitter Card meta tags to all pages — validate with Facebook Sharing Debugger and Twitter Card Validator

When a URL is shared on Facebook, LinkedIn, Twitter/X, Slack, WhatsApp, or iMessage, the platform reads Open Graph (og:) meta tags to generate the preview card — the title, description, and image shown in the link preview. Without these tags, each platform picks whatever content it finds, producing poorly formatted previews or no preview at all. Required tags: og:title, og:description, og:image (minimum 1200×630px for Facebook and LinkedIn; 1200×600px for Twitter/X), og:url, and og:type ('website' for most pages). For Twitter specifically: add twitter:card='summary_large_image' and twitter:image. After adding the tags, test with Facebook's Sharing Debugger (developers.facebook.com/tools/debug) and Twitter's Card Validator — both tools show exactly how the preview will render and flag any size or format issues. Most SEO plugins for CMS platforms (Yoast SEO, Rank Math) generate Open Graph tags automatically from existing title and meta description fields and require only the image to be set manually.

#18

Verify the XML sitemap exists at /sitemap.xml and submit it to Google Search Console

The XML sitemap is the explicit list of URLs you want search engines to discover and index — it's the fastest way to ensure new pages aren't missed by crawlers that rely solely on following links. Most CMS platforms generate sitemaps automatically (WordPress with Yoast SEO or Rank Math: look for /sitemap.xml or /sitemap_index.xml). Verify before submitting: the file loads in a browser, all URLs are production URLs (not staging URLs — a common post-migration error), and it excludes pages you want kept out of search results (admin areas, private pages, duplicate paginated archives). Submit via Google Search Console under Sitemaps → 'Add a new sitemap.' For a brand-new domain with no inbound links, sitemap submission significantly accelerates the time from 'site exists' to 'pages appear in Google search results.'

#19

Verify robots.txt is not blocking search engines — specifically check for 'Disallow: /' targeting all crawlers

Blocking search crawlers via robots.txt is the correct standard practice during development — you don't want a staging site indexed. The critical pre-launch step: reverting this before going live. Navigate to yourdomain.com/robots.txt in a browser and verify it does not contain 'Disallow: /' (blocks all crawlers from all pages) or a targeted block like 'User-agent: Googlebot / Disallow: /.' A minimal safe robots.txt for a fully public site: 'User-agent: * / Allow: / / Sitemap: https://yourdomain.com/sitemap.xml.' Also confirm the staging domain either has its own robots.txt that blocks crawlers or is inaccessible after launch — if staging remains publicly accessible, Google may index duplicate content across both domains.

#20

Add canonical tags to every page to establish the authoritative URL and prevent duplicate content issues

A canonical tag (rel='canonical') tells search engines which URL is the definitive version of a page when identical or near-identical content is accessible at multiple URLs. Common situations requiring canonicals: a page accessible at both example.com/page and www.example.com/page, paginated content (/blog?page=2), filtered or sorted product listings (/shop?sort=price&color=red), and syndicated content published on external sites. At minimum, every page should carry a self-referencing canonical pointing to its own production URL — this prevents accidental duplicate content signals caused by URL parameters, tracking codes, or session IDs appended by analytics tools. Yoast SEO and Rank Math add self-referencing canonicals by default; for custom-built sites, the tag goes in the <head>: <link rel='canonical' href='https://yourdomain.com/the-page' />.

#21

Add structured data (schema markup) to key page types — products, articles, local business, and FAQs

Structured data is machine-readable code added to a page (in JSON-LD format inside the <head> section) that explicitly tells search engines what the content represents — a product with a price and rating, a recipe with cooking time and ingredients, a local business with hours and address. Google uses valid structured data to generate rich snippets in search results: star ratings, prices, FAQs, and event dates displayed directly in the search listing. These rich results can substantially increase click-through rate. Priority page types: local businesses (LocalBusiness schema — name, address, phone, hours), blog articles (Article schema — author, date, image), product pages (Product schema — price, availability, reviews), and FAQ pages (FAQPage schema — question and answer pairs). Validate all markup with Google's Rich Results Test at search.google.com/test/rich-results before launch — it shows exactly which rich result types are eligible and flags any errors.

#22

Verify SSL is active on all pages and check for mixed content warnings that silently break HTTPS protection

HTTPS is non-negotiable: browsers display a 'Not Secure' label for HTTP pages, many modern browser APIs (geolocation, push notifications, service workers) require HTTPS to function, and it's a weak but real Google ranking consideration. Verification: confirm the padlock icon appears in the address bar on every page — including dynamic pages, user dashboard areas, cart pages, and admin panels. Mixed content occurs when an HTTPS page loads individual resources (images, scripts, stylesheets, fonts) via plain HTTP — browsers block active mixed content (scripts, stylesheets) and warn about passive mixed content (images), in both cases weakening HTTPS protection. Detection: open browser DevTools (F12 → Console) and look for mixed content errors while browsing the site. For a full certificate analysis including expiry date and cipher configuration, use SSL Labs at ssllabs.com/ssltest — also note the expiry date and set a renewal reminder 30 days in advance.

#23

Remove or restrict access to sensitive development files before going live — verify .env, .git, log files, and debug pages return 403 or 404

Development environments routinely contain files that must never be publicly accessible: .env files (database credentials, API keys, secret tokens), .git directories (which expose the full source code and commit history to anyone who accesses /.git/config), PHP debug pages (phpinfo() output reveals server configuration, PHP version, and loaded modules), backup archives (.zip, .sql, .tar.gz files of the database or codebase), and verbose error logs. Test exposure by navigating directly to yourdomain.com/.env and yourdomain.com/.git/config in a browser — both should return a 403 Forbidden or 404 Not Found response, never file contents. For WordPress: wp-config.php should be inaccessible. For Node.js and PHP applications: .htaccess rules or server-level configuration should block directory traversal and direct access to these file types. A publicly accessible .env file containing a live database password or Stripe secret key is one of the most severe security vulnerabilities a web server can expose.

#24

Configure HTTP security headers on the server — at minimum X-Content-Type-Options, X-Frame-Options, and Strict-Transport-Security

Security headers are server response headers that instruct browsers how to treat the site's content and connections. The three highest-priority headers: X-Content-Type-Options: nosniff prevents browsers from interpreting files as a different MIME type than declared — it stops MIME-type confusion attacks. X-Frame-Options: DENY (or SAMEORIGIN if you need to embed your own content in iframes) prevents the site from being embedded in an iframe on another domain, blocking clickjacking attacks where a hidden version of your site is overlaid on a malicious page. Strict-Transport-Security (HSTS) with a max-age value tells browsers to always use HTTPS for the domain even if a user types HTTP — this prevents protocol downgrade attacks. A more advanced header, Content-Security-Policy (CSP), controls which external domains can load resources on your site, but is more complex to configure without breaking functionality. Audit current header status and receive a letter grade at securityheaders.com. Most CDN providers, including Cloudflare, allow headers to be set without direct server access.

#25

Install and verify Google Analytics 4 — confirm real-time event tracking and link to Google Search Console

Analytics must be installed and verified before launch so day-one traffic is captured — this data cannot be retroactively recovered. Install the GA4 measurement tag (via Google Tag Manager for flexibility, or direct page code insertion) and then validate: open GA4 → Reports → Realtime and browse several pages on the site — confirm page_view events appear in real time as you navigate. Verify the correct GA4 property ID is receiving data (it's easy to accidentally install a tag pointing to a test property from development, which will quietly collect no real data). Configure conversion events for the most important user actions: form submissions, quote requests, purchases, phone link clicks. Finally, link GA4 to Google Search Console under GA4 → Admin → Product Links → Search Console — this surfaces keyword ranking data and search performance directly within GA4 reporting.

#26

Set up automated daily backups with at least 30-day retention stored to a separate off-server location

A backup stored on the same server as the live site is lost in the exact scenarios you need it most: server hardware failure, account compromise, accidental data deletion, or hosting provider issues. Backup storage must be physically separate: Amazon S3, Backblaze B2 (lower cost), Google Drive, or Dropbox are all reliable off-server destinations. For WordPress: UpdraftPlus (free tier) supports scheduled daily backups to all major cloud storage providers. Retention period: at minimum 30 days — malware infections and database corruption are frequently not discovered for 1–3 weeks, which means a 7-day retention window may already contain the compromised state. After configuring: trigger a manual backup immediately and verify the backup files appear in the remote storage location. A backup whose restoration process has never been tested should be treated as unreliable — the backup system itself is not working until a restore has been successfully completed at least once.

#27

Test the custom 404 page and verify it returns an actual HTTP 404 status code — not a 200

Navigate to yourdomain.com/this-page-does-not-exist and verify: a branded, custom 404 page appears (not a blank white screen or raw server error page), it clearly communicates the page wasn't found in user-friendly language, and it includes navigation back to the main site — at minimum, a link to the homepage, and ideally a search bar or links to popular content. A well-designed 404 page recovers some would-be bounces; a blank page loses them entirely. The critical hidden technical issue: some CMS configurations serve the homepage (or a custom page) in response to any invalid URL and return HTTP 200 (OK) status — this is called a 'soft 404' and causes Google to waste crawl budget attempting to index thousands of non-existent URLs. Verify the actual response code using curl -I yourdomain.com/nonexistent-page in a terminal, or install a browser extension like 'HTTP Status' that overlays response codes on links.

#28

Configure uptime monitoring before launch day and set up immediate alert notifications

Uptime monitoring tools continuously attempt to load the site at regular intervals (typically every 1–5 minutes) and send an immediate alert — email, SMS, or Slack — if the site becomes unavailable. Free options with reliable free tiers: UptimeRobot monitors up to 50 URLs at 5-minute intervals; Freshping offers 1-minute check intervals. Configure monitoring before launch rather than after, for two reasons: first, you receive a positive confirmation notification when the site goes live, confirming the DNS switch succeeded; second, the monitoring baseline is established from day one. Without proactive uptime monitoring, the typical pattern is learning about downtime from a customer complaint rather than an automated alert — which means the outage has already been running for an unknown amount of time before it's addressed.

#29

Replace all staging domain references in the database and configuration files with the production URL

After a staging-to-production migration, database records (internal links, image source URLs, site settings, serialized configuration) frequently retain the staging domain. The pages can appear visually identical on production because some references are resolved by the server, but underlying links, media, and settings still point at staging. For WordPress: run Better Search Replace across the full database to replace every instance of the staging URL with the production URL — run it for both HTTP and HTTPS variants of the staging domain. After the database replacement, crawl the production site with Screaming Frog and filter results for any URL containing the staging domain — each remaining hit is a missed replacement. For non-CMS sites: grep the codebase and configuration files for the staging domain string and replace all occurrences.

#30

Password-protect or take offline the staging environment after the production site launches

If the staging site remains publicly accessible after the production launch, search engines may index duplicate content across two domains — splitting link equity and ranking signals, and creating a confusing situation where Google ranks the staging URL for queries instead of (or alongside) the production URL. Options ranked by preference: take the staging site offline entirely if the hosting plan allows it; password-protect it with HTTP basic authentication (most hosting control panels support this in two clicks); or add a Disallow: / rule in the staging robots.txt. For WordPress staging on managed hosts (WP Engine, Kinsta, Flywheel): there's typically a one-click password protection toggle. Also confirm that any development-specific settings active on staging — debug mode enabled, verbose PHP error display, WP_DEBUG = true — are not active on the production server. Debug output visible in the browser exposes internal file paths, plugin names, and database structure to any visitor who encounters an error.

#31

🔬 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 Chrome displays 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.

Master This Checklist Quickly

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

Start Here

1
Click any item row to mark it complete.
2
Use the note row under each item for quick notes.
3
Use the tool row for undo, redo, reset, and check all.
4
Use Save Progress when you want to continue later.

Checklist Row Tools

UndoRedoResetCheck allCollapse/Expand sectionsShow/Hide detailsInline notes

Top Action Buttons

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