WordPress Development

First we get read access to the existing site and run a baseline. Lighthouse on three real product or article URLs, Query Monitor in the admin, a fresh staging copy on our infrastructure, and the output of wp plugin list --status=active so we know exactly what's installed. Around 30% of the WordPress sites we inherit have core file edits, an abandoned child theme, or plugins where the active version on disk doesn't match what's on the WordPress.org repository. Before we touch anything, we write down what's there.

The build phase runs in two-week sprints. Each sprint starts with a kickoff call, ends with a review on staging, and we keep tickets in Linear synced with whatever the client uses. For a custom theme we work block-first: register the blocks the editorial team actually needs in theme.json, build them with @wordpress/scripts, and avoid ACF for anything where native Gutenberg blocks already do the job. ACF still earns its place for repeating content types and option pages, but layout shouldn't live in custom field groups anymore.

Deploys go out via Git push to a staging branch, manual review on staging.client.com, then a tagged release that triggers production. We don't use the WordPress admin to ship code, ever. Database changes go via WP-CLI migration scripts checked into the repo. After launch you get a runbook, staging credentials, and a calendar of when the next core or plugin updates need testing.

The most common failure on a WordPress site we inherit is a plugin conflict that only shows up on a real customer's checkout. We've watched Yoast SEO plus WPML plus WooCommerce produce a 500 error on Polish-language product pages and nowhere else. The fix is boring: we keep a copy of the production database refreshed weekly, replay actual customer journeys on staging, and keep WPML pinned within one minor version of WooCommerce. If you're running 10 or more active plugins you need a staging environment that mirrors production, not a local install seeded with sample data.

The second one is page builders. If the previous developer built the site in Elementor or Divi and you want a custom theme, we don't migrate page by page. We rebuild templates from scratch in Gutenberg, then run a content migration script to move the body copy across. Trying to preserve a Divi layout inside a custom theme is a six-week trap, and we'll tell you that on the first call before quoting anything.

The third one is managed WordPress hosting. WP Engine, Kinsta, and Pressable cache aggressively, and a theme that works fine on cheap shared hosting can break on a managed host because of edge cache rules around logged-in cookies. Before we migrate hosting we test cache rules against actual user flows, especially logged-in WooCommerce sessions where a misconfigured cookie pattern can serve customer A's cart to customer B.