Questions to ask a web designer before hiring: an evidence-first scorecard
Do not choose a web designer from a portfolio alone. Before hiring, ask how the provider will turn your business goals into pages, what you must supply, what will be tested, what you will control, and who is responsible after launch.
Use one rule for every answer: ask what you will be able to see, test or retain. “We handle SEO” is a promise. A page-and-URL plan, launch checks and an agreed measurement owner are evidence you can discuss. A useful answer names a deliverable or demonstration; a vague one leaves a risk for you to resolve.
This guide is for a small service-business owner who has already decided to seek professional help. If you are still choosing between building the site yourself and hiring someone, start with our DIY website versus professional web designer guide.
The nine-question interview scorecard
Use the same questions with every shortlisted provider. Keep the answer and the evidence separate.
| Ask about | A clear answer should identify | Evidence to retain or see |
|---|---|---|
| Website job | Primary visitor, decision and next action | Proposed page map and enquiry path |
| Scope | Included work, exclusions and your inputs | Written scope and responsibility list |
| Relevant work | Comparable business job and actual provider contribution | Live example or a bounded walkthrough |
| Review | Stages, feedback route and acceptance checks | Staging plan and acceptance record |
| Existing site | Content, URLs, integrations and data that must survive | Inventory, URL map and launch checks |
| Editing and access | What your team can change and with which roles | Editing demonstration and named accounts |
| Handover | Accounts, files, database, licences and instructions | Handover list and safe restore evidence |
| Maintenance | Updates, backups, renewals and incident ownership | Recurring-cost and responsibility record |
| Change | Effect of a new request on scope and timing | Written change decision |
Mark each row clear, needs evidence or unresolved immediately after the conversation. The labels are not a universal scoring system; they stop a confident presentation from erasing an open dependency.
1. What must this website help a visitor do?
Ask the designer to restate the primary visitor, their decision and the next action the site will support. For a heating company, that might be helping a homeowner understand the service area, distinguish emergency from planned work and request a suitable appointment. “A modern website” is not a business requirement.
Ask for a proposed page map and the purpose of each page. It should connect the service, proof and enquiry path rather than simply reproduce a standard five-page package. If your own requirements are still loose, complete a website design brief before comparing providers.
2. What is included, excluded and dependent on me?
Ask for the scope in nouns and numbers: pages or templates, content, forms, products, booking or payment connections, migration work, analytics, training and launch support. Then ask for exclusions and assumptions.
The provider should also name your responsibilities. Who supplies the logo, service details, photographs, legal wording and approvals? What happens to the schedule if those inputs arrive late? A quote is easier to compare when the boundaries are written down. Our website quote guide explains how page count, content and integrations change scope.
3. What relevant work can you walk me through?
A portfolio shows appearance. Ask the designer to walk through one or two projects with a similar business job: generating enquiries, explaining a complex service, taking bookings or selling a small catalogue.
Ask what the provider personally delivered, what constraints shaped the result and which evidence belongs to the public project. A screenshot cannot prove that a form delivers, a site is easy for its owner to edit or a claimed sales result came from the redesign. Treat confidential or unavailable evidence as unavailable rather than filling the gap with assumptions.
4. How will I review and accept the work?
Ask when you will see the site, where you will review it and how changes are recorded. A staging site is a private working copy used before the public release. Agree how many review rounds are included, who consolidates feedback and what counts as acceptance.
Turn broad promises into observable checks. Instead of “mobile friendly,” agree to inspect the main pages and enquiry path on representative phone and desktop sizes. Instead of “accessible,” ask which accessibility target applies, what will be checked and who owns unresolved issues. W3C guidance recommends assigning responsibilities, setting scope and checking accessibility throughout a project rather than leaving it until completion (W3C planning guidance).
5. How will you protect an existing site's useful parts?
For a redesign, ask for an inventory of current pages, forms, downloads, tracking and external connections before replacement work starts. Ask which URLs will stay, which will change and who will prepare and test redirects.
Google's site-move guidance recommends preparing the new site, mapping old URLs to new ones, using redirects and monitoring the old and new site after a move. It also warns that rankings can fluctuate while changed URLs are processed (Google Search Central). A provider can plan and monitor a migration, but cannot promise unchanged rankings.
6. What will I be able to edit, and what access will I receive?
Ask the designer to demonstrate the actual editing workflow for a service description, team member, image and call to action. A content management system, or CMS, is the software used to manage site content. “Built in WordPress” does not by itself explain whether your team can safely make the changes it needs.
Ask which WordPress role each person will use and whether the business will receive its own administrator account. WordPress roles control capabilities such as publishing pages, managing users, updating plugins and exporting content (WordPress roles and capabilities). Access should match responsibility; not every routine editor needs full administrator rights.
7. What will I receive at handover?
Ask for a handover list before the project begins. It can include business-controlled domain and hosting records, WordPress access, theme and plugin details, renewal owners, source assets, documentation, training and a current backup.
Clarify what “backup” means. WordPress states that a typical restorable site needs both its database and its files (WordPress backup guidance). The built-in WordPress export creates a WXR file containing content such as posts, pages, comments and taxonomies; that is useful, but it is not the same as a complete files-and-database recovery set (WordPress export documentation). Ask how a restore will be demonstrated without risking the public site.
8. Who owns ongoing maintenance and third-party costs?
Ask who will update WordPress, themes and plugins, monitor backups, renew the domain and hosting, and respond if the enquiry path fails. Separate work included in the build from optional maintenance.
Request a list of recurring third-party costs and the account that controls each one. This may include hosting, premium software, booking services, email delivery or image licences. Do not assume that a build fee includes every future renewal. Agree who receives renewal notices and what happens if the working relationship ends.
9. What happens when scope or timing changes?
Ask for the change process before a change is urgent. A useful process records the request, effect on cost and timing, the decision and the person who approved it. It should also allow a new request to replace or defer another item rather than quietly adding work.
Our scope-creep worksheet provides a simple approve, replace, defer or reject decision. The aim is not to prevent change; it is to keep the agreed launch and responsibilities visible.
A hypothetical comparison: polished promise versus usable evidence
Suppose a heating-service owner interviews two studios. This is a made-up example, not a WPShip customer result.
Studio A shows attractive homepages and promises a fast, search-friendly launch. It cannot yet say who will write the service pages, how the old URLs will be mapped or what backup will be handed over. Those rows are needs evidence or unresolved—not automatic reasons to reject the studio, but decisions that still belong in the scope.
Studio B proposes a page map around emergency repair, planned installation and service areas. It names the owner's content deadline, a staging review, a form-receipt test, a URL map, business-controlled administrator access and a files-plus-database recovery set. These are clearer answers because the owner can inspect or retain them. They still do not prove future rankings or enquiries.
The comparison does not require you to decide which studio is “best” in the abstract. It reveals which proposal has fewer important assumptions and which unresolved items need a price, owner or test before acceptance.
Compare answers, not confidence
“Clear” means an answer identifies an owner, deliverable or test. “Needs evidence” means the promise sounds relevant but the example, demonstration or written term is missing. “Unresolved” means the provider cannot yet explain the boundary or responsibility.
A lower-priced proposal with unresolved migration, content or maintenance work may not be the lower-risk choice. A more expensive proposal is not automatically better either. Compare the same requirements, evidence and open decisions across every provider.
If you are considering WPShip, request a website plan and bring your brief, current URL if you have one, required visitor action and this question list. WPShip's current start page asks for the project requirements before payment; the resulting conversation should confirm what fits, what needs separate scope and what you will review before launch. A visible form is not proof of message delivery, so keep your submitted details and any reply as the enquiry record.
Choose only after the open decisions are written down. The best interview outcome is not a perfect sales conversation; it is a project you can understand, test and accept.