Questions to ask before hiring a web design agency

You have two or three web design quotes in your inbox. The numbers are different. The promises sound similar. None of the proposals give you a clear way to tell which agency actually knows what they are doing.

This is the list of questions I would ask if I were sitting where you are sitting. Most of these a real practitioner can answer in thirty seconds. Your job is to listen for whether the agency has thought about any of this before. The answers do not have to match mine. They have to exist.

I have cleaned up enough relaunched WordPress sites in Milwaukee to know which questions surface the cracks early. Here are the twelve.

Ownership and what you are left with

1. Who owns my domain, and where will it be registered?

A domain quietly registered under the agency’s account is a problem you do not see until you want to leave. I have watched a business owner spend three weeks and a lawyer’s billable hour trying to recover a domain a previous developer had bought under a personal GoDaddy. The site worked. The marketing worked. Nothing in the engagement told the owner that the title to the front door of the business was not theirs.

A strong answer: the domain lives in your account, in your name, with you as the WHOIS registrant. The agency has access to manage DNS, but they do not own the asset. If they registered it on your behalf to save you the friction, the transfer auth code is documented somewhere you can find without asking.

If you hear “we manage that for you,” ask the next question more slowly.

2. Will the site be in version control, and will I have access to the repository?

No version control means every fix gets uploaded to production directly. There is no rollback. There is no history of who changed what. Years later, when something breaks, nobody can answer the question of what changed last Tuesday because nothing tracks it.

A strong answer: the site lives in a Git repository at GitHub, GitLab, or Bitbucket. You are added as a collaborator at handoff. Every change is a commit with a message. Deploys happen by pushing to a branch, not by dragging files into Filezilla.

This question also doubles as an exit question. If you ever want to switch developers, the new one will ask for the repository within the first five minutes. The agency that cannot hand one over is the agency that built you a site you cannot leave.

3. Are you going to build this on a page builder like Elementor, Divi, or Bricks?

Page builders are fast to start and expensive to leave. The marketing pitch is that you will be able to edit anything yourself. In practice, you will not edit anything yourself, and the next developer you hire will quote you a rebuild because nobody wants to inherit somebody else’s Bricks project.

I have inherited a site that used a page builder for the homepage. The visible page rendered fine. The database still held thousands of bytes of abandoned block markup from a previous builder the agency had migrated off two years earlier. Two builders worth of layout code, both still in the row that the homepage loads from every time. Future you cannot tell what is source of truth.

A strong answer: custom-coded theme, or a block theme with structured fields. The next developer can read the codebase without a license. You can leave the agency without rebuilding the site.

If the agency says they only build with one specific page builder, ask them what the migration story looks like when the builder stops being maintained. There is no good answer to that question. The good answer is to not be in the situation.

Process and the working relationship

4. Who specifically is doing the work? You, or someone else?

This is the most common pattern in the agency world. The senior partner sells the project. The contractor two years out of school builds it. By the time you realize the person on your kickoff call is not the person writing your code, the contract is signed.

A strong answer: a named person, ideally the same person sitting across from you. If a team is involved, you should know who reviews the code before it ships, who you can email when something breaks, and what happens when that person goes on vacation.

“We have a team” tells you nothing. The answer you are looking for sounds more like this: “I write it, my designer handles visual review, and I am the person you will email.”

5. Will I have a staging environment from day one, or only at launch week?

Staging from day one means every change is reviewed on a real URL before it touches your live site. Staging at launch week means the agency has been building blind in a local environment for six weeks and you will see the site for the first time three days before it goes live.

There is a specific failure mode I have seen on relaunches built without a real staging environment. The agency builds locally, where the site URL is something like http://localhost:8881. Hundreds of references to that local URL bake into the database in subtle places. Background image fields. Page builder configurations. Hero blocks. JSON-escaped variants. On launch day, nobody runs a final scan for the development URL. The site goes live with broken images on dozens of articles, and nobody notices for days because the homepage looks fine.

A strong answer: a staging URL within the first week, accessible to you, that mirrors the production environment. Every change ships to staging before production. A documented checklist runs against staging before launch.

6. What plugins will you install, and why each one?

Plugin sprawl is real. I have looked at WordPress sites with forty active plugins doing what five could do. Every plugin is three things at once: a security surface, a performance cost, and an update conflict waiting to happen. The agency that installs everything is also the agency you will be paying a maintenance retainer to forever, because somebody has to keep all of them updated.

A strong answer: a short list with a one-line justification per plugin. SEO, form handling, security, caching. Anything else gets defended. The agency that needs ten plugins to render a page is the agency that is going to charge you a lot of money to maintain ten plugins forever.

One specific thing to listen for. I once audited a site that had an admin-only “Custom Scripts” tab from a plugin that let any administrator inject arbitrary JavaScript into every page of the site. Combined with a default admin username and no two-factor authentication, a single password compromise would have meant the attacker could plant malware on every page the site served. The plugin was on the agency’s standard install list because it was useful. Useful does not mean safe.

SEO and traffic continuity

7. What is your plan for redirecting my old URLs so I do not lose existing rankings?

This is the single most common silent failure of a website relaunch. The new site goes live with cleaner URLs. The old URLs return 404. Google deindexes them over the next thirty days. Your search traffic falls off a cliff and nobody can explain why because nothing visibly broke.

