Blog

Hiring a WordPress developer should be straightforward. You have a project, they have skills, you exchange money for work. In practice, it’s one of the most consistently botched purchases in small business — overpaying for the wrong person, underpaying for someone who disappears, ending up with a Frankenstein site cobbled together from page builders and abandoned plugins.

This guide is the result of being on both sides of that transaction many times. It covers where to actually find good developers in 2026, what to pay (with real numbers, not vague ranges), the questions that separate competent developers from confident ones, the red flags that should end the conversation, and how to run the project once you’ve hired.

If you’re about to spend money on WordPress development and you want it to go well, read this first.

---

TL;DR — The short version

• Decide what you actually need first: a freelancer for a small fix, an agency for a real project, or an in-house hire for ongoing work. The right answer depends on scope and timeline, not budget.
• Expect to pay $40–$80/hr for a competent freelancer, $80–$200/hr for an agency, and $4,000–$15,000+ for a full custom WordPress build with a good team. Anything substantially below these ranges is a warning sign.
• Ask to see real code, not just screenshots of finished sites. The screenshots tell you nothing about how the site is built underneath.
• Avoid anyone whose first answer to “how would you build this?” is the name of a page builder. The good ones ask questions before they answer.
• Get a written scope, fixed deliverables, and a payment schedule tied to milestones — not hours.

If you only had thirty seconds, that’s the article. The rest is detail.

---

Step 1: Decide what kind of WordPress developer you need

The single most common mistake is hiring the wrong type of person. There are four real options and they cost very different amounts:

A freelancer (individual developer). Best for: small fixes, single-feature additions, plugin customization, sites under $3,000 total budget. Typical hourly rate $40–$80. You’re trading lower cost for less project management — they write code, you handle planning, scope, and coordination.

A small agency or studio. Best for: full sites, complex builds, anything where you want someone else to manage the project. Typical project pricing $4,000–$25,000. You’re paying more per hour but getting designers, project managers, and developers as a coordinated team. For most business owners with a real website project, this is the right choice even though it feels expensive.

An in-house developer. Best for: companies with ongoing WordPress development needs (a SaaS built on WordPress, a busy WooCommerce store, a publisher with constant content infrastructure work). Cost $60k–$140k/year depending on location and seniority. Don’t hire in-house for a one-time project.

A “WordPress expert” on Fiverr or similar marketplace. Best for: very small, well-defined tasks (“install this plugin and configure these three settings”). Cost $20–$200 per task. Treat as transactional — don’t expect ongoing relationship or quality at the level of the first three options.

Be honest about which category fits. If you have a $15,000 e-commerce build in your head and a freelancer budget on paper, one of those numbers is wrong, and it’s almost always the budget.

Step 2: Where to actually find WordPress developers in 2026

Most “where to find WordPress developers” articles list the same five generic platforms. Here’s a more realistic version of what works in 2026, ranked by quality of who you’ll find:

Direct outreach to WordPress-specific agencies. The highest-quality option for projects of meaningful size. Search “WordPress agency [your city]” or “WordPress development agency”, visit 5–10 of their actual sites, and email the ones whose work you like. Quality agencies — like SiteMile, Human Made, 10up, rtCamp, and many others — work directly with clients and respond to inquiries. You’re going to spend more, but you’re also going to get a vetted team rather than a random stranger.

Codeable. A vetted WordPress-specific freelancer marketplace. The vetting is real — about 2% of applicants are accepted. Pricing is higher than Upwork but the quality floor is much higher.

The official WordPress.org “Find a Pro” directory. Underused. Lists vetted developers and agencies. Lower spam-to-signal ratio than general freelancer marketplaces.

WPMU DEV’s developer directory. Smaller than Codeable but solid for plugin and theme work.

Toptal. General-purpose top-tier freelancer platform. Has WordPress developers, expensive, vetting is real.

Upwork and Fiverr. Massive supply, very mixed quality. You can find good people here but you’ll spend significant time filtering. Best if you have time to interview many candidates and clear criteria for rejection.

LinkedIn. Good for senior developers and agency owners. Bad for cold-pitching small projects — you’ll get ghosted.

Reddit r/Wordpress, r/forhire, r/PHP. Hit or miss. Occasionally excellent freelancers post here looking for work. More often: low-effort posters.

WordPress meetups and WordCamps. Best for in-person hires and ongoing relationships. Worse if you need someone tomorrow.

For anything substantial — a real custom build, a serious WooCommerce store, a site you’ll rely on for revenue — start with the first three or four options. The marketplace platforms are fine for narrow tasks but they’re a poor primary channel for hiring someone you’ll trust with your business.

Step 3: Understand WordPress developer pricing in 2026

Honest pricing is hard to find online because everyone has an incentive to either undersell (“starting from $99!”) or oversell. Here’s what real pricing looks like in 2026:

Freelance hourly rates

Region	Junior	Mid-level	Senior
US/UK/Australia	$30–$50	$50–$100	$100–$200
Western/Northern Europe	$30–$60	$50–$90	$80–$150
Eastern Europe / Latin America	$20–$40	$30–$60	$60–$100
South/Southeast Asia	$15–$30	$25–$50	$40–$80

These are realistic 2026 ranges for working WordPress freelancers, not aspirational rates from “WordPress is dead, switch to Next.js” influencers. Anything dramatically below the bottom of these ranges is either inexperience, desperation, or fraud.

Agency project pricing

Rough ranges for full WordPress builds, including design and development:

• Brochure/business site (5–15 pages): $3,500–$12,000
• WooCommerce store (basic): $5,000–$20,000
• WooCommerce store (custom): $15,000–$60,000+
• Membership or LMS site: $8,000–$40,000
• Marketplace, auction, or classifieds site: $15,000–$80,000+
• Enterprise WordPress build (multisite, custom infrastructure): $50,000–$250,000+

These cover wide ranges because scope drives cost more than the WordPress part. A “simple” site with custom design, custom functionality, three integrations, and bilingual content is not actually simple.

What to expect at each price point

• Under $1,000: A page-builder template install with your logo dropped in. Acceptable for a minimum viable presence; will not scale.
• $1,000–$3,500: A polished theme install with light customization. Good freelancer territory. No custom design.
• $3,500–$10,000: Real custom design on top of a solid theme framework, light custom functionality. Small agency territory.
• $10,000–$25,000: Genuinely custom site, custom functionality, proper QA and project management.
• $25,000+: Complex builds, integrations, multi-language, performance work, accessibility audits.

If a quote is dramatically below these ranges for the scope described, the most likely explanations are: the work is being subcontracted to an unvetted developer overseas, corners are being cut on quality (no testing, no responsive design QA, no security review), or the quote will balloon mid-project as “out of scope” items appear.

Maintenance and ongoing costs

Often forgotten until after launch. Realistic numbers:

• Hosting: $20–$200/month for most sites; more for high-traffic or specialized hosting
• Maintenance plan: $50–$500/month depending on plan and site complexity
• Security and backup: Often included in maintenance, sometimes $20–$50/month standalone
• Plugin/theme licenses: $0–$2,000/year depending on what you use

A common mistake is budgeting only for the build and ignoring ongoing costs. If a site costs $8,000 to build, expect another $1,200–$3,600/year in operating costs minimum.

Step 4: Questions to ask before you hire

The interview matters more than the portfolio. Portfolios are easy to fake or cherry-pick. How someone answers technical and project questions reveals what they’ll actually be like to work with.

Technical questions

“Walk me through how you’d approach building [your project]. What questions would you need answered first?” A good developer asks questions before answering. A red-flag developer launches into a generic answer about “using WordPress and a theme.”

“What’s your approach when a plugin conflict breaks the site?” Looking for: methodical debugging process (deactivate plugins one at a time, check error logs, identify the conflict). Red flag: “I just try a different plugin.”

“How do you handle WordPress updates on client sites?” Looking for: staging environment, test before update, automated backups, rollback plan. Red flag: “I just click update.”

“Show me a piece of code you’ve written that you’re proud of, and explain why.” Looking for: real understanding of what they wrote and why. Red flag: nothing to show, or showing code they clearly didn’t write.

“What’s your opinion on page builders?” Looking for: a nuanced answer (page builders are appropriate for some projects, problematic for others, here’s how I decide). Red flag: “I use [single page builder] for everything.”

