Hire WordPress developers

WordPress runs a very large share of the web, and the range of what a WordPress developer can be varies more than in any other technology on this list.

What WordPress actually is

WordPress is an open-source content management system written in PHP, originally for blogging and now used for everything from small brochure sites to large publishing platforms and commerce stores. Its market share is larger than any competing system by a wide margin, which means an enormous ecosystem of themes and plugins and an enormous range of quality within it.

Its defining characteristic is extensibility through hooks: plugins and themes attach behaviour to events in the core lifecycle without modifying core itself. That is why so much functionality exists as a plugin and why a WordPress site can be assembled rather than built. It is also why WordPress sites degrade the way they do, accumulating plugins over years until nobody can say what any of them does.

For hiring, the practical problem is that the title covers at least three different jobs. Configuring a site from existing themes and plugins is one. Building custom themes and plugins properly, with attention to security and performance, is another. Operating WordPress at serious scale, with caching layers, custom infrastructure and a headless front end, is a third. All three call themselves WordPress developers and the gap between the first and the third is enormous.

The part that separates seniors from mid-levels

Hooks are the core mechanism and the first thing to test. Actions let code run at a point in the lifecycle; filters let code modify a value passing through. Understanding the difference, knowing execution order and priority, and knowing how to find which hook fires when is what separates someone who extends WordPress properly from someone who modifies core files or overrides templates by copying them wholesale. The second approach works and cannot be updated safely.

The database structure is the second area, and it explains most WordPress performance problems. Content lives in a posts table with arbitrary metadata in a key-value table alongside it. That design is flexible and it means queries filtering by metadata are expensive, because the database cannot index the data the way a purpose-built schema would. Sites that slow down as they grow are usually doing exactly this, and a developer who understands why can fix it.

Security is the third, and it is not optional given WordPress's position as one of the most attacked surfaces on the internet. The vulnerabilities are rarely in core, which is well maintained; they are in plugins, in file permissions, and in code that trusts input. Capability checks, nonces on state-changing requests, prepared statements and proper escaping on output are the basics, and their absence is the most common serious finding in a WordPress audit.

Where WordPress is used

The label “WordPress developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Marketing and brochure sites

The largest category by volume, where the work is design implementation and editorial workflow.

Publishing and media

Content-heavy sites with editorial teams, where performance and workflow matter and scale is real.

Commerce through WooCommerce

Stores built on the commerce plugin, which is a substantially different technical problem from content.

Membership and learning platforms

Gated content and courses, typically assembled from several plugins that must be kept compatible.

Headless implementations

WordPress as a content back end with a separate front end, keeping the editorial interface while replacing the presentation layer.

Multisite networks

Many sites on one installation, common in universities, franchises and publishers.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Which WordPress versions are still supported

WordPress releases regularly and back-ports security fixes to older lines for a long time, but plugin and theme compatibility is what actually determines whether a site can be kept current.

The table is generated from public release data rather than written by hand, so it states what is supported today rather than what was true when any given article was published. Of the 8 most recent release lines, 1 are still maintained and 7 have passed their published end-of-life date. That distinction is the practical one when you read a job specification: a requirement written against a line that is now out of support tells you the specification is older than the codebase it describes, and it is worth asking which of the two the new developer will actually work in.

Source: endoflife.date public release data, read 2026-09-25.

Two questions follow from this table in an interview. The first is which line the candidate has most recently shipped against, because someone whose last production work was on an unsupported line has not had to deal with the changes since. The second is how they have handled an upgrade. Version migrations are where you see whether a developer reads release notes, writes characterisation tests before changing anything, and knows how to stage a rollout, or whether they upgrade in place on a Friday and hope.

The toolchain around it

Nobody hires for WordPress alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

PHP

The language underneath. Depth here is what separates a builder from an assembler.

MySQL or MariaDB

The data store, whose structure explains most WordPress performance behaviour.

The block editor

The current editing experience, and custom block development is a distinct modern skill.

Advanced Custom Fields or similar

Structured content beyond the default post model, used on most serious builds.

WP-CLI

Command-line management, essential for anything automated or at scale.

Caching

Object and page caching, plus a CDN. The difference between a fast and a slow WordPress site.

Composer and a build step

Modern dependency and asset management, and a reasonable indicator of professional practice.

A staging environment

Somewhere to test updates, whose absence tells you how the site has been maintained.

Related skills that frequently appear on the same specification: PHP, JavaScript, MySQL, WooCommerce, Drupal.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Actions versus filters

The core extension mechanism, and a quick test of whether someone extends or hacks.

• Strong answer: Explains the difference, discusses priority and ordering, and can describe finding the right hook for a requirement.
• Warning sign: Modifies core or plugin files directly, or copies templates wholesale to change one line.

Security practice

WordPress is heavily attacked and most vulnerabilities come from custom and third-party code.

• Strong answer: Capability checks, nonces, prepared statements, escaping on output, and an opinion about plugin selection.
• Warning sign: Trusts input from forms, or treats security as the host's responsibility.

