The Pre-Launch Checklist I Run on Every Site

Before any site I build goes live, I run the same checklist. Not because I might forget the obvious things, but because 'I think I got that' is how launch disasters happen. The checklist externalizes memory so I am not relying on confidence at 11 PM before a morning launch.

The Short Answer: What the Checklist Is and Why It Exists

The checklist is a forcing function. IBM's Systems Sciences Institute research puts the cost of fixing a defect post-launch at 4 to 5 times higher than fixing it during development, and up to 100 times higher if it sits in production for a while. That math alone justifies the two to four hours it takes to run through everything before the DNS switch flips.

This checklist lives in eight categories: performance, accessibility, SEO plumbing, analytics and conversion tracking, redirects, email deliverability, and an honest accounting of where the checklist itself can mislead you. If you are thinking about what to include in your developer brief, these eight categories map directly to what a good brief should specify before a single line of code is written. Catching problems at the brief stage is cheaper than catching them at launch, which is still cheaper than catching them in production.

Running this checklist does not make a mediocre site excellent. It makes sure a good site does not get sabotaged by a missing robots.txt directive or an unfired analytics tag.

Performance: Core Web Vitals and Load Time

Google's three Core Web Vitals are Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). The passing thresholds are: LCP under 2.5 seconds, CLS under 0.1, INP under 200 milliseconds. Those are the numbers I check before launch, not after.

I test with PageSpeed Insights and Chrome DevTools. PageSpeed Insights gives both lab data and, for sites that have had prior traffic, field data from the Chrome User Experience Report. For a new build with no existing traffic, lab data is all you have pre-launch, and that is fine: it tells you what the starting point is before third-party scripts degrade it.

For any site where form completion is the primary conversion goal, I treat a passing CWV score as a minimum, not a target. A Deloitte study commissioned by Google found that a 0.1-second improvement in load time can increase conversion rates by up to 8% for retail and financial services sites. That is a meaningful number when the conversion is a high-intent action like submitting an application.

The three most common culprits I find at the pre-launch audit stage are unoptimized images (WebP conversion and explicit width/height attributes solve most CLS problems), render-blocking scripts loaded synchronously in the head, and web fonts loading without a proper font-display strategy. I have written more about which fixes actually move Core Web Vitals numbers if you want the specifics behind each lever.

The fastest path to good Core Web Vitals is choosing an architecture that does not fight you. Sites that are fast by default before any optimization start the race ahead; dynamic stacks with heavy JavaScript frameworks start behind it.

Accessibility: WCAG 2.1 AA Before You Ship

WCAG 2.1 AA is not a stretch goal. It is the baseline, and I want to be direct about that: WCAG AA is the baseline of professional work, not an add-on for clients who ask for it.

The legal context has sharpened in recent years. The Department of Justice finalized its rule in April 2024 under Title II of the ADA requiring web content accessibility for state and local government entities, and private-sector sites, particularly in financial services, have faced civil litigation under the ADA for inaccessible online applications. The WebAIM Million 2024 report found that 96.3% of the top one million websites have detectable WCAG failures on their homepage. That is a population of sites where launching without checking is the norm, not the exception. Being in that population is not a defense.

I use two automated tools: the axe DevTools browser extension and the Lighthouse accessibility audit built into Chrome DevTools. Both are fast and both are incomplete. Automated tools catch roughly 30 to 40 percent of actual WCAG failures. The rest require manual testing.

The most common failures I find are missing or inaccurate alt text on images, color contrast ratios below the 4.5:1 minimum for normal text, unlabeled form fields (a placeholder attribute is not a label), and keyboard navigation traps where focus gets stuck inside a modal or dropdown. I test every site with a keyboard only, no mouse, before launch. If I cannot complete the primary user flow using only Tab, Shift-Tab, Enter, and arrow keys, the site is not ready.

SEO Plumbing: The Infrastructure Layer

I separate SEO into two buckets: content SEO, which is ongoing and never truly finished, and SEO plumbing, which must be correct on day one. The plumbing is what I check on the pre-launch checklist.

The specific items I verify before launch:

Canonical tags: every indexable page has a self-referencing canonical, and paginated or filtered URLs canonicalize to the correct primary URL.
robots.txt: the file exists, is reachable at the root, and does not accidentally block Googlebot from crawling the entire site. I have seen this exact mistake on relaunches where the staging site's robots.txt got deployed to production. It is the kind of error that can cost months of index visibility.
XML sitemap: generated, accurate, and submitted to Google Search Console on day one.
Meta titles and descriptions: every indexable page has a unique title under 60 characters and a meta description between 140 and 155 characters. Missing or duplicate titles are a drag from the start.
Open Graph tags: at minimum og:title, og:description, and og:image on every page so social sharing does not generate broken previews.

For structured data, the three highest-value schema types for informational content are FAQPage, HowTo, and BreadcrumbList. I validate every structured data implementation in Google's Rich Results Test before launch. The test checks syntax and basic eligibility; it does not check whether the content is accurate or whether the schema matches the page content. That part is on me.

Understanding how search, AI, and voice discovery work differently is worth reading alongside this section: structured data is a direct input to the AI Overview and featured snippet surfaces that are increasingly the first thing a user sees for informational queries.

Analytics and Conversion Tracking: Get the Baseline Right

