WordPress Website Launch Checklist: 491 Checks Before You Go Live

A WordPress website launch checklist is the set of verifications that must pass before a site goes live, covering content, accessibility, performance, security, search, analytics, consent, and the cutover itself. This one is a comprehensive 491-check framework for custom WordPress launches, spanning pre-launch, launch day, post-launch, and handoff so the site is stable not just at go-live, but in the weeks that follow.

A complete checklist includes several hundred items and doesn’t stop at launch day. The checks that catch the most expensive failures often happen in the first 60 days after launch, when search visibility, tracking, redirects, consent, uptime, and conversion paths can quietly break.

This is the checklist Parachute Design runs for mid-to-large B2B and B2C organizations, including tech companies, law firms, startups, healthcare organizations, and other teams investing in high-quality custom WordPress sites. It holds 491 checks across eleven sections, 208 of them classified as Critical, meaning a failure can block launch, lose data, expose a security or privacy risk, or materially damage search and conversions. You can download the full checklist below and use it for your own launch.

Inside, you’ll get the full launch process: universal pre-launch checks, launch-type-specific checks for same-domain rebuilds, domain migrations, and multilingual websites, plus launch day runbook tasks, post-launch reviews, handoff steps, and the common mistakes that cause avoidable problems later.

Download the checklist

The full Parachute WordPress Launch SOP is free, with no sign-up and no email gate.

• Spreadsheet (ZIP). The working version. Every check has an Owner, a Status, a Priority and an Evidence field. Filter it to Blocked items or to Critical items, and it becomes the launch meeting agenda.
• PDF. The printable version, for reviewers who want to mark it up on paper or circulate it for sign-off.

Duplicate the workbook for each project and rename it with the client and the launch date. Start with the Universal Pre-Launch sheet, then add the sheet matching your launch type.

What a WordPress launch checklist should actually cover

Most launch checklists cover four things: check the design, compress the images, install an SEO plugin, connect Google Analytics. Those matter, and they are the easy part. They are also where almost every published checklist stops.

The failures that cost real money sit elsewhere. A staging URL left inside a serialized database field. A canonical tag pointing at a staging host. A redirect map missing the fifteen-year-old URLs nobody knew existed. A consent banner that loads after the analytics tag it is supposed to gate. None of those are visible when you look at the site.

A launch checklist earns its place by covering the work in the order it actually happens:

1. Universal pre-launch, the 214 checks that apply to every WordPress launch
2. Launch type, the additional checks for a same-domain rebuild, a domain or URL migration, or a multilingual build
3. Launch day, run as an ordered runbook rather than a list
4. After launch, at 24 hours, 72 hours, 7 days, 30 days and 60 days
5. Handoff, where ownership and access actually transfer

The rest of this article walks through each phase and names the checks that catch the most.

Phase 1: Universal pre-launch

Every WordPress launch runs the same 214 pre-launch checks regardless of type. They divide into seventeen sections. Five of them account for most of the launches that go wrong.

Production database and URLs

This section is Critical in full, and it quietly breaks more launches than any other.

When a site is built on staging, the staging hostname ends up in hundreds of places: post content, widget options, custom field values, menu items, theme settings, and serialized arrays where a naive find-and-replace will corrupt the data instead of fixing it. Use a search-and-replace tool that understands PHP serialization. A plain SQL replace will break every serialized option it touches.

Then verify the result rather than assuming it. Confirm that staging, development and localhost references are absent. Confirm that internal links and media use production URLs. Confirm that forms, APIs, canonical tags, Open Graph tags, schema, sitemaps and feeds all resolve to production. A canonical tag still pointing at staging tells Google the staging site is the authoritative version of every page you just launched.

Technical SEO

Fifteen Critical checks, and the first one is the single most common launch failure in WordPress.

Disable “Discourage search engines from indexing this site” on production. It lives in Settings, Reading. It is switched on during development for good reason, and it gets forgotten. A site can sit with a site-wide noindex for weeks before anyone notices traffic never arrived.

The rest of the section covers the checks that decide whether the launch keeps its search position: confirming important pages return HTTP 200, confirming removed pages return the intended redirect, 404 or 410, checking soft 404s, verifying canonical tags use HTTPS and the production domain, and confirming canonicals do not point at staging or at redirected URLs; clean, SEO-friendly permalinks also support better indexing. On-page SEO helps search engines index your content. Meta tags help search engines understand the site’s content. Generate the XML sitemap, validate it, and exclude noindex, redirected, and 404 URLs so crawlers can understand your site structure. A sitemap listing URLs that redirect tells Google your map is out of date.

Keep staging password-protected or non-indexable for the same reason. Two live copies of the same site competing for the same queries is a problem you create yourself.

Forms and conversion paths

