Twelve Questions to Ask Before You Hire a WordPress Developer

Ask the candidate to choose two relevant examples and explain their responsibility on each. Designing a homepage, configuring a purchased theme and building a custom booking integration are different contributions. All can be useful, but the evidence should match the work you are buying. If confidentiality limits a demonstration, a redacted walkthrough or a permitted reference can still explain the role.

Open a relevant site on your phone and attempt an ordinary journey: find a service, open a menu and reach the contact form. Discuss an observed problem without treating another client's current website as a complete assessment of the original work. Listen for a specific explanation of scope, constraints and what the developer would investigate.

Name the domain registrar, hosting, DNS, email, analytics and source repository separately. Ask whose organisation and recovery email will control each account. A WordPress administrator login does not give you control over a registrar account or hosting subscription. Record any existing accounts that will be retained.

Ask the contract to identify custom code, design files, content and third-party components. WordPress is distributed under the GPL, while stock assets, commercial subscriptions and other deliverables may have separate terms. A useful answer distinguishes those terms and states what you receive. Treat a vague promise that you will own everything as a request for clarification, rather than legal certainty.

Ask to see the proposed access model. Staff should have named accounts with the permissions they need. The person editing articles may not need administrator rights, while an authorised business owner still needs a documented way to recover administrative control. Multi-factor authentication and recovery codes need a responsible owner.

Avoid emailing a spreadsheet of working passwords as the handover. Agree on secure invitations or a managed password-sharing process, a record of service accounts, and a date for removing temporary access. The OWASP session guidance explains why a login session is itself sensitive; access management includes active sessions and integration credentials as well as passwords.

Ask the developer to demonstrate a representative edit: change a heading, replace an image and add a repeatable content item. See whether the editor can do it without breaking the layout. Custom code and page builders both need maintenance; the right answer explains the trade-offs for your actual content and team.

Request the recurring licence costs, the source of any premium components and the consequences of an expired subscription. Ask whether another developer can maintain the chosen stack. An unfamiliar tool is not automatically a problem, but a dependency that only one contractor can operate creates a continuity cost that belongs in the proposal.

Get a list of templates, content quantities, integrations, revision rounds and responsibilities. State who writes copy, obtains image rights, imports products and signs off payment or email settings. A list of pages alone cannot describe the effort involved in a multilingual shop or a migration with hundreds of redirects.

Ask how a change is requested, priced and approved before it is built. For example, a second payment provider discovered during development should produce a documented scope decision. This makes quotes easier to compare and prevents a low initial figure from hiding necessary work. Record assumptions whose failure would change the price or schedule.

Ask for a staging environment, a short review schedule and a named decision-maker on each side. Staging should avoid exposing confidential content, sending real customer messages or taking live payments. Search-engine exclusion alone is not access control; a private review environment needs appropriate protection.

Request a demonstration of one complete journey early in the project. A working form with validation, a confirmation state and a controlled delivery test reveals more than several static screenshots. Agree how feedback is collected and what counts as acceptance. Milestones should describe observable results and the client inputs needed to achieve them.

Ask for a test checklist covering mobile navigation, keyboard use, form errors, delivery, relevant checkout states, redirects and a missing URL. Require confirmation of what was tested and in which environment. A successful build or a screenshot of a speed score does not establish that a real business journey works.

Identify checks requiring your participation, such as approving a test enquiry or verifying a payment settlement. Agree who supplies the test accounts and which external systems are safe to use. A good response names limits honestly, including any third-party service that cannot be fully tested before its owner completes setup.

Ask which representative pages, devices and visitor journeys will be measured. A cached homepage and a logged-in checkout have different workloads. The proposal should identify image handling, script costs, caching and field measurement where available, rather than promising one score for every page.

For a migration, request an old-to-new URL map, redirect tests, canonical checks and a sitemap review. Ask who checks that private staging settings do not reach production. Search visibility depends on more than a developer's work, so guaranteed ranking claims deserve scrutiny. The hiring overview helps compare the wider service fit.

Ask whether backups include the database, uploads, configuration and custom code, how often each is captured, and where copies are stored. A recent backup is useful only if someone can restore it with the access and tools available during an outage. Request evidence of a controlled restoration test.

For a store, discuss the risk of losing orders placed after the last backup. Agree who makes the decision to restore and how recent business data will be reconciled. A development rollback and a database restore are different procedures. The answer should name an owner and describe a recovery process, rather than simply naming a backup plugin.

Request a repository or source export, build instructions where needed, an account inventory, a licence register and instructions for common edits. Ask for a recorded training session using the actual site. The handover should distinguish routine content changes from tasks requiring a developer.

Make acceptance practical: someone on your team logs in with their own account, makes a test edit, locates a backup and finds the support contact. Documentation that exists only in a contractor's private workspace has not been delivered. Include the website handover checklist in the final review once the build is complete.

Separate a defect against the agreed scope from new functionality, routine updates and incidents caused by another service. Ask for the support period, working hours, contact route and expected acknowledgement time. A promise of support needs a boundary and an escalation path.

Discuss an example: the contact form stops delivering on a weekend. Who receives the report, who can inspect the mail service, and what temporary contact option remains? Do not assume a solo developer offers continuous coverage. The maintenance plan guide explains the recurring work to compare alongside the build price.

Translate the call into a short acceptance worksheet. For each item, record the promised evidence, its owner and the review date. Ask the candidate to correct misunderstandings before the proposal becomes a contract. That conversation often exposes a mismatch early enough to solve it.

A useful final review covers the working journeys, ownership access, source handover, training, backup recovery and unresolved issues. Tie commercial milestones to the contract you actually agree, with appropriate professional advice when needed. The decision is whether the two parties can describe the same deliverable and prove that it was received.