Redesigning your website without losing traffic or ranking

Complete guide: measure first, map your URLs, use 301 redirects, and compare at 7, 30, and 90 days. What is lost in a website redesign and how to preserve it.

A redesign does not ruin your search ranking because of design changes; it ruins it by changing URLs without a redirect map, losing content, and launching without a baseline. Measure beforehand, use permanent 301 redirects, preserve pages that already work, and compare at 7, 30, and 90 days.

There are two distinct types of redesigns, and almost no one separates them. One changes how your website looks. The other changes where each page lives. The former is a design problem. The latter is an address problem, and it is the one that costs you traffic.

We wrote this guide because we have been encountering the same case for years: a Spanish business remakes its website, the new one is cleaner, faster, more organized, and three weeks later, the phone stops ringing. Nobody did anything wrong in the design. Someone changed /servicios/reformas-integrales-madrid to /que-hacemos and left no trace.

Here is the complete procedure: when it makes sense to redesign, what to measure before touching a line of code, how to execute in phases, what to do on launch day, and how to interpret the numbers afterward without fooling yourself.

What is actually lost in a redesign

Let’s start by deconstructing the phrase. "Losing SEO" means nothing operationally. What is lost are specific things, and each has a different mechanism:

Addresses. Each indexed URL is an asset with a history: external links pointing to it, accumulated signals, earned positions. If the URL disappears and doesn't say where it has gone, that asset evaporates.

Content. A typical redesign "simplifies." Twelve service pages become one services page with twelve paragraphs. You have deleted eleven pages that answered eleven different searches and now you have one that answers all of them poorly.

Internal links. The old menu linked to the pricing page from 40 places. The new menu hides it in the footer. The page still exists, but it has stopped receiving signals from your own website.

Data. You switch platforms, change tracking, and lose the reference point for comparison. Without a baseline, there is no diagnosis: there are only feelings.

Speed. A redesign with a background video, three fonts loaded via CDN, and a carousel can be slower than the 2019 website it replaces.

The industry standard: The industry sells redesigns as a makeover and treats URLs as a technical detail to be solved at the end, the eve of the launch.

Our criteria: We treat the URL map as the first deliverable of the project, before the grid and before the color. The design is drawn on top of a structure that has already been decided.

When to redesign: thresholds, not hunches

"The website looks dated" is not a criterion. It is a feeling, usually held by the founder, usually after seeing a competitor's website. We do not accept a redesign project based solely on that.

A redesign is justified when you can name the number you want to move. These are five of the seven triggers that actually support the decision:

1. Conversion falls while traffic is stable. You have the same visits as a year ago and fewer leads. The problem is inside the page, not on Google.
2. Maintenance costs exceed the cost of rebuilding. Every small change requires a developer because nobody documented the system. You are paying rent.
3. The structure no longer describes the business. You sell four service lines and the website talks about two. The menu is lying.
4. Field performance is consistently in the red. Not for one day: three months straight above the thresholds.
5. Legal requirements force you to touch the interaction layer. Accessibility, consent, invoicing. If you are going to pop the hood, open it completely.

If none of these five apply, what you need is not a redesign: it is a surgical intervention on three templates. We tell you this in those words even if it loses us the project. The complete development of these seven thresholds, with the exact way to measure each one, is in When to redesign your website: 7 measurable thresholds.

The baseline: what to measure before touching anything

This is the phase that almost no Spanish budget includes and the one that decides whether you will be able to diagnose a problem or just lament it. It is a week's work, not an afternoon's.

The rule is simple: if you haven't exported it before the launch, it doesn't exist afterward. The Search Console performance report shows the last three months by default, and Google Analytics 4 applies a retention limit to user-level and event-level data — standard options are 2 or 14 months, extendable only in 360 properties. Aggregate reports are not affected by that setting, but any fine-grained analysis is.