Eighteen checks, all Critical, and the reason is simple: a form that fails silently costs more than a slow page.

Inventory every production form, including contact forms, then submit each one end to end with a real test. Not a validation test. A real submission that you then trace all the way through. Confirm the visitor confirmation arrives. Confirm the internal notification arrives. Confirm the record lands in the CRM with the fields mapped correctly. Confirm the conversion event fires. Confirm UTM parameters persist through the submission so the lead carries its source.

Then test every form again on mobile, because conditional fields, file uploads and CAPTCHA behave differently there.

Accessibility

Twenty-one checks, and automated scanning covers only part of them; production forms, such as contact forms, must be tested end to end.

Run a full-site automated scan and resolve critical and serious violations. Parachute uses axe DevTools, WAVE and Google Lighthouse. Automated testing alone detects only a minority of accessibility issues, which is why a manual pass carries a conformance claim and why dedicated accessibility testing is still required.

Manual checks matter for a conformance statement: navigate the entire site by keyboard only, confirm a logical tab order and visible focus states, confirm focus is never hidden behind a sticky header, test skip navigation, and eliminate keyboard traps. Test menus, modals, and other interactive elements specifically, since focus management is where most component libraries fail. Confirm images have alt text that works for screen readers, review mobile responsiveness across devices, and check browser compatibility on mobile and desktop so the experience is consistent for website users.

Parachute builds to WCAG 2.2 Level AA, exceeding the commonly requested 2.1 AA and satisfying AODA web requirements for Ontario organizations. At Beta, Parachute issues a Technical Accessibility Conformance Statement confirming the delivered templates’ technical conformance. A formal third-party ACR or VPAT is a separate engagement through Deque.

Parachute does not use accessibility overlay products. They do not produce genuine conformance and have been rejected in legal proceedings. Build the conformance in and verify it by hand.

Privacy, cookies and consent

Eight checks, and this is the section almost no published launch checklist covers.

Configuring a consent banner is not the same as verifying it works. The accessibility test that matters is whether Consent Mode’s default state fires before the consent platform updates it, on a cold load, in a clean browser profile. If the default command arrives after your analytics tag, the tag has already fired unconsented, and the banner is decorative.

Read the dataLayer directly on a cache-busted load and confirm the default state. On a correctly configured site, you will see six storage types denied by default and one granted:

Storage type	Default
ad_storage	denied
ad_user_data	denied
ad_personalization	denied
analytics_storage	denied
functionality_storage	denied
personalization_storage	denied
security_storage	granted

security_storage staying granted is correct and intended. It covers fraud prevention and authentication, and Google’s own guidance is to leave it granted. A checklist that tells you to deny all seven is wrong, and it is a common error. Top websites still show over 51 million accessibility errors, which is why automated scans are only a starting point.

Test the rejection path and the preference centre, not just acceptance. Confirm the choice persists, and confirm a later change of mind takes effect. One caveat on method: if your browser already carries a consent cookie from an earlier visit, you will see a consent update follow the default in the same page load. A true first-visit test needs a clean profile. Also confirm your legal pages link correctly in the banner or preferences area so users can easily review privacy details. When you test keyboard navigation, check interactive elements with keyboard access and screen readers, too. Check menus and modals across different devices and mobile devices, because mobile responsiveness means the interface adapts to different browser settings automatically. Finally, check browser compatibility so accessibility and functionality stay consistent across major browsers.

Phase 2: Checks specific to your launch type

After the universal checks, add the sheet matching what you are actually doing. The three types carry very different risk.

Same-domain rebuild

Twenty additional checks. The lowest-risk launch type, because the domain, the Search Console history and usually the URLs all survive.

The work concentrates on continuity. Confirm whether URLs and permalink patterns change at all; if they do, keep the replacement structure clean and SEO-friendly for indexing, as part of your basic settings. Inventory anything whose URL will change. Confirm unchanged URLs still return HTTP 200 after deployment. Preserve live orders, form entries, memberships and comments, since the production database holds real data that staging does not. Before deployment, review WordPress core, themes, and plugins and update any outdated software. Also remove unused plugins and themes, because even on a same-domain rebuild they increase risk and add unnecessary weight—delete unused plugins rather than carrying them over. Confirm analytics continuity with no duplicate tracking, and confirm Search Console ownership survives the deployment.

Domain or URL migration

Forty-five additional checks, and this is where a launch can lose a year of search performance in an afternoon.

The redirect map is the whole job. Build it from more than one source, because no single source is complete:

• A full crawl of the current live site
• Indexed URLs exported from Google Search Console
• Landing pages exported from analytics
• Backlink destination URLs
• Paid campaign destination URLs

Map one-to-one wherever a direct equivalent exists. Write group rules only where a genuine pattern exists, and a group rule makes the list shorter and easier to maintain. Avoid redirect chains, and never write a broad rule sending everything to the homepage. A redirect to the homepage tells Google the old page is gone, and its replacement is unrelated, which throws away whatever that URL had earned.

A worked example. On a law firm migration, Parachute mapped and redirected more than 7,000 URLs. Most went one-to-one. Where a real pattern existed, the team wrote group redirects instead, which shortened the list and made it maintainable rather than leaving several thousand individual rules for someone to inherit.

The complication was one nobody could crawl their way out of. The firm had legacy redirects dating back fifteen years living on an old server, and the previous agency wouldn’t grant access. Those URLs appeared in no crawl, no export and no sitemap. They were invisible until someone requested one.

The answer wasn’t to find them before launch, because that wasn’t possible. It was to catch them the moment they surfaced. Parachute ran a full production crawl immediately on launch day and monitored 404s in real time as traffic hit the new site. The missing legacy URLs appeared within hours as live 404s, and the team wrote those redirects the same day.

That is the useful lesson. Some information is genuinely unavailable before a launch. Plan for discovery rather than assuming your pre-launch inventory is complete, and staff launch day so somebody is watching 404s as they happen instead of reading about them in a report next week.

The rest of the migration section covers DNS readiness: export the full zone, document every record type, lower TTL in advance, protect email records from accidental changes, and record previous DNS values so you can roll back. Provision the SSL certificate for both apex and www before cutover, not after. Before launch, review WordPress core, themes, and plugins for outdated software. Delete unused plugins instead of only deactivating them, because they still create avoidable maintenance and security risk.

Multilingual

Fifty-seven additional checks covering Multisite architecture, network configuration, the publishing workflow, the language switcher, international SEO, and network-wide QA.

Parachute builds multi-language on WordPress Multisite. Multisite gives better content variance control per language and a stronger URL structure for search than a plugin-based approach, and it keeps each language a first-class site rather than a translation layer over one.

The international SEO checks are Critical in full. Set the HTML lang attribute on every language version. Implement reciprocal hreflang annotations using valid language or region codes, include an x-default where appropriate, and confirm every hreflang target is canonical, indexable and returns HTTP 200. Use self-referencing canonicals per localized page, and never let a canonical collapse two distinct language pages into one.

One thing to avoid: automatic redirects based only on IP address or browser language. They trap users who want a different language than the one you guessed, and they prevent search engines from crawling the versions they cannot reach.

Phase 3: Launch day

Forty-four checks, and this sheet is a runbook rather than a list. Work it top to bottom in order.

It opens with a go/no-go decision based on evidence, not confidence. Confirm every Critical item is Complete or explicitly marked not applicable. Confirm the client has approved and the content freeze is in force. Review the known issues and the rollback criteria out loud. Record the launch start time. Take final backups of the database, files, and hosting, and confirm a backup solution is in place (e.g., a WordPress backup plugin), because backup plugins are essential for data recovery; write down the timestamp.

Name the rollback decision-maker before you start, not during the incident. Use strong, unique passwords and two-factor authentication for WordPress admin access before launch.

Deployment follows: deploy the release, run database migrations or safe URL replacements, update production environment variables and API keys, flush permalinks, and clear every cache layer, including application, object, server, CDN and browser. Warm the critical pages. Record the deployment completion time and the release identifier.

Then run the live smoke test, logged out, on the real production site. Load the homepage and priority landing pages. Test navigation on desktop and mobile. Submit a primary form and verify every destination it should reach. Check the browser console and the server logs. Essential WordPress plugins should already be active to extend site features, and security plugins should be configured before traffic hits the live site, especially since websites face an average of 94 attacks daily. Confirm no staging banner, basic authentication prompt or maintenance page survived the deployment.

The search and measurement block closes the window. Remove any production noindex. Verify robots.txt, canonicals, sitemap and structured data on live URLs. Test the redirects. Verify GA4 Realtime is receiving data and the correct GTM container is in production mode. Trigger a primary conversion and confirm it registers. Submit the production sitemap. Annotate the launch in your reporting so that every chart you read for the next year has the date marked on it.

Phase 4: After launch

Thirty checks in the first 72 hours, then reviews at 7, 30 and 60 days. This is the phase almost every published launch checklist omits entirely, and it is where the expensive problems surface.

First 24 hours. Run an external uptime check. Review hosting, PHP, application and JavaScript errors. Check 4xx and 5xx responses. Check site speed on live pages, because Google recommends load times under 3 seconds. Retest the primary forms, transactional email and CRM delivery, since a form that worked on staging can fail on production for reasons that have nothing to do with the form. If you have an online store, test the live purchase flow and make sure the returns policy is easy to find, since awkward returns policies can drive abandonment. Confirm Search Console has the property and the sitemap. Crawl the priority pages and a sample of redirects.

24 to 72 hours. Run a full production crawl and compare the counts against your approved site inventory. A crawl that returns fewer URLs than you expected is telling you something. Review redirect chains, loops and unexpected destinations. Check new 404s and soft 404s, which is where undiscovered legacy URLs show up. Review the live site again on mobile, because over 60% of online traffic now comes from mobile users and a slow site can hide issues desktop checks miss. Review server logs for bot errors, since Googlebot may see responses your browser doesn’t.

7 days. Review Search Console indexing, exclusions, crawl stats and enhancements. Confirm sitemap processing. Reconcile key conversions against CRM or form records rather than trusting the analytics number on its own. Review consent rates and tag behaviour. Confirm redirect coverage for any legacy URLs discovered since launch.

30 and 60 days. Review organic traffic, rankings, landing pages and conversions against the pre-launch baseline. Review redirects and legacy URL hits. Confirm long-term redirects remain in place, and keep them. For migrations, retain redirects long term and keep monitoring beyond the 60-day review while risk remains.

One measurement note that matters more than it looks. When you are watching whether search has recovered after a launch, watch Days Since Last Crawled in Search Console, not coverage state. Crawl frequency moves first. Coverage state is a lagging indicator, and it can sit unchanged for weeks while the underlying situation is already improving or already deteriorating.

Phase 5: Handoff

Twenty-eight checks, and this is where a launch becomes a working relationship or an unresolved mess.

Transfer or confirm ownership of every account: hosting, domain, DNS, CDN, SSL, analytics, Search Console, tag manager, consent platform, email, CRM and any other third-party service. Confirm multi-factor authentication and recovery contacts on each one. Remove temporary agency or contractor accounts that are no longer needed. Store credentials in an agreed secure system, never in the checklist workbook itself. This should also include access to connected social media platforms and any tools that support social sharing functionality.

Provide the documentation that makes the site maintainable by someone who did not build it: architecture and hosting overview, deployment and rollback procedures, the redirect map and migration records, analytics event and conversion definitions, consent configuration notes, and an honest list of known issues and accepted limitations. Include who owns post-launch monitoring and how user feedback will be collected and reviewed.

Then deliver training, and confirm it worked by having the client complete a representative publishing task rather than watching a demonstration. Parachute includes client training in every project as a standard deliverable. The goal is that a client can run their website well after launch without depending on the agency for every content change.

What most launch checklists get wrong

Three things, consistently.

They stop at launch day. The checklist ends with “announce it on social media” and hand over access to hosting, analytics, search tools, and any social media platforms the client owns as part of site operations. Everything genuinely expensive happens after that: the 404s from URLs nobody knew about, the conversions that stopped being recorded, the pages that were never indexed.

They treat consent as a plugin install. Installing a consent platform and verifying it gates anything are different activities. The verification takes ten minutes, and almost nobody does it.

They confuse configuration with verification. “Install an SEO plugin” is configuration, and so are basic seo settings. “Confirm every indexable page has a title tag, no page carries an accidental noindex, and the sitemap excludes redirected URLs” is verification. Only the second one tells you whether the launch worked, which is what actually supports a successful launch.

One more, specific to 2026: some launch checklists now recommend blocking AI crawlers in robots.txt as a default. Think about that one rather than adopting it. The crawlers that feed generative answers are increasingly how people find businesses, and blocking them removes you from those answers. Separate the crawlers that drive discovery from the ones that only scrape, decide deliberately, and write the rule you actually meant.

How Parachute runs a launch

Parachute Design has built custom WordPress websites since 2003 and deployed more than 400. For a new WordPress website, the checklist above is the working document, not an article summary, and the omissions below are what undermine a successful launch.

Launches are gated rather than scheduled. A WordPress site is ready when every Critical and High item is Complete or explicitly marked not applicable, the rollback plan is confirmed, and nothing is missing. Evidence is required against each check: a backup timestamp, a test URL, a report, a screenshot, a client approval.

A recent performance engagement shows what the pre-launch and post-launch performance checks produce when run. On the Patronscan platform, PageSpeed Insights performance scores moved from 54 to 98 on mobile and 63 to 100 on desktop across eleven days, measured from a baseline taken on September 4, 2026.

The field data tells a second story worth understanding. Patronscan already passed its Core Web Vitals assessment on real user data at the 54 and 63 baseline, and it still passed after the work, recording Largest Contentful Paint at 2.3 seconds on mobile and 1.4 seconds on desktop and Cumulative Layout Shift at 0 and 0.01 as of September 15, 2026. Lab scores and field assessments measure different things. A site can pass Core Web Vitals on real user data while its lab performance score sits in the fifties, which is exactly why the checklist asks you to review both rather than either one alone, because that discipline affects the site’s success.