Orice agenție care vinde redesign are un număr: trei ani, sau doi, sau cinci. Niciunul nu vine din cercetare — vine din durata unui ciclu tipic de vânzare. Un site nu se degradează cu vârsta cum se degradează un acoperiș. Se degradează când lumea din jurul lui se mișcă, iar el stă pe loc, iar lucrurile care se mișcă o fac la date publicate și verificabile: o ramură PHP pierde suportul de securitate, o directivă de accesibilitate devine executorie, o metrică de ranking e înlocuită, o funcție de browser devine sigură de folosit. Asta face ca întrebarea „e momentul?” să aibă un răspuns, nu să fie o chestiune de gust. Dă click pe fiecare fază de mai jos pentru ce îmbătrânește cu adevărat, ce să măsori și jaloanele care marchează punctul în care reparația nu mai e varianta ieftină.
— Timeline
Când e momentul unui redesign de site și când chiar nu e.
Nimic dintr-un site nu expiră după trei ani. Anumite lucruri îmbătrânesc la date pe care le poți verifica — un runtime, o lege de accesibilitate, o metrică de ranking, un sistem de design — și fiecare are alt răspuns. Iată ce îmbătrânește și când, plus semnalele care chiar justifică o reconstrucție.
Ce îmbătrânește de fapt, an cu an
Anul 0 e ziua lansării — sau ziua ultimului tău redesign, oricare a venit mai târziu. Selectează o fază ca să vezi ce îmbătrânește în ea, ce să măsori și ce jaloane cad înăuntru.
Anii 0–1
Primul an: măsoară, nu umbla la el
Un site mai tânăr de un an aproape niciodată nu are nevoie de redesign, iar presiunea de a-l schimba vine de obicei din interiorul firmei, nu din date. Singura muncă rentabilă aici e instrumentarea: nu poți argumenta pentru sau împotriva unui redesign în anul trei fără o bază de comparație din primul an.
Ce îmbătrânește de fapt
- Încă nu a îmbătrânit nimic. Stiva e la zi, designul e cel pe care l-a aprobat toată lumea, iar conținutul e cel mai proaspăt din câte va fi vreodată.
- Ce se schimbă e propria ta părere despre el. Echipele se plictisesc de un design cu vreo optsprezece luni înainte ca vizitatorii să observe că există — familiaritatea nu e uzură morală.
- Apare traficul real și contrazice presupunerile: pagini pe care nu le-a anticipat nimeni devin cele mai vizitate, iar pagini pentru care echipa s-a certat săptămâni întregi nu iau aproape nimic.
- Ies la iveală greșeli mici de structură — un câmp de formular care pierde oameni, o etichetă de meniu pe care n-o înțelege nimeni. Astea sunt corecturi, nu redesign.
Ce să măsori
- Ia o bază de comparație în prima lună: Core Web Vitals din date de teren, rata de conversie pe fiecare tip de pagină, paginile de intrare din organic și procentul de trafic de pe mobil. Tot restul acestei cronologii se măsoară față de aceste patru cifre.
- Urmărește ce pagini câștigă efectiv trafic. Un redesign argumentat cu un inventar de pagini bate unul argumentat cu un moodboard.
- Notează fiecare „ar trebui să schimbăm asta” în loc să acționezi pe fiecare. Un an din lista aia e cel mai onest brief de redesign pe care îl vei avea.
Jaloane
- A0Bază de comparație la lansare — vitals, conversie, pagini de intrare, split pe dispozitive
- A1Primul an complet, analizat față de acea bază
Anii sunt o bandă realistă, nu o regulă — un site bine întreținut poate trece de anul șase fără nimic structural de făcut, iar unul prost gândit poate ajunge în teritoriu de reconstrucție în optsprezece luni. Elementele cu dată se pot verifica: ferestrele de suport PHP, trecerea la INP din 12 martie 2024, Actul European privind Accesibilitatea de pe 28 iunie 2025 și regula Baseline de 30 de luni vin toate din sursele de mai jos. Structura fazelor și pragurile sunt ale noastre, din proiecte cu clienți.
Semnalul, ce înseamnă de fapt și cât costă remedierea
| Ce vezi | Ce indică de obicei | Reparație sau reconstrucție |
|---|---|---|
| Traficul e plat, pozițiile sunt stabile | O problemă de conținut și de intenție. Paginile care există nu sunt paginile pe care le caută oamenii. | Reparație. E un proiect de conținut, iar un redesign nu schimbă rezultatul. |
| Conversia a scăzut și la tine nu s-a schimbat nimic | S-a mișcat ceva în exterior — oferta unui competitor, o pagină de campanie, un default de browser, o așteptare de preț. | Reparație la nivel de pagină. Un Redesign pentru conversie țintește tipurile de pagină care au pierdut, nu tot site-ul. |
| Orice modificare de conținut cere un programator | CMS-ul a fost modelat în jurul designului vechi, nu în jurul conținutului tău. Frecarea se adună zilnic. | Reparație dacă modelul se poate corecta, reconstrucție dacă platforma nu poate exprima ce vinzi. |
| Runtime-ul a trecut de data de sfârșit al suportului de securitate | Un fapt cu dată, verificabil — nu o opinie. E și cel mai ieftin element de pe listă de rezolvat. | Reparație. Un Upgrade de website rezolvă asta fără să atingă designul. |
| Nu trece de WCAG 2.1 AA și vinzi către consumatori din UE | Expunere legală de pe 28 iunie 2025, cu sancțiuni stabilite de fiecare stat membru. | Întâi reparație. Reconstrucție doar dacă structura markupului blochează conformitatea. |
| Peste 60% din trafic e mobil, pe un layout gândit pentru desktop | O nepotrivire structurală între design și public, nu o preferință de stil. | Reconstruiește șabloanele. Adaptarea ulterioară a unui grid desktop costă mai mult decât înlocuirea lui. |
| Fiecare pagină nouă cere un șablon nou, făcut special | Sistemul de design a fost mâncat de excepții — argumentul lui Nielsen despre coerență, în practică. | Reconstrucție. E singurul semnal din listă pe care o reparație chiar nu îl poate rezolva. |
Cinci din aceste șapte semnale se rezolvă prin reparație. Raportul ăsta e imaginea onestă și e motivul pentru care ofertăm un audit înaintea unui redesign, nu invers.
Regula celor trei ani e un ciclu de vânzare, nu o concluzie
Nu există niciun studiu în spatele ideii „redesign la doi-trei ani”. Nu există o durată de înjumătățire măsurată pentru un site, nu există un moment în care HTML-ul se degradează și nu există dovezi că un site de patru ani convertește mai prost decât unul de un an, dacă amândouă sunt întreținute. Există doar un număr repetat des, care se potrivește exact cu cât de des ar vrea o agenție să-ți vândă un proiect.
Înlocuirea utilă a regulii e o întrebare: ce anume s-a schimbat de când a fost construit site-ul ăsta și remedierea cere înlocuirea structurii? Aproape întotdeauna, răspunsul onest la a doua jumătate e nu. Conținutul e vechi, un tip de pagină performează slab, o dependență e depășită, o problemă de accesibilitate trebuie rezolvată — toate astea sunt lucrări de reparație, iar prețuirea lor ca redesign e cel mai comun mod în care firmele cheltuiesc prea mult pe site.
Patru ceasuri merg cu viteze diferite
Conținutul merge cel mai repede. Serviciile, prețurile, echipa, studiile de caz și argumentele de credibilitate ies din actualitate într-un an sau doi de la orice schimbare reală în firmă, iar nicio cantitate de rafinament vizual nu compensează o pagină care descrie o versiune a companiei care nu mai există.
Ceasul platformei merge pe date publicate. PHP dă fiecărei ramuri doi ani de suport activ și încă un an de corecturi de securitate, totul anunțat din timp — 8.2 nu mai primește corecturi de securitate după 31 decembrie 2026, iar toate ramurile de dinainte au trecut deja de acel punct. Framework-urile, versiunile de CMS și API-urile de plată funcționează la fel. Nimic nu e o surpriză, exact de aceea e evitabil să te prindă pe picior greșit.
Ceasul standardelor merge mai încet, dar e mai dur. Interaction to Next Paint a înlocuit First Input Delay ca Core Web Vital pe 12 martie 2024, cu un prag „bun” de 200 de milisecunde la percentila 75 — un site optimizat ca să treacă vechea metrică nu s-a schimbat, dar s-a schimbat criteriul după care era notat. Pe partea de browsere, o funcție e Baseline „larg disponibilă” abia la 30 de luni după ce o susțin toate browserele principale, deci un cod scris acum trei ani cară soluții de compromis care acum sunt greutate curată.
Ceasul legal are cele mai clare margini. Actul European privind Accesibilitatea e executoriu de pe 28 iunie 2025, se aplică prin EN 301 549, care e construit pe WCAG 2.1 AA, și îi vizează și pe cei din afara UE care vând către consumatori din UE. E singurul ceas la care „ne ocupăm la anul” are un preț stabilit de un regulator, nu de tine.
Upgrade-ul bate redesignul mai des decât recunoaște cine vinde redesign
Ia cele șapte semnale din tabelul de mai sus. Cinci se repară fără să atingi structura site-ului: un proiect de conținut, o corectură de conversie la nivel de șablon, un upgrade de runtime, o remediere de accesibilitate, o corecție a modelului de conținut. Doar două — un layout gândit pentru desktop sub trafic majoritar mobil și un sistem de design înlocuit de excepții — cer cu adevărat reconstrucție, pentru că în ambele cazuri ce e greșit e chiar structura.
Financiar contează, pentru că cele două trasee nu sunt nici pe departe la fel de scumpe. Un Upgrade de website mută site-ul pe o stivă suportată și repară ce e stricat, păstrând designul, URL-urile și istoricul de poziționare. Un Audit tehnic e pasul mai ieftin dinaintea oricăreia dintre decizii: livrează versiunile, vitals din teren și lipsurile de conformitate ca listă, ca discuția despre redesign să pornească de la fapte, nu de la cine e cel mai obosit de homepage în ședință.
Suntem un studio mic, deci nu avem o normă de redesign de îndeplinit. Să-i spui unui client că are nevoie de conținut de 800€, nu de o reconstrucție de cinci cifre, ne costă factura mai mare și ne câștigă relația, iar schimbul ăsta a meritat de fiecare dată.
Când reconstrucția chiar e răspunsul corect
Cel mai puternic argument pentru reconstrucție nu e vizual și nu a fost niciodată. Jakob Nielsen l-a formulat exact în 2009: schimbarea incrementală e în mod normal corectă, pentru că utilizatorilor nu le place perturbarea — dar „pe termen lung, incrementalismul distruge coerența și cere o nouă arhitectură de interfață”. Orice site cârpit cinci ani ajunge în punctul în care ce folosește efectiv un vizitator sunt cârpelile, nu designul.
Al doilea argument solid e structural: modelul de conținut nu mai poate exprima ce vinde firma. Adăugarea unei piețe, a unei limbi, a unui tip de produs sau a unei linii de servicii ar trebui să fie o intrare nouă, nu o soluție de compromis. Când e soluție de compromis de fiecare dată, problema e modelul de date, iar munca de design nu ajunge până acolo. Ghidul nostru de arhitectură multilingvă acoperă versiunea care doare cel mai tare.
Al treilea e măsurabil, nu arhitectural: costul schimbării crește. Dacă ultimele cinci cereri au durat vizibil mai mult decât aceleași cereri acum doi ani, linia aceea e argumentul de reconstrucție și e singurul care rezistă în fața unui director financiar.
Ce nu e un motiv bun: echipa s-a plictisit, un competitor a relansat sau designul „pare învechit” celor care se uită la el zilnic. Sunt sentimente reale și sunt brief-uri groaznice. Dacă o reconstrucție nu ar mișca niciuna dintre cele patru cifre pe care le-ai fixat ca bază în primul an, e o revopsire — un lucru absolut legitim de cumpărat, atâta timp cât e prețuit și justificat ca atare.
Reconstruiește fără să arunci ce funcționează deja
Un redesign care pierde poziții e o rană autoprovocată și e destul de frecvent cât să fie previzibil: URL-uri schimbate fără redirecturi, noindex-ul de pe staging ajuns în producție, linkuri interne care arată spre structura veche. Am scris toată secvența în redesign fără să pierzi SEO, iar pentru platforme mai mari ghidul de migrare a unui CMS enterprise acoperă mecanica trecerii.
Păstrează dovezile, înlocuiește structura. Inventarul de pagini, șabloanele care convertesc cel mai bine, paginile de intrare care aduc trafic organic și textele testate pe clienți reali sunt active — o reconstrucție ar trebui să le moștenească pe toate și să rescrie doar ce spun datele că nu merge.
Planifică fereastra de stabilizare în loc să te prefaci că nu există. Traficul real găsește lucruri pe care staging-ul nu le găsește niciodată, iar o reconstrucție nu se termină în ziua lansării — se termină când a trecut prima lună în liniște. Pentru asta e gândită Mentenanța lunară.
Cum decidem asta cu clienții
Începem cu un Audit tehnic, pentru că închide în câteva zile jumătatea disputabilă a întrebării: versiuni față de datele de sfârșit de viață, Core Web Vitals din teren inclusiv INP, lipsuri de conformitate WCAG 2.1 AA și un inventar de pagini cu trafic atașat. Cea mai mare parte din discuția „are nevoie de redesign?” se evaporă odată ce există aceste patru liste.
Dacă răspunsul e reparație, un Upgrade de website acoperă stiva și părțile stricate, iar un Redesign pentru conversie acoperă exact șabloanele care pierd bani — niciunul nu atinge URL-urile sau istoricul de poziționare.
Dacă răspunsul e reconstrucție, o spunem și o evaluăm față de baza din primul an, nu față de un moodboard. O reconstrucție care nu poate numi ce cifre trebuie să miște e o revopsire cu o factură mai mare, iar noi preferăm să pierdem proiectul decât să-l livrăm așa.
Surse
Fiecare afirmație cu dată de mai sus — calendare de suport, schimbări de metrici, termenul de accesibilitate și regula Baseline — vine din acestea, verificate în august 2026. Structura fazelor, pragurile și împărțirea reparație–reconstrucție sunt ale noastre, din proiecte cu clienți.
- PHP — Supported Versions ↗
Calendarul oficial de suport: fiecare ramură primește circa doi ani de suport activ plus încă un an de corecturi de securitate. PHP 8.2 (lansat pe 8 decembrie 2022) primește corecturi de securitate până pe 31 decembrie 2026; 8.3 până pe 31 decembrie 2027; 8.4 până pe 31 decembrie 2028. Tot ce e anterior versiunii 8.2 e deja ieșit din suport.
- web.dev — Interaction to Next Paint becomes a Core Web Vital on March 12 ↗
Anunțul Google că INP a înlocuit First Input Delay ca Core Web Vital pe 12 martie 2024 și că FID a fost scos din uz în aceeași tranziție.
- web.dev — Interaction to Next Paint (INP) ↗
Definește pragurile măsurate la percentila 75: bun la 200 de milisecunde sau sub, de îmbunătățit între 200 și 500 de milisecunde, slab peste 500 — și confirmă INP ca metrică succesoare a FID.
- EUR-Lex — Directive (EU) 2019/882 (European Accessibility Act) ↗
Directiva propriu-zisă. Statele membre îi aplică măsurile de pe 28 iunie 2025, acoperind comerțul electronic, serviciile bancare, transportul și serviciile digitale pentru consumatori — inclusiv firme din afara UE care vând către consumatori din UE.
- web.dev — Baseline ↗
Definește „newly available” (susținută de toate browserele principale) și „widely available” (la 30 de luni după acea dată). Diferența de 30 de luni e motivul pentru care un cod de trei ani cară de obicei soluții de compromis de care nu mai are nevoie.
- Nielsen Norman Group — Fresh vs. Familiar: How Aggressively to Redesign ↗
Jakob Nielsen, septembrie 2009. Argumentează schimbarea incrementală ca opțiune implicită, cu excepția pe care se sprijină ghidul de față: „pe termen lung, incrementalismul distruge coerența și cere o nouă arhitectură de interfață”.
- HTTP Archive — Web Almanac 2025, CMS chapter ↗
Rate de trecere a Core Web Vitals pe platforme, din webul real — utile ca reper extern când judeci dacă datele tale de teren arată o problemă de site sau una de platformă.
— FAQ
Întrebări frecvente
Nu ești sigur dacă site-ul are nevoie de reconstrucție sau doar de o listă de reparații?
Trimite-ne adresa și ce te deranjează la el, iar noi îți spunem care dintre cele două e de fapt — inclusiv când răspunsul e „lasă-l în pace”.