“Have you contributed to any WordPress plugins, themes, or core?” Looking for: any genuine contribution, even small. Red flag: doesn’t know what this means.

Project questions

“How do you handle scope changes mid-project?” Looking for: a clear process — change request, written estimate of impact, your approval before work continues. Red flag: vague answer about “we’ll figure it out” — this is how projects double in cost without warning.

“What’s your typical timeline for a project like this?” Looking for: realistic timeline broken into phases. Red flag: aggressively short timeline (especially “two weeks for a full site”) — they’re either lying or about to ship something terrible.

“Who exactly will be working on this project?” Looking for: clarity about whether the person you’re talking to is the one writing code, or whether it’ll be subcontracted. Red flag: evasive answer.

“Can I talk to two recent clients?” Looking for: yes, here are their contacts. Red flag: refusal, or only offers to share testimonials.

“What happens if I’m not happy with the work?” Looking for: revision policy, dispute process, clear answer about refunds for unfinished work. Red flag: “that won’t happen.”

Communication questions

“How often will I hear from you during the project?” Looking for: a specific cadence — weekly check-ins, milestone updates, your preferred channel. Red flag: “whenever I have updates” is a recipe for going dark.

“What’s your timezone and working hours?” Looking for: clear answer, mention of overlap with your hours if relevant. Red flag: vague answer.

Step 5: Red flags that should end the conversation

Some things should make you walk away no matter how good the price or portfolio looks:

No physical address or company information anywhere. Real developers and agencies have findable identities — a real address (even a home office), a registered business if applicable, real names attached to real LinkedIn profiles. A site with only a contact form and no traceable identity is a liability when something goes wrong.

Quotes dramatically below market rate for the scope. A $12,000 e-commerce build quoted at $1,500 is not a deal. It’s a different project than the one being described — usually a template install with the work either rushed, subcontracted to someone unvetted, or both.

Pressure to pay 100% upfront. Standard practice is 30–50% upfront, milestone payments, and final payment on delivery. 100% upfront means you have no leverage if work stalls.

Reluctance to use a written scope or contract. “Let’s just start and see how it goes” is how projects end in disputes. Any developer who won’t put scope in writing is one you can’t hold accountable to it.

Vague answers about what’s included vs not included. Specifically watch for: hosting setup (often not included), domain configuration, content migration, SEO setup, training. Each of these is a potential surprise charge if not specified upfront.

Bad communication during the sales process. If they’re slow to respond, evasive, or sloppy when they’re trying to win your business, it gets worse after you’ve paid.

No portfolio of similar work. If you need an e-commerce site and they have only brochure sites in their portfolio, they’re going to be learning on your project. That’s fine if you’re paying junior rates and have time. It’s not fine if you’re paying senior rates.

They list every WordPress technology as a specialty. “We do WordPress, Shopify, Webflow, Magento, Squarespace, Wix, custom React, Next.js, mobile apps, AI integration, and SEO.” Maybe — but more likely they’re a marketing front for whichever subcontractor takes the job.

Recent negative reviews with patterns. One bad review is normal. Five reviews mentioning the same problem (going dark mid-project, hidden fees, ignoring revisions) is the pattern.

Step 6: How to structure the project once you’ve hired

Hiring is half the battle. The other half is running the project so it actually delivers.

Get scope in writing before any work starts. A scope document should specify: pages and their content, design deliverables (mockups, revisions allowed), functionality (specific features, integrations, what’s explicitly out of scope), timelines and milestones, payment schedule, and what happens if either party wants to change scope. This document is the reference for every “is that included?” question that comes up later. Skipping it is the #1 reason WordPress projects go bad.

Tie payments to milestones, not hours. “50% on contract signing, 25% on design approval, 25% on launch” is a clean structure for a fixed-price project. Don’t pay hourly for a fixed-scope project — you lose any incentive for the developer to be efficient. Don’t pay 100% on completion either — they need cash flow during the work.

Use a staging environment for everything. No work happens on the live site. Every change goes to staging first, you review, then it gets deployed to live. This is standard practice; if your developer doesn’t work this way, that’s a competence flag.

Set a regular communication cadence. Weekly is usually the sweet spot — a 15-minute call or written update covering: what was finished this week, what’s blocked, what’s next, any decisions needed from you. Going dark for two weeks is how projects quietly fail.

Test on real devices before signing off. Not just “looks good in Chrome on my MacBook.” Test on an actual phone, an actual tablet, ideally on someone else’s phone with different browser settings. Half of post-launch bugs are mobile rendering issues that nobody caught.

Get all access credentials at the end. Hosting login, domain registrar login, WordPress admin, FTP/SSH if used, Git repository, any third-party service accounts (Stripe, Mailchimp, etc.). If any of these are in the developer’s name, transfer them to yours before final payment. Otherwise you don’t actually own your own site.

Step 7: What to do if it goes wrong

Sometimes projects go bad despite good hiring. What to do:

Document everything in writing. If conversations have been over phone or video, follow up with email summaries: “Confirming what we discussed today: X, Y, Z. Please let me know if I’ve misunderstood anything.” This gives you a paper trail.

Raise concerns early and specifically. Vague unhappiness gets vague responses. Specific complaints with examples (“the homepage doesn’t match the approved mockup in these 4 places”) get specific fixes.

Use the milestone structure as leverage. If work isn’t meeting standards, don’t release the next milestone payment until it does. This is exactly why milestone payments exist.

Get a second opinion before declaring failure. Sometimes what feels like bad work is actually a misunderstanding about what was scoped. Have another developer (or technical friend) review what’s been built and tell you whether the issues are real.

Know your dispute options. If you used a marketplace platform (Codeable, Upwork, Fiverr), they have dispute resolution processes — use them. If you paid by credit card, you may have chargeback options. If you signed a contract, you may have legal recourse, though this is usually expensive relative to small project budgets.

As a last resort, cut losses cleanly. Pay what’s been earned (not necessarily what’s been billed), get whatever has been completed, get all credentials transferred, and find a different developer to finish. Sunk cost is sunk; don’t keep paying a relationship that isn’t working.

FAQ

How much does it cost to hire a WordPress developer in 2026? Hourly rates range from $30–$200+ depending on experience and region, with $50–$100/hr being typical for a competent mid-level freelancer. Full project pricing for an agency build typically runs $4,000–$25,000 for most business sites, with complex e-commerce and custom builds going significantly higher.

Should I hire a freelancer or an agency? Freelancers are better for small, well-defined tasks under $3,000. Agencies are better for full sites, complex builds, and projects where you want someone else managing the work. The right choice depends on scope and how much project management you want to take on yourself.

How long does it take to build a WordPress site? A simple business site takes 3–6 weeks with a competent agency. A WooCommerce store typically takes 8–16 weeks. Complex custom builds run 3–9 months. Anyone promising to deliver a real custom site in under 3 weeks is either skipping critical work or doing a template install.

What’s the difference between a WordPress developer and a WordPress designer? Designers handle visual design — layout, typography, color, user experience. Developers handle the code — themes, plugins, integrations, performance. Smaller agencies and freelancers often do both; larger agencies separate the roles. For a real custom site, you usually want both skill sets on the project.

Can I hire a WordPress developer offshore to save money? Yes, but with care. Eastern European and Latin American developers in particular often offer strong technical skills at lower rates than US/UK markets. The watch-outs are timezone overlap (matters more than people think), language clarity in writing, and verifying portfolio claims are real. The cheapest options on Asian marketplaces usually cost more in revision time than they save in initial price.

Do I need a WordPress developer if I’m just using a theme? For a basic site with a quality theme and no customization, often no. For anything that needs to look distinctive, perform well, integrate with other tools, or scale meaningfully, yes. The line between “I can do this myself” and “I need a developer” is usually crossed the first time you find yourself searching for “how to fix [WordPress problem] without breaking the site.”

Should I hire someone local or remote? For most projects, remote is fine and gives you a much wider talent pool. Local is worth it if you specifically need in-person collaboration (rare for WordPress projects), if you have legal or compliance reasons to keep work in your jurisdiction, or if you’re doing ongoing work where quarterly in-person meetings would help.

Conclusion

Hiring a WordPress developer well comes down to a few principles: be honest about what scope your project actually needs, pay realistic rates for that scope, ask the questions that separate confident from competent, and structure the engagement so both sides have incentive to finish well. Most bad WordPress development experiences come from skipping one of those — usually the first.

