Every successful website redesign follows seven phases: Plan, Audit, Information Architecture and Content, Design, Build, Test, and Launch and Monitor. Before touching a single page, benchmark your current KPIs and set three measurable goals since that baseline is what tells you later whether the redesign actually worked. Whatever you do, protect your existing URLs and page speed as you restructure, or you risk losing the search visibility you already earned.
TL;DR:
- Maintaining existing URLs and page speed during a redesign is crucial to preserve search rankings and visibility.
- Conducting a thorough content and SEO audit enables prioritization of pages to keep, merge, or retire, based on backlink strength and traffic.
- Setting clear, measurable goals with assigned owners and deadlines ensures focused progress and minimizes scope creep.
- Implementing accurate 1:1 URL redirects and preserving structured data during migration is essential to prevent ranking losses.
- Continuous post-launch monitoring of search and performance metrics for at least a year helps address issues early and sustain SEO value.
Table of Contents
- Planning Checklist: Goals, Leadership, Scope, and Timeline
- Audit: Analytics, Content Inventory, and SEO Crawl
- Create the Sitemap, URL Strategy, and Content Migration Plan
- Design Phase: Wireframes, Prototypes, and Accessibility Checks
- Build Phase: Staging, SEO Preservation, and Performance Targets
- QA and Prelaunch Checklist: Functional, Cross-Device, and SEO Validation
- Launch Day and Post-Launch Monitoring: The First 30 to 90 Days
- What 200+ Redesign Projects Have Taught Us About What Actually Breaks
- When a DIY Redesign Reaches Its Limit
- FAQ
- Sources
Planning Checklist: Goals, Leadership, Scope, and Timeline
A redesign is not automatically the right move. If your core issue is stale copy or outdated photos, a content refresh solves it faster and cheaper. Reach for a full redesign when the structure itself is broken: confusing navigation, a platform that cannot support mobile traffic, or conversion rates that have stalled despite steady traffic.
Once you confirm a redesign is justified, write down why. Vague goals like “make it look better” produce vague results. Instead, set 3 to 5 SMART goals tied to outcomes you can measure: increase organic traffic by a defined percentage, lift conversion rate on your top landing page, or cut page load time to a specific target. Each goal needs an owner and a deadline.
Next, name a single project leader. Redesigns commissioned by committee tend to drift, because every stakeholder pushes a different priority and nobody has authority to make the final call. Guidance from the University of Iowa’s web community recommends assigning one leader or a small leadership team specifically to avoid this pattern, since a single decision-maker cuts down on repeated scope changes and review cycles.
With a leader in place, draft a timeline that marks major milestones (audit complete, wireframes approved, staging live, launch date) and attach a rough budget to each phase. Build in buffer time for stakeholder review rounds, since approvals almost always take longer than planned.
Before design work begins, produce these deliverables:
- A full content inventory listing every existing page and its traffic.
- A draft sitemap showing proposed site structure.
- An exported KPI baseline covering traffic, conversions, and page speed.
- A one-page project brief stating goals, leader, timeline, and budget range.
That brief becomes the reference document everyone returns to when a new idea threatens to expand the project mid-stream.
Audit: Analytics, Content Inventory, and SEO Crawl
A redesign built on assumptions instead of data tends to repeat old mistakes with a new coat of paint. Start the audit by exporting a defined set of KPIs from your analytics platform: top landing pages by traffic, conversion funnel drop-off points, top exit pages, and device split between mobile and desktop. That last number matters more than most owners assume, since mobile devices account for a substantial share of website traffic across most industries, which means your redesign has to work on a phone screen first and a desktop monitor second.
Build a content inventory spreadsheet with these columns: URL, page owner, monthly traffic, number of referring backlinks, and an action column marked keep, merge, or delete. This single sheet becomes the backbone of your information architecture decisions later.
Run a technical SEO crawl alongside the content audit. Follow these steps in order:
- Fetch key pages as Google to confirm they render correctly for crawlers.
- Check canonical tags on every page to catch duplicate-content issues.
- Review index coverage reports finding pages that are not currently indexed.
- Export a full backlink inventory so you know which URLs carry external link equity.
- Flag any page with strong backlinks or rankings as high-priority to preserve.
While you are reviewing competitors for inspiration, store screenshots and notes in a shared folder rather than copying layouts directly. Borrowing a general approach is fine; replicating specific design elements can create legal and brand-dilution problems.
Pro Tip: Sort your content inventory by backlink count first, not traffic. A low-traffic page with strong external links can do more damage to your rankings if deleted than a popular page that converts poorly.
The audit phase ends with one deliverable: a prioritized backlog that tells your team exactly which pages move as-is, which get merged, and which get retired. That backlog feeds directly into the next phase.
Create the Sitemap, URL Strategy, and Content Migration Plan
Your content inventory and SEO crawl now become the raw material for a new sitemap. Group pages by topic and user intent rather than by your internal org chart, since visitors navigate by what they need, not by your department structure.
Apply simple rules when deciding what happens to each URL:
- Keep a URL unchanged when it ranks well and the page content is not changing structurally.
- Change a URL only when the new slug is meaningfully clearer or shorter for both users and search engines.
- Write slugs in lowercase, with hyphens between words, and skip stop words like “the” or “and”.
- Never let two different pages end up targeting the same keyword after the redesign.
For every URL that does change, build a 1:1 redirect mapping spreadsheet before development starts, pairing each old URL with its new destination. Google’s own site-move documentation treats this mapping as the foundation of a safe migration, and skipping it is the single most common cause of traffic loss after a redesign. Pages you are merging need their own backlog entry showing which surviving URL will absorb their traffic and backlinks.
Once the sitemap is set, define page templates: homepage, service page, blog post, product page, and landing page, for example. For each template, specify the required metadata fields: title tag, meta description, header structure, and schema markup where relevant. Consistent templates make the build phase faster and prevent gaps where a page quietly ships without basic SEO fields filled in.
Finally, build an editorial calendar assigning a content owner to each page that needs rewriting, trimming, or new copy before migration. Give each owner a deadline tied to the design and build timeline, because content that is not ready when development needs it is one of the most common causes of launch delays.
Design Phase: Wireframes, Prototypes, and Accessibility Checks
Design work moves through two gates before a single pixel gets finalized. Start with low-fidelity wireframes that map layout and content hierarchy without color or imagery, and get stakeholder signoff here first, since revisions are cheap at this stage and expensive later. Once wireframes are approved, build interactive prototypes that simulate real navigation and get a second signoff before development begins.
Between those two gates, run a small usability test. Five to eight participants from your target audience is enough to surface the most common friction points. Give each one a specific task, such as finding your pricing page or completing a contact form, and watch where they hesitate or backtrack. Success looks like most testers completing the task without help and without expressing confusion about where to click next.
Build your accessibility checks into this phase rather than treating them as a final audit. WCAG 2.2 adds several testable success criteria worth checking at the design stage:
- Confirm keyboard focus indicators are visible and never hidden behind sticky headers or overlays.
- Check that interactive elements like buttons and links meet minimum target size for touch and click.
- Verify text and background color combinations meet contrast ratio requirements.
- Test that navigation order follows a logical, predictable path for keyboard-only users.
The W3C’s own summary of what changed in WCAG 2.2 highlights “Focus Not Obscured” and “Focus Appearance” specifically, both aimed at making sure users navigating by keyboard can always see where they are on the page.
Prepare a design system alongside these checks: color tokens, reusable components, typography scales, and content blocks that developers can assemble consistently. Log every major design decision and usability finding in a shared document, since that record becomes invaluable if a stakeholder questions a choice months later.
Pro Tip: Run your contrast checks and focus-visibility checks on the actual prototype, not on static mockups. Problems that look fine in Figma sometimes disappear or reappear once real browser rendering is involved.
Build Phase: Staging, SEO Preservation, and Performance Targets
Development starts with a secure staging environment, password-protected and blocked from search engine indexing through a noindex directive or server-level access restriction. A staging site that accidentally gets indexed creates duplicate content problems that can confuse rankings for weeks.
As pages get built, preserve the SEO signals your audit identified as valuable:
- Carry over canonical tags exactly as mapped in your redirect spreadsheet.
- Rebuild structured data markup for products, articles, or local business information.
- Transfer title tags and meta descriptions according to your template specifications.
- Set hreflang tags correctly if you serve multiple languages or regions.
- Implement your 1:1 redirect map using server-side 301 redirects, never JavaScript or meta-refresh redirects.
Google’s site-move guidance is specific on this point: avoid redirect chains where one URL hops through two or three intermediate redirects before reaching its destination, since each hop adds load time and dilutes link equity. Plan to keep every redirect live for at least one year, giving search engines enough time to fully reassign ranking signals to the new URLs.
Performance is not optional at this stage. Core Web Vitals set three specific thresholds that define a “good” user experience: Largest Contentful Paint at 2,500 milliseconds or faster, Interaction to Next Paint at 200 milliseconds or faster, and Cumulative Layout Shift at 0.1 or lower, each measured at the 75th percentile of real visits, according to Web. Hitting those numbers matters because they reflect what a typical visitor experiences, not just a best-case lab test.
To hit those targets, Chrome’s own performance guidance recommends a short list of fixes that cover most redesign-related slowdowns:
- Compress and serve images in modern formats like WebP.
- Reduce and defer non-critical JavaScript so it does not block rendering.
- Reserve space for images and ads that load after the initial page paint.
- Limit third-party scripts, since each one adds its own loading delay.
Before moving to testing, run your staging site through PageSpeed Insights and Lighthouse, and compare the results against Chrome User Experience Report (CrUX) data if your domain has enough traffic to appear there. Those three tools together give you both lab data and real-world field data, which catch different kinds of performance problems.
QA and Prelaunch Checklist: Functional, Cross-Device, and SEO Validation
Staging is where you catch the problems that are expensive to fix after launch. Start functional QA with every interactive element: submit every form, complete a test transaction if you run e-commerce, confirm third-party integrations like booking tools or CRMs still fire correctly, and log in and out of any user account area.
Test across devices and browsers methodically rather than spot-checking at random:
- Load every major page template on at least one iOS and one Android device.
- Check rendering in Chrome, Safari, and Firefox at minimum.
- Run automated smoke tests on critical paths like checkout or contact forms.
- Confirm tablet breakpoints do not break navigation or layout.
Analytics validation deserves its own pass, separate from functional testing. Confirm that goal completions, event tracking, and e-commerce transactions all fire correctly on staging before launch, and check that any UTM parameters from paid campaigns still resolve to the correct landing pages. Our reporting and analytics resources cover setup details if your tracking needs a deeper look before go-live.
SEO prelaunch tasks close out this phase:
- Crawl the staging site with a tool like Screaming Frog to catch broken links or missing metadata.
- Spot-check your redirect map against the live redirect behavior on staging.
- Review robots.txt and meta robots tags to confirm nothing is accidentally blocking production pages.
Pro Tip: Keep a plain-text launch checklist that your project leader checks off line by line on launch day. A verbal “looks good to me” is not a verification step.
Decide between a full launch, switching everything at once, or a phased migration, moving sections in stages. Phased migration reduces risk for large sites but stretches out the monitoring period.
Launch Day and Post-Launch Monitoring: The First 30 to 90 Days
Launch day starts with a handful of immediate checks, not a celebration. Run through these in order:
- Confirm every page returns a 200 status code and redirects resolve correctly, not as chains.
- Submit your updated XML sitemap through Search Console.
- Verify robots.txt is not accidentally blocking the live site the way it blocked staging.
- Run a quick PageSpeed Insights test on your homepage and top landing pages.
For the following weeks, watch four dashboards daily at first, then weekly: Search Console for crawl errors and indexing status, your analytics platform for traffic and conversion trends, an uptime monitor for downtime alerts, and server error logs for 404s or 500 errors that surface once real traffic hits the new site.
The most common post-launch issues are predictable: a missing meta description on a page that slipped through template assignment, an internal link pointing to an old URL instead of the redirect destination, or an image missing alt text. Each has a quick fix once flagged, which is why daily monitoring in the first two weeks matters more than monitoring in month two.
Keep your redirects live for at least a year rather than removing them once rankings seem stable, since Google’s migration guidance notes that search engines need sustained time to fully reassign signals, and old links from external sites or social shares can keep sending traffic to outdated URLs for far longer than expected.
Set an ongoing governance schedule once the dust settles: a monthly content review, a quarterly performance audit, and a clear process for any future A/B test so changes do not quietly bypass the same review discipline that got you through the redesign.
What 200+ Redesign Projects Have Taught Us About What Actually Breaks
Across more than 200 projects, we keep seeing the same two failure patterns derail otherwise well-planned redesigns: design-by-committee, where every stakeholder’s preference gets folded into the final design with no one empowered to say no, and missing ownership, where nobody is accountable for content migration until launch week arrives and half the copy is not ready.
Our standard practice is simple and non-negotiable on every project: assigning a project leader from day one and using a detailed launch checklist to verify readiness before going live. Neither step takes much time, and both prevent the kind of last-minute scramble that turns a redesign into a stressful launch night. Small, consistent checks beat heroic last-minute fixes every time, and that pattern holds whether a project is a five-page brochure site or a full e-commerce rebuild.
— Arsan
When a DIY Redesign Reaches Its Limit
Following this checklist works well for straightforward sites with a handful of pages and no complex integrations. Once e-commerce, custom web applications, or multiple third-party integrations enter the picture, the margin for error narrows fast, and that is usually when outside help pays for itself in avoided downtime alone.
We develop websites, e-commerce platforms, and web applications following a structured phase-by-phase process, accompanied by ongoing support after launch. If you are weighing a hire, consider:
- Complexity: multiple integrations or custom functionality raise the risk of a DIY misstep.
- Risk tolerance: an e-commerce site losing rankings during checkout season costs more than it saves.
- Time: a dedicated team moves through audit, design, and build phases concurrently instead of sequentially.
Our free website design offer is a straightforward way to see what a professional redesign plan looks like for your specific site, and our services overview covers custom design, e-commerce development, and ongoing support in more detail.
FAQ
What are the steps to a website redesign?
The standard sequence is Plan, Audit, Information Architecture and Content, Design, Build, Test, and Launch and Monitor. Each phase produces a deliverable, like a KPI baseline or a redirect map, that the next phase depends on, so skipping a step tends to cause rework later.
What to do before website redesign?
Before any design work starts, export your current analytics KPIs, complete a full content inventory, and set 3 to 5 SMART goals tied to business outcomes. Assign a single project leader, since guidance on managing redesign projects points to committee-led decisions as a common cause of delays and scope creep.
How much does a full website redesign cost?
Cost depends heavily on scope: a small brochure site costs far less than an e-commerce platform or a custom web application. Custom design and development, e-commerce development, and web application solutions are priced individually per project, with quotes available on request through our services page.
Will I lose Google ranking if I redesign or redevelop my website?
A redesign risks temporary ranking drops mainly when URLs change without proper redirects or when page speed regresses. Following Google’s site-move guidance, which calls for a complete 1:1 redirect map and server-side 301 redirects kept live for at least a year, substantially reduces that risk.
