A website redesign process is the ordered set of steps that takes a site from audit to launch without losing what already works. The core sequence: audit the current site, set measurable goals, research users, plan content and URLs, choose the platform, design, build and migrate, test, launch with redirects, then measure.
Most redesigns start in the wrong place. Someone opens a competitor’s site, decides yours looks dated, and the project begins with colors and layouts. Months later the new site launches, looks better, and quietly loses search traffic, breaks a contact form nobody tested, or drops the analytics tag that told you which pages produced leads. None of that is a design problem. It is a process problem.
The website redesign process below is the order we recommend to US businesses, whether the new site will be custom-coded or built on WordPress. It has eleven steps, grouped into four phases: understand, plan, build and prove. Each step has an output and a sign-off, because the most expensive mistakes in a redesign are decisions made late that should have been made early. Where Google publishes guidance that applies, such as its documentation on moving a site with URL changes, we point to it and stay close to what it actually says.
If you are still deciding whether you need a redesign at all, or what kind of team should run it, our custom web development page explains how we approach new builds and rebuilds as one discipline. This guide assumes the decision is made and focuses on doing it well.
What is a website redesign process?
A website redesign process is a structured plan for replacing or substantially changing an existing website while keeping the assets it has already earned. Those assets are easy to underestimate. They include pages that rank in Google, URLs that other sites link to, forms and phone numbers that produce leads, tracking that tells you which channels work, and content that customers already rely on. A new site that ignores them starts from a lower position than the old one, however good it looks.
A redesign is not a new website. It is a change to a working system, and the first job of the process is to find out what that system already does well.
The four phases at a glance
Most published redesign guides use between five and nine steps. The names differ, but the logic is the same. We group the eleven steps into four phases so it is clear what each one is for.
| Phase | Steps | Output you should have before moving on |
|---|---|---|
| Understand | 1. Audit · 2. Goals · 3. Research | A written baseline, measurable goals and a short list of user problems to solve |
| Plan | 4. Content · 5. Architecture and URLs · 6. Platform | A content inventory with decisions, a sitemap, an old-to-new URL map and a platform choice |
| Build | 7. Design · 8. Build and migrate · 9. Testing | Approved designs, a working staging site with real content and a passed test plan |
| Prove | 10. Launch · 11. Measure | A live site with redirects, tracking verified and a comparison against the baseline |
Before you start: what problem is the redesign solving?
Write the reason down in one or two sentences before anyone opens a design tool. Good reasons are specific and tied to the business. The site does not produce enough enquiries. Visitors on phones cannot find the booking button. The team cannot update pages without a developer. The site no longer describes what the company sells. A security or platform issue makes the current setup hard to maintain. Each of those reasons points to a different priority in the steps below.
Weak reasons are about taste or timing alone: the site feels old, a competitor launched something new, it has been a while. Those may be true, but they do not tell the team what to protect, what to change or how to judge success. A redesign driven only by appearance often ends with a site that looks newer and performs the same, or worse.
Separate symptoms from causes
Low leads, for example, can come from traffic that never arrives, from the wrong traffic, from pages that do not answer the visitor’s question, or from a form that fails on some devices. A redesign fixes only some of those. If the real cause is a broken form, a redesign is an expensive way to fix it. Our guide to why a website is not getting leads walks through how to find the real cause first, and it is worth reading before you commit to a full project.
Step 1: How do you audit your current website before a redesign?
The audit is the step most often rushed and the one that saves the most money later. Its purpose is to record what the current site does, in numbers and in lists, so the new site can be planned around evidence and judged against a baseline. Without it, nobody can say after launch whether the redesign helped.
- Export every URL. Combine the XML sitemap, a crawl of the site, the pages report in Google Analytics 4 and the pages report in Google Search Console. Google’s site move guidance suggests the same sources for building a list of old URLs: sitemaps, server logs, analytics, Search Console and your CMS. The crawl alone usually misses old pages that still get visits or links.
- Record performance per page. For each URL, note organic clicks and impressions from Search Console, sessions and key events from GA4, and which pages other sites link to. Sort by value so the important pages are obvious.
- Capture the conversion paths. List every form, phone number, booking tool, chat widget and email link, where it appears and where its submissions go. Note which events GA4 currently records for each one.
- Measure speed and stability. Record field data for Core Web Vitals where it exists and lab results for key templates. Google’s web.dev documentation defines good scores as an LCP within 2.5 seconds, an INP of 200 milliseconds or less and a CLS of 0.1 or less, measured at the 75th percentile of page loads.
- Check accessibility. Run automated checks and a short manual test with a keyboard and a screen reader on the main templates. Note issues against WCAG, the standard most accessibility requirements reference.
- Document the technical setup. Platform, hosting, plugins or dependencies, integrations, structured data, redirects already in place, robots.txt, and who holds access to the domain, hosting and analytics accounts.
Do not skip the boring pages
Old blog posts, location pages, PDF downloads and thank-you pages rarely appear in design discussions, yet they often hold links and long-tail search traffic. Our guide to migrating a website without losing SEO rankings explains why these pages matter more than their appearance suggests.
Step 2: How do you set goals and success metrics for a redesign?
Turn the reason you wrote down earlier into goals that can be measured with the tracking you already have or will add. A goal should name the action you want more of, the pages or audience it applies to, and how you will measure it. More qualified enquiries from service pages, measured as form submissions and calls recorded in GA4, is a goal. A modern look is not.
Pair each goal with the baseline from the audit and a comparison window, but be careful with targets. Redesign outcomes depend on traffic, seasonality, competition and offers as well as the site itself, so a promised percentage is a guess. It is more honest to commit to the direction, the measurement and the date you will review it.
| Business goal | What to measure | Where it comes from |
|---|---|---|
| More enquiries | Form submissions, phone clicks, chat starts, bookings | GA4 key events, form and booking tool records |
| Keep or grow search visibility | Organic clicks and impressions on priority pages and queries | Google Search Console, same date ranges before and after |
| Better mobile experience | Mobile engagement and conversion rate, Core Web Vitals field data | GA4 by device, Search Console Core Web Vitals report |
| Easier updates | Time and steps needed to publish a common page change | A short before-and-after test with the people who edit the site |
| Clearer positioning | Whether first-time visitors can say what you do and for whom | Five-second tests or short interviews with real prospects |
Step 3: Research your users and your market
The audit tells you what the site does. Research tells you why visitors behave the way they do and what they need that the current site does not give them. It does not need to be a large study. A small amount of direct evidence beats a large amount of internal opinion.
Talk to the people closest to customers
Sales staff, front-desk teams and account managers hear the same questions every week. Ask them what prospects ask before buying, what they misunderstand, and which pages they send people to. Those questions become content priorities and often FAQ entries on the new site.
Watch real behavior
Search Console shows the queries that bring people to each page, which reveals how customers describe their problem in their own words. GA4 shows where they enter, where they leave and which paths end in an enquiry. If you use session recordings or heatmaps, watch a sample of visits to your most important pages on a phone. Short usability tests with five or so people from your audience, asked to complete a real task, usually surface the biggest problems quickly.
Research also feeds search planning. The questions customers ask are often the same ones they type into Google or ask an AI assistant. Our explainer on AEO vs SEO vs GEO covers how one set of well-structured answers can serve classic search results, featured answers and AI-generated responses at the same time.
Step 4: Plan the content before the design
Content decides the design, not the other way round. When designers work with placeholder text, the finished pages often cannot hold the real content, and the team ends up cutting useful information to fit a layout. Plan what each page will say, at least in outline, before the design work starts.
Use the page inventory from the audit and give every URL a decision. This is where the redesign protects its search value or loses it, so make the decisions with the performance data in front of you.
| Decision | When to use it | What happens to the URL |
|---|---|---|
| Keep | The page performs and is accurate | Same URL if possible; light edits only |
| Improve | The page has traffic or links but is thin, outdated or unclear | Same URL if possible; rewrite and expand |
| Merge | Several pages answer the same question and compete with each other | Keep the strongest URL; redirect the others to it |
| Move | The page is useful but belongs in a new section | New URL with a permanent redirect from the old one |
| Remove | The page has no traffic, no links and no current purpose | Return 404 or 410, unless a closely related page exists to redirect to |
| Create | Research shows a question the site does not answer | New URL planned in the sitemap |
Write for scanning and for answers
Put the main answer near the top of each page, use descriptive headings, keep paragraphs short and include the facts a buyer needs to decide: what you do, for whom, where, how the process works and what to do next. Pages written this way tend to work better for visitors, for search engines and for AI systems that summarize them. Google’s guidance on helpful content, which we cover in our guide to what E-E-A-T means, rewards the same qualities: clear ownership, real expertise and content that exists to help people rather than to rank.
Step 5: How do you plan site architecture and URLs?
Architecture is the structure of the site: which pages exist, how they are grouped, how visitors move between them and what each URL looks like. In a redesign it also includes the map from every old URL to its new home. This step is where most search losses are prevented, because it is the step where URLs change.
Build the sitemap and navigation
Start from the content decisions and group pages by how customers think, not by how your company is organized internally. Keep the main navigation short and predictable. Make sure every important page can be reached in a few clicks from the homepage and is linked from related pages, not only from a menu.
Keep URLs that work
The simplest way to protect search value is not to change URLs that do not need to change. If an existing page ranks and its URL is readable, keep it, even if the new structure would suggest something tidier. Every changed URL needs a redirect, and every redirect is a small risk that has to be maintained.
Create the redirect map
For every URL that changes or disappears, record the old URL, the new destination and the reason. Google’s documentation recommends permanent server-side redirects, such as 301 or 308, from each old URL to the matching new page. It advises against sending many old pages to an unrelated page such as the homepage, and against redirect chains; redirect directly to the final destination. It also says to keep redirects in place for generally at least one year, and suggests keeping them longer where possible.
- One row per old URL, including PDFs and images that receive traffic or links.
- One destination per row, chosen as the closest match in content and intent.
- No chains. If an old redirect already exists, update it to point straight to the new final URL.
- Planned 404 or 410 only for pages with no useful equivalent, as Google’s guidance suggests for deleted content.
- Updated internal links on the new site so they point to final URLs, not to redirects.
Structured data belongs in this step as well. Decide which page types need markup, such as organization, service, article or FAQ content that is visible on the page, and plan it into the templates. Our beginner’s guide to schema markup in website SEO covers the basics.
Step 6: Choose the platform and technical foundation
Some redesigns keep the existing platform; others move. Either way, make the decision in the planning phase, after you know what the site must do and before design work commits to features the platform cannot support well. Changing platforms halfway through a project is one of the most expensive surprises a redesign can produce.
Questions that decide the platform
- Who will edit the site, and how often? A marketing team publishing weekly needs a different editing experience from a business that changes a few pages a year.
- What has to connect? CRM, booking, email, payments, live chat, inventory or listing feeds. List them and confirm each one is supported.
- What does performance require? Heavy themes and stacks of plugins can make good Core Web Vitals harder to reach. Our guide to Core Web Vitals explains the metrics in more detail.
- Who maintains it after launch? Updates, backups, security monitoring and fixes need an owner and a budget.
- Who owns the accounts? Domain, hosting, code repository, analytics and every third-party tool should be in your company’s name, with your team holding admin access.
Custom code or a CMS
For most business sites, the choice comes down to a well-built WordPress site or a custom-coded one. Both can be fast, secure and easy to edit when they are built properly, and both can be slow and fragile when they are not. Our comparison of custom websites and WordPress sets out when each fits. If you are weighing other content management systems, our guide on how to choose a CMS adds more options.
Plan the staging environment
The new site should be built on a staging copy that search engines cannot index. Google’s guidance on site moves suggests a testing environment that is protected, for example with restricted access, and reminds teams to remove any noindex or robots.txt blocks used during development when the site goes live. Forgetting that last step is a classic launch-day error, which is why it appears again in the launch checklist below.
Platform choices are easier with someone who has built on both. If you would like a second opinion on the stack before you commit, book a Blueprint Briefing and bring your list of integrations.
Step 7: Design from wireframes to a working system
With goals, content and structure agreed, design has something solid to work with. Good redesign design work moves from low detail to high detail, and it checks decisions against the goals at each stage rather than at the end.
Wireframes first
Wireframes show what goes on each key page and in what order, without colors or images. They are fast to change, which makes them the right place to argue about priorities: what the visitor sees first, where the main call to action sits, how proof and pricing factors are presented. Review them on a phone-sized layout as well as a desktop one, because most business sites now receive a large share of visits from mobile devices.
Visual design and a design system
Once the structure is approved, visual design applies the brand: type, color, imagery, spacing and components. Rather than designing every page separately, define a small system of reusable parts, such as headers, cards, forms, buttons, tables and calls to action. A system keeps the site consistent, speeds up development and makes future pages cheaper to add.
Design for evidence and action
- One clear next step per page, visible without hunting, and repeated where the page is long.
- Real proof near decisions: project examples, reviews you can link to, specific facts about the business. A public portfolio of real projects is often more persuasive than any headline.
- Forms that ask only what you need, with clear labels, error messages and a confirmation that tells people what happens next.
- Accessible by default: sufficient color contrast, visible focus states, real text instead of text in images, and layouts that work at larger text sizes. Our guide to building an accessible website covers the practical side.
Step 8: Build the site and migrate the content
Development turns the approved designs into templates and components on the chosen platform. In a redesign, it also includes moving content, recreating integrations and rebuilding the tracking that the old site had. Treat those as first-class tasks with owners, not as clean-up at the end.
Migrate carefully
- Page titles and meta descriptions for pages that already rank should be carried over or improved deliberately, not lost by default.
- Images need their file names, alt text and captions reviewed, and should be compressed and sized for the new templates.
- Canonical tags on the new site should point to the new URLs themselves, as Google’s site move guidance recommends.
- Internal links in body content should be updated to final URLs rather than relying on redirects.
- Downloads, embeds and forms should be checked one by one, including where form submissions are delivered.
Rebuild tracking, then verify it
Recreate the GA4 setup and every key event from the audit list: form submissions, phone clicks, chat starts, bookings, downloads. Add anything the goals require that was missing before. Then test each event on staging and confirm it reaches the right property. Tracking that silently breaks at launch leaves you unable to judge the redesign, and the data for those weeks cannot be recovered.
Performance belongs in development, not after it. Set budgets for page weight and script use per template, check them as features are added, and watch the effect of every third-party tag. A site that is fast in the design file and slow in production usually got that way one plugin or script at a time.
Step 9: What should you test before a redesign launches?
Testing is where the plan meets reality. Allow real time for it in the schedule, because it always finds something, and the fixes need time too. Test on the staging site with final content, final integrations and the redirect rules ready to switch on.
| Area | What to check | Who usually checks |
|---|---|---|
| Content | Spelling, accuracy, prices or pricing factors, legal pages, contact details that match your listings | Content owners and a fresh pair of eyes |
| Functionality | Every form, booking tool, chat, search, download and email notification, end to end | Developer and a non-technical tester |
| Devices and browsers | Phones, tablets and desktops on the browsers your analytics show visitors use | QA tester |
| Speed and stability | Lab tests on key templates against the performance budget and Core Web Vitals thresholds | Developer |
| Accessibility | Keyboard navigation, screen reader basics, contrast, form labels and errors | Developer and accessibility reviewer |
| SEO | Titles, descriptions, headings, canonicals, structured data, robots rules ready for launch, XML sitemap of new URLs | SEO lead |
| Redirects | Every row of the redirect map, tested for a single hop to the right page | SEO lead or developer |
| Tracking | Every key event fires once, with the right parameters, into the right property | Analytics owner |
Test the redirect map before launch day
Redirects can usually be tested on staging with a list of old paths. Run the whole list, not a sample, and fix any row that lands on the wrong page, loops or chains. Doing this before launch turns the riskiest part of launch day into a switch you already know works.
Step 10: How should you launch a redesigned website?
Launch is a short, planned sequence, not a single button. Pick a time when traffic is relatively low and the people who built the site are available for the following days. Avoid launching just before a holiday or a major campaign.
- Back up the old site completely, files and database, so you can compare or roll back if something serious goes wrong.
- Deploy the new site and switch on the redirect rules at the same time.
- Remove development blocks. Check robots.txt and noindex settings on the live site immediately; this is the step Google’s guidance specifically reminds teams about.
- Test the top pages live: homepage, main service pages and the pages that held the most traffic and links in the audit.
- Submit the new XML sitemap in Search Console. Google says warnings about redirecting URLs in an old sitemap are expected during a move.
- Use Change of Address only for domain changes. Google’s tool is for moving to a new domain or subdomain, not for path changes or HTTPS switches.
- Verify tracking in real time by completing a form, a phone click and a booking yourself and watching them arrive in GA4.
- Update listings and profiles that link to changed URLs, such as your Google Business Profile, social profiles and key directories.
What to expect in search
Google states plainly that sites should expect temporary fluctuation in rankings during a move, and that a medium-sized site can take a few weeks or more for most pages to be picked up at their new URLs, with larger sites taking longer. It also says that 301 redirects do not cause a loss of PageRank. In practice, a short dip that recovers is common after a well-planned change; a steep or lasting drop usually points to a specific problem, such as missing redirects, blocked pages or removed content.
If you want an experienced team beside you for the launch window, from the redirect test to the first week of monitoring, talk to us in a Blueprint Briefing before you set the date.
Step 11: Measure, compare and keep improving
The redesign is not finished at launch. The final step is to confirm the new site works as intended and to compare it fairly with the baseline you recorded in step 1.
The first days
Watch Search Console for crawl errors and pages reported as not found, check server logs or your host’s error reports for unexpected codes, and review GA4 daily for events that stopped firing. Google’s guidance for site moves recommends monitoring the Sitemaps and indexing reports, search query data and server logs during this period. Fix broken redirects and missing pages as soon as they appear.
The first weeks and months
Compare like with like: the same length of period, adjusted for seasonality where you can, using the metrics you chose in step 2. Look at priority pages individually, not only site-wide totals, because a gain on one section can hide a loss on another. Expect search data to move more slowly than conversion data while Google processes the changes.
Measurement is also where search and AI visibility come together. Clean structure, clear answers and consistent business details help pages appear in classic results and in AI features; our guide on how to appear in AI Overviews explains what Google says it uses.
Website redesign checklist
Here is the whole website redesign process as a checklist you can copy into a project plan. Each line is a deliverable or a decision, not a task description, so it is clear when it is done.
| Step | Done when you have |
|---|---|
| Reason and owner | A one-sentence problem statement and a named decision-maker |
| 1. Audit | A full URL list, per-page performance, conversion paths, speed, accessibility and technical notes, with date ranges |
| 2. Goals | Measurable goals tied to the baseline, a review date and agreed tracking |
| 3. Research | Customer questions, behavior findings and a short list of problems to solve |
| 4. Content | A decision for every URL, page owners, outlines and content deadlines |
| 5. Architecture | A sitemap, navigation, an old-to-new redirect map and a structured data plan |
| 6. Platform | A platform choice, integration list, maintenance owner, account ownership confirmed and a protected staging site |
| 7. Design | Approved wireframes, a design system and tested prototypes for key flows |
| 8. Build | Templates with real content, migrated metadata and images, rebuilt tracking and performance budgets met |
| 9. Testing | A passed test plan and the full redirect list verified |
| 10. Launch | A backup, live redirects, development blocks removed, sitemap submitted and tracking verified live |
| 11. Measure | Daily checks in the first days and a fair before-and-after comparison |
Common website redesign mistakes, and how the process prevents them
Most redesign problems are predictable. The table below lists the ones we see most often and the step that is designed to catch each one.
| Mistake | What it causes | Step that prevents it |
|---|---|---|
| Starting with visual design | A site that looks new but does not fix the real problem | The problem statement and step 2 |
| No baseline | No way to prove whether the redesign helped | Step 1 |
| Changing URLs without redirects | Lost search traffic and broken links from other sites | Step 5 |
| Redirecting everything to the homepage | Visitors and search engines land on a page that does not answer their question | Step 5 |
| Placeholder content until the end | Late delays and pages that cannot hold the real information | Step 4 |
| Deleting low-traffic pages that hold links | Lost authority and long-tail visits | Steps 1 and 4 |
| Forgetting tracking | Weeks of missing data after launch | Steps 8 and 10 |
| Leaving noindex or robots blocks on | Pages dropping out of search after launch | Steps 6 and 10 |
| Adding features without a performance budget | A slower site than the one it replaced | Steps 6 and 8 |
| Accounts in a vendor’s name | Difficulty changing providers or recovering access later | Step 6 |
The same discipline applies when choosing who runs the project. A team that asks for your analytics, your Search Console access and your list of URLs in the first conversation is following a process. One that starts with mood boards may not be. Our guide to what an established web development company looks like covers other signals worth checking.
How GoSocial runs a website redesign
GoSocial is a custom web design company in Boca Raton, Florida, building websites for businesses across the United States since 2016. We build websites around buyer psychology, strengthened with SEO, AEO and GEO, and we treat a redesign as a change to a working system rather than a fresh start.
Our web development process runs from discovery and strategy through architecture, design and content, development, testing, launch and measurement, which maps closely to the eleven steps above. We build both custom-coded and custom WordPress websites, and the domain, hosting account and code are yours either way, so another team can maintain the site if you ever choose to. If search visibility is a priority, our SEO, AEO and GEO services are planned into the same foundation rather than added after launch.
Every site launches with GA4 and Google Search Console connected, tracking form submissions, phone clicks, WhatsApp clicks and bookings, so the redesign can be judged by data. We do not promise a score or a ranking. We build for the metrics and show you the measurements. If you are planning a redesign, the first step is a Blueprint Briefing: a short conversation about what your website has to produce, with no pitch deck.
Website redesign process: FAQ
What are the main steps in a website redesign process?
The core steps are: audit the current site, set measurable goals, research users, plan content, design the architecture and redirect map, choose the platform, design, build and migrate content, test, launch with redirects and tracking verified, then measure against the baseline. Each step should end with a clear output and a sign-off.
How long does a website redesign take?
It depends on the number of pages, how much content changes, the integrations involved, whether the platform or URLs change and how quickly decisions and content are approved. Content and approvals cause more delays than design or development. A scoped plan after the audit gives a far more reliable timeline than any general figure.
Will a website redesign hurt my SEO?
It can if URLs change without redirects, content is removed, or development blocks are left on. Google says to expect temporary ranking fluctuation during a move and that 301 redirects do not lose PageRank. Keeping ranking URLs, mapping every changed URL to its closest match and testing redirects before launch protects most of the value.
How long should I keep redirects after a redesign?
Google’s site move guidance says to keep redirects in place for generally at least one year, and suggests keeping them longer where possible. Many sites keep them indefinitely, because old links from other websites and bookmarks continue to send visitors for years.
What should a website redesign checklist include?
A problem statement and decision-maker, a baseline audit, measurable goals, user research findings, a content decision for every URL, a sitemap and redirect map, a platform and account ownership plan, approved designs, a build with real content and tracking, a passed test plan, a launch sequence and a post-launch measurement plan.
Should I change platforms during a redesign?
Only if the current platform blocks your goals, such as editing, integrations, performance or maintenance. A platform change adds work and risk, so decide during planning, not halfway through the build. Both custom-coded sites and well-built WordPress sites can serve most business needs.
Do I need Search Console Change of Address for a redesign?
Only if you are moving to a new domain or subdomain. Google’s Change of Address tool is not used for path changes, HTTP to HTTPS moves or www changes. For a redesign on the same domain, redirects, an updated XML sitemap and monitoring in Search Console are what matter.