The good news is that the WordPress development market in 2026 is mature. There are thousands of competent freelancers and hundreds of solid agencies, and the tools for finding them, vetting them, and working with them are better than they’ve ever been. If you do the work upfront, you’ll get a website you’re happy with. Skip it, and you’ll probably be hiring a second developer to fix the first one’s work.

What to read next

• Cursor vs Claude Code vs Copilot for WordPress: hands-on comparison
• The Complete Guide to Using AI Coding Assistants for WordPress Development in 2026
• Best AI coding assistants for PHP developers in 2026
• Building custom WooCommerce checkout fields with Cursor

Cursor lives in your editor. Claude Code lives in your terminal. That sounds like a small distinction until you realize what it unlocks: an AI that can run wp plugin list, inspect your database, run your test suite, watch the output, and respond to what it sees — all without you touching the keyboard.

For day-to-day WordPress edits, Cursor is faster. For multi-file refactors, codebase audits, plugin modernization, or anything where the AI benefits from being able to do things (not just read and write code), Claude Code is the better tool.

This guide walks through the full setup: installing Claude Code, configuring CLAUDE.md for WordPress, connecting WP-CLI as a tool, MCP integrations, custom slash commands, and the workflows that make a terminal-based agent worth the context-switch from your editor.

Prerequisites: A WordPress project (local development environment recommended), WP-CLI installed and working, an Anthropic API key or Claude subscription with Claude Code access, and basic terminal comfort.

---

Step 1: Install Claude Code

Install Claude Code from the official Anthropic install method (typically via npm or a curl install script — check claude.com or Anthropic’s documentation for the current command, since the install path has changed a few times).

After install, run:

claude --version

You should see a version number. If the command isn’t found, your shell’s PATH doesn’t include the install location — check the install output for instructions.

Authenticate by running claude in any directory and following the prompts. Claude Code supports both Anthropic API keys (pay-per-use) and Claude subscription accounts (Pro, Max, Team). For consistent WordPress work, the subscription plans are usually better value than API usage; for occasional use, API works fine.

Step 2: Open your WordPress project and create CLAUDE.md

Navigate to your WordPress project root in the terminal:

cd ~/projects/my-wordpress-site

Just like Cursor reads .cursorrules, Claude Code reads CLAUDE.md at the project root on every session. Create one:

touch CLAUDE.md

Open it in your editor and paste this:

# Project context

This is a WordPress project. All code you generate or modify must follow
WordPress coding standards and security best practices.

## Project specifics

- WordPress version: [e.g. 6.5+]
- PHP version: [e.g. 8.2]
- Theme: [your theme name, or "custom"]
- Active plugins of note: [WooCommerce, ACF, etc.]
- Local environment: [LocalWP / wp-env / Docker / DDEV]
- Database access: WP-CLI is configured and available

## Security requirements (non-negotiable)

- Escape all output: esc_html(), esc_attr(), esc_url(), esc_js(), wp_kses().
- Sanitize all input: sanitize_text_field(), sanitize_email(), etc.
- All forms require wp_nonce_field() and verification with check_admin_referer().
- All AJAX handlers must verify nonces with check_ajax_referer().
- All privileged operations check capabilities with current_user_can().
- All database queries use $wpdb->prepare() — never concatenate user input.
- No deprecated functions: mysql_*, create_function, ereg, eregi.

## WordPress conventions

- Translation: __(), _e(), esc_html__(), esc_html_e() — always with text domain.
- Hooks: only use hooks that exist in core or active plugins. Never invent hook names.
- Distinguish actions (no return) from filters (must return first argument).
- HTTP requests: wp_remote_get / wp_remote_post, not cURL or file_get_contents.
- File operations in plugins: use WP_Filesystem, not direct PHP file functions.
- Database changes in plugins: dbDelta() in activation hooks, not raw CREATE TABLE.

## Workflow expectations

- Before making non-trivial changes, briefly explain what you plan to do
  and which files you'll touch. Wait for confirmation.
- After making changes, run any relevant tests or validation
  (php -l on changed PHP files, npm run build if JS changed).
- For destructive operations (deleting files, dropping tables, mass updates),
  always ask first.
- Use WP-CLI to inspect the live install when relevant. Don't guess
  about plugin activation status, post counts, option values, etc.

## Coding style

- WordPress PHP standards: snake_case functions/variables, PascalCase classes.
- Tabs for PHP indentation, 2 spaces for JS/CSS.
- Docblocks on all functions and classes (@param, @return, @since).
- Namespaces for plugin classes (PSR-4 autoloading preferred).

## Project notes

[Anything weird, undocumented, or important about this codebase.
Architectural decisions, "why we did it this way" history,
known fragile areas, third-party API quirks, etc.]

The “Project notes” section is the one that pays off most over time. As you work, when you discover something non-obvious — a custom field that breaks if you sanitize it the normal way, a plugin conflict, an API rate limit — add it. Future Claude Code sessions inherit that knowledge automatically.

Test that Claude Code is reading it. Start a session:

claude

Then ask: “What’s in CLAUDE.md? Summarize the project context.”

Claude Code should summarize the contents accurately. If it doesn’t reference the file, the file isn’t being picked up — check the filename (exactly CLAUDE.md, case sensitive on most filesystems) and that it’s at the directory where you started Claude Code.

Step 3: Configure WP-CLI as a tool

This is the step that makes Claude Code substantively more useful than Cursor for WordPress work. Once Claude can run WP-CLI commands, it can:

• Check which plugins are active and their versions
• Inspect post counts, user counts, options, transients
• Run database queries via wp db query
• Activate, deactivate, install, and update plugins
• Reset passwords, manage users
• Export and import content
• Run cron events manually
• Check site health

The good news: Claude Code can run shell commands by default, and WP-CLI is just a shell command. There’s no special integration needed — you only need to tell Claude Code in CLAUDE.md that WP-CLI is available (which the template above does).

Confirm WP-CLI works in your project directory:

wp plugin list

If you see your plugin list, you’re set. If you get “Error: This does not seem to be a WordPress installation,” check that you’re in the WordPress root and that wp-config.php is accessible. For some local environments (Docker-based setups, especially), WP-CLI needs to be configured to talk to the right container — check your stack’s docs.

Test it through Claude Code. Start a session in your project root and ask:

“How many published posts are in this WordPress install? Use WP-CLI.”

Claude should run something like wp post list --post_status=publish --format=count and return the actual number. If it tries to guess instead of running the command, your CLAUDE.md needs more explicit instruction — add a line like “Always use WP-CLI to inspect the live install rather than guessing.”

A few WP-CLI patterns worth knowing

These are commands I find Claude Code uses most often during WordPress work, so it’s worth confirming they all work in your environment:

wp plugin list --status=active --format=json
wp option get [option_name]
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_status='publish'"
wp post list --post_type=any --posts_per_page=5 --format=json
wp eval-file path/to/script.php
wp cron event list
wp transient delete --all

The wp eval-file one is particularly useful: Claude Code can write a one-off PHP script to investigate something, then execute it inside your WordPress runtime via WP-CLI. This sidesteps the limitation that AI can’t normally execute PHP — combined with WP-CLI, it can.

Safety note. Claude Code asks for confirmation before running commands by default. Don’t disable this for WordPress work. WP-CLI can do destructive things (wp db reset, wp post delete --force, wp plugin uninstall), and you want a confirmation step before any of them run. If you want to be extra safe, work against a local copy of your site, not staging or production.

Step 4: Connect MCP servers

MCP servers extend Claude Code beyond shell access. The integrations worth setting up for WordPress:

A MySQL/MariaDB MCP server. Lets Claude inspect your schema, run safe read queries, and (with care) execute writes. Useful when you want structured data access rather than going through wp db query. There are several community options — search for “mysql mcp server” or check the official MCP server registry.

A filesystem MCP server scoped to your project. Claude Code already has filesystem access in its working directory, but a scoped MCP server can give it controlled access to additional paths (like a media directory mounted elsewhere, or a sibling project).

A GitHub MCP server. If your WordPress project lives in GitHub and you want Claude Code to manage issues, PRs, and reviews from the terminal. Less WordPress-specific, more useful in general.

A web search/fetch MCP server. When Claude Code needs to verify a hook exists in WordPress core, look up a function signature, or check current plugin documentation, web access closes the loop. The built-in tools are usually enough, but a dedicated MCP server makes this faster.

