How to Choose a WordPress Developer: A Buyer's Checklist

01 / 08

Why choosing well matters more than choosing fast

I build WordPress sites for a living, and a fair share of my work is rebuilding sites that were built badly the first time. The pattern is consistent: the owner chose on price or on portfolio screenshots, and the problems surfaced months later as slow pages, plugin conflicts, or a site nobody could safely edit. A rebuild almost always costs more than a correct first build.

This checklist is what I would use to evaluate any WordPress developer, including me. None of it requires technical skill. It requires about an hour of homework and a willingness to ask direct questions.

02 / 08

Read the portfolio like an inspector, not a shopper

Screenshots hide everything that matters. Ask for live URLs and open them on your phone, because that is where most of your visitors will be. Watch how fast the first screen appears, whether text shifts around while loading, and whether the menus and forms actually work with a thumb.

Then ask which parts of each site the developer actually built. Some portfolios are template installs with the demo content swapped out. There is nothing wrong with building on Elementor — I use it daily — but you want someone who designs interfaces and structures pages, not someone who only changes the colors on a template.

• Open three portfolio sites on your phone and pay attention to the first load.
• Resize a desktop browser window and watch whether layouts break.
• Ask "which parts of this were custom?" and listen for specifics.
• Check that the portfolio sites are still online and still maintained.

03 / 08

The developer's own website is your first audit

A developer's own site is the one project with no client constraints, so it shows you their real standards. Run their domain through Google's PageSpeed Insights — it is free and takes a minute. Look at the Core Web Vitals results: whether the page loads quickly, responds quickly, and holds still while it loads.

Perfection is not the standard here; consistency is. If someone sells fast websites from a slow website, that gap will appear in your project too. It is the reason I treat website performance as part of the build itself, not an optimization sold afterward.

04 / 08

Five SEO questions that reveal real literacy

You are not hiring an SEO agency, and you should be suspicious of a developer who talks like one. But the technical foundation of search visibility — clean markup, heading structure, metadata, schema, fast loading, crawlable pages — is set during development. A developer who cannot explain these will hand you a site that needs expensive rework before it can compete.

These questions reflect how I approach SEO-friendly development on every project: metadata, internal linking, and schema are implemented as part of the build, and the site is verified in Google Search Console before handoff. Any developer worth hiring should be able to describe an equivalent process without hesitation.

• "How will you structure headings and metadata on each page?" Expect a plain, systematic answer, not buzzwords.
• "What schema markup will my site ship with?" A business site should at least carry Organization or LocalBusiness markup.
• "If this is a redesign, what happens to my existing URLs?" The only acceptable answer involves redirects mapped before launch.
• "How do you keep Core Web Vitals passing on a page-builder site?" Listen for image handling, asset loading, and hosting choices.
• "How do you make the site readable for AI search?" Clear content structure and schema matter, because answer engines cite pages they can parse.

05 / 08

Plugin discipline separates builders from assemblers

Plugins are where WordPress sites quietly rot. Every plugin is code someone else wrote, running on your server, requiring updates forever. Ask any developer you are evaluating for the plugin list they intend to use and the reason each one is on it.

Good discipline looks boring: one page builder, one SEO plugin, one caching layer, one security layer, each doing a job nothing else does. Bad discipline looks like two plugins doing the same job, plugins installed to patch problems other plugins created, or nulled premium plugins — pirated copies that routinely carry malware. A developer who can write a few lines of PHP or CSS will often solve a problem without adding a plugin at all.

06 / 08

Ask what happens after launch

A WordPress site is not a finished object. Core, themes, and plugins ship updates constantly, and unpatched sites are the ones that get hacked. Before signing, get clear answers on who applies updates, how backups run, where those backups are stored, and what happens when something breaks at 2 a.m.

Hosting belongs in this conversation too. Ask where the site will live, who controls the server, and whether SSL, a firewall, and automated backups are configured from day one. I run client sites on VPS servers I administer directly — DNS, SSL/TLS, security hardening, and backup schedules included — because the server is part of the product, not someone else's problem.

07 / 08

Ownership: you should hold every key

This is the checklist item that saves businesses from disasters. You — not the developer — should own the domain registration, the hosting account, and an administrator login to WordPress itself. Insist on receiving that access early in the project, not after the final invoice clears.

Ask about plugin licenses as well. Premium plugins purchased under a developer's own license stop receiving updates if you ever part ways. Know which licenses are yours, which are theirs, and what replacing them would cost.

• Domain registrar account in your name.
• Hosting or server account in your name, or documented full access.
• A WordPress administrator user that belongs to you.
• A written list of premium plugin licenses and who owns each.

08 / 08

Red flags, and what a good process feels like

Some signals should end the conversation regardless of price: a guarantee of first-page rankings, refusal to share live portfolio URLs, resistance to giving you admin access, a quote with no written scope, or vagueness about plugins and hosting. Each of these predicts a specific, expensive problem later.

A good process feels plain by comparison. You get a written scope, a realistic timeline, questions about your business before any design talk, and technical decisions explained in ordinary language. When a good developer says no to a request, they tell you why.

If you are comparing developers right now, use this list on me too. My WordPress development and website redesign work is meant to pass every check on this page — ask me the five SEO questions above and I will answer them in writing at info@mustafadev.org.