A 301 redirect map should be built before launch, not after. Every entry in the map should be verified to land on a page that returns 200. I have seen redirect lists that pointed at slugs that did not exist on the new site, including one redirect for a Jacksonville city page that had a triple-L typo in the destination slug. That redirect 301’d two inbound URLs into a 404 for three days before anyone noticed.

A strong answer: an explicit list of old URLs mapped to new URLs, written before launch, tested against the staging site, and committed to version control alongside the rest of the project. The agency knows what an .htaccess file is, or has a redirect plugin configured, or has nginx rewrites in their deploy.

If the answer is “WordPress handles redirects automatically,” it does not.

8. What happens to my Google Business Profile and Knowledge Panel when we relaunch?

If your business shows up in Google search with a side panel that has your phone number, hours, and photos, that is your Knowledge Panel. It is fed partly by your Google Business Profile and partly by structured data on your website. A relaunch can knock that panel out for weeks or months if the schema on the new site does not match what Google has on file.

I have audited a site where the Knowledge Panel disappeared for six weeks after a relaunch. The website schema shipped with name, URL, and logo. No address. No phone number. No hours. No social profile links. The phone number on the website did not match the phone number on the Business Profile. The Knowledge Panel had to rebuild itself from a near-zero signal state, and the rebuild took as long as it did because every signal it checked against the website failed.

A strong answer: organization schema written to match the Business Profile exactly, including address, phone, hours, geo coordinates, and social profile links. NAP consistency (name, address, phone) checked across major citation sites. The agency knows what Google’s Rich Results Test is and has run the new site through it.

“We use an SEO plugin for schema” is the answer to a different question.

Cutover

9. What is the plan for my email when DNS changes?

If your email runs on your domain, your email is one nameserver change away from breaking. The site flips to a new hosting provider. The nameservers move. The MX records, which point email to wherever your email provider lives, do not come along automatically. Email stops arriving. Nobody can reach you. The agency does not notice because the agency is not the one expecting email.

A strong answer: MX records, SPF records, and DKIM records are documented before any DNS change. If the nameservers move, those records are reapplied at the new provider before the switch. Email gets tested after the cutover by sending and receiving a real message.

If the agency says they do not handle email, ask who does. The answer is usually nobody, which is the answer you needed.

Leads and data

10. How will you keep my contact form submissions from silently failing?

A form that only emails the agency is a single point of failure with several places to break. The email goes to spam, or the plugin update fails, or the SMTP provider rejects the message. The submission disappears and nobody finds out until somebody asks why a lead never followed up.

I once worked on a form that was supposed to push leads into Salesforce. The site looked like the submissions were going through. The visitor saw a success page. Internally, Salesforce was silently rejecting most of the submissions because the website was sending friendlier values than Salesforce’s restricted picklists accepted. A field called Industry sent “E-commerce.” Salesforce wanted “Ecommerce.” The lead disappeared into a rejection log nobody was reading. By the time anyone noticed, the sales team had been sitting idle for two weeks.

A strong answer: the submission writes to the WordPress database first, before any email or CRM sync, so a lead is never lost even when downstream systems fail. Email and CRM are secondary destinations with their own logging. Failures show up in the admin where somebody can see them. Any picklist field that maps to a CRM has a documented value mapping and a server-side fallback.

11. How do you handle a GDPR or data-deletion request for the leads we collect?

Every business that collects leads will eventually get a deletion request. Sometimes it is a state-level privacy law. Sometimes it is a customer asking. Either way, the request is binding and the clock is short.

If your leads live in WordPress and a CRM and an email tool, the agency needs a plan for deleting from all three. Most agencies have a plan for deleting from WordPress. A surprising number have never thought about the rest.

A strong answer: a written privacy policy that names the data stores. A documented deletion path that has been tested. If the CRM does not have a deletion API, that is named as a manual step. Nobody is pretending the problem is solved if it is not.

A blank look is its own answer.

Contract

12. What is not included in this quote? Walk me through what a change order looks like.

Every agency knows what is in the quote. Fewer of them can clearly tell you what is not. Things commonly left out: an accessibility audit. A second round of revisions after launch. Photography. Real copywriting. SEO research. Schema markup. A documented backup procedure. Performance testing on a real device. Any of these can be a line item, and the question is whether you find out before or after you sign.

I once worked on an accessibility audit that uncovered seventy-two contrast failures across seven page templates, plus a dropdown navigation that could not be operated by keyboard. None of that work was in the original build’s scope. None of it was even tested. The audit landed after launch as a separate engagement because nobody had asked the question up front.

A strong answer: a written scope document with explicit inclusions, named exclusions, the rate for additional work, and a list of the decision points where scope can change. If there are stages in the build at which you can add work, those are named. The agency does not hide behind “we’re flexible.”

“We’re flexible” usually means “we will tell you the price after the work is done.”

A closing thought

Not every project surfaces all twelve of these. Some businesses do not run email on the domain, others have no Knowledge Panel to protect, and plenty have never collected a lead in their life.

Use the list to hear how the agency thinks. The answers do not have to match mine. They have to exist, and they have to sound like the agency has been here before. If you walk through this list and you hear “we’ll figure that out when we get there” on more than two of these, you have learned something you needed to learn.

If you want to walk through these questions about a project you are weighing, send me the details. I built this site so I could answer all twelve in plain language, on a real call, before anyone signs anything.