Adding an MCP server to Claude Code:

claude mcp add [server-name] [command-or-url]

Or edit your global Claude Code config file directly (location depends on OS — claude config will show you the path). The format is similar to other MCP clients:

{
  "mcpServers": {
    "mysql": {
      "command": "npx",
      "args": ["-y", "@some-org/mysql-mcp-server"],
      "env": {
        "MYSQL_HOST": "localhost",
        "MYSQL_USER": "root",
        "MYSQL_PASSWORD": "...",
        "MYSQL_DATABASE": "wordpress"
      }
    }
  }
}

Restart Claude Code and the new MCP tools become available.

The same warning as before: don’t connect MCP servers to production. The point of these integrations is fast, free exploration. Save fast, free exploration for environments where mistakes don’t take down a live site.

Step 5: Create custom slash commands for repeated tasks

Slash commands are the productivity multiplier most Claude Code users miss. They’re saved prompts you can invoke with a single command instead of retyping the full instruction.

Create a .claude/commands/ directory in your project:

mkdir -p .claude/commands

Each markdown file in this directory becomes a slash command. Examples worth creating:

.claude/commands/security-review.md:

Review the changes in this session (or the file I specify) for WordPress
security issues. Specifically check for:

1. Missing output escaping (esc_html, esc_attr, esc_url, wp_kses)
2. Missing input sanitization
3. Missing nonces on forms or AJAX handlers
4. Direct database queries without $wpdb->prepare()
5. Use of deprecated functions
6. Missing capability checks (current_user_can) on privileged operations
7. Unescaped data in JavaScript output
8. Path traversal risks in file operations

Produce a list of findings with severity (critical/high/medium/low) and
the specific fix for each. Do not modify files yet — just produce the report.

Now in any Claude Code session, you type /security-review and the prompt fires.

.claude/commands/explain-codebase.md:

I need to understand this WordPress plugin/theme/codebase. Read through it and produce:

1. A summary of what it does in plain language
2. The main entry points (plugin file, hook registrations, AJAX handlers, etc.)
3. The architecture pattern (MVC? Procedural? Custom framework?)
4. External dependencies and APIs
5. Any concerning patterns (security issues, deprecated code, performance problems)
6. Files I should read first to understand the rest

Don't change anything. This is a read-only investigation.

.claude/commands/modernize-plugin.md:

Audit this plugin for modernization opportunities:

1. Deprecated PHP functions (mysql_*, create_function, etc.)
2. Deprecated WordPress functions
3. Procedural code that would benefit from OOP refactoring
4. Missing namespaces / autoloading
5. jQuery usage that could be vanilla JS
6. Direct file operations that should use WP_Filesystem
7. Direct cURL that should use WordPress HTTP API

Produce a prioritized list. Do not make changes yet.

.claude/commands/test-plugin.md:

Run all available tests for this plugin:

1. Run php -l on every PHP file (syntax check)
2. If PHPCS is configured, run it with the WordPress standard
3. If PHPUnit is configured, run the test suite
4. If npm test is defined, run it
5. Run any custom test commands defined in composer.json or package.json

Report all failures with file/line/error.

Build up your slash command library over time. Whenever you find yourself writing the same prompt twice, save it as a slash command. After a few months you’ll have a personal toolkit that turns common WordPress tasks into one-line operations.

Step 6: Set up agent-friendly output

One quirk of Claude Code: it works much better when your project’s tools produce structured output. A few configuration tweaks that pay off:

WP-CLI: prefer --format=json or --format=csv. These are easier for Claude to parse than the default table format. You can either remember to add the flag, or set environment variables / aliases. I have an alias wpj='wp' and ask Claude to “use json format with WP-CLI” in my CLAUDE.md.

PHPCS: configure phpcs.xml at project root. If the config is in a known location with WordPress standards configured, Claude will run it automatically when checking code quality.

Composer scripts. Add named scripts to composer.json like lint, test, format. Claude Code will discover and run these when relevant.

A short Makefile or package.json scripts. Even better than composer scripts for cross-language projects. Define make test, make lint, make build and Claude can run them on its own.

The pattern: the more deterministic, named commands you have for common operations, the more autonomous Claude Code can be. It doesn’t have to figure out how to test your code — it runs make test.

Step 7: Test the full setup with a real task

Configuration is theoretical until you put it through a real task. Try this:

“Audit the active plugins on this WordPress install for security issues. Use WP-CLI to list them. Read each plugin’s main file and look for: missing nonces, unescaped output, deprecated database functions, and unsafe direct file access. Produce a report grouped by plugin, with severity and specific line references. Don’t fix anything yet.”

A well-configured Claude Code should:

1. Run wp plugin list --status=active --format=json to get the plugin list
2. Read each plugin’s main file (and possibly key includes)
3. Produce a structured report
4. Stop without modifying anything

If it skips WP-CLI and tries to guess plugin names from your file structure, your CLAUDE.md needs more emphasis on using WP-CLI for runtime data.

If it starts fixing things instead of producing a report, your CLAUDE.md needs more emphasis on the “wait for confirmation before changes” workflow.

Iterate on CLAUDE.md until the test runs cleanly. The few hours you spend tuning the config repay themselves on the first real refactor you delegate to Claude Code.

When to use Claude Code vs Cursor

Now that both are configured, the question is when to use which:

Use Cursor for: Single-file edits, inline refactoring with Cmd+K, writing new code in an existing file, quick “explain this function” questions, and anything where you’re staying in flow inside the editor.

Use Claude Code for: Multi-file refactors, full-codebase audits, plugin modernization, automated workflows (running tests, building assets, deploying), tasks that require WP-CLI access to live data, tasks where the AI benefits from running commands and reading their output, and anything where you’d rather walk away for 30 minutes than hand-hold an agent.

The boundary blurs — Cursor’s agent mode does some of what Claude Code does, and Claude Code can edit single files. But the strengths are real and you’ll naturally develop a feel for which to reach for.

Common setup problems and fixes

“Claude Code can’t find WP-CLI.” Your shell’s PATH in the Claude Code session might differ from your normal terminal. Run which wp in Claude’s session to confirm. If it’s not found, add the absolute path of WP-CLI to your CLAUDE.md and reference it explicitly.

“WP-CLI errors out inside Claude Code but works in my normal terminal.” Common cause: you’re using a Dockerized local environment, and WP-CLI needs to run inside the container. Configure a wrapper command (e.g., wp aliased to docker exec myproject_php wp) and document it in CLAUDE.md.

“Claude keeps making changes without confirming.” Your CLAUDE.md needs stronger language. Try: “NEVER modify files without first describing what you’ll change and waiting for me to approve. The only exception is fixing a typo I explicitly asked you to fix.”

“The MCP server isn’t loading.” Run claude mcp list to confirm it’s registered. Check the server’s logs (location varies by server). Most MCP server issues are environment variable or path issues.

“Costs are higher than expected.” Long sessions with large file reads consume tokens fast. Strategies: use .cursorignore-style patterns to keep large files out of context (Claude Code respects .gitignore by default plus its own ignore files), be explicit about which files to read instead of letting the agent explore freely, and use slash commands to keep prompts focused.

What good Claude Code output looks like

A well-configured Claude Code session for WordPress should feel like working with a focused engineer who knows the codebase. Specifically:

• Asks clarifying questions on ambiguous tasks rather than guessing
• Uses WP-CLI to verify rather than assuming
• States its plan before making non-trivial changes
• Runs tests/linters after changes without being asked
• Catches its own mistakes when output doesn’t match expectations
• Stops when something looks risky and asks for guidance

If your sessions don’t feel like that, the configuration needs more iteration. The setup investment is real — expect to spend a couple of weeks refining CLAUDE.md, slash commands, and conventions before it clicks.

What to read next

This article covers Claude Code in isolation. For the broader workflow:

• The Complete Guide to Using AI Coding Assistants for WordPress Development in 2026 — the pillar piece comparing all major tools
• How to set up Cursor for WordPress development — the editor-based companion to Claude Code
• Cursor vs Claude Code vs Copilot for WordPress: hands-on comparison — the head-to-head benchmark
• How to use AI coding assistants on legacy PHP codebases — the use case Claude Code handles best
• Automating WordPress development tasks with Claude Code + WP-CLI — workflow recipes building on this setup

