Website Redesign Strategy: What to Prioritize First

Concept illustration. The chart and blueprint labels are illustrative, not measured results or the article's publication date.

A website redesign can change your content, customer experience, search visibility, and the way inquiries reach your team. Choosing a visual direction is part of that work. First, decide which problems justify the project and what you need to preserve.

You may need a full rebuild, a clearer content structure, or a smaller set of repairs. This guide helps you make that decision and turn it into a brief that a designer or developer can work from.

Start with the resource: Download the free Website Redesign Planning Worksheet (PDF). Use it to record the problem, review existing pages, choose priorities, and assign owners for launch checks. No signup required.

1. Write the problem before choosing the solution

“The website looks old” describes an impression. Explain what that impression prevents you from doing. Perhaps the site misrepresents your current services, important information is difficult to update, or customers cannot complete a request on their phones.

Write a short brief with four parts:

• Audience: Who needs to use the site, and what are they trying to do?
• Problem: What have you observed, and where does it happen?
• Needed outcome: What should become easier for the customer or your team?
• Constraints: What must stay, and what limits the budget or schedule?

A hypothetical landscaping company might write: “Customers cannot tell which maintenance plans cover their property. We need clearer plan information and an inquiry process that captures the address and service needed. Keep the existing booking system.”

That brief gives the team decisions to make. It also makes exclusions easier: a customer portal might be useful later, but it does not automatically belong in this redesign.

If the audience or offer itself has changed, start by deciding between a rebrand and a website redesign. Clarifying the business message may need to come before the page design.

2. Record what works before changing it

Save a picture of the current site: its pages, important content, customer tasks, and measurement setup. This becomes your baseline and helps prevent useful material from disappearing during the build.

Start with these records:

Record	Why it belongs in the brief
Existing page URLs and their purpose	Shows what the site currently covers and what may need moving
Important landing pages and search queries	Helps identify information people already find useful
Completed inquiries and their quality	Connects site activity to work the business wants
Form, booking, and notification behavior	Records the customer actions and integrations that must continue working
Customer questions and staff feedback	Reveals missing information and repeated confusion

Use analytics and Search Console where they are available. Also walk through real tasks and ask the people handling inquiries what customers struggle with. Low traffic or missing tracking should be recorded as a limitation, rather than filled in with assumptions.

Label findings accurately. A failed form submission is an observed defect. “Visitors may not understand this service name” is a hypothesis you can investigate with customer conversations or a usability check.

3. Choose outcomes you can assess consistently

Pick a small set of outcomes that reflects the reason for the project. A service business might track suitable new inquiries and whether those inquiries reach the right person. A team struggling to maintain its site might also measure whether staff can update essential information successfully.

Define each measure before comparing results. Does “inquiry” mean a submitted form, a connected call, or a qualified opportunity? Who decides whether it is suitable? Keep those definitions consistent across the launch.

Record the starting position and agree on a review period that fits your traffic and sales cycle. There is no useful universal target for conversion improvement. With a small number of inquiries, one additional request can substantially change the percentage.

Include things you want to protect, such as access to existing resources, mobile usability, or a reliable booking integration.

4. Separate urgent repairs from redesign decisions

Prioritize using the consequence of a problem, the people affected, the evidence behind it, and the effort required. A scoring spreadsheet can help organize discussion, but precise-looking scores do not make uncertain assumptions reliable.

Here is an illustrative decision list:

Problem and evidence	Sensible next action
Requests never reach the team. A test submission is missing from the inbox and CRM.	Repair delivery and verify receipt now.
Customers cannot tell which plan fits. Recent inquiry notes show the same question.	Improve the plan comparison and test understanding.
Important pages are hard to edit. Staff cannot change service details without developer help.	Assess the editing workflow and platform requirements.
A competitor uses a more elaborate animation. This is a visual preference, without evidence of a customer problem.	Evaluate after the essential scope is clear.

Some defects can be fixed before the redesign starts. Others reveal a structural limitation that supports rebuilding. Keep a separate list of optional improvements so they do not quietly become launch requirements.

5. Give every important page a decision and an owner

Review content before assuming that the new design needs fewer pages or completely new URLs. For each important page, choose one of four actions:

• Keep: It remains useful and needs little change.
• Revise: Its purpose still matters, but the explanation or presentation needs work.
• Combine: Another page can serve the same reader better, with the useful information retained.
• Retire: The material no longer serves a current need and has no relevant replacement.

Record the reason, the intended URL, and who will provide or approve the content. Include downloads and important images, not just pages in the main navigation.

Age alone is a weak reason to remove a page. Check whether it answers a current question, attracts relevant visitors, or supports customers who already know the link.

