18 client questions for a website redesign

Questions 1–5: define the job of the website

Start with the intended visitor and the action that matters. “Make the website modern” describes a preference, but it does not tell you which pages, messages or journeys need attention. Ask the client to identify a primary outcome and explain how the current site gets in its way.

Request examples with commentary rather than a folder of inspiration links. A client may like the typography on one website and the booking process on another. Without that distinction, the project team can mistake a visual preference for a functional requirement.

These answers should become a short agreed brief. If stakeholders disagree about the main audience or action, resolve that before collecting detailed page copy. A polished questionnaire cannot compensate for an unresolved business decision.

• 1. Who is the primary visitor, and what are they trying to accomplish?
• 2. What is the most important action that visitor should take?
• 3. Which current pages or journeys are failing to support that action?
• 4. What must remain familiar or unchanged in the redesign?
• 5. Which two or three reference sites are useful, and what specifically should we learn from each?

Questions 6–10: turn content into named inputs

Ask for a page list before asking for “all the copy.” Each page should have an owner, a status and a place to find the latest version. Distinguish copy that is ready to use from a draft that still needs internal approval. This prevents design work from being built around text that everyone assumes someone else checked.

Also ask where factual claims come from. Product specifications, customer quotations and service promises need a responsible reviewer. If copy was produced with AI assistance, that does not change the need for a person who can confirm its accuracy and suitability.

The website content checklist helps translate these answers into individual requests. Keep related documents linked to the relevant page instead of expecting the delivery team to reconstruct the relationship from file names.

• 6. Which pages will be kept, added, combined or removed?
• 7. Who supplies and approves the copy for each page?
• 8. Which content is final, and which content still needs work?
• 9. Where are the approved logo, images and brand guidelines?
• 10. Which claims, testimonials or statistics need verification or permission before use?

Questions 11–14: identify dependencies and access

Access questions should identify the service, responsible administrator and required role. Do not ask clients to paste passwords into the questionnaire. A platform invitation or an approved access process is easier to manage than credentials scattered through a project record.

For forms and integrations, ask what should happen after the visitor takes an action. A form can appear correct while routing to the wrong inbox or creating an incomplete record. Identify the person who will test the result with you and the account where the test can be verified.

File links also need checking. An owner being able to open a folder does not prove the project team can access it. Gather stores links and answers; sharing a link in Gather does not change permissions in the service that hosts the file. See how to review received inputs before marking access complete.

• 11. Who administers the domain, hosting and current content system?
• 12. Which forms, bookings, payments or integrations must continue working?
• 13. Who can provide the necessary role-based invitations and test access?
• 14. Are there known launch dependencies, unavailable stakeholders or restricted dates?

Questions 15–18: make approval possible

A project needs an accountable decision maker, even when several people contribute. Ask who consolidates feedback and who can approve the final result. Those may be different people. Record both responsibilities so a helpful reviewer is not accidentally treated as the commercial approver.

Define the format of a useful response. “Approved for design” can be different from “approved for publication.” A design team may be allowed to explore a layout with draft copy while publication still depends on a legal or product review. Record the stage of approval rather than using one checkmark for every purpose.

Finish by asking about known gaps. This gives the client an honest way to surface uncertainty and lets you plan around it. A questionnaire is complete when the answers are usable or the missing decisions have owners and dates.

• 15. Who consolidates feedback from the client’s stakeholders?
• 16. Who has final approval authority for content and launch?
• 17. How long should we allow for each review, and what happens if it is delayed?
• 18. Which answers or materials are still uncertain, and who will resolve them?

Review the answers before calling kickoff ready

Use a short review pass after the client responds. Check completeness, access and consistency. If the audience answer points to enterprise buyers but the page list describes a consumer checkout, ask a specific follow-up. The purpose is to discover mismatches while they are still inexpensive to fix.

Convert unanswered items into a request register. An illustrative register might show final service copy awaiting a named reviewer, a logo file ready for use and hosting access awaiting an administrator. Each should have a next action and due date, not simply a red status label.

Start with Gather’s free website kickoff checklist. The client kickoff template provides a reusable structure. With a paid account, client response links let clients submit answers and file links; you review the submissions before marking the project inputs ready.