Before You Start

This checklist covers everything that needs to happen before a nonprofit website goes live. It's written for the person responsible for managing the launch — typically a Digital Communications Manager or Head of Communications — rather than the technical team.

I've structured it in the order things should actually happen, not alphabetically or by department. Some items will feel obvious. Others are the ones organisations skip and then regret.

This is the companion to my Website Governance Policy guide — if you don't have a governance framework in place yet, start there first.

Phase 1: Content and Structure Sign-Off (4–6 Weeks Before Launch)

Content Audit Complete

Every page has been reviewed by someone with authority to approve it. This isn't a proofreading task — it's a governance task. Someone with institutional knowledge needs to confirm that what the website says is accurate, current, and aligned with your strategy.

• All body copy reviewed and approved
• All statistics and figures verified against current data
• All team member profiles confirmed accurate
• All programme descriptions reflect current offerings
• Contact information verified across every page

Legal and Compliance Review

These items require sign-off from someone with authority — typically your CEO, legal advisor, or Board-designated officer. Don't treat this as a checklist item that communications can approve unilaterally.

• Privacy policy reviewed and updated for current data practices
• Cookie consent mechanism reviewed by someone with GDPR authority
• Charity registration number displayed correctly (UK charities)
• Financial information reviewed if displayed (annual accounts, fundraising figures)
• Any regulated content (health information, legal guidance) reviewed by qualified person
• Accessibility statement drafted (required for UK public sector; best practice for all)

Brand and Tone Sign-Off

• Brand guidelines applied consistently across all pages
• Tone of voice consistent with approved brand documentation
• All imagery reviewed for appropriateness and licensing
• Logo usage correct across all contexts

Phase 2: Technical Verification (2–3 Weeks Before Launch)

Accessibility

WCAG AA compliance isn't optional if you receive public funding, serve diverse beneficiaries, or care about reaching everyone your mission is intended to serve. Run automated checks, but don't rely on them exclusively — automated tools catch around 30% of accessibility issues.

• Automated accessibility scan completed (WAVE, Axe, or similar)
• Keyboard navigation tested on all interactive elements
• Screen reader tested on key pages (NVDA or VoiceOver)
• Colour contrast verified for all text/background combinations
• All images have appropriate alt text
• All form fields have visible labels
• Error messages are descriptive and helpful
• Focus indicators visible throughout
• Skip navigation link present and functional

For a deeper guide to what this involves, see my article on WCAG AA compliance for nonprofit websites.

Forms and Data Collection

• All forms tested end-to-end (submission, confirmation, notification)
• Form data going to correct destination (CRM, email, spreadsheet)
• Confirmation emails configured and tested
• Error states tested (required fields, invalid formats)
• GDPR consent checkboxes present where required
• Form data storage reviewed against your data retention policy

If you're using Webflow's native forms or a third-party embed, see my guide on embedding donation forms in Webflow for integration considerations.

Performance

• PageSpeed Insights score reviewed on both mobile and desktop
• Images optimised (WebP format where possible, appropriately sized)
• No unused scripts or plugins loading
• Core Web Vitals reviewed (LCP, FID, CLS)
• Site tested on slow connection (Chrome DevTools throttling)

Cross-Browser and Device Testing

• Tested on Chrome, Firefox, Safari, and Edge
• Tested on iOS and Android mobile browsers
• Tested on tablet viewport
• Critical user journeys tested on each browser/device combination
• No layout breaks at common breakpoints

SEO Foundations

• Meta titles set for all pages (50–60 characters)
• Meta descriptions set for all pages (150–160 characters)
• Heading hierarchy correct (one H1 per page)
• Image alt text complete
• Canonical URLs configured
• Sitemap generated and verified
• robots.txt reviewed
• No pages accidentally set to noindex

For tracking setup, see my guide on setting up Google Tag Manager on Webflow.

Phase 3: Analytics and Tracking Setup (2 Weeks Before Launch)

Analytics Configuration

• Google Analytics 4 property created and connected
• Google Tag Manager container published with GA4 tag
• Goals/conversions configured (donations, newsletter signups, contact form submissions)
• Internal traffic filters set up (exclude your office IP addresses)
• Google Search Console verified and sitemap submitted

Tracking Verification

• GA4 DebugView confirms events firing correctly
• Conversion events verified with test submissions
• Tag Manager preview mode used to verify all tags firing on correct pages
• Cookie consent mechanism integrated with analytics (consent mode configured)

