Blog - 11 questions to ask your WordPress developer (before you instruct them)

Here’s a list of questions to ask your WordPress developer before you instruct them to do any functional or application-level development.

This comes from recent work I’ve been involved with, and it really struck me how many developers don’t have a plan for the fundamentals—yet they still win projects. Clients end up disappointed and wondering why the build didn’t become the success they were promised.

If a developer can answer the questions below clearly and specifically, you’re probably in safe hands. If they can’t, walk away.

1) How will background jobs run? (wp-cron vs real server cron)

• Why it matters: Imports, feeds, emails, indexing and clean-ups depend on reliable scheduling. wp-cron (traffic-triggered) is flaky at scale.
• Good answer: “We’ll disable traffic cron and set a server cron to call wp-cron.php every 5 minutes (or WP-CLI). We’ll surface failed jobs (Action Scheduler) in the admin and logs.”
• Red flags: “wp-cron is fine” / “We’ll just rely on traffic.”

2) What’s your plan to prevent wp_postmeta bloat?

• Why it matters: Page builders and mass page generation can explode table size and kill backups/performance.
• Good answer: “We’ll keep reusable components in code, not 10k cloned builder pages; we’ll limit custom fields, index critical keys, archive old revisions, and monitor table growth. If landing pages are required, we’ll generate them programmatically with lean templates (not Elementor JSON).”
• Red flags: “We’ll make thousands of Elementor pages for SEO.”

3) What are the hosting & database capacity requirements?

• Why it matters: Hitting plan limits (MySQL quota, RAM, I/O) breaks writes, cron, and backups.
• Good answer: “We’ll size the host: PHP 8.x, memory limit ≥ 512MB, Redis object cache, and document DB growth expectations (tables, rows, GB). We’ll confirm provider limits and headroom.”
• Red flags: “Any shared plan will do.”

4) How will email deliverability be handled?

• Why it matters: WordPress can’t send reliably from the server; failed emails = lost leads.
• Good answer: “We’ll use SMTP or a transactional service (Postmark, SendGrid, Mailgun), authenticate with SPF/DKIM/DMARC, and add failure alerts.”
• Red flags: “PHP mail() is fine.”

5) What is the deployment workflow (staging → production)?

• Why it matters: Editing on live risks downtime and data loss.
• Good answer: “We’ll develop in staging, version theme/custom plugins in Git, and deploy through a repeatable process. We’ll plan content-aware DB changes and asset sync.”
• Red flags: “We’ll build on live” / no mention of version control.

6) Who owns licences and what happens at handover?

• Why it matters: Vendor-owned keys can brick your site later.
• Good answer: “All licences are purchased to your accounts and documented. On handover you receive files, DB, keys, and a runbook. We never leave you locked to our infrastructure.”
• Red flags: “We use our agency keys; you’ll be fine. Any custom code is ours too”

7) What is your security & hardening plan at launch?

• Why it matters: Debug logs, admin exposure, weak perms and default settings are common own-goals.
• Good answer: “We’ll disable WP_DEBUG_LOG on prod, restrict editor and XML-RPC as needed, enforce least-privilege roles, rotate keys/salts, add WAF/CDN (e.g., Cloudflare), implement server cron, bot rules, and rate limiting.”
• Red flags: Silence on hardening; leaving debug on.

8) How will you monitor, log and back up the application?

• Why it matters: If you can’t see errors or restore quickly, you don’t have a production system.
• Good answer: “Daily off-site backups (files+DB) with 30-day retention and scheduled test restores; error logging with rotation; uptime checks; database table health reports; clear recovery runbook.”
• Red flags: “Your host has backups.”

9) What’s your performance strategy?

• Why it matters: Speed affects UX, SEO and server bills.
• Good answer: “We’ll use page caching (LSCache/NGINX/FastCGI), object caching (Redis), lazy assets, critical CSS, and image optimization; measure with Lighthouse/WebPageTest; CDN for media; define budgets (TTFB, LCP).”
• Red flags: “We’ll install a cache plugin and it’ll be fast.”

10) How will URLs, sitemaps and deprecation be handled?

• Why it matters: Big content changes without proper status codes cause crawl waste and SEO decay.
• Good answer: “We’ll manage redirects with rules, remove dead mass pages with 410 Gone (not endless 404s), curate sitemaps, and submit changes in Search Console; no auto-sprawl of thin ‘AI SEO’ pages.”
• Red flags: “We’ll just 301 everything” / “AI will generate thousands of pages.”

11) How will you handle SEO (without wrecking performance or the data model)?

• Why it matters: SEO isn’t “install Rank Math and pray.” Poor choices (e.g., mass AI pages, duplicate archives, crawl traps) bloat wp_postmeta, hammer the DB, and waste crawl budget.
• Good answer:
• “We’ll design information architecture first: CPTs/taxonomies, canonical URLs, and faceted navigation rules.
• We’ll generate lean, templated pages (code-driven) rather than thousands of cloned builder pages.
• We’ll control indexation (robots, noindex on thin archives, canonical tags), and serve sitemaps per type.
• We’ll implement structured data (JSON-LD) for listings, org, and breadcrumbs.
• We’ll use 410 for removals (not endless 404s), stable redirect rules, and prevent parameter crawl traps.
• Technical performance: Core Web Vitals budgets, CDN, caching/object cache, image optimization.
• We’ll document what the client team can safely edit and we’ll monitor Search Console for errors.”
• Red flags:
• “We’ll auto-generate thousands of location pages with a page builder.”
• “We’ll just install Yoast/Rank Math.”
• No plan for canonicals, structured data, crawl management, or performance budgets.

Bonus mini-questions (fast tells)

• Integrations: “Show me your approach to secrets management for API keys.”
• Data model: “Which custom post types/taxonomies vs custom tables will you use and why?”
• Action Scheduler: “How will failed tasks be surfaced and retried?”
• Docs & handover: “What documentation will I receive? Who can run the site if you disappear?”
• SLAs: “What’s your response time for P1 outages post-launch?”

How to score answers

• Professional: Mentions server cron, object cache, capacity planning, licence ownership, staging, Git, logging/monitoring, and documented handover.
• Cowboy: Hand-waves with “plugin fixes,” mass builder pages for SEO, agency-owned licences, edits on live, or ignores capacity/security.

Hand this to any prospective developer. The ones who light up and start talking specifics are the ones you want building an application, not just a website.