• Full crawl of the current website (all URLs with their status code, title, meta description, headers, canonical, and internal inbound links)
• Search Console export: queries, pages, clicks, impressions, and average position for the last available months, in CSV
• Analytics export: sessions, conversions, and landing pages per month, with the longest window your retention settings allow
• List of pages receiving external links, sorted by the number of referring domains
• Snapshot of current field Core Web Vitals, per template and per device
• Inventory of forms, with the destination of each submission and associated email address
• Inventory of integrations that call one of your URLs: payment gateway, booking tools, CRM, invoicing, active campaigns
• Full copy of the database and files, with date and location noted

That last point deserves its own sentence. In a Spanish store with Redsys, the gateway returns the buyer to a specific URL and notifies another. If the redesign changes those paths and no one updates the configuration in the virtual POS, charges are authorized and orders are not recorded. It is not a positioning problem: it is an invoicing problem, and it appears on the first day. How Redsys and Bizum are integrated, and which routes must be preserved, we explain in Redsys and Bizum in your online store.

The six movements of a redesign

We work the same way on a redesign as on a new website, with one difference: here there is a past to respect. These are our movements.

Movement 03 is what separates a healthy redesign from an expensive one. It is done in a spreadsheet with two columns and as many rows as you have indexed URLs. It is not done from memory.

The redirect map

This is where almost all the project risk is concentrated and a minimal fraction of the budget. It is a disproportion that should be corrected.

What code to use

Google is explicit: for a move, use server-side permanent redirects. In its documentation on site moves with URL changes, it recommends using HTTP permanent redirects "if possible, such as 301 and 308".

The difference from temporary ones is not cosmetic. With a 301 or 308, according to Google's own documentation, "the indexing process uses the redirect as a signal that the redirect target should be the canonical one". With a 302 or 307, "the indexing process does not use the redirect as that signal", and the old page may remain indexed.

How long to keep them

They are not a two-month fix.

We leave them in place indefinitely and document it in the handoff, because the cost of maintaining a redirect table is zero and the cost of removing it on the wrong day is a month of traffic.

The four map errors

Chains. URL A redirects to B, which redirects to C. Each jump is an opportunity to lose something and one more call to the server. The map is flattened: A goes directly to C.

Loops. The non-www version redirects to the www version, which redirects to the non-www version. This is detected in two minutes with a header request. It is detected if someone actually checks.

Mass redirect to the homepage. It is the industry's favorite shortcut: everything I can't find, send to the homepage. Google treats many of these redirects as not-found pages, and the user who was looking for your pricing page lands on a header with a background video. Each URL goes to its thematic equivalent, or to an honest 404. There is no third option.

Forgetting resources. The catalog PDF, the image someone linked in a forum, the cookie policy URL that appears in your legal documentation. These are also addresses.

Before the launch, we run the full list of old URLs through an automated check that verifies, one by one, the status code and final destination. No exceptions and no sampling.

Domain change: a separate case

If, in addition to the design, you change the domain — from .com to .es, for rebranding, for corporate restructuring — there is a specific tool with strict rules.

Three conditions worth knowing before planning:

• You need to be a verified owner of both properties in the same Google account.
• The tool works only at the domain level, not the path level. You can move ejemplo.com; you cannot move ejemplo.com/tienda.
• It requires a 301 redirect from the old homepage to the new one before starting.

And a clarification that saves confusion: you don't need it if you switch from HTTP to HTTPS, if you change between www and non-www on the same domain, or if you reorganize routes within the same domain. A well-executed redirect map is sufficient for that.

Regarding timelines, Google promises nothing beyond this: "a small or medium-sized website may take a few weeks for most of its pages to move, and large sites take longer". Anyone giving you an exact recovery date is making it up.

1. The indexed staging environment

The classic. It is developed on nuevo.tudominio.es, someone forgets to block it, Google indexes it, and on launch day you have two versions of each page competing with each other.

And its inverse variant, more silent: blocking the environment with robots.txt and believing that it de-indexes it. It does not. Google is categorical: "if the page is blocked by a robots.txt file or the crawler cannot access it, the crawler will never see the noindex rule". The correct way is to allow crawling and return noindex, via the meta tag or the X-Robots-Tag header. Password blocking also works, and it is what we use.

2. Launching with noindex enabled

The exact opposite. The staging environment had noindex in the base template and no one removed it upon publishing. The new website works, looks good, and is actively asking not to be indexed. It is a thirty-second error that costs six weeks. It goes on the pre-launch checklist, not in anyone's memory.

3. Pruning content without data

"These 30 blog posts are old, let's delete them." Before deleting, cross-reference the list with the Search Console export. The 2019 post that no one remembers might be the one bringing you a significant portion of your search traffic. If the content is truly redundant, it is retired and its URL is redirected to the content that replaces it. This is decided with the export in front of you, not with the aesthetic criteria of the meeting.

4. Breaking the legal layer in the move

When switching platforms, the cookie banner is remade and the configuration that already worked is lost: prior consent, actual blocking of tags before acceptance, the signal that analytics needs. The new website can be faster and yet less compliant than the old one. We treat this as another template in the project, with its own tests. The detail is in Legal obligations of a website in Spain.

Add a very specific Spanish case: if your current website came from a Kit Digital grant, review what maintenance and exclusivity commitments are still binding in your contract with the digital agent before replacing anything.

5. Confusing redesign with platform change

They are two different projects. You can redesign on the same platform and you can migrate platforms without touching the design. Doing both at the same time multiplies the variables and makes it impossible to know what caused what when something fails. When the client insists, we do it anyway, but sequenced and with two different launch windows. The platform decision tree is in Which platform to choose for your website in 2026.

Performance: what actually improves

The redesign is the best opportunity you will have to fix speed, and the worst if no one monitors it. The thresholds are public and do not admit interpretation.

Two nuances that almost no Spanish page on the subject includes, and which contradict each other only in appearance.

The first: Google literally says that "Core Web Vitals are used by our ranking systems", and on the same page that achieving good results "does not guarantee that your pages will rank high". It adds that Search "always tries to show the most relevant content, even if the page experience is poor". Operational translation: speed does not buy positions, but it breaks ties. Optimizing below the threshold does not give you anything extra; being above it does subtract.

The second, and it is the one that breaks expectations: field data takes time.

If you launch today, two weeks from now your field report will still be mixing the old website with the new one. The clean reading arrives at 28 days. Anyone showing you a field improvement after five days is showing you laboratory data and calling it something else. When it pays to optimize and how much, in Web performance for businesses.

Accessibility: in 2026 you redesign under the EAA

If you are going to redo the interaction layer of your website, redo it in compliance. Redoing it twice costs double.

The directive expressly covers "e-commerce services", defined as services provided at a distance through websites and mobile applications to conclude a consumer contract. Also banking services, passenger transport, e-books, and telephony. And it exempts micro-enterprises providing services: Article 4 establishes that the requirements and obligations of the directive "shall not apply to micro-enterprises providing services".

That exemption is narrower than people think and does not exempt micro-enterprises that manufacture or distribute products included in the scope. Before relying on it, check your case. The detail, in Web accessibility in Spain after the European Accessibility Act.

Checked on 08-27-2026 against the text of Directive (EU) 2019/882 and Law 11/2023 published in the BOE. Spanish regulatory development and supervisory criteria may evolve: verify the current status before making a decision with contractual consequences.

A practical warning: overlay widgets that promise compliance with a line of JavaScript do not provide it. Accessibility is solved in the markup, in the contrast, in the focus order, and in the states. Why overlays are not enough, here.

The launch: order and the first 72 hours

Launch is a checklist, not a leap of faith. These are the decisions we make before the window.

When. Tuesday or Wednesday morning. Never a Friday, never the eve of a holiday, never during your peak revenue week. If you sell turrón, you don't launch in November.

In what order. First the redirects, then the DNS. Never the other way around: if the domain already points to the new server and the redirects are not in place, every visit to an old URL is a 404 served to a real user.

With what exit strategy. A written reversion plan, with the name of the person who executes it and the estimated time. If you cannot revert in less than an hour, you are not ready to launch.

• Automatic check of old URLs: status code and final destination, no sampling
• New sitemap generated and submitted in Search Console; old sitemap removed afterward
• Production robots.txt reviewed line by line, and no template with noindex inherited from the staging environment
• Valid certificate and forced redirect to HTTPS, with the canonical domain version chosen and applied
• Test forms submitted, one by one, confirming that the email arrives in the correct inbox
• Payment gateway tested with a real transaction of minimum amount, including the return notification
• Analytics and consent verified: the tag does not fire before acceptance and does fire after
• Server errors monitored in logs during the first 24 hours
• Search Console indexed pages report reviewed on the third day to detect 404 spikes and exclusions

Our full list, the one we apply in production, has 47 checks and is published in full in Checklist of 47 checks before putting a website into production.

A note on the sitemap: don't inflate it. The limit for one file is 50,000 URLs or 50 MB uncompressed, and Google uses the lastmod value only "if it is consistent and verifiably accurate", while completely ignoring priority and changefreq. A sitemap with fake dates is worse than one with no dates.

What to measure afterward, and when to look at it

The temptation is to open the analytics every hour of the first day. It's useless and leads to bad decisions. This is the calendar we follow.

Always compare against the same period of the previous year, not against the last month. In Spain, August and December distort any reading, and a redesign launched in July will look like a disaster in August for reasons that have nothing to do with your website.

And compare by page, not just in aggregate. A flat total can hide the fact that your five commercial pages have fallen while the blog has risen. The aggregate consoles; the breakdown informs.

How long it takes and how much it costs

Our framework: brand and website in 6-12 weeks, digital products in 8-week phases. Fixed price per phase, agreed upon before starting, no surprise hours. Upon completion, we deliver code, source files, and documentation, and 30 days of support included after launch.

A redesign with SEO preservation adds work that a new website does not have: the inventory, the redirect map, content migration, and subsequent monitoring. That work is budgeted separately and named in the contract, so you know exactly what you are paying for.

— = data being measured; we will publish it once we have our own sample.

Regarding recovery timelines, we give no guarantees because no one can give them. What we can tell you is what we have measured in our own projects:

And its reverse, which is the data you would really want to know before signing:

When those two numbers are measured with method, they are published here with their n and their date. We prefer a marked space to a comfortable figure. If you want to see how we treat prices with the same criteria, it is in Why almost no Spanish agency publishes prices (and these are ours), and the budget is read knowing if the figure includes VAT or not: we developed that in Does a website price include VAT?.

When you shouldn't redesign

Three situations where we decline the project or propose something else.

When the problem is the offer, not the website. If no one buys from you because your proposal isn't clear in your head, a new website will express it poorly with better typography.

When you have just redesigned. If your website is less than eighteen months old and the problem is conversion, it is fixed with measured changes on three templates. Redesigning the whole thing is wasting learning.

When there is no one who can maintain it. Delivering a system that your team cannot touch is creating a dependency. We design so that your team can carry on without us, and if there is no team, that is the first thing to solve.

A redesign is judged by what it preserves, not by what it unveils.

A well-done redesign goes unnoticed. There is no drop, no weird week, no emergency meeting. The phone keeps ringing the same, and after three months it rings a bit more. That silence is the result.

A redesign is not an opportunity to reinvent yourself: it is an opportunity to preserve what already works and remove what gets in the way. We start by asking what pages bring you food, not by proposing a palette.

Does this way of working fit? Tell us what you have in front of you in an initial 30-minute call at no cost. We respond in less than 24 working hours.

Frequently asked questions

How much traffic is lost when redesigning a website?

With URLs intact and content preserved, the loss should be zero or close to zero. If you change URLs, there is a normal fluctuation of weeks while Google reindexes; Google indicates that a small or medium site may take a few weeks to move most of its pages. No one can guarantee an exact figure, and anyone who does is blowing smoke.

Is it better to keep the old URLs even if they are ugly?

Yes, in most cases. An ugly URL that ranks is worth more than a new one that starts from scratch. Change only those that are inconsistent with the new structure, and when you do, redirect them one by one with a 301.

How long should redirects be kept?

Google recommends keeping them for at least a year. We leave them indefinitely and document it in the handoff: maintaining a redirect table costs nothing and removing it on the wrong day costs a month of traffic.

Can I redesign and change platforms at the same time?

You can, but you multiply the variables and lose the ability to know what caused a problem. We sequence it in two separate launch windows. If your calendar doesn't allow it, we do it together and tell you clearly: the subsequent diagnosis will be slower.

Do I have to redo the cookie banner and accessibility?

Yes. Changing the interaction layer invalidates previous tests. Take advantage of the work to leave the website compliant from the first day, because redoing it in two passes costs double.

Keep reading

• When to redesign your website: 7 measurable thresholds (not "7 signs")
• Checklist of 47 checks before putting a website into production
• Web performance for businesses: what Core Web Vitals are and when it pays to optimize
• Web accessibility in Spain after the European Accessibility Act
• Which platform to choose for your website in 2026: honest decision tree
• How to get your website to appear on Google and be cited by ChatGPT and Perplexity
• Template for contract and transfer of rights

Transparency note. Some of our own data in this guide is still being measured on real projects, with a single method. We will publish it with its sample size and date range once the sample is large enough; until then, every figure you see carries its source and date of consultation.

Sources

• https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes — permanent redirect 301/308 recommendation, "keep the redirects for as long as possible, generally at least 1 year", move timelines ("a few weeks" for small and medium sites) and new sitemap submission. Accessed 08-27-2026.
• https://developers.google.com/search/docs/crawling-indexing/301-redirects — difference between permanent (301/308, canonical signal) and temporary (302/307, no such signal); meta refresh 0s vs delayed; warning about JavaScript redirects. Accessed 08-27-2026.
• https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes — temporary crawl rate drop after infrastructure change and monitoring recommendations (server logs, indexing reports). Accessed 08-27-2026.
• https://support.google.com/webmasters/answer/9370220 — change of address tool: verified ownership of both properties in the same account, domain level only, 301 homepage-to-homepage, and transfer signal for 180 days. Accessed 08-27-2026.
• https://developers.google.com/search/docs/crawling-indexing/block-indexing — "if the page is blocked by robots.txt or the crawler cannot access, it will never see the noindex rule"; implementation with meta robots or X-Robots-Tag. Accessed 08-27-2026.
• https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap — 50,000 URL or 50 MB uncompressed limit per sitemap; lastmod used only if accurate and verifiable; priority and changefreq ignored. Accessed 08-27-2026.
• https://developers.google.com/search/docs/appearance/page-experience — "Core Web Vitals are used by our ranking systems", good results don't guarantee positions, and Search shows the most relevant content even if page experience is poor. Accessed 08-27-2026.
• https://web.dev/articles/vitals — "Good" thresholds: LCP 2.5s, INP 200ms, CLS 0.1, evaluated at the 75th percentile segmented by mobile and desktop. Accessed 08-27-2026.
• https://developer.chrome.com/docs/crux/api — "The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics"; daily update around 04:00 UTC. Accessed 08-27-2026.
• https://developer.chrome.com/docs/crux/methodology — CrUX eligibility criteria: page must be publicly discoverable (no noindex, status 200) and sufficiently popular. Accessed 08-27-2026.
• https://support.google.com/webmasters/answer/7576553 — Search Console performance report shows the last three months by default. Accessed 08-27-2026.
• https://support.google.com/analytics/answer/7667196 — data retention in GA4: 2 or 14 months in standard properties (26/38/50 in 360); does not affect standard aggregate reports. Accessed 08-27-2026.
• https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32019L0882 — Directive (EU) 2019/882: art. 31 (measures applicable from June 28, 2025), art. 4 (requirements do not apply to micro-enterprises providing services), art. 2 (e-commerce services included). Accessed 08-27-2026.
• https://www.boe.es/diario_boe/txt.php?id=BOE-A-2023-11022 — Law 11/2023, of May 8, on the transposition of EU Directives regarding accessibility of certain products and services (among others); BOE of May 9, 2023. Accessed 08-27-2026.
• https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en — list of products and services covered by the EAA (e-commerce, banking services, passenger transport, e-books, telephony). Accessed 08-27-2026.