Phase 4: Domain and Hosting (1–2 Weeks Before Launch)

DNS and Domain

DNS changes take time to propagate. Don't leave these until 24 hours before launch.

• Domain ownership confirmed and registrar access verified
• DNS records reviewed (understand what's currently pointing where)
• TTL values reduced 48 hours before planned cutover
• SSL certificate confirmed (should be automatic in Webflow, but verify)
• www and non-www versions both resolve correctly
• Old hosting confirmed accessible until DNS propagation complete

For detailed DNS setup instructions, see my custom domain connection guide.

Redirects

If you're replacing an existing website, every URL that has inbound links, search engine rankings, or bookmarks needs a 301 redirect to its new equivalent. Missing redirects lose SEO equity you've built over years.

• Crawl of existing site completed (Screaming Frog or similar)
• List of URLs with meaningful traffic or inbound links identified
• 301 redirects mapped and implemented
• Redirects tested before DNS cutover
• Redirect chains avoided (A→B→C should be A→C)

See my full guide on 301 redirects for nonprofit website migrations for the complete process.

Phase 5: Stakeholder Sign-Off (1 Week Before Launch)

Internal Approvals

Who needs to see the website before it goes live? This isn't just communications preference — it's governance. If your CEO or Board Chair discovers a problem after launch, that's a governance failure, not a communications oversight.

• CEO or Executive Director has reviewed and approved
• Communications Director has final sign-off
• Any Board members requiring approval have reviewed
• Legal advisor has confirmed compliance items
• Fundraising team has reviewed any donation-related content

Stakeholder Briefing

• Internal team briefed on launch date and what's changing
• Key donors or funders notified if relationship warrants it
• Partner organisations informed if joint content is changing
• Mailing list communication drafted (if announcing publicly)

Phase 6: Launch Day

The Sequence

Launch day is not the time for surprises. Everything here should have been verified in the preceding days.

• DNS cutover initiated at a low-traffic time (Tuesday–Thursday, morning)
• Old site kept accessible or cached until propagation confirmed
• Post-launch check: all key pages loading correctly on live domain
• Forms tested on live domain (not just staging)
• Analytics confirmed firing on live domain
• Redirects confirmed working on live domain
• SSL certificate active and no mixed content warnings

Immediate Post-Launch Monitoring

• GA4 real-time view monitored for first hour
• Search Console monitored for crawl errors in first 48 hours
• Team on standby for any reports of issues
• Rollback plan confirmed (what happens if something critical breaks)

Phase 7: Post-Launch (First 30 Days)

Search Engine Recovery

If you've migrated from an existing site, expect a temporary drop in search rankings. This is normal and typically recovers within 4–8 weeks if redirects are properly implemented.

• Search Console monitored for 404 errors (redirect gaps)
• Coverage report reviewed after first crawl
• Any redirect gaps identified and fixed promptly

Ongoing Governance

• Content review schedule established (who reviews what, how often)
• Update request process communicated to internal teams
• Analytics review schedule set (monthly minimum)
• Accessibility monitoring approach confirmed

For establishing ongoing governance, see my Website Governance Policies guide and the Content Audit framework.

The Items Organisations Most Often Skip

Based on the sites I've audited, these are the items that appear most frequently on pre-launch checklists but least frequently get done properly:

Accessibility testing beyond automated scans. Automated tools give a false sense of completion. Keyboard navigation testing takes 30 minutes and catches issues automated tools miss entirely.

Redirect implementation for migrated sites. The pressure to launch creates shortcuts. Missing redirects affect search performance for months.

Analytics conversion tracking. GA4 installed doesn't mean conversions are tracked. Most organisations launch with pageview tracking but no goal configuration.

Legal review of privacy and cookie policies. These get approved by communications rather than the person with actual legal authority. That's a governance problem.

Post-launch monitoring plan. Launch day has a plan. The following week typically doesn't.

Using This Checklist

I'd recommend turning this into a shared document with named owners and sign-off dates for each section. Not because the checklist is the point, but because the named accountability is.

If you're working with an agency, this checklist is useful for clarifying what's their responsibility versus yours. Most launch failures I've seen come from assumptions about who owns what — not from anyone being incompetent.

If you're managing this internally, the governance sections (stakeholder sign-off, legal review) are the ones most worth protecting when time pressure hits.

Ready to start a Webflow project with proper launch governance? The Blueprint Audit is where I start every engagement — it maps what's needed before any build work begins.