Website redesign checklist: what to prepare before hiring a studio

A redesign conversation becomes more useful when you can explain what the business needs, rather than show a collection of websites you like. Visual references have a place, but they cannot tell a studio which service matters most, who approves the copy, or what must happen when someone sends an inquiry.

You do not need a finished sitemap or polished website copy before contacting a studio. You need reliable business context and a clear view of what is available, missing, or still undecided.

This website redesign checklist is for project preparation. It helps you assemble the inputs a team needs to recommend the right scope, identify dependencies, and plan the work. If you are still deciding whether a redesign is necessary, start by reviewing the specific problems on the existing site.

1. Describe the business goal and the website's role

Write down the change you want the site to support. Perhaps a consultancy is introducing a new offer, a firm needs to explain several services, or an established business wants its public presence to reflect the quality of the work.

Make the goal specific enough to guide decisions. “A more premium website” leaves the team to interpret a mood. “Help operations directors understand our advisory engagement before they book a discussion” identifies an audience, offer, and action.

Separate the website's job from a wider business ambition. A new site can explain the offer, show evidence, and improve the inquiry route. Client acquisition also depends on suitable traffic, the service itself, sales follow-up, and other factors. Record any useful baseline information you have, with the period and source, without turning a goal into a promised outcome.

2. Identify the audiences and important offers

List the main people the site serves and what they need to understand. Use what you know from real conversations, proposals, or inquiries. If you are making an assumption about a new audience, label it as a question to investigate.

Then list the current services and distinguish those you want to emphasize from those you are retiring or changing. Note which offers have different delivery conditions, audiences, or buying processes. This helps the studio decide whether the site needs an overview, individual service pages, audience routes, or another structure.

Do not approve a page list while the offer itself is still changing without recording that dependency. A design can accommodate a decision; it cannot quietly resolve a business question the team has not answered.

3. Choose who makes the decisions

Name the project contact, the people supplying specialist information, and the final approver. If legal, compliance, or a partner must review specific content, identify that requirement early.

Agree how feedback will be consolidated. A studio can work with several perspectives, but it needs to know whether a comment is a preference, a required correction, or a final decision. One coordinated response at an agreed stage is easier to interpret than contradictory comments arriving through several channels.

Record unavailable periods and any real launch dependency. A conference date, contractual requirement, or replacement of a retiring system may affect the plan. Distinguish that external requirement from a date chosen simply because it would be nice to launch then.

4. Inventory the content and proof

Gather the current website, service descriptions, proposals, team information, images, and approved work examples. Identify the source of each item and who can confirm it is current.

For proof, record what you can actually support: a completed deliverable, an approved client comment, a documented project decision, or a measured result with context. Mark permission requirements and missing details. A shared folder full of old screenshots is a starting point, not an approved case-study library.

You can organize each important item with four simple entries: source, owner, status, and next action . For example: “Service overview; operations director; outdated; confirm the new scope.” This gives the project team something to act on without asking everyone to polish the material first.

Original preparation checklist. Give each group an owner, a source, and a current status in your project notes.

5. Record the systems the website must connect with

List the tools involved in the visitor journey and the team's workflow: forms, scheduling, email, customer records, payment or booking services where relevant, and analytics. Describe the required action, not just the software name.

“Connect our booking tool” leaves important questions open. “A visitor chooses an available consultation, receives the existing confirmation, and the booking appears in the advisor's calendar” gives the team a workflow to assess. Confirm which parts already work and which are proposed.

Also identify the domain registrar, hosting, current website platform, and relevant account owners. Establish how the project team will receive appropriate access when it is needed. Use account invitations and secure sharing methods available in those tools. A project brief should identify access requirements rather than contain passwords.

6. Preserve the important pages and URLs

Make an inventory of the current URLs, especially pages that receive useful visits or have been shared widely. Note the proposed destination for any page that may move, merge, or disappear.

If you have Search Console or analytics, include the reports that help identify important content, with their dates. Do not assume that a page with low recorded traffic has no value; measurement may be incomplete, and some pages serve existing clients or referral conversations.

Google's guidance for site moves with URL changes includes mapping old URLs to new ones and using appropriate redirects. The preparation task is to supply the inventory and context so the migration can be planned. A redesign does not guarantee that rankings will improve or remain unchanged.

A worked example: preparing a fictional advisory firm

Imagine an advisory firm replacing a site that describes its work through broad practice-area labels. The firm now wants to emphasize two distinct engagements, but its partners have not agreed on the final names. It has completed projects and useful client feedback, though only some material is approved for public use.

The project brief should state the business goal: help a suitable buyer distinguish the two engagements and understand which conversation to request. It should record the names as pending, identify the partner who will make that decision, and explain what can proceed while the decision is open.

A content handoff could include these entries:

• Service descriptions: current proposal documents supplied by the project contact. Final scope and names require partner approval.
• Team biographies: existing website copy supplied by the office manager. Each advisor must confirm current details.
• Project evidence: a completed report and client feedback supplied by the lead advisor. Public excerpts and attribution need permission.
• Inquiry workflow: the current form and receiving inbox supplied by the operations owner. The team must confirm who replies and what acknowledgment is promised.

This is more useful than a folder labeled “Website final” containing several contradictory documents. The studio can see which information is dependable and which decisions affect the work. It can also discuss copywriting requirements before assuming that every page arrives as finished text.

Illustrative handoff for a fictional advisory firm. It shows how to record uncertainty rather than hide it inside a final-content folder.

7. Agree how the work is shared

A studio's responsibilities and the client's inputs should be clear in the proposal. The precise division depends on the project, so confirm it rather than relying on what another business received.

Our True Space process includes understanding the business, planning the site, writing and wireframing, design and development, and testing and launch. Copy can be written, reshaped, or supplied by the client, with requirements agreed in scope.

The business still needs to confirm that its facts, services, and claims are accurate, supply access and relevant material, and approve decisions at the agreed stages. If a specialist review is required, the project plan should make room for it. The studio and client can then assign the work without asking either side to guess.

For each stage, record three things: what the studio produces, what the business provides or confirms, and what approval allows the next stage to begin. This makes the review process concrete.

Original responsibilities map. Confirm the detailed division in your own proposal and project plan.

8. Prepare for launch and ongoing ownership

Before the project starts, discuss who approves launch and what needs to be checked first. The list may include key pages, mobile layouts, contact delivery, booking paths, redirects, search settings, and access for the people who will maintain content.

Record who will own the website after launch. Which content areas should the team be able to update? Who keeps services, team information, and work examples current? Does the team need basic handoff guidance or a continuing support arrangement?

These decisions influence the platform and publishing structure. A business adding articles regularly has different needs from one updating only a few static pages. Explain the expected work so that maintenance is part of the brief.

Bring the brief you have, with its gaps visible

You are ready for a useful first conversation when you can explain the goal, identify the important audience and offer, show the available material, and name the decisions that are still open. The preparation does not need to be immaculate. It needs to be honest and organized.

Keep the checklist beside your notes and mark each group as ready, incomplete, or undecided. Assign a next action where something is missing. That gives you a practical starting point for discussing scope.

If you are preparing to rebuild, explore True Space to see our website process. Bring your priorities, current site, and open questions so the project can be planned around what the business needs.