Cursor works fine for WordPress out of the box. It also works much better with about thirty minutes of upfront configuration — and that gap is the difference between AI that generates plausible-looking PHP and AI that generates code you’d actually commit.

This guide walks through the full setup: installation, rules file, project indexing, the settings that actually matter for WordPress work, and a few integrations (MCP servers, WP-CLI tie-ins) that elevate Cursor from a smart editor to a genuine development partner.

If you’ve installed Cursor, opened your WordPress project, and felt like it’s “just VS Code with autocomplete,” this is the article for you.

Prerequisites: A WordPress project (local or remote), basic familiarity with VS Code, and an active Cursor subscription. The free tier works for most of this, but the rules-file features get more useful with the larger context windows on paid plans.

---

Step 1: Install Cursor and open your WordPress project

Download Cursor from cursor.com and install it. On first launch, it’ll offer to import your VS Code settings and extensions — accept this. Most of the WordPress-relevant extensions you already use (PHP Intelephense, WordPress Snippets, etc.) work in Cursor unchanged.

The first decision is what to open as your project root. Three reasonable choices:

Option A — The full WordPress installation. Open the directory containing wp-config.php, wp-content/, wp-admin/, etc. Cursor will index core, your themes, and your plugins. The AI will know about everything but the index is large and consumes context.

Option B — Just wp-content/. Skip core, index only what you actually edit. This is what I use most of the time.

Option C — A single plugin or theme. Open just the plugin or theme directory you’re working on. Smallest index, fastest context, but the AI doesn’t see the rest of WordPress for reference.

For most workflows, Option B is the right default. Open it once and Cursor will start indexing. You’ll see the indexing progress in the bottom status bar — let it finish before you start prompting, especially on larger projects.

Step 2: Add a .cursorrules file (this is the most important step)

The single highest-leverage thing you can do is add a .cursorrules file at your project root. Cursor reads this file automatically and includes it as context in every AI interaction. Without it, you’re prompting a generic AI. With it, you’re prompting an AI that knows it’s working on WordPress.

Create .cursorrules in your project root and paste this:

# Project context

This is a WordPress project. All generated code must follow WordPress
coding standards and security best practices.

# Security requirements (non-negotiable)

- Escape all output: use esc_html(), esc_attr(), esc_url(), esc_js(),
  or wp_kses() depending on context. Never echo unescaped variables.
- Sanitize all input: use sanitize_text_field(), sanitize_email(),
  sanitize_textarea_field(), or appropriate WP sanitizer for the data type.
- All form submissions must include wp_nonce_field() and verify with
  check_admin_referer() or wp_verify_nonce().
- All AJAX handlers must verify nonces with check_ajax_referer().
- All privileged operations must check capabilities with current_user_can().
- Use $wpdb->prepare() for all direct database queries. Never concatenate
  user input into SQL strings.
- Do not use deprecated functions: mysql_*, create_function, split,
  ereg, eregi, each, or any function deprecated in PHP 8+.

# WordPress conventions

- All user-facing strings must use translation functions: __(),
  _e(), esc_html__(), esc_html_e(), _n(), _x().
- Always include the text domain in translation calls.
- When using hooks, only use hooks that exist in WordPress core or
  the active plugins/themes. If unsure whether a hook exists, ask
  before using it. Never invent hook names.
- Distinguish actions from filters: action callbacks do not return
  values; filter callbacks must return their first argument
  (modified or unmodified).
- Use WordPress HTTP API (wp_remote_get, wp_remote_post) instead
  of cURL or file_get_contents for external requests.
- Use WordPress filesystem API (WP_Filesystem) for file operations
  in plugins, not direct PHP file functions.

# Coding style

- Follow WordPress PHP coding standards (snake_case for functions and
  variables, PascalCase for classes, kebab-case for files).
- Yoda conditions are not required.
- Use spaces inside parentheses for function calls in PHP files.
- Indent with tabs in PHP files, 2 spaces in JS/CSS files.
- Use namespaces for plugin classes (PSR-4 autoloading preferred).

# When generating code

- Before writing code that uses unfamiliar hooks or functions,
  state which hooks/functions you plan to use and confirm they exist.
- Prefer modifying existing files over creating new ones unless
  scaffolding a new plugin or feature.
- When generating a function, generate the docblock with @param,
  @return, and @since tags.
- For database changes, use dbDelta() in plugin activation hooks,
  not direct CREATE TABLE statements.

# Project-specific notes

[Add notes about your specific project here: PHP version, target WP version,
theme framework, custom architecture decisions, etc.]

That last block matters. Replace the placeholder with project-specific context — your PHP version, your theme framework if any, naming conventions you’ve already established, weird quirks of the codebase. The more honest project context Cursor has, the better its output.

Test it. Open any PHP file in your project, hit Cmd+L (or Ctrl+L) to open the chat, and ask: “What rules are you following for this project?” Cursor should summarize the contents of your .cursorrules file. If it doesn’t, the file isn’t being picked up — check that it’s at the project root and named exactly .cursorrules (with the leading dot).

Step 3: Configure project indexing

Cursor’s chat and agent features rely on its index of your codebase. By default, Cursor indexes everything in your project, which for a WordPress site can include node_modules, vendor, build artifacts, and uploads — all of which waste context budget and slow down responses.

Add a .cursorignore file at your project root with these patterns:

# Dependencies
node_modules/
vendor/
bower_components/

# Build output
dist/
build/
*.min.js
*.min.css
*.map

# WordPress uploads and cache
wp-content/uploads/
wp-content/cache/
wp-content/wflogs/
wp-content/upgrade/
wp-content/backup-db/
wp-content/backups/

# WordPress core (uncomment if you opened the full WP install)
# wp-admin/
# wp-includes/
# wp-*.php

# Local development
.wp-env/
*.sql
*.log

# IDE
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

The wp-content/uploads/ line is the most important one. If you don’t ignore it, Cursor will try to index every image and PDF on your site, which destroys both indexing performance and context relevance.

If you opened the full WordPress install, uncomment the wp-admin/, wp-includes/, and wp-*.php lines. Indexing core is rarely useful — Cursor’s training already includes WordPress core, and re-indexing it locally just dilutes your project context.

After saving .cursorignore, rebuild the index: open Cursor settings (Cmd+,), search for “indexing,” and click “Resync Index” or equivalent.

Step 4: Set up the model and context settings

Cursor lets you choose which AI model to use. The setting that matters most is the default model for the chat panel.

Open settings → Models. For WordPress work specifically, my recommendation:

• Default chat model: Claude Sonnet 4.6 or whichever recent Claude model is available. Claude handles PHP and WordPress conventions noticeably better than GPT-class models in my testing.
• Auto-complete (cmd+K) model: Cursor’s faster default model is fine here. The latency matters more than the depth of reasoning for inline edits.

Two other settings worth changing:

Increase context length if your plan supports it. Settings → Models → Long Context (or similar). WordPress projects benefit disproportionately from larger context — there’s a lot of cross-file referencing.

Turn on “Include open files in context.” Settings → Editor. This makes Cursor automatically include the files you have open as context, which is exactly what you want for refactoring tasks.

Step 5: Install WordPress-relevant extensions

Cursor inherits the VS Code extension marketplace. The extensions worth installing for WordPress work:

• PHP Intelephense — PHP language server. Provides go-to-definition, autocomplete, and inline error detection. Worth the paid license if you’re full-time on PHP.
• WordPress Snippets by WordPresshooks or similar — autocomplete for WordPress functions and hook names. Also helps Cursor’s autocomplete by surfacing real hook names in your editor context.
• PHP DocBlocker — generates docblocks with one keystroke.
• WP Hooks IntelliSense — adds inline hook documentation. Useful both for you and as visible context for Cursor.
• EditorConfig — if your project has an .editorconfig file, this enforces it.
• GitLens — better git integration. Cursor uses git context for some features, and GitLens makes it easier to give the AI specific commit ranges to reason about.

After installing PHP Intelephense, point it at your WordPress install so it indexes core function signatures:

1. Open settings (Cmd+,)
2. Search for “intelephense.environment.includePaths”
3. Add the path to your WordPress core directory (e.g., /path/to/wordpress)

This is what unlocks “Intelephense knows that get_post() returns WP_Post|null,” which feeds back into Cursor’s context as docblock hints during generation.

Step 6: Connect MCP servers (optional but powerful)