For new or revised pages, assign responsibility for service details, photographs, permissions, pricing information, and approvals. “Content supplied by the client” is too vague to schedule against.

6. Build the schedule around dependencies

A credible schedule follows the agreed scope and the work required to deliver it. The number of pages matters, but so do integrations, content readiness, accessibility requirements, review availability, and the condition of the existing platform.

Ask for milestones tied to reviewable work: an approved structure, a representative page design, complete content, a working test site, and a launch review. Identify who signs off each milestone and what happens when a decision changes.

Decide who controls the domain, hosting, analytics, and connected services. Arrange the necessary access before the launch window. Keep a recoverable copy of the current site and agree on a recovery plan if an essential function fails.

Use the redesign planning worksheet to make these responsibilities visible. A smaller scope with available content may be more useful than a larger proposal dependent on material nobody has time to produce.

7. Plan search migration work when URLs change

A visual redesign does not necessarily require new URLs. Preserve useful addresses when the page's purpose remains the same. Changing the design, changing platforms, and changing domains are different decisions; identify which ones your project actually requires.

When an address must change, record the old URL and its relevant destination. For permanent moves, Google recommends server-side permanent redirects where possible, including 301 or 308 responses. Google's redirect guidance.

Send an old page directly to its appropriate replacement. Do not redirect unrelated retired pages to the homepage simply to avoid errors. A genuinely consolidated page can receive redirects from the content it replaces; irrelevant redirects can be treated as soft 404s. Google's site-move guidance.

If content is intentionally removed and there is no relevant replacement, return an appropriate 404 or 410 status. A friendly error page can help visitors find other options while retaining that status. Google does not index URLs returning those responses. Google's HTTP status documentation.

Have the implementation owner test the URL map before launch. Include links from advertisements, emails, and downloadable documents when planning which addresses must keep working.

8. Make launch approval a practical checklist

Review the working site against the brief. A screenshot approval does not verify a form, a booking integration, or a redirect.

Before launch, confirm:

• Important customer tasks work on a phone and computer, including keyboard use.
• Forms show clear success and error states, and test requests reach their intended destination.
• Phone links, booking links, downloads, and integrations work.
• Current content, permissions, contact details, and service information are correct.
• Measurement captures the intended actions without counting the same submission twice.
• Changed URLs reach the correct destination without loops or unnecessary intermediate redirects.

Give the search checks their own owner. Remove development-only noindex instructions from pages intended for search, checking both page markup and HTTP headers. Confirm that public pages are also accessible to crawlers. Keep intentional exclusions on private or otherwise nonpublic content. Google's robots documentation explains both forms of indexing control.

Check that canonical tags identify the intended production URLs, rather than a staging domain or an unrelated page. Keep the preferred URL consistent across the site's signals. Google's canonical guidance.

Generate a sitemap containing the canonical, indexable URLs you want discovered, and submit it through Search Console when appropriate. A sitemap helps discovery; submission does not guarantee indexing. Google's sitemap guidance.

Repeat essential checks on the production domain immediately after release. Staging and production can differ in configuration, access, or integrations.

9. Review the launch before judging the business result

Start by checking that the site is available and that customer actions still work. If forms fail or important pages unexpectedly disappear, investigate promptly. You do not need to wait for a scheduled review to repair a demonstrated problem.

Then compare outcomes with the baseline using the same definitions. Separate technical faults, tracking changes, changes in visitor mix, and possible effects of the redesign. Advertising, seasonality, and a different offer can also affect the result.

Google notes that search visibility can fluctuate while a significant site move is processed. That does not make every decline harmless or establish a fixed recovery deadline. Google's site-move guidance.

Choose a monitoring frequency that fits the risk and volume. Record who will investigate an issue and when you will have enough evidence to review the broader outcome.

Frequently asked questions

Do we need to replace our current platform?

Only when the requirements justify it. Check whether the existing platform can support the content, editing, accessibility, performance, and integrations you need. Compare the cost and disruption of improving it with the cost of moving before choosing.

Our website platform comparison for service businesses provides a requirements worksheet for making that choice.

How long should redirects remain in place?

For site moves, Google recommends keeping redirects as long as possible, generally at least a year. Keeping useful redirects longer can also help visitors following old links. Google's redirect-retention guidance.

Bring a clear brief to the next conversation

Start with the worksheet, an inventory of important pages, and a short list of observed problems.

When you are ready to discuss that brief with a provider, use our guide to evaluating a web design agency and its proposal to compare scope, responsibilities, and evidence of fit.

Wallace Shift's free website first check covers simulated mobile loading and basic technical checks. It does not assess your offer or replace a redesign review. The Shift Finder is a separate three-question quiz that suggests a starting direction.

To discuss the scope, tell us what needs to change. Our website services and website pricing provide context for that conversation.