How to Hire a WordPress Developer: What to Look For in 2026

Most WordPress Developers Will Say Yes to Everything in the Interview

That’s the first thing you should know going in. Ask a developer if they’ve worked with WooCommerce — yes. Custom post types — of course. REST API — absolutely. The answers are almost meaningless because the bar for “worked with” is so low it’s underground. Someone who copy-pasted a Stack Overflow snippet into a functions.php file has technically “worked with” the WordPress hook system.

So this post isn’t really about what questions to ask. It’s about what to look for underneath the answers — the signals that tell you whether you’re talking to someone who understands WordPress or someone who has learned to sound like they do.

What Skills Actually Matter in 2026

WordPress has changed a lot in the last few years, and not all developers have kept up. The block editor (Gutenberg) is no longer optional — it’s the default experience for every new site, and the Full Site Editing (FSE) workflow is now mature enough that clients expect it. A developer who’s still routing every project through a page builder from 2019 isn’t necessarily bad, but they’re working against the grain of where the platform is going.

Here’s what a capable WordPress developer should be solid on in 2026:

• Custom block development — not just using existing blocks, but registering custom ones with register_block_type() and building block.json configurations
• The hook system — add_action(), add_filter(), priority handling, when to use each. This is the backbone of all WordPress customization.
• WooCommerce extension development — if e-commerce is in scope, this includes cart hooks, custom payment gateway integration, HPOS (High-Performance Order Storage) compatibility
• REST API and headless patterns — even for traditional sites, a developer who understands register_rest_route() and authentication patterns has a much better mental model of the platform
• Performance fundamentals — query optimization, object caching, understanding what WP_Query is actually doing, and when to avoid it entirely
• Security basics — nonce verification, capability checks, data sanitization with sanitize_text_field() / esc_html() / wp_kses(), prepared statements via $wpdb->prepare()

If you’re building something more complex — an SaaS product on WordPress, a multi-tenant setup, a headless frontend with a React or Vue layer — the requirements get narrower. At that level you need someone who has actually shipped a plugin with thousands of active installs, not someone who has made a few client sites.

The Code Quality Test Most Clients Skip

Ask for a sample of their WordPress plugin or theme code. Not a GitHub link to a forked repo — their own code they wrote themselves. Then look for these specific things.

Here’s an example of the kind of code that should concern you:

// Bad: Direct database query without preparation
function get_user_orders($user_id) {
    global $wpdb;
    $result = $wpdb->get_results("SELECT * FROM wp_posts WHERE post_author = " . $user_id);
    return $result;
}

That query is a SQL injection vulnerability. The developer skipped $wpdb->prepare(), which exists precisely for this purpose. It’s a small thing that reveals a lot — either they don’t know about it, or they know and don’t think it matters. Neither is good.

Here’s what the correct version looks like:

// Good: Prepared statement, proper data handling
function get_user_orders( int $user_id ): array {
    global $wpdb;
    $results = $wpdb->get_results(
        $wpdb->prepare(
            "SELECT ID, post_title, post_status FROM %i WHERE post_author = %d AND post_type = 'shop_order'",
            $wpdb->posts,
            $user_id
        ),
        ARRAY_A
    );
    return $results ?? [];
}

Notice the differences: prepared statement, typed parameter hint, only selecting needed columns, explicit return type, null coalescing. A non-technical reader can’t audit every line, but if you paste the “good” version into a conversation with a candidate and ask them to explain it, their comfort level will be immediately clear.

Red Flags That Are Easy to Miss

A developer who can’t explain why they used a specific hook — who just says “I googled it and it worked” — is going to cost you money eventually. WordPress has hundreds of action and filter hooks, and knowing which one to reach for, and why, is the difference between a clean solution and one that breaks during a core update.

Other things to watch for:

• Everything is in functions.php. A sign they don’t understand plugin architecture or separation of concerns. Custom functionality belongs in a plugin, not the theme, so it survives theme switches.
• They recommend a plugin for everything. Real WordPress developers write code. If the answer to every requirement is “there’s a plugin for that,” you’re going to end up with a 40-plugin site that nobody can maintain.
• They’ve never pushed a plugin to the WordPress.org repository. This isn’t required, but developers who have been through that review process have had their code scrutinized against WordPress coding standards. It shows.
• Vague answers about performance. Ask them what they do when a site is slow. If they say “install a caching plugin,” that’s the floor, not the ceiling. A good developer will talk about slow queries, get_posts() vs WP_Query, unnecessary wp_head scripts, reducing database calls in loops.
• They’ve never heard of WP_CLI. It’s the command-line interface for WordPress. Any developer doing serious WordPress work uses it constantly — for migrations, database operations, running cron jobs, updating plugins across environments. If they look blank when you mention it, that’s a signal.

Interview Questions Worth Asking

These aren’t trivia questions. They’re designed to surface how someone thinks about problems, not just what they’ve memorized.