MCP (Model Context Protocol) servers extend what Cursor’s AI can actually do — beyond reading and editing files in your project. For WordPress development, two MCP integrations are worth setting up:

A WP-CLI MCP server. This lets Cursor execute WP-CLI commands directly. Instead of asking “what plugins are active in this install” and getting a guess, Cursor runs wp plugin list and gets the real answer. There are several community WP-CLI MCP servers; check the Cursor MCP directory or GitHub for current options.

A MySQL/database MCP server. Lets Cursor inspect your database schema and run safe read queries. Especially useful when working with custom tables or trying to understand a schema you didn’t design.

To add an MCP server in Cursor:

1. Open settings → MCP
2. Click “Add new MCP server”
3. Paste the server’s configuration (each server’s docs will provide this)
4. Restart Cursor

Once connected, Cursor’s chat will list the MCP server’s tools as available actions. You’ll see them being invoked when relevant.

Don’t connect MCP servers to production databases. Use a local or staging environment. The point of these integrations is to let the AI poke around freely; you don’t want freely-poking-around on a live site.

Step 7: Test your setup with a real task

Configuration is meaningless without testing. Run this benchmark on your newly-configured Cursor:

Test prompt: “Create a small WordPress plugin called ‘Reading Time Estimator’ that adds an estimated reading time above the content of every single post. Use a filter on the_content. Include a settings page under Settings where the admin can configure words-per-minute (default 200). Follow all WordPress security and coding standards from the project rules.”

A well-configured Cursor should produce:

• A main plugin file with a proper plugin header
• A settings page registered under Settings → Reading Time
• Settings registered with register_setting() and a sanitization callback
• The settings page using wp_nonce_field() and verifying the nonce
• Output escaped with esc_html() and esc_attr()
• The reading time hooked into the_content via add_filter
• Translation-ready strings using __() with a text domain
• A check for current_user_can('manage_options') on the settings page

If the generated code is missing more than one of those, your .cursorrules isn’t being applied or the rules need more specific language. Iterate on the rules file until the test passes cleanly.

A few configuration patterns I’ve found useful

Per-plugin rules files. If you’re maintaining multiple plugins in the same project root, you can put a .cursorrules file inside each plugin directory with plugin-specific notes. Cursor uses the most specific rules file for the file you’re currently editing.

CLAUDE.md as a fallback. If you also use Claude Code occasionally, keep a CLAUDE.md file with similar content. Some teams symlink the two so they stay in sync. The rules content is roughly portable between tools.

Project notes file. Beyond .cursorrules, I keep a NOTES.md at the project root with architecture decisions, gotchas, and “we tried this and it didn’t work” history. When starting a complex Cursor session, I paste relevant sections of this into the chat. The rules file handles defaults; the notes file handles specifics.

Snippet files for common prompts. I keep a prompts/ directory in my projects with markdown files like security-review.md, refactor-to-oop.md, add-settings-page.md. Each is a tested prompt I can paste into Cursor when I need that task done. Saves rewriting the same prompts every project.

Common setup problems and fixes

“Cursor isn’t picking up my .cursorrules file.” Check that it’s at the project root (where you opened the project), not in a subdirectory. Filename must be exactly .cursorrules with a leading dot. Restart Cursor after creating it.

“The AI keeps generating insecure code despite the rules.” Your rules file is being read but the AI is ignoring parts of it. Solution: make the rules more explicit and shorter. Long rules files get partially ignored. Also try restating the most critical rules in the prompt itself for high-stakes tasks.

“Indexing is slow.” Check .cursorignore is set up. Most slowness is from indexing node_modules, vendor, or wp-content/uploads.

“Cursor doesn’t recognize WordPress functions.” Install PHP Intelephense and configure its includePaths to point at your WordPress core directory. This is the most common fix.

“Generated code uses outdated patterns.” Your rules file probably doesn’t ban them explicitly. Add specific bans: “Do not use query_posts(). Use WP_Query instead.” Specificity beats generality in rules files.

“I’m hitting context limits on larger refactors.” This is when you switch to Claude Code. Cursor is editor-bound; for tasks that span many files, a terminal-based agent handles the context budget better. See How to set up Claude Code for a WordPress project.

What good Cursor output looks like

After all this configuration, you should be getting WordPress code that needs light review rather than rewriting. Specifically:

• Hook names are real (you can grep for them in core or in your active plugins)
• Output is escaped, input is sanitized
• Forms have nonces, AJAX handlers verify them
• Database queries use prepare()
• User-facing strings are wrapped in translation functions
• Privileged operations check capabilities
• Code follows your project’s existing patterns rather than generic ones

You should still review every line. AI-generated code with good configuration is closer to “junior developer who knows WordPress” output than to “drop-in production code.” That’s an enormous productivity gain, but it’s not autopilot.

What to read next

This article covers Cursor specifically. For the broader picture of how Cursor fits into a WordPress development workflow:

• The Complete Guide to Using AI Coding Assistants for WordPress Development in 2026 — the pillar piece, with comparisons across tools
• How to set up Claude Code for a WordPress project — the terminal-based agent for larger jobs
• Cursor vs Claude Code vs Copilot for WordPress: hands-on comparison — the head-to-head benchmark
• Writing a WordPress plugin from scratch with Cursor — end-to-end tutorial using the configuration above
• AI prompts that actually work for WordPress developers — prompt library that pairs with the rules file

---

Last updated: April 28, 2026. Cursor’s settings UI changes occasionally — if a setting name in this article doesn’t match what you see, check Cursor’s release notes for the current location.

WordPress runs roughly 43% of the web. Every AI coding tutorial uses a Next.js demo app.

There’s a reason for that gap, and it isn’t that AI tools can’t write PHP. It’s that PHP, the WordPress hooks system, the plugin API, theme conventions, and the specific way WordPress handles globals confuse generic AI tools in specific, repeatable ways. If you’ve tried prompting Cursor to “add a custom field to the WooCommerce checkout” and watched it invent a hook that doesn’t exist, you know exactly what I mean.

This guide is the result of using Cursor, Claude Code, GitHub Copilot, and Windsurf on real WordPress projects — client work, my own plugins, a couple of theme rebuilds. It covers which tool to use for what, how to actually configure them for WordPress, the prompt patterns that work, and the failure modes you need to catch before they ship.

If you’re a WordPress developer evaluating AI tooling and you’re tired of articles written by people who’ve never opened functions.php, this is for you.

---

TL;DR — Which AI tool should you use for WordPress?

Tool	Best for	Pricing	Learning curve	Verdict
Cursor	Day-to-day plugin and theme development	$20/mo Pro	Low — it’s VS Code	The default choice for most WordPress devs
Claude Code	Larger refactors, multi-file changes, automation with WP-CLI	Usage-based + Claude plans	Medium — terminal-first	Best for serious refactoring work
GitHub Copilot	Inline autocomplete inside an existing IDE	$10–$19/mo	Very low	Fine as a typing assistant, weak for WordPress-specific reasoning
Windsurf	Cursor alternative with agentic features	$15/mo Pro	Low	Worth trying if Cursor’s pricing or limits frustrate you

If you only read this far: use Cursor for daily work, add Claude Code when you need to do something bigger than one file. Skip Copilot unless you already have it.

---

Why WordPress is harder for AI than typical web stacks

This is the section most articles skip. Understanding why AI tools struggle with WordPress matters more than knowing which tool is “best,” because the failure modes carry across all of them.

The hooks system confuses AI

WordPress’s add_action / add_filter system is a runtime event bus. Hook names aren’t defined in any single file — they’re scattered across core, plugins, and themes. AI tools handle this in two bad ways:

The first is inventing hook names. Ask Claude or Copilot to “modify the cart total before display” and you might get woocommerce_before_cart_total (real) or woocommerce_modify_cart_total_display (made up). The made-up version is plausible enough that you’ll only catch it when nothing happens at runtime.

The second is mixing actions and filters. Actions don’t return values; filters must. AI tools occasionally generate a callback that returns a value but is registered with add_action, or vice versa. Both are silent failures — no PHP error, just behavior that doesn’t match what you asked for.

The fix isn’t tool-side. It’s prompt-side: name the hook explicitly, or tell the AI to verify the hook exists in the WordPress documentation before using it.

Globals and the loop create context AI can’t infer