The first few weeks of data after launch become the permanent benchmark. Every future comparison, every month-over-month report, every attribution analysis gets measured against that baseline. Corrupt data at launch means every future comparison is built on a bad foundation, and that problem compounds silently.

The minimum GA4 configuration I verify before any launch:

Conversion events defined: at minimum one primary conversion event (form submission, phone call click, or whatever the site's primary goal is) is marked as a conversion in GA4, not just tracked as an event. An event that fires but is not marked as a conversion will not appear in conversion reports or inform bidding if the site runs paid traffic.
Internal IP traffic filtered: the team's office and home IP addresses are filtered out in the GA4 Admin panel under Data Streams > Configure Tag Settings > Define Internal Traffic. This is not a developer note on a sticky note; it is a setting in the platform.
Enhanced measurement verified: GA4's enhanced measurement should be reviewed, not just enabled. Scroll depth, outbound clicks, and file downloads are useful; unreviewed form interactions can double-count or misfire.
Cross-domain tracking configured: if the site uses a third-party checkout, scheduling tool, or form hosted on a different domain, cross-domain tracking must be configured or the session breaks at the handoff and attribution is lost.

I verify event firing with GA4 DebugView before removing the debug label. Google Tag Manager preview mode is the correct way to confirm tags are firing before publishing the container. Publishing unverified tags is the fastest way to create the corrupt baseline problem I just described.

Redirects: The Migration Step That Kills Rankings

Redirect mapping is not optional for a relaunch. It is required any time URLs change, whether the domain changes or not. Changing a CMS often changes URL structure even if the domain stays the same, and that still requires a full redirect map.

Ahrefs' migration research puts the average organic traffic loss after a site migration at 5% to 20%, primarily from broken redirects and canonical errors. For a site with years of accumulated local or topical authority, that loss can take 6 to 12 months to recover. It is worth a full day of mapping work to avoid it.

My process: crawl the old site with Screaming Frog and export every URL that returns a 200 response. Map each one to its new destination. Implement all mappings as 301 permanent redirects. Then re-crawl after launch to find chains and loops.

A redirect chain is what happens when the old URL redirects to an interim URL that then redirects to the final destination: old > interim > new. Each hop loses a small percentage of link equity and wastes crawl budget. A redirect loop is when URL A redirects to URL B which redirects back to URL A, which prevents the page from loading at all. Both are findable with a post-launch Screaming Frog crawl filtered to 3xx responses.

One step that gets skipped even when the redirect map is correct: updating internal links. Redirects preserve external link equity from other domains, but internal links should point directly to the new URLs. Relying on a redirect for your own internal links is sloppy and fractionally inefficient at scale.

Email Deliverability: SPF, DKIM, and DMARC

Email deliverability is the most commonly absent section in pre-launch checklists I have seen, and for any site sending transactional email, that absence is a direct revenue problem. Rate alerts, confirmation emails, document requests, and password resets landing in spam are not a minor annoyance; they are broken user flows.

The three DNS records that control deliverability:

SPF (Sender Policy Framework): a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. Without it, receiving servers have no way to verify that the email claiming to come from your domain actually did.
DKIM (DomainKeys Identified Mail): a cryptographic signature attached to each outgoing email that allows the receiving server to verify the message was not altered in transit and came from an authorized sender.
DMARC (Domain-based Message Authentication, Reporting and Conformance): a policy record that tells receiving servers what to do when SPF or DKIM checks fail. At minimum, p=none with a rua reporting address lets you collect data without rejecting mail; p=quarantine or p=reject enforces stricter handling.

A 2023 Valimail report found that only 33% of websites have a properly configured DMARC record. That means the majority of domains are either vulnerable to email spoofing or simply have no policy at all.

I verify all three records using MXToolbox, mail-tester.com, and Google's Check MX tool before the first transactional email fires. The minimum configuration for day one is SPF and DKIM set up for every service that sends email on behalf of the domain: the CMS, the CRM, the email marketing platform, and any form notification service. Missing one of those services from the SPF record means its emails may fail authentication even if the others are correctly configured.

Where This Checklist Goes Wrong: Honest Tradeoffs

Running the full checklist adds time. For a simple new build with no migration, that time is two to four hours. For a 200-page CMS migration with a full redirect map, the redirect work alone can take a full day. Sometimes that pushes a launch date, and sometimes clients do not want to hear that.

The tradeoff is real but asymmetric. The redirect mapping day costs one day. Recovering lost organic traffic from a botched migration costs months.

Some items scale with site complexity. Redirect mapping is the obvious one: a five-page brochure site with stable URLs does not need it. Structured data is lower priority for a pure brochure site with no FAQ or how-to content worth marking up.

Automated accessibility tools give false confidence. Passing axe DevTools means the tool did not find the 30 to 40 percent of issues it is capable of finding. It does not mean the site is accessible. The keyboard-only navigation test is not optional.

Structured data can be implemented incorrectly and still pass the Rich Results Test. The test checks syntax, not accuracy. A FAQPage schema that lists questions the page does not actually answer will validate cleanly and still mislead both users and search engines.

The checklist is a floor. It catches the launch disasters. It does not make a mediocre site perform well, rank well, or convert well. Those outcomes require the right architecture, the right content, and ongoing work after the launch. The checklist just makes sure the foundation is solid before you build on it.

Start by downloading or copying this checklist into whatever project management tool you use, then run it against your current site or next build and see what comes back.