Performance and the metadata problem

Explains why WordPress sites slow down as they grow.

• Strong answer: Understands why metadata queries are expensive, uses caching properly, and has profiled a slow site.
• Warning sign: Installs a caching plugin and considers performance addressed.

Plugin selection and maintenance

The main long-term risk in any WordPress site.

• Strong answer: Evaluates plugins for maintenance status and code quality, keeps the count low, and has removed plugins.
• Warning sign: Installs a plugin for every requirement without evaluating what it brings.

Custom blocks

The clearest test of whether their knowledge is current.

• Strong answer: Has built custom blocks and understands the modern editing model.
• Warning sign: Works only with the older editor and shortcodes, which places their experience several years back.

Update and maintenance approach

WordPress sites fail through neglect more than through anything else.

• Strong answer: Staging environment, tested updates, version control, and a backup they have actually restored.
• Warning sign: Updates in production, or avoids updating because something broke once.

When WordPress is the wrong tool

Tests judgement rather than loyalty.

• Strong answer: Can describe applications where a framework would serve better, and has said so to a client.
• Warning sign: Treats WordPress as suitable for everything.

Warning signs in a WordPress codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

Modified core or plugin files

• What you see: Changes made directly inside core or a third-party plugin.
• What it costs: Every update either reverts the change or is avoided, leaving the site unpatched on a heavily attacked platform.
• The fix: Use hooks and filters. Where a plugin offers no hook, fork it deliberately and track the fork, or replace it.

Plugin accumulation

• What you see: Dozens of plugins, several unused, some unmaintained for years.
• What it costs: A wide vulnerability surface, conflicting behaviour, and performance nobody can attribute.
• The fix: Audit what is active and needed. Remove rather than deactivate, and require justification for additions.

Unescaped output

• What you see: Values echoed into templates without escaping.
• What it costs: Cross-site scripting, which remains one of the most common WordPress findings.
• The fix: Escape on output with the function appropriate to the context. Treat every dynamic value as untrusted.

Expensive metadata queries

• What you see: Queries filtering or sorting by post metadata on large datasets.
• What it costs: Page loads measured in seconds, degrading as content grows.
• The fix: Use taxonomies where the data is categorical, cache aggressively, or move genuinely relational data into its own table.

No staging or version control

• What you see: Changes made directly on production through the admin interface.
• What it costs: No way to test an update, no history, and no route back when something breaks.
• The fix: Put the theme and custom plugins in version control and stand up a staging environment. On a neglected site this is usually the honest first task, before anything on the original brief.

Page builders on complex sites

• What you see: A heavy visual builder used for a site with substantial custom requirements.
• What it costs: Bloated markup, poor performance, and content locked into a proprietary format that is painful to migrate.
• The fix: Use a builder for genuinely simple marketing pages where editors need autonomy. For anything with real custom requirements, build a theme with native blocks.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a WordPress developer.

Junior

Configures sites, implements designs in existing themes, and manages content. Needs review on anything touching security.

Mid-level

Builds custom themes and plugins, uses hooks correctly, and handles performance and updates responsibly.

Senior

Owns architecture: custom plugin structure, caching strategy, deployment pipeline and the plugin policy. Can operate WordPress at scale or headless.

Staff

Owns the platform across multiple sites, the security posture, editorial workflow at scale, and the decision about when WordPress should be replaced.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Marketing site build

• Usual team: One developer plus a designer.
• What governs it: Fast. Scoped by design complexity and by how much structured content modelling is needed.

Custom plugin development

• Usual team: One developer with real PHP depth.
• What governs it: This is application development inside WordPress and should be staffed as such.

Performance remediation

• Usual team: One senior developer, time-boxed.
• What governs it: Usually caching, plugin removal and metadata queries. Quick wins are common.

Headless implementation

• Usual team: One WordPress developer plus a front-end developer.
• What governs it: Two distinct skill sets. Editorial preview is usually the part that is underestimated.

Rescuing a neglected site

• Usual team: One senior developer.
• What governs it: Scoped by how far behind updates are and how much was customised by modifying files.

Migration work you may actually be hiring for

A large share of WordPress work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

The classic editor to the block editor

• Why teams do it: The classic experience is legacy and new functionality is built for blocks.
• What to watch: Content in shortcodes and page builders does not convert cleanly. Audit how content is actually stored first, because that determines whether this is a settings change or a content migration.

A page builder to native blocks

• Why teams do it: Lighter markup, better performance, and content no longer locked into a proprietary format.
• What to watch: Content is usually stored in the builder's own format, so this is a content migration rather than a theme change. Scope it per template and accept that some pages will need rebuilding.

Traditional WordPress to headless

• Why teams do it: A front end WordPress templating cannot deliver, or several channels consuming one content source.
• What to watch: Editorial preview is the thing teams miss most and underestimate hardest. Solve preview before committing, because without it editors lose a workflow they rely on.

An unmaintained site to a maintained one