WordPress relies on globals ($post, $wp_query, $wpdb) and an implicit “loop” state that depends on where in the request lifecycle your code runs. A function that works inside a template might fail in an AJAX handler because $post isn’t set there.

AI tools generate code based on the file they can see. If you’re editing a single template file, the AI doesn’t know whether you’re inside or outside the loop, whether wp_reset_postdata() is needed, or whether you should be using get_the_ID() versus $post->ID. They guess, and the guess is often wrong in subtle ways that work in dev and break in production under specific conditions.

Plugin and theme conventions get skipped

WordPress has security and i18n conventions that aren’t enforced by PHP — they’re enforced by code review and the plugin directory team:

• All output must be escaped (esc_html, esc_attr, esc_url, wp_kses)
• All input must be sanitized (sanitize_text_field, wp_unslash)
• All form submissions need nonces (wp_nonce_field, check_admin_referer)
• All user-facing strings need translation functions (__(), _e(), esc_html__())
• Database queries should use $wpdb->prepare(), never string concatenation

AI tools skip these defaults unless you explicitly tell them not to. Generated WordPress code is often functional but not safe and not submittable to the plugin directory.

I’ll come back to specific prompt patterns that fix this.

---

The 4 AI coding tools worth using for WordPress

Cursor

What it is: A fork of VS Code with AI features built into the editor. Inline edits, multi-file changes, chat panel, and an “agent mode” that can read and modify files autonomously.

Setup for WordPress: Install Cursor. Open your WordPress project (the full WP root, or just wp-content/ if you only work on themes/plugins). The two settings that matter:

1. Add a .cursorrules file at your project root with WordPress-specific context (example below).
2. Index your project — Cursor will offer this on first open. Let it run; it’s how the AI gets context across files.

A minimal .cursorrules for WordPress:

This is a WordPress project.
- Always escape output using esc_html, esc_attr, esc_url, or wp_kses.
- Always sanitize input using sanitize_text_field or appropriate WP sanitizer.
- All form submissions must use wp_nonce_field and check_admin_referer.
- All user-facing strings must use translation functions (__, _e, esc_html__).
- Use $wpdb->prepare() for all database queries.
- When using hooks, verify the hook name exists in WordPress core or the relevant plugin.
- Follow WordPress PHP coding standards (snake_case, Yoda conditions are not required).
- Do not use deprecated functions (mysql_*, create_function, etc).

For deeper configuration, see How to set up Cursor for WordPress development.

What it’s good at: Day-to-day work. Adding a function, modifying a template, generating a plugin scaffold, writing a Gutenberg block. The inline edit (Cmd+K) is the killer feature — select a function, describe the change, get a diff.

Where it fails: Large multi-file refactors where context exceeds the model’s window. Anything that requires running code or commands (Cursor’s agent can do this but it’s not as smooth as Claude Code’s terminal-native flow).

Real example: I asked Cursor to “add a settings page under WooCommerce that lets the admin set a minimum order quantity per product category.” It generated the menu registration, the settings page HTML with proper nonces and escaping, the option saving logic, and the filter on woocommerce_quantity_input_args. About 80% correct on first try — it forgot to register the settings using register_setting() so the values weren’t persisting. One follow-up prompt fixed it.

Claude Code

What it is: Anthropic’s terminal-based coding agent. Runs in your shell, reads your codebase, executes commands, and edits files. Less of an editor, more of a pair programmer that lives in iTerm.

Setup for WordPress: Install Claude Code. In your WordPress project root, create a CLAUDE.md file — this is the equivalent of .cursorrules but Claude Code reads it on every session start. Same content as the Cursor rules above works fine.

The real unlock is connecting WP-CLI. Claude Code can run wp plugin list, wp post list, wp db query, wp option get — meaning it can actually inspect your live WordPress install rather than guessing from code. This changes the kind of tasks you can delegate to it.

For deeper configuration, see How to set up Claude Code for a WordPress project.

What it’s good at: Anything that touches multiple files or requires iteration. Refactoring a plugin from procedural to OOP. Bulk-updating deprecated function calls. Running a security audit by combining file reads with WP-CLI queries. Writing tests where the agent can run PHPUnit and respond to failures.

Where it fails: Quick one-liner edits. The startup time and token cost don’t make sense for “rename this variable.” Use Cursor or your editor for those.

Real example: I had a 12-year-old client plugin using mysql_* functions, no nonces, output not escaped. I told Claude Code: “Audit this plugin for WordPress security and modernization issues. Produce a list of findings, then fix them in order, running the test suite after each fix.” It produced a 14-item list, fixed them sequentially, and ran the (admittedly thin) tests. About 90 minutes of agent time. Equivalent manual work would have been a day and a half.

GitHub Copilot

What it is: Microsoft/GitHub’s autocomplete-style AI, integrated into VS Code, JetBrains, Neovim, and others.

Setup for WordPress: Nothing WordPress-specific. Install the extension, sign in.

What it’s good at: Inline autocomplete while you type. If you write function my_plugin_register_ and pause, it’ll often complete the function name and body sensibly. Useful as a typing assistant.

Where it fails: It doesn’t reason across your codebase the way Cursor or Claude Code do. It doesn’t read a .cursorrules equivalent. It will happily generate WordPress code without escaping, without nonces, without translation functions. For anything beyond autocomplete, it’s the weakest of the four for WordPress work.

I keep it installed because it’s cheap and the autocomplete is genuinely fast, but I don’t rely on it for anything meaningful.

Windsurf

What it is: Cursor’s main competitor. Similar editor-based experience with agentic features. Owned by Codeium, then acquired, then re-spun — the company history is messy but the product is solid.

Setup for WordPress: Same as Cursor. It supports a similar rules file (.windsurfrules).

What it’s good at: Most things Cursor is good at. Pricing has historically been more generous on the free tier, and some developers prefer its UI.

Where it fails: Smaller community, fewer third-party tutorials. If you hit an edge case, you’ll find more StackOverflow help for Cursor.

I’d suggest trying it if Cursor’s pricing or limits become a problem, but I wouldn’t lead with it.

---

Head-to-head: same task, four tools

I gave each tool the same task: “Build a custom Gutenberg block that displays the 5 most recent posts from a selected category. Include a category selector in the block sidebar.”

Brief, deliberately. The kind of one-liner request a developer would actually give.

Cursor generated a complete block.json, edit.js with InspectorControls and a SelectControl, save.js using server-side rendering, and a PHP render callback. It used wp.data.useSelect to fetch categories. It missed registering the block via register_block_type initially — I had to ask for that. Total time: ~6 minutes including corrections.

Claude Code asked one clarifying question first (“should the category selector pull all categories or only ones with posts?”), then generated the same set of files plus a package.json with the right @wordpress/scripts dependencies and ran npm install. It tested the build. Total time: ~12 minutes, but it was actually working at the end.

GitHub Copilot doesn’t really do this kind of task — it’s autocomplete. I gave up after trying to coax it through file by file.

Windsurf produced output very similar to Cursor’s, slightly better organized but missed the same register_block_type step.

Verdict: Cursor and Windsurf are roughly equivalent. Claude Code does more, takes longer, and the result is closer to shippable. Copilot is the wrong tool for this kind of multi-file generative task.

For the full benchmark with screenshots, see Cursor vs Claude Code vs Copilot for WordPress: hands-on comparison.

---

Prompt patterns that work for WordPress

Generic prompts produce generic code. WordPress-specific prompts produce WordPress-specific code. Here are the patterns I reuse constantly.

The “WP context primer”

Paste this at the start of any session where you’ll be generating WordPress code:

You’re working on a WordPress project. All generated code must follow WordPress coding standards and security practices: escape all output (esc_html, esc_attr, esc_url, wp_kses as appropriate), sanitize all input, use nonces for forms, use translation functions for user-facing strings, and use $wpdb->prepare for any direct database queries. Do not invent hook names — if you’re not sure a hook exists, ask before using it.

Even with .cursorrules configured, restating this at the start of a complex session improves output quality noticeably.

The “hook-aware” refactor

Refactor [function/file] to use the appropriate WordPress hooks instead of [direct calls / output / whatever]. Before writing code, list the hooks you plan to use and explain why each is the right choice (action vs filter, priority, expected arguments). Wait for me to confirm before generating code.

The “wait for me to confirm” line is the important part. It catches invented hooks before they end up in your codebase.

The “security review” prompt

