Website Redesign

Most website redesign projects start with how the site looks: a competitor's site feels sharper, the old theme looks awkward on a phone, the brand has moved on. Yet the real risk is invisible: pages that have ranked for years, links other websites point to and the landing pages your campaigns depend on can all disappear on launch day.

We have ordered this guide the way Talha Aslan and team make decisions on a redesign: first whether you need one at all, then the inventory, redirects, content, speed, tracking, launch day and the weeks after. Each section gives you criteria you can apply to your own site or to an agency proposal.

01Redesign, rebuild from scratch, or leave it alone

The first question is not about design; it is how much value the current site already carries. A site that earns steady search traffic, has links from other websites or catches paid traffic needs a different project from a brand new build. The job becomes moving that value into a new structure.

These are the criteria we use to decide:

• Search traffic: If Search Console shows pages earning clicks over the last twelve months, you need a planned website redesign that protects those pages.
• Surface or structure: If only colors, photos and copy feel dated, a visual refresh that keeps every URL may be enough.
• Maintainability: A theme that can no longer be updated, or old code nobody wants to touch, points to a platform change.
• Brand change: A new domain or several sites merged into one is the riskiest scenario and needs the longest preparation.
• No traffic at all: If the site carries no search or link value, starting from scratch is the simpler path.

Sometimes the right answer is not to redesign yet. A site with strong rankings but a broken contact form and a missing phone number may gain more from fixing those two things this week than from a six month project. When a new site is the right call, our web design service standards take over from there.

02Take a snapshot of the old site before anything changes

The only way to judge a website redesign is to record the old site's numbers before launch. Without that record, every rise or fall afterward is open to debate, and nobody can show what actually changed.

A few weeks before launch, export and keep the following:

1. Clicks and impressions by page and by query from the Search Console performance report, for the longest period available.
2. Sessions and conversions by landing page from Analytics, with form submissions, calls and chat clicks counted separately.
3. Mobile speed tests and Core Web Vitals for every important page.
4. Your current positions for the main searches you target, with the date noted.
5. The number of indexed pages and the current list of errors in Search Console.

These numbers also turn the project goal into something you can check later. "Make it look modern" is not a goal; "more form submissions on mobile, service pages moving off page two" is. If your business is seasonal, compare against the same period last year rather than last month, or a seasonal dip will be blamed on the redesign.

Store the exports in the project folder with their dates. Search Console only keeps performance data for a limited window, so detail from the old period may be gone from the dashboard by the time you want to compare. That report, not a mockup, is the first deliverable of a careful website redesign.

03Build a complete inventory of old URLs

A redirect map is only as good as the URL list behind it: any address missing from the list returns a 404 error after launch. That is why we build the inventory from several sources that fill each other's gaps, not from one.

• Crawl: A crawler lists every page, image and PDF the site links to.
• XML sitemap: Pages dropped from the menu but still live often show up only here.
• Search Console and Analytics: Any URL with impressions or visits in the past year goes on the list, even if nothing on the site links to it anymore.
• Inbound links: URLs that other websites link to get flagged in their own column, because each one will be tested by hand before launch.
• Offline and campaign URLs: QR codes on brochures, email signatures, final URLs in ad accounts and the website link on your Google Business Profile.

The last group is the one most often forgotten. A QR code printed for a trade show keeps circulating for years and points to an old campaign page; if that page vanishes, everyone who scans the brochure lands on an error. Writing each URL's source, traffic and number of linking domains into the sheet makes the next step far easier.

04Keep, merge or retire: a decision for every page

Every URL in the inventory gets one written decision, and that decision comes from data, not taste. "This page does not fit the new layout" is not a reason to delete it.

We decide with these criteria:

• Keep and update: A page with search traffic or inbound links stays; its topic and depth stay the same while the copy is refreshed.
• Merge: Two or three thin pages answering the same question become one strong page, and every old URL redirects to it.
• Retire and redirect: An outdated announcement that earned links is permanently redirected to the closest parent page.
• Remove completely: A page with no traffic, no links and no natural match can return a 410 status, which tells crawlers it is gone on purpose.

A concrete case: a furniture retailer with two short posts, "choosing an office chair" and "how to pick an ergonomic chair", answering the same search could merge them into one thorough guide that serves readers better than either. On the other hand, burying a page that has ranked well on its own for years inside another page, just so the new menu looks tidy, scatters the signals it has built.

Review the sheet with the business owner as well. A page with little traffic may still be the price list or technical sheet your sales team sends to customers every week, and that never shows up in the data. Once the decisions are written down, the redirect map almost writes itself.