• Why teams do it: An unpatched WordPress site on a heavily attacked platform is a question of when rather than whether.
• What to watch: Update in staging with backups, one major component at a time. Where core files have been modified, that has to be resolved first or every update undoes it.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a WordPress developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Whether the work is configuration, custom development, or operating at scale. These are three different hires.
• Whether the site uses the block editor, the classic editor, or a page builder.
• Whether WooCommerce is involved, since commerce is a distinct and substantially harder problem.
• Whether version control and a staging environment exist, because their absence changes the job.
• How many plugins are active and whether anyone has audited them.
• Whether the site is headless or may become so, which requires a different skill set.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

WordPress work is counted by the US Bureau of Labor Statistics under Web Developers. That classification is broader than the technology itself, so treat the figures as the shape of the market a WordPress developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 70,190 people in this occupation, with a median annual wage of $92,650.

The spread matters more than the midpoint. The 90th percentile is about 3.4 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a WordPress developer can sit at $48,100 and $162,290 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for WordPress frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Web Developers, the gap between the highest and lowest of the 27 metro areas covered here is a factor of about 2.3. San Jose sits at the top with a median of $166,670; Portland sits at the bottom with $73,920. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. San Jose, Washington, D.C., Seattle, Portland each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

Site assembler hired as a developer. Ask what they have built rather than what they have configured. The gap is the widest in this field.

No security practice. Ask about nonces and escaping. WordPress is too exposed for this to be optional.

Outdated editor experience. Ask about custom blocks. Experience predating the block editor is common and is a real gap.

No PHP depth. Matters as soon as the requirement exceeds what a plugin provides, which on any serious project it will.

Hiring WordPress developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of WordPress developer who will be available.

• New York, NY $104,820 median
• Seattle, WA $130,440 median
• San Jose, CA $166,670 median
• Washington, D.C. $134,350 median
• San Francisco, CA $152,450 median
• Dallas-Fort Worth, TX $96,740 median
• Los Angeles, CA $107,290 median
• Boston, MA $108,520 median
• Chicago, IL $96,870 median
• Atlanta, GA $93,590 median
• Austin, TX $84,960 median
• Phoenix, AZ $76,230 median
• Philadelphia, PA $94,570 median
• Minneapolis-St. Paul, MN $106,890 median
• Denver, CO $92,060 median
• Detroit, MI $108,550 median
• Houston, TX $89,040 median
• Charlotte, NC $101,980 median
• San Diego, CA $98,300 median
• Salt Lake City, UT $88,770 median
• Miami, FL
• Portland, OR $73,920 median
• Baltimore, MD $107,590 median
• Tampa, FL $78,910 median
• Orlando, FL $83,820 median
• Raleigh, NC $82,250 median
• Kansas City, MO $89,420 median
• Pittsburgh, PA $82,560 median

Frequently asked questions

Is WordPress a serious platform for a business site?

Yes, and a great deal of serious publishing runs on it. Its weaknesses are usually self-inflicted: too many plugins, no maintenance, and code that modifies rather than extends. Well built and maintained, it is fast, secure and pleasant for editors, which is the thing it does better than almost anything else.

How do we tell a WordPress developer from a WordPress configurator?

Ask what they have built rather than what they have used. Someone who has written custom plugins and themes, uses hooks properly and has a view on security is a developer. Someone whose experience is selecting and configuring themes and plugins is doing a legitimate but different job, and the distinction should be in the brief rather than discovered in month two.

Why is our WordPress site slow?

Usually one of three things: no object or page caching, too many plugins running on every request, or expensive metadata queries as content has grown. All three are diagnosable in a morning by someone who knows where to look, and the fixes are usually structural rather than exotic. Installing another caching plugin is rarely the answer.

How many plugins is too many?

There is no number, and the useful questions are whether each is maintained, whether it runs on every request, and whether anyone can say what it does. A site with fifteen well-chosen plugins can be faster and safer than one with six badly chosen ones. What matters is that somebody has made a decision about each rather than accumulating them.

Should we go headless?

If you need a front end WordPress's templating cannot deliver, or you are serving several channels from one content source, it is a reasonable choice. It costs you a great deal of what makes WordPress pleasant, particularly preview and the immediacy of editing, and those matter a lot to editorial teams. Do it for a specific reason, not for modernity.

Is WordPress secure?

Core is well maintained and patched quickly. The vulnerabilities are overwhelmingly in plugins, in themes, and in custom code that trusts input. The site's security is therefore mostly a function of what you installed and how it was built, plus whether updates are actually applied. Sites that are neglected get compromised; sites that are maintained largely do not.

WordPress or a framework like Laravel?

WordPress when content and editorial workflow are central and the requirements are broadly those of a content site. A framework when the product is an application with complex business rules, where WordPress's content model becomes something you fight. The decision usually comes down to whether non-technical people need to manage content, which WordPress does better than any framework will without substantial work.

What does a WordPress developer need from us on day one?

A staging environment, access to the code in version control rather than only through the admin interface, and a list of what the site depends on. Many WordPress sites have none of these, and establishing them is often the honest first task rather than anything on the original brief.