Review this code for WordPress security issues. Specifically check for: missing output escaping, missing input sanitization, missing nonces on forms or AJAX handlers, direct database queries without prepare(), use of deprecated functions, and missing capability checks (current_user_can) on privileged operations. List each issue with severity (critical/high/medium/low) and the fix.

Run this on every piece of AI-generated WordPress code before committing. Yes, even when you’re sure it’s fine.

The “plugin scaffold”

Generate a WordPress plugin scaffold for a plugin called “[name]”. Include the main plugin file with proper header, an autoloader for classes, a uninstall.php that cleans up options, a readme.txt template, and folder structure (includes/, admin/, public/, languages/). Use object-oriented PHP with namespaces. Do not implement business logic yet — just the scaffold.

Splitting “scaffold” from “logic” produces much cleaner starting points than asking for the whole plugin in one shot.

The “explain this codebase” prompt

I just took over this WordPress plugin/theme. Read through the code and produce: (1) a summary of what it does, (2) the main entry points and how they’re triggered, (3) any concerning code patterns (security issues, deprecated functions, performance problems), (4) the dependencies it relies on. Don’t change anything yet.

This is a Claude Code prompt specifically — it works because Claude Code can actually read all the files. It’s saved me hours on legacy client takeovers.

For the full library, see AI prompts that actually work for WordPress developers.

---

Common failure modes and how to catch them

Specific things AI tools get wrong on WordPress, in roughly the order of how often I see them:

Inventing hook names. Mentioned above. Catch it by grepping the WordPress core or plugin source for the hook name before relying on it. Or paste the AI’s code into Claude Code and ask “verify all hook names used in this code exist.”

Forgetting nonces on forms and AJAX. AI tools generate the form HTML and the handler, but skip the nonce field and the check_admin_referer call. Always grep your generated code for nonce before shipping.

Using deprecated database functions. Less common in 2026 than it was, but Copilot especially still generates mysql_query if it’s in its training data near WordPress code. Ban this in your rules file.

Missing escape functions on output. The most common security issue. AI generates echo $variable; without esc_html(). Your security review prompt should catch this on every PR.

Skipping translation functions. Strings get hardcoded instead of wrapped in __(). Easy to fix in bulk later but easier to prompt for upfront.

Confusing actions and filters. Filter callbacks that don’t return a value. Action callbacks that try to return one. PHP doesn’t error — the bug is silent.

Mixing block editor and classic editor patterns. AI sometimes generates a metabox using the classic editor’s metabox API when you’re working on a block-editor-only site, or vice versa. Specify which editor you’re targeting in your prompt.

Bypassing capability checks. Code that performs a privileged action without checking current_user_can(). AI tools assume the user calling the function is authorized. They often aren’t.

For a deeper dive on auditing AI-generated WordPress code, see How to use AI to audit a WordPress theme for security issues.

---

A real workflow — how I actually use AI on WordPress projects

This is what a typical day looks like. Specific so you can copy what works.

Morning: planning. I open Claude Code in the project I’m working on. First prompt is usually “Read the project, summarize where we left off based on the most recent commits, and list the open todos in CLAUDE.md.” Two minutes, and I have my context back without having to remember.

Mid-morning: feature work. Switch to Cursor for the actual implementation. The pattern I use is: write a one-paragraph description of the feature in a markdown file at the top of my project (PLAN.md), then Cmd+K on each function I want generated, referencing that plan. Cursor’s inline edits are fast enough that I’m not waiting on the AI — I’m reviewing its output as fast as it produces it.

Afternoon: debugging. When something breaks, the prompt I use most is “Here’s the code, here’s the error, here’s what I expected to happen. What’s the most likely cause? Don’t fix it yet — explain first.” The “explain first” matters because AI tools love to fix bugs by adding code, not by understanding them. For a longer treatment, see Debugging WordPress white screen of death with AI assistance.

End of day: review. Before committing anything AI-generated, I run the security review prompt above and skim the diff. Any AI-generated code that I haven’t read line by line doesn’t get committed. This is non-negotiable for me and should be for you.

If you want a worked example of building something end-to-end this way, see Writing a WordPress plugin from scratch with Cursor.

---

When NOT to use AI for WordPress

Counterintuitive section, but it’s the most useful one if you’re early in your AI workflow.

Quick CSS edits. Opening a chat, describing what you want, reviewing the diff — overhead. Just edit the file.

Anything touching authentication or user roles, without a senior reviewing. AI will generate plausible-looking auth code that has subtle bugs. The cost of getting auth wrong is too high.

Database migrations on production. AI can write the migration. AI cannot understand the consequences of running it on your specific data. Run migrations manually on staging first, every single time, AI or not.

The first time you’re learning a concept. If you’ve never written a Gutenberg block before, don’t ask AI to write your first one. You’ll skip understanding the architecture and you’ll be helpless when something breaks. Build one manually, then use AI for the second.

One-line prompts where you don’t know what you want. “Make this better” produces nothing useful. If you can’t write a one-paragraph description of what you want, you’re not ready to ask the AI yet.

---

FAQ

Can AI write WordPress plugins? Yes — Cursor and Claude Code can both generate functional WordPress plugins from a description. Quality depends entirely on how specific your prompt is and whether you’ve configured the tool with WordPress-aware rules. Expect to review and correct security issues (nonces, escaping, capability checks) before shipping.

Is Cursor or Claude Code better for WordPress? Cursor is better for day-to-day editing and small features. Claude Code is better for multi-file refactors, codebase audits, and anything that benefits from running commands (WP-CLI, npm, PHPUnit). Most WordPress developers should use both — Cursor as the default editor, Claude Code for bigger jobs.

Does GitHub Copilot work with WordPress? It works in the sense that it’ll autocomplete WordPress code as you type. It doesn’t reason about your codebase or follow WordPress conventions automatically. As of 2026, it’s the weakest of the major AI coding tools for WordPress-specific work, though it’s perfectly fine as a typing assistant alongside another tool.

Can AI tools handle WooCommerce code? Yes, with caveats. WooCommerce has hundreds of hooks and filters, and AI tools confuse or invent them more often than with core WordPress hooks. Always verify hook names against the WooCommerce documentation before relying on AI-generated WooCommerce code. The “explain first, code second” pattern catches most of these errors.

Is it safe to use AI-generated code on a live WordPress site? Only if you’ve reviewed it. AI-generated WordPress code routinely misses escape functions, nonces, and capability checks. Run the security review prompt on every piece of generated code, test on staging, and never commit code you haven’t read line by line. This is true of any code, but the temptation to skip review is higher with AI.

What about AI for Gutenberg block development? Cursor and Claude Code both handle Gutenberg blocks well. The key is to be explicit in your prompt about which APIs to use (@wordpress/scripts, @wordpress/blocks, server-side rendering vs save.js). The head-to-head section above shows the kind of output you can expect.

Will AI replace WordPress developers? No. It changes what WordPress developers spend time on. Less time typing boilerplate, more time on architecture, security review, debugging weird production issues, and client communication. Developers who treat AI as a typing assistant get marginal gains. Developers who learn to delegate larger tasks while reviewing carefully get substantial ones.

---

Conclusion

The TL;DR hasn’t changed since the top of this article: use Cursor for daily WordPress work, add Claude Code for bigger jobs, skip Copilot unless you already pay for it, try Windsurf if Cursor frustrates you. Configure your rules file. Write specific prompts. Review every line before committing. Never trust AI on auth, migrations, or first-time learning.

The bigger point — the one the rest of the AI-coding internet hasn’t caught up to — is that WordPress is its own thing. Generic AI coding advice doesn’t translate. The hooks system, the security conventions, the WooCommerce ecosystem, the difference between block editor and classic editor: all of it matters, and tools that don’t account for it produce subtly wrong code that ships subtly wrong bugs.

The tools are good enough now that a careful WordPress developer using AI well will out-ship a developer not using it. Be the careful one.

What to read next

• How to set up Cursor for WordPress development — the full configuration walkthrough
• How to set up Claude Code for a WordPress project — including the WP-CLI integration
• Cursor vs Claude Code vs Copilot for WordPress: hands-on comparison — the full benchmark
• Writing a WordPress plugin from scratch with Cursor — end-to-end tutorial
• AI prompts that actually work for WordPress developers — the full prompt library
• How to use AI to audit a WordPress theme for security issues — the security playbook