05Rules for a redirect map that holds up

Every old URL should point to exactly one closest matching new URL with a permanent, server side 301 redirect. The quality of the map depends on the accuracy of each line, not on how many lines it has.

• One hop: The old URL goes straight to its final destination; no chains from A to B to C, and redirects left over from earlier redesigns are updated to the new targets.
• No bulk home page redirects: Sending hundreds of unmatched URLs to the home page strands visitors, and Google often treats such redirects like missing pages.
• URL variants: Versions with and without a trailing slash, with and without www, and http and https all resolve to one standard.
• Query strings: URLs carrying campaign parameters keep those parameters through the redirect, or ad tracking breaks.
• Files: Ranking images and downloadable PDFs belong in the map too.

You can draft the first pass of the match between old and new URLs with our free redirect mapping tool, then review every suggested match line by line. Google generally recommends keeping redirects in place for at least a year; we recommend never removing them, because old links keep getting clicked years later.

Decide early where the rules will live. They can sit in the server configuration or in the new platform's redirect module; what matters is that the redirect happens on the server, not through a script that runs in the browser after the page loads. If hosting changes too, moving the rules to the new server goes on the launch checklist.

06Do not change URL structure without a reason

The safest redirect is the one you never need. A new design can usually run on the old URL structure, so change URLs only when there is a real problem to solve.

The cases that justify a change are limited: URLs full of meaningless numbers or session codes, the same content opening at two addresses, inconsistent casing or word separators, or a site structure that mirrors internal departments rather than the services customers look for. Shortening URLs simply because they look long is a risk with no clear payoff.

When we design the new structure, we work in this order:

1. Group the services and questions visitors actually search for, and build the main menu around those groups.
2. Give each service exactly one page instead of two pages competing for the same topic.
3. Write the URL rules down: lowercase only, one separator between words, no dates in evergreen pages.
4. Leave the URLs of ranking pages untouched wherever possible.

If the redesign adds a new language, decide the folder structure for language versions now; changing it later means a second migration. We cover that separately on our multilingual website page.

07Moving content without losing rankings

A ranking page should keep its topic, main heading and depth on the new site; the copy can be refreshed, but the page must not turn into something else. Google ranks a page for what it says, and when that disappears, the ranking goes with it.

These are the points we check page by page during migration:

• Title tag and H1: The phrase that matches the queries bringing traffic is kept, and no template leaves a title empty or duplicated.
• Subheadings and FAQs: Questions the old page answered are still answered; text inside an accordion stays in the page source.
• Internal links: Links inside old content are updated to point directly at the new URLs instead of running through redirects.
• Images: File names, alt text and, where possible, image URLs are preserved.
• Structured data: Organization, product or FAQ markup is rebuilt in the new templates and tested.

One more practical rule: do not publish new content on the old site while migration is underway. Every page added during design and build creates a second round of inventory work. A short content freeze closes that gap; if an urgent change cannot wait, make it on the old and new site on the same day and note it in the sheet.

If you want the technical side and content strategy handled together, our SEO service is run by the same team that builds the site.

08Make speed and mobile targets part of acceptance

The speed of the new design should be a written acceptance criterion, measured before launch. "It will be fast" cannot be measured; Google's Core Web Vitals thresholds can.

Google assesses page experience with three metrics and treats these values as good when at least 75 percent of visits meet them:

• LCP: How long the largest piece of content, usually the hero image, takes to load; 2.5 seconds or less.
• INP: How quickly the page responds when a visitor taps or clicks; 200 milliseconds or less.
• CLS: How much elements jump around while the page loads; 0.1 or less.

The usual speed killers in a website redesign are predictable: full screen sliders, uncompressed photos, plugins loaded on every page but used on two, external fonts and chat widgets. Each should be debated during design, not after the build is finished. Measure the top service pages and blog posts, not just the home page, because most visitors never enter through the home page.

On mobile, speed is not the only test. A phone number that dials with one tap, a form that works comfortably with the on screen keyboard and a menu you can open with your thumb belong on the same list. Check how your current site behaves on a phone with our mobile friendly test, then run the same pages again on the new build to compare.

09Tracking, cookie consent and conversions that carry over

If tracking breaks on launch day, you will never know whether the redesign worked. That is why tags are installed on the new site before launch and tested on staging.

Our checklist covers these items:

• Analytics and tag manager: Keep the same account and property so the old and new periods sit in one report.
• Conversions: Form submissions, call clicks and chat clicks are reconnected to the new buttons; triggers that relied on old CSS class names stop working in a new design.
• Ad final URLs: Ads are updated to point at the new pages directly instead of relying on redirects.
• Form notifications: A real submission confirms that leads reach the right inbox.

Privacy rules travel with the redesign. In the EU, non essential tracking needs cookie consent first, and Google requires consent mode for its measurement and personalized advertising features for users in the European Economic Area. If you serve UK visitors, check the ICO's current guidance on cookies as well.

A banner that only appears but lets tags fire before consent does not meet these rules; you can check it by watching network requests in the browser's developer tools before clicking accept.

If ads keep running during the migration, catching campaign traffic on a stable landing page reduces the chance that the switch hurts ad performance.

10Staging and a launch day checklist

The new site is finished on a staging environment closed to search engines, and launch follows a written sequence. Every step left to improvisation on launch day leaves an error that is hard to trace later.

The right way to close staging is password protection. Google cannot read a noindex tag on a page blocked in robots.txt, so a staging URL that leaks through a shared link can end up indexed. A password keeps out both visitors and crawlers.

We run launch day in this order:

1. Take a full backup of the old site and a final export of its URL list.
2. Move the new site to the live server and remove the password and every noindex tag.
3. Switch on the redirect rules and crawl every URL in the map in bulk.
4. Open URLs with inbound links, ad final URLs and QR code targets one by one.
5. Test forms with a real submission and tags in the realtime report.
6. Submit the new XML sitemap in Search Console and, if the domain changed, use the Change of Address tool.

Our redirect checker shows which status code any single URL returns and how many hops it takes to reach its target. Schedule launch for a quieter day and keep the next two working days free for checks.

11What to watch in the weeks after launch

A redesign does not end on launch day; the real checks happen in the weeks while Google recrawls the new URLs. Small fluctuations in the first days are normal, but a lasting drop almost always points to something missing.

During the first weeks we review these regularly:

• Not found pages: The 404 list in Search Console is read every week, and any URL the map missed is added as a redirect.
• Index status: We check that pages from the new sitemap are being indexed and that new URLs are replacing the old ones in results.
• Traffic by page: Compare against your snapshot page by page; the total can look fine while one important page has dropped.
• Conversions: If leads fall relative to traffic, the problem is the new page itself, not rankings.

When a page drops, we ask three questions in order: does the old URL redirect to the right place, does the new page still answer the question the old one answered, and is the page indexed. Most problems turn up in one of those three and can be fixed. Do not delete the Search Console property or verification for the old site either; you may need it to trace the move.

Close the monitoring period with a short report: which URLs were added later, which pages dropped and how they were fixed, and how speed compares with the old site. It becomes the starting point for the next website redesign or major update.

12Common website redesign mistakes

Most losses after a redesign are not technical bad luck; they are predictable omissions. These are the mistakes we see most often, each with what to do instead.

• Starting with mockups: Screens get approved first and content is squeezed in later. Start with the inventory and content decisions, then design around them.
• Redirecting every old URL to the home page: It looks easy but loses both visitors and signals. Pick the closest matching page for each URL.
• Leaving the staging noindex tag on the live site: The new site stays out of the index for weeks. Put this check on the launch list as its own item.
• Cutting long ranking articles: Detailed guides get trimmed to a few paragraphs so the new design looks clean. Keep the text and improve readability with subheadings and layout.
• Adding tracking after launch: The first weeks of data are lost and nothing can be compared. Install and test tags on staging.
• Leaving access with the previous vendor: If the domain, hosting or Search Console sits in someone else's account, launch day stalls. Move that access into your company's name before the project starts.

Going through this list with an agency at proposal stage makes clear which items are in scope.

13Choosing a partner, ownership and next steps

When you compare website redesign proposals, look at the process before the portfolio: who builds the inventory, who writes the redirect map, who monitors after launch. If those three answers are vague, the proposal is selling a new look and little else.

Ask every team you talk to:

• Will the redirect map be delivered in writing, and will it stay with us after the project?
• How will staging be closed, and what gets checked on launch day?
• Are speed targets written into the proposal and reported before launch?
• How many weeks of monitoring follow launch, and are fixes included?
• In whose name will the domain, hosting and admin accounts be registered?

To see our approach in practice, this page links to a live demo site that walks through the redesign process, and you can browse work we have done for clients in our references.

For budgeting, our fixed scope packages are listed under pricing; the scope of a redesign becomes clear once the old site's inventory is done. Send us your current site address through the contact form, and we will talk through what should stay and what should change, then prepare a written redesign plan and quote.