1. “Walk me through how you’d build a custom post type with a custom taxonomy and expose it via the REST API.” — This touches registration, query integration, and API exposure. A strong developer can sketch this in under two minutes.
2. “A client’s WooCommerce checkout page is loading in 8 seconds. Where do you start?” — Listen for: Query Monitor, slow query log, dequeuing unnecessary scripts, plugin conflict testing. Anyone who jumps straight to “buy a faster host” isn’t debugging the problem.
3. “How do you handle WordPress multisite? Have you worked with it?” — Multisite is complex. If they have experience, they’ll have opinions (often frustrated ones) about network admin vs. site admin, shared tables, domain mapping. If they haven’t used it, that’s fine — but they should know it exists and what it’s for.
4. “What does wp_localize_script() do and when do you use it?” — This is a very specific function that passes PHP data to JavaScript. A developer who knows it has written real JavaScript integrations. A developer who doesn’t has probably been copying frontend code without understanding the WordPress data layer.
5. “How do you keep a plugin compatible with future WordPress updates?” — Good answers include: following WordPress Coding Standards, avoiding deprecated functions, using hooks instead of overriding core behavior, having a test suite, watching the core Trac for breaking changes.

Evaluating Portfolios Without Being Technical

Most portfolio sites show you screenshots of finished designs. That tells you almost nothing about the developer’s actual work — the design might be from a theme, a designer, or a client who supplied the mockups. What you want to see is the work underneath.

Ask specifically: “Which parts of this project did you build from scratch?” Then follow up: “What was the hardest technical problem you solved on this one?” The answer will quickly separate people who built something from people who assembled it.

If they’ve contributed to open source — even small patches to plugins — that’s worth weighting heavily. Open source contributions are public, reviewable, and show that other developers thought their code was worth merging. A plugin on WordPress.org with real active installs is the clearest signal of all: real users chose to install it and haven’t broken their sites.

For agencies or more complex projects, ask if you can see a staging environment and give you a brief walkthrough. A developer who can explain how the admin interface works, why they structured the data model a certain way, and what they’d do differently in hindsight — that’s someone who was deeply involved.

Pricing Models: Hourly, Project, or Retainer

There’s no universally correct answer, but there are better fits depending on your situation.

Hourly makes sense when the scope is unclear — you’re exploring what’s possible, or you’re doing ongoing work where the tasks change week to week. The risk is obvious: no ceiling on cost unless you set one explicitly. The upside is flexibility. Track hours closely, agree on a budget threshold where the developer pauses and checks in before continuing.

Fixed-price project works well when requirements are detailed and stable. The key word is detailed — a vague spec leads to scope disputes regardless of pricing model. Before agreeing to a fixed price, a good developer will ask a lot of clarifying questions. If they don’t, they’re either guessing or planning to charge for change orders. Fixed-price projects typically include a defined number of revision rounds. Get that in writing.

Retainer is the model that works best for ongoing maintenance, feature development, and the kind of relationship where you want someone who already knows your codebase. A retainer usually means a set number of hours per month at a slightly reduced rate in exchange for availability. It suits businesses where the site is a revenue-generating tool, not a static brochure. The thing nobody tells you: retainers require discipline on your end too. If you don’t have tasks queued up, those hours don’t roll over — you’re paying for availability, not just output.

On rates: WordPress developers range from $15/hr to $200+/hr depending on experience, location, and specialization. Rates on the very low end — platforms like Fiverr in the $5-$20 range — almost always indicate someone who is learning on your project. That’s fine if you have the time and tolerance to manage the quality gap. For anything business-critical, the $60-$120/hr range for an experienced independent developer gets you someone who can own the problem and solve it without hand-holding.

Where to Actually Find Good WordPress Developers

The best developers aren’t actively browsing job boards. They get most of their work through referrals and reputation. But if you’re starting from zero:

• WordPress.org forums and Slack communities — developers who answer support questions publicly are demonstrating their knowledge in real time. Watch how they explain things.
• GitHub — search for WordPress-related repositories, look at who’s making meaningful commits to plugins you recognize
• Toptal — vetted, expensive, good signal-to-noise ratio
• Codeable — WordPress-specific marketplace, developers are screened
• X (Twitter) / LinkedIn — developers who write about WordPress publicly, share opinions about core changes, participate in WordCamps — those are the ones with genuine investment in the platform
• WordCamp speaker pages — anyone who has given a technical talk at a WordCamp is worth a look

One thing that’s worked well in hiring conversations I’ve been on the other side of: the clients who came in having actually read something I’d written, or who asked about a specific project in my portfolio, had a much better sense of fit before the first call even started. Do some research before you reach out. Developers notice.

The Part Nobody Wants to Talk About: Maintenance

WordPress core, plugins, and PHP itself update constantly. A site built well today will still need someone watching it six months from now. Outdated plugins are the most common vector for WordPress compromises — not exotic zero-days, just unpatched known vulnerabilities in plugins that site owners stopped updating because “the site was working fine.”

When you hire a developer, ask them upfront what they offer (or recommend) for ongoing maintenance. A developer who has no answer for this either hasn’t thought about it or is hoping you won’t ask. The answer doesn’t have to be “I’ll do it” — they might refer you to a managed hosting service or a maintenance agency — but they should have a position.

This is an unsolved problem in the WordPress ecosystem, honestly. There’s no great way to keep a complex site secure and performant without either paying for managed maintenance or having someone on your team who takes ownership of it. Don’t hire a developer, launch a site, and then assume the job is done. It isn’t.

If You’re Looking for Someone

I’ve been building on WordPress for a long time — plugins with real user bases, WooCommerce stores, headless setups, custom block editors, Laravel backends that talk to WordPress frontends. I work with clients remotely and I’m selective about what I take on, because I’d rather do fewer projects well than spread thin across too many.

If what’s described in this post matches what you’re looking for, my work is at this site/hire-me. No form to fill out — just a straightforward way to start a conversation.