You do not need to interrogate a web designer like they are applying for a security clearance. You are not trying to catch anyone. You are trying to find out one thing: does this person see a website as a set of pages, a working business system, or something in between — and is that the thing you actually want to buy?

Here is the part most "questions to ask" lists skip. The questions barely matter. Any competent provider can produce a smooth answer to "who owns the domain" or "is it mobile-friendly." What tells you something is what happens to the answer when you ask one more question. A real answer gets more specific under a follow-up. A sales answer gets vaguer, changes the subject, or repeats itself louder. You are not testing whether they know the vocabulary. You are testing which direction the specificity moves.

So this article is built around the follow-up, not the opener. For each thing you need to know, here is the question, what a useful answer actually sounds like, what an empty answer sounds like, and the single follow-up that separates them. You do not need every technical detail on the first call. You need to hear whether specificity rises or falls when you push.

What problem do they think you have

Ask: "Based on what you've heard, what problem should this website solve?"

A useful answer names the audience, the business goal, the current constraint, and what they'd still need to check — something like "your best-earning service is buried, the contact path can't be verified, and I'd want to see the current form and Search Console before I say more." An empty answer jumps straight to fashion: the site looks old, competitors have animation, the homepage needs more energy. Visual quality is real, but it is not a diagnosis.

The follow-up: "What would you need to look at before you were sure a rebuild is the right call?" A strong provider can name the evidence — pages and their jobs, search performance, forms and lead records, mobile and keyboard tasks, performance data, platform and ownership constraints — and will tell you the honest verb: keep, repair, restructure, migrate, or rebuild. If every possible answer somehow leads to their largest package, you have learned something about the audit, not about your site. (What that inspection should actually cover is its own subject — see "What a Website Audit Should Check Before Recommending a Redesign.")

What is included, excluded, and assumed

Most painful website disputes are scope disputes that were allowed to stay polite and vague.

Ask: "What's included, what's excluded, and what are you assuming I'll provide?"

A useful answer is specific in nouns and verbs — number and type of pages, whether copywriting is included or you supply it, who handles photography and licensing, which integrations are in scope, what accessibility work (and to what standard) is claimed, whether migration and redirects are included, and what "training and support" means. An empty answer leans on words that sound complete and price nothing: "standard integrations included," "full-service," "turnkey." Standard does not tell you whether the scheduler, CRM, call tracking, and form database you actually use are covered.

The follow-up: "When you say 'client provides content,' do you mean raw facts, or finished approved copy and correctly sized, licensed images?" The gap between those two is often the whole difference between the quoted timeline and the real one. (For what a complete scope looks like, see "What Small-Business Web Design Services Should Actually Include" and "How to Read a Website Redesign Proposal Before You Sign It.")

Who is responsible for what

Projects stall because everyone believes someone else owns the content and the decisions.

Ask: "For each input this needs, who produces it, who approves it, and what happens when it's late?"

A useful answer assigns real people to the facts, the copy, the proof, the images and their rights, any regulated claims, account access, and the final launch approval — and is honest that the provider does not perform every role. An empty answer says "we'll figure it out as we go," which means the schedule will discover the gaps in production, at production prices.

The follow-up: "Who can give binding feedback?" A website can survive a committee. A schedule may not survive five people editing the same paragraph in different directions. A provider who has thought about this will have a way to resolve conflicting feedback into one instruction.

How the important parts get proven

This question separates a finished appearance from a finished system.

Ask: "What evidence will I get that the forms, calls to action, analytics, and launch actually work?"

A useful answer describes proof, not vibes: a form submission that is saved to a real record, notified to the right person, and confirmed to the visitor; working phone, email, map, and file links; representative mobile and desktop layouts; keyboard operation; analytics events that are defined and trigger-tested; redirects from important old URLs; and the error and empty states, not just the success state. The format can be a checklist, test records, screenshots, a recording, or a live acceptance session — the format matters less than the claim behind it. An empty answer is "we test everything before launch."

The follow-up: "'Form tested' — where was the inquiry saved, who got the notification, and what happens if the notification fails?" A thank-you message on screen proves the interface showed a thank-you message; it does not prove an email arrived or that anyone will respond. Treat an accessibility or PageSpeed score the same way — it is a signal, not a promise that every customer had a fast, usable, successful experience. (The full lead-path test is its own procedure — see "How to Test Whether Your Contact Form Is Actually Losing Leads" — and what an accessibility checker can and can't prove is covered in "What a Website Accessibility Checker Can—and Cannot—Prove.")

What moves the price and the calendar

Ask: "What would make the price or the schedule change?"

A useful answer names the boundaries the estimate already contains — new pages or functionality, content arriving incomplete, extra revision rounds, an integration that needs custom work, missing account access, unexpected migration or data cleanup, a stakeholder reversing an approved decision, an immovable launch date that forces scope down — and describes a simple change process: written description, price or schedule effect, your approval, then the work. An empty answer gives you a single confident number with no visible conditions, which usually means the conditions arrive later as a memory contest.

The follow-up: "Can you show me dependencies, not just a date — which tasks run in parallel, which input controls the critical path, and what would make it slip?" A schedule that can't show what would delay it hasn't found the real work yet. (What actually drives a website timeline is its own article — see "How Long Does It Take to Build a Small-Business Website?")

What you will actually own

"You own your website" is not a complete answer. Website ownership is a bundle of separate things, and the useful providers are the ones who can take the bundle apart.

Ask: "Which accounts, files, data, and licenses will the business control?"

A useful answer separates them without being prompted: domain registration and DNS; the hosting or platform account; billing and renewal; source code or export rights; the copy and original design; licensed stock, fonts, plugins, and themes; analytics, Search Console, and business listings; form submissions and lead data; design source files; and backups. ICANN describes the registrant as the person or entity that registers the domain and manages its settings through the registrar — so confirm the business is the intended registrant and can reach the registrar, even if the provider helps administer it.

Copyright is worth getting in writing, and here the law is specific enough to be useful. Under U.S. copyright law, ownership initially vests in the author of the work, and unless a valid work-made-for-hire arrangement or a signed written transfer applies, the person who created the work can retain rights even after you pay for it — a transfer of copyright ownership generally has to be in a writing signed by the owner of the rights. Paying an invoice and receiving a copy of a file are not, by themselves, the same as receiving every copyright right. That is a factual reason to make the contract specific; it is not legal advice about your particular agreement, and where the rights matter, have qualified counsel read the ownership language.

The follow-up: "If we split up, what exactly can I take, and what stops working?" (Ownership and exit terms belong in the contract — the depth is in "What a Website Design Contract Should Say About Ownership, Access, and Exit.")

What happens after launch, and if it ends

Ask both while everyone still likes each other.

Ask: "What support is included after launch, who owns a failure, and what happens if we stop working together?"

A useful answer distinguishes what "maintenance" actually contains — software updates, uptime checks, an hour of edits, emergency response, or merely keeping the hosting paid — and names who monitors the forms, who tests updates, who holds backups and has actually restored one, and what response applies to a broken lead path. On exit, it covers notice terms, domain and DNS continuity, data and content export, backup delivery, license limits, and removing the provider's access after handoff. An empty answer is "maintenance is included" with nothing behind it.

The follow-up here is the honest boundary, and it protects both sides: a provider can preserve and deliver a captured inquiry, but they cannot guarantee your business qualifies, responds to, quotes, closes, or collects revenue from it unless that downstream work is a separately named service. "No lock-in" also does not mean "no transition work" — a hosted platform may keep the site up only while a subscription runs, and a custom integration may depend on a paid service. The right exit answer is not "you get every file we ever touched." It is specific enough that you can predict the exit before it happens. (For the full handover, see "How to Change Web Designers Without Losing Your Website, Domain, Email, or Leads.")

A field guide to answers that need one more question

Some answers are incomplete for a good reason — the provider hasn't inspected your site yet, and precision before discovery is sometimes just theater. Don't reject these; push once and watch which way they move.

What you hear What it might be hiding The follow-up
"It depends." An honest pre-inspection answer — or a way to avoid committing. "Depends on what, and how will you resolve it?"
"We use our standard process." A real process — or a template with no acceptance evidence. "Can you show me the milestones, who owns each, and how completion is proven?"
"You own everything." A true statement — or a blur over copyright, licenses, accounts, and data. "Can you separate the domain, accounts, copyright, licenses, data, and source files?"
"We handle SEO." Technical setup — or an implied ongoing campaign that isn't scoped. "Which parts: technical controls, migration, local listings, content, links, reporting?"
"We make accessible websites." Real work — or a plugin and a score. "Which guidelines, which pages and tasks, which manual methods, and what conformance are you claiming?"
"Maintenance is included." Genuine support — or paying the hosting bill. "Who responds, what's monitored, what gets updated, and what evidence do I get?"

In every row, the tell is the same: a real answer gets more specific, a selling answer gets more general. You are not trying to catch someone using the wrong phrase. You are turning shorthand into scope while it's still cheap to do.

The short version for your first call

Copy this into your notes. You will not get through all of it, and you don't need to — three good follow-ups tell you more than ten unanswered questions.

  • What problem do you think this website should solve — and what would you inspect before saying "rebuild"?
  • What's included, excluded, and assumed — and what does "client provides content" mean exactly?
  • Who produces and approves the content, assets, and business claims, and who can give binding feedback?
  • What evidence proves the forms, actions, analytics, and launch actually work?
  • What would change the price or timeline, and can you show dependencies, not just a date?
  • Which accounts, code, data, and licenses will I control — and is the business the domain registrant?
  • What's in "maintenance," who owns a failure, and what happens if we split up?

Bring it, but listen for the trajectory, not the transcript. The goal is to know whether this provider sees a website the way you do — and whether that's the product you meant to buy.

If you're evaluating RP, ask the same questions. The packages and monthly fees are published, and the current offer says no retainers and no lock-in — which is only useful if the scope and the exit are still made explicit, in writing, the same way you'd expect from anyone else. A buyer-protective list that its own author can't answer isn't worth much.

Sources