When to redesign your website: 7 measurable thresholds (2026)

Redesigning shouldn't be based on intuition. Seven thresholds with specific cut-offs: LCP, INP, mobile conversion, language support, accessibility, and maintenance.

Redesign when you cross a threshold, not when you grow tired of your design. The seven we use: LCP above 4 seconds in the 75th percentile on mobile, INP above 500 ms, mobile conversion below half of desktop conversion, language without security support, failure to meet accessibility standards, disproportionate annual maintenance, and changes that require touching code.

Search for "when to redesign my website" and you will find lists of signals. Your website "looks old." Your website "doesn't communicate." Your website "isn't up to par with your business." None of those phrases contains a number, and therefore none can be verified on a Monday morning.

We work in reverse. A threshold is a number with a side: below it, you optimize; above it, you rebuild. Here are the seven we apply before accepting a redesign project, with their cut-off, source, and method of measurement.

A prior warning, as it is the most expensive confusion in the industry: the 0-100 PageSpeed Insights score is not a threshold. It is a laboratory simulation of a single load. Real thresholds live in field data, from real users, and are read in the 75th percentile segmented by mobile and desktop, according to Google's documentation at web.dev. We have seen entire redesign budgets justified based on a 43 laboratory score while the field data was in the green. A website was rebuilt that didn't need it.

The seven thresholds, at a glance

Crossing one doesn't mandate anything. Crossing three at once is the pattern that makes us say yes to a full redesign project.

Threshold 1 · LCP above 4 seconds in the 75th percentile on mobile

The Largest Contentful Paint measures how long it takes for the main element on the screen to render. Google sets the "good" cut-off at 2.5 seconds and the "poor" cut-off at 4 seconds, measured at the 75th percentile of actual loads (web.dev, accessed 08-27-2026).

The nuance that changes the decision lies in the intermediate range. Between 2.5 and 4 seconds you don't have a design problem: you have uncompressed images, render-blocking fonts, and a slow server. That can be fixed in days, with the website you already have.

Above 4 seconds sustained for three months, with obvious optimizations already done, what is failing is the architecture: a template with twenty chained plugins, a visual builder that generates four thousand lines of CSS, or a purchased theme that loads the entire icon library to paint three arrows. That isn't optimized: it's replaced.

Google confirms in its documentation that "Core Web Vitals are used by our ranking systems," and on the same page clarifies that there is no single signal and that content relevance takes precedence over page experience (Google Search Central, accessed 08-27-2026). These are two statements that coexist and that the industry tends to quote only half of. Poor performance subtracts from you; perfect performance does not invent relevance.

Threshold 2 · INP above 500 milliseconds

INP measures the latency between when the user taps something and the screen responds. It has been a stable metric since 2024, replacing FID. Good: 200 ms or less. Poor: above 500 ms.

Here is a diagnosis that almost nobody performs and that saves a lot of money. If your INP is poor but your LCP is good, you don't need to redesign: you need to remove JavaScript. That profile—fast loading, late response—is almost always the support chat, the tag manager with nine active tags, and the consent banner being re-evaluated on every interaction. It is solved by auditing scripts, not grids.

The redesign comes in when LCP and INP are both in the red. Then the problem is the foundation, and patching is more expensive than starting over.

Threshold 3 · Mobile conversion below half of desktop

This is the threshold that decides the most, and the one measured the least.

We aren't going to give you an "industry average" conversion rate, because any such figure mixes e-commerce with professional services and means nothing when applied to your specific case. We give you a ratio that only compares you to yourself: divide your conversion rate on mobile by your rate on desktop.

A ratio above 0.80 is normal. Between 0.50 and 0.80 there is localized friction: a long form, a keyboard covering the button, a payment step with too many fields. Below 0.50, with majority mobile traffic, your website is working on the device that almost nobody uses to buy from you. That isn't a conversion leak: it's a website built for the wrong screen.

Threshold 4 · Your language has run out of security support

This threshold is binary and admits no conversation. Either your version receives security patches, or it doesn't.

As of August 27, 2026, according to endoflife.date/php: PHP 8.1 and earlier are end-of-life; PHP 8.2 has security support until 12-31-2026; PHP 8.3, until 12-31-2027. According to endoflife.date/nodejs: Node 18 stopped receiving security updates on 04-30-2025 and Node 20 on 04-30-2026; Node 22 maintains it until 04-30-2027 and Node 24 is still in active support until 10-20-2026.

Just because your Spanish hosting still offers PHP 7.4 in the panel doesn't mean it's secure. It means your provider doesn't want to break your website. Those are two different things.

Now, an old version does not automatically equate to a redesign. If the problem is only the version, update it; if the problem is that the theme and the eight paid plugins that support your website don't support the new version, then it is indeed a redesign. The correct question is not "what version do I have?" but "what is preventing me from upgrading?"

Threshold 5 · You fail accessibility and the EAA applies to you

Directive (EU) 2019/882, the European Accessibility Act, was transposed in Spain through Act 11/2023, of May 8, whose preamble sets June 28, 2025, as the date of effective application. It is no longer a future date: it has been in force for over a year.

Here the threshold is not statistical, it is legal: a single criterion of WCAG 2.1 level AA failed, if the standard applies to you, is a non-compliance. Insufficient contrast, forms without an associated label, video without subtitles, invisible keyboard focus.

The subjective scope of Act 11/2023—which companies and services it exactly obliges, and what exemptions exist—has nuances that should be checked on a case-by-case basis. Date of verification for this section: August 27, 2026. If your situation depends on an exemption, verify it before deciding anything.

The important thing for your decision: accessibility rarely justifies a redesign on its own. It can almost always be corrected on the existing website. Justify the redesign when the failure is at the base: when the entire color system fails to achieve contrast, when the template generates markup without a heading hierarchy, when the visual builder doesn't let you touch the HTML it emits.

[ ]

Threshold 6 · Annual maintenance exceeds one third of rebuilding it

This is the economic threshold, and it is calculated with a division.

Add up what you paid last year to maintain the website: theme and plugin licenses, hosting, hours for fixes, that emergency August invoice. Divide it by what it would cost to rebuild it properly. If the result exceeds 0.33, in three years you will have paid for a new website without having it.

A reasoned estimate, marked as such: at 60 €/hour—the usual rate for a Spanish studio of this size—maintenance of 4 hours per month is 2,880 € per year before VAT. Against a redesign of 12,000 €, the ratio is 0.24: hold on. Against one of 7,000 €, it is 0.41: cross the threshold. The numbers are illustrative of the method, not a rate.

[ ]

And remember to read quotes with the VAT in mind: the general rate applicable to design and web development services in Spain is 21% (VAT Act 37/1992, art. 90). A quote that does not explicitly say "plus VAT" is hiding 21% from you.

Threshold 7 · Changing a text takes more than five working days

Time the following: from the moment someone on your team asks to change a paragraph on the pricing page until that paragraph is published. Count working days.

Below one day, you have a system. Above five, you have a bottleneck shaped like a website, and that bottleneck has a cost that doesn't appear on any invoice: campaigns you don't launch, prices you don't update, the page that keeps advertising a service you no longer provide.

A website that can only be edited by the person who built it is not an asset: it is a dependency. That is why we deliver code, source files, and documentation, and perform a handover: so your team can continue without us.

[ ]

What we do differently when the threshold is crossed

The industry standard: The average Spanish studio rebuilds the entire website all at once, launches it on a Friday, and discovers on Monday that organic traffic has dropped by half because no one mapped the old URLs.

Our criteria: We measure first, map each URL to its destination with 301 redirects, and launch in phases, with the same seven thresholds measured at 30 and 90 days.

Google's official documentation on migrations with URL changes is explicit: use permanent 301 or 308 redirects, keep them "at least 1 year," chain a maximum of three hops, and allow for "a few weeks or more" for Google to start showing the new URLs on a site of average size (Google Search Central, accessed 08-27-2026).

That last figure is the one that prevents the most arguments. The drop in the first few weeks is expected; it is not a failure. What is not expected is that after three months you are still down.

A migration is judged at 90 days, not the Monday after the launch.

• You have the seven thresholds measured today, with a date, to be able to compare them later
• You distinguish field data (75th percentile, real users) from laboratory PageSpeed scores
• You have the complete inventory of current URLs exported and saved
• The quote explicitly says "plus VAT" and sets the price per phase before starting
• The contract names the code, source files, and design in the rights assignment
• You have access to the repository from the first day, not at delivery
• It is written what will be re-measured at 90 days and what happens if it is not reached

Frequently asked questions

Every how many years should you redesign a website?

There is no number of years: there are thresholds, and a well-built website can easily go past five without crossing any. If someone tells you that "it's time every three years" without having measured your LCP or your mobile conversion ratio, they are selling you a calendar, not a diagnosis.

Does redesigning the website make you lose positions on Google?

A redesign without a redirect map loses positions; a redesign with each old URL pointing with a 301 to its equivalent preserves the majority. Google indicates that fluctuations are normal and that on average sites it may take "a few weeks or more" to settle, so do not judge the result before 90 days.

Is the PageSpeed Insights score useful for deciding?

It is useful for knowing what to fix, not for deciding whether to redo. The decision is made with field data at the 75th percentile—LCP, INP, and CLS—because the laboratory score simulates a single load on a device that is probably not your users'.

I cross one threshold alone. Do I redesign?

Almost certainly not: an isolated threshold usually has a punctual fix that costs a fraction of the redesign, and we will tell you so even if it leaves us without a project. The pattern that does justify redoing is three or more crossed at once, because then the problem is the foundation and not the pieces.

How long does a phased redesign take?

Brand and website in 6-12 weeks, with a fixed price per phase agreed before starting and no surprise hours. It includes 30 days of support after launch and the delivery of code, source files, and documentation, so your team can continue without us.

A redesign is earned with figures

Redesigning by intuition costs the same as redesigning by necessity, and produces much less. Measure the seven thresholds this week, save the date, and decide with the table in front of you.

If you don't cross any, don't hire us: fix the concrete issue and come back in a year. If you cross three, tell us what you are facing in a 30-minute introductory call at no cost. Does this way of working fit you?

Keep reading

• Redesign your website without losing traffic or ranking: how it's done in phases and what to measure before and after
• What are Core Web Vitals, how much do they influence conversion, and when does it pay to optimize
• 47-point checklist before putting a website into production
• How to check if your website meets the EAA: self-test in 20 minutes
• Total cost of a website at 36 months: the number almost nobody gives you

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://web.dev/articles/vitals — official Core Web Vitals thresholds: LCP 2.5 s / 4 s, INP 200 ms / 500 ms, CLS 0.1 / 0.25, measured at the 75th percentile and segmented by mobile and desktop; INP became a stable metric in 2024 replacing FID
• https://developers.google.com/search/docs/appearance/page-experience — Google confirms that "Core Web Vitals are used by our ranking systems," that there is no single signal, and that relevance takes precedence over page experience
• https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes — official migration guide with URL changes: use 301/308, keep redirects "at least 1 year," chains of 3 hops or less (maximum 10), and "a few weeks or more" for Google to show new URLs on average-sized sites
• https://endoflife.date/php — PHP 8.1 and earlier end-of-life; 8.2 with security until 12-31-2026; 8.3 with security until 12-31-2027; 8.4 active support until 12-31-2026; 8.5 until 12-31-2027
• https://endoflife.date/nodejs — Node 18 without security since 04-30-2025; Node 20 without security since 04-30-2026; Node 22 with security until 04-30-2027; Node 24 in active support until 10-20-2026
• https://www.boe.es/buscar/doc.php?id=BOE-A-2023-11022 — Act 11/2023, of May 8, which transposes Directive (EU) 2019/882 (European Accessibility Act); its preamble sets June 28, 2025, as the effective application date