Most WordPress agencies look broadly similar from the outside. They have case studies, testimonials, and a process page that says something reassuring about communication. What’s harder to assess until something goes wrong is whether they actually know what they’re doing when things get complicated.
These three questions cut through that. They’re not designed to trick anyone. Any competent technical WordPress agency should be able to answer them clearly and without hesitation. If they can’t, that tells you something important.
1. How do you deploy changes, and what’s your rollback process if something goes wrong?
This is the question that separates agencies with a real engineering practice from those who are essentially working on a prayer.
The right answer involves staging environments, a repeatable deployment pipeline, and a tested rollback procedure. Changes should be developed locally or on a staging site, tested, reviewed, and then deployed to production in a controlled and documented way. Rollback should be a defined process.
This needs to be something the team has actually done in the past and not an improvised scramble.
The wrong answer is anything involving making changes directly on the live site. “We’ll just restore from backup” is also a red flag. Backups are a recovery mechanism for disasters. They are not a deployment strategy, and treating them as one means there’s no real process in place! This is just an assumption that nothing will break badly enough to need one.
Deployment practices are a reliable test for engineering discipline across the board. Agencies that handle this well tend to handle QA, version control, and incident response well too. Agencies that don’t tend to wing those things as well.
2. If there’s a critical issue at 11pm on a Friday, what actually happens?
Just answering “We have an SLA in place” is not an answer to this question.
Who receives the alert and how is it triaged? Is it automated monitoring, or does it rely on someone noticing a ping in email or Slack?
Who is on call, and do they have the access and context to act on it? Does the agency even have an on call rota system in place? What about if they need to escalate to someone? What’s the escalation path if the first person can’t resolve it? How quickly does someone with the right skills and permissions actually pick it up?
The reason this question matters is that most production incidents don’t happen at 10am on a Tuesday. You can’t schedule failure!
They happen when your team is unavailable, when the agency’s support desk is closed, and when the business impact is mounting by the minute. A vague response like “we monitor uptime using X app” or “there’s always someone available because Dave never sleeps” is just not the same as a clear description of what actually happens if things go south.
A good answer is specific. It names the monitoring setup, describes how alerts are routed, and explains who picks it up and in what timeframe. It might also acknowledge the honest limits of any systems that are in place. Being human in this situation and 100% honest about what is and isn’t covered, and at what cost, is far more useful than trying to over-promise and then under-deliver.
3. When the engagement ends, what do you hand over?
You should own your code and content. All of it, in full, without restriction. That means everything that was built during the engagement should be in some form of version control like Git, structured in a way that another developer can pick up, and documented to a reasonable standard. It should not be dependent on tools, accounts, or logins that only the agency controls. If you have a more basic “no-code” site then make sure to get a full backup of everything on the server.
Some agencies and freelancers end up holding the keys to things they shouldn’t. I’ve lost count of how many times a client doesn’t even own their domain name or when the client has no idea where or how the site is hosted.
These setups make switching to a new agency difficult, which may suit the current agency but almost never suits you.
A good answer to this question includes specifics like how code in a Git repository you own or can be transferred and how you should expect documentation covering the site architecture and any non-obvious nuances with the site. You should expect a full planned off-boarding process with a structured handover, not just a final invoice and a wave goodbye.
If an agency can’t give you a clear and confident answer to this, treat it as a flag. Either they haven’t thought about it, or they have and they’d prefer not to discuss it.
These aren’t trick questions
Any technically competent agency should be able to answer all three without concern. Clear deployment practices, honest out-of-hours processes, and clean handovers aren’t optional extras they’re the fundamentals of a professional engagement.
If you’re currently evaluating agencies, or if you’ve inherited a WordPress site from a previous partner and you’re not sure what state it’s in, this is exactly the kind of situation we work with regularly. Our Adoption & Rescue service is built for teams who need to get a clear picture of what they’ve got and a plan for what comes next.
