WordPress specialist developer: what changes compared to a generalist.

Moving a production WordPress site is more than a backup and restore. You need to know how WordPress serialises URLs in the database, manage DNS TTL before propagation, flush and rebuild caching layers without leaving stale pages. One wrong step in sequence and the site goes down during peak hours.

A specialist has a protocol: search-replace on serialised data, checking for hardcoded options, staging tests before cutover. There is no improvisation. This reduces the risk of errors and makes the process faster to run and easier to delegate.

The typical response to a plugin conflict is to disable one and find an alternative. That works on simple sites. On structured projects — where every plugin is there for a reason — replacement isn't an option. You need to understand which hook they're colliding on, who has priority, and whether you can resolve it with a custom filter.

Diagnosing a WordPress conflict requires knowing plugin load order, the hook and filter system, and how to isolate the problem without breaking the rest of the build. A generalist can do it; a specialist does it in a fraction of the time.

ACF, custom post types, and meta queries are standard on any reasonably structured agency project. Writing WordPress queries that scale requires deep knowledge of WP_Query: when to use meta_query, when a direct SQL query is better, how to use the object cache to avoid repeated database round-trips.

A generalist produces working code. A specialist produces working code that doesn't degrade when the site grows from a hundred to ten thousand posts. On an e-commerce site or a content-heavy portal, the difference shows in load times before the client even asks for an audit.

Any developer can open Lighthouse. Knowing what to look at after is a different matter. On WordPress the most common bottlenecks are platform-specific: render-blocking theme CSS, filters on the_content that inflate markup, synchronously loaded scripts from form plugins, unoptimised images because wp_get_attachment_image isn't being used correctly.

A specialist arrives with a diagnostic framework already in place: they know that on certain builders LCP depends on how hero images are loaded, that certain cache plugins break native lazy loading. The diagnosis is faster and the fixes are more precise.

The worst time to bring in a specialist is halfway through a project, after a generalist has already built the architecture. Getting up to speed on someone else's codebase, understanding the decisions made, and correcting them without breaking the rest costs more than starting with the right person from day one.

This isn't a criticism of generalists — it's the structure of the problem. Every developer optimises for what they know. If the project requires WordPress-specific skills, involving a specialist from the start is almost always cheaper than involving them after.

The most useful questions aren't about years of experience. They're about concrete situations: have you handled a zero-downtime migration? How do you resolve a plugin conflict on a shared hook? Have you worked with ACF on multi-post-type architectures? Vague or generic answers already tell you something.

A good indicator is also how they describe past mistakes. Someone who has resolved specific WordPress problems remembers them in detail — the type of problem, what they tried first, what worked. Someone who has only grazed the surface tends to generalise.