WordPress Theme Launch Checklist — My Complete Pre-launch Process

This WordPress theme launch checklist covers the final checks I run before handing a custom site to a client.

Every custom theme I have launched has produced the same category of last-minute problems: not broken features, but missing details. A favicon is absent. An ACF field renders an empty wrapper. A mobile menu works on five templates and fails on the sixth because that page uses a different header partial. The theme may be technically complete, but launch day exposes the details that were easy to miss while building the larger system.

The answer is not memory. The answer is a repeatable WordPress theme launch checklist that catches the small omissions before a client, customer, or search crawler finds them first.

WordPress Theme Launch Checklist: Performance Checks

The first pass in my WordPress theme launch checklist is performance, because performance debt spreads through templates quickly. I verify every registered image size and make sure each template calls a deliberate size through wp_get_attachment_image() or the_post_thumbnail(). A card component should not serve a full 5000-pixel upload. A hero should not lazy-load if it is the likely LCP element. Every image needs width and height attributes to reduce layout shift.

add_action( after_setup_theme, function () {
    add_image_size( card, 400, 300, true );
    add_image_size( hero, 1600, 900, true );
    add_image_size( content-width, 800, 0, false );
} );

I also check scripts and styles. Contact form JavaScript should not load on the homepage if the homepage has no form. Slider assets should not load on posts with no slider. Block styles should be dequeued when a classic custom theme does not use core blocks on the front end. For reusable implementation details, my defer WordPress scripts snippet and WordPress responsive images snippet cover two checks from this section.

WordPress Theme Launch Checklist: Security Checks

The security section of the WordPress theme launch checklist is an escaping audit. I search the theme for echo, get_field(), the_field(), get_post_meta(), and get_option(). Every dynamic value needs the right escaping function: esc_html() for text, esc_url() for URLs, esc_attr() for attributes, and wp_kses_post() for trusted rich text.

$heading  = esc_html( get_field( hero_heading ) );
$subtitle = wp_kses_post( get_field( hero_subtitle ) );
$cta_url  = esc_url( get_field( hero_cta_url ) );

Any handler that modifies data needs a capability check and a nonce. AJAX handlers, settings forms, importer tools, and contact forms should all prove the request is intentional. I also search for debugging leftovers: var_dump, print_r, and temporary error_log calls. A theme can look perfect and still leak internal data into source or logs if those checks are skipped.

WordPress Theme Launch Checklist: Content Integrity

Content integrity is where many launches look unfinished. I search for placeholder strings such as “Lorem ipsum”, “Sample title”, and “Your heading here”. I test empty ACF fields and repeaters. If a section has no content, it should collapse gracefully. If a hero title is missing, it should fall back to the page title or disappear by design.

This part of the WordPress theme launch checklist includes the 404 page, search results, archive templates, and any custom post type templates. These pages are easy to ignore because they are not the homepage, but visitors and search engines still hit them. The navigation must work, the page title must be useful, and the path back into the site must be obvious.

WordPress Theme Launch Checklist: SEO and Sharing

Before launch, I verify that every important page has a unique SEO title, a concise meta description, a canonical URL, and an Open Graph image. I confirm XML sitemaps are enabled and that robots.txt is not blocking crawlers. On staging sites, “Discourage search engines” is often enabled during development; on production, it must be off.

I also test social previews. A shared article without an image looks unfinished, and a shared project page with the wrong title weakens the portfolio signal. The official WordPress theme developer handbook is the reference I use for theme standards, while live examples from my WordPress developer portfolio show the checklist applied to real client work.

WordPress Theme Launch Checklist: Client Handoff

The final section of the WordPress theme launch checklist is handoff. I confirm admin labels make sense, ACF field instructions are clear, required fields are actually required, and the editor can update key content without touching code. A client should not need to guess which image ratio belongs in a card or which field controls the call-to-action text.

I check favicon and touch icons, footer copyright year, contact form delivery, analytics, backups, caching, and redirects from old URLs. If the site is a migration, I test the old high-value URLs directly. Redirect mistakes are expensive because Google finds them quickly and users find them immediately.

WordPress Theme Launch Checklist: Accessibility Checks

Accessibility belongs in the same WordPress theme launch checklist, not in a separate someday document. I test keyboard navigation first because it exposes structural problems quickly. The menu must open, close, and move focus predictably. Modal windows must trap focus while open and return focus to the triggering button when closed. Skip links should appear on focus and jump to the main content area.

I also check colour contrast, form labels, visible focus states, and heading order. A beautiful page with three skipped heading levels is harder for assistive technology to navigate. A contact form with placeholder-only labels becomes confusing as soon as the visitor starts typing. These are not edge cases. They are normal use cases, and they are cheaper to correct before launch than after a client receives complaints.

WordPress Theme Launch Checklist: Production Domain QA

The final production pass is where staging assumptions get tested. I open the live domain before DNS is widely announced and verify SSL, mixed content, canonical URLs, sitemap URLs, robots settings, analytics, form delivery, and cache headers. A staging-to-production search replace can miss serialized data, hardcoded image URLs, or Open Graph image paths. Those errors rarely show in a local browser because the assets are cached or still reachable on the development domain.

This is also where I test redirects. If an old services page moved, the old URL should land on the new page with a permanent redirect. If a project URL changed, the old case study link should still resolve. Redirect checks protect search equity and prevent visitors from landing on a 404 immediately after launch.

Engineering Takeaway

A WordPress theme launch checklist is not a sign of inexperience. It is the recognition that launch work contains dozens of small decisions, and memory is not a reliable QA system after weeks of development. The checklist absorbs that risk. Every time something reaches production that should have been caught earlier, it becomes a new checklist item.

Treat the checklist as part of the deliverable. Run it on staging, then run the critical checks again on the production domain before announcing the launch.

I also record who approved the launch, which redirects were tested, and which forms were submitted successfully, so the handoff has a clear QA trail today.

A WordPress theme launch checklist should keep evolving after launch. Every missed redirect, broken form, slow template, or unclear admin field becomes a new QA item for the next build.