Migrarea de pe un CMS enterprise vechi fără să pierzi SEO-ul sau uptime-ul.

Nimeni nu înlocuiește un CMS vechi de cincisprezece ani pentru că tehnologia e interesantă. Îl înlocuiește pentru că orice funcție nouă durează acum luni întregi, dezvoltatorii care înțelegeau arhitectura originală au plecat de mult, iar furnizorul a încetat discret să mai susțină versiunea pe care rulează. Ce diferă la această migrare față de o refacere obișnuită de website e scara și raza de impact: domeniul poartă o autoritate de căutare acumulată timp de un deceniu și jumătate, zeci de sisteme interne citesc din el sau scriu în el, iar o singură regulă de redirect ratată sau un tag robots.txt de pe staging care ajunge din greșeală în producție poate șterge ani de poziționare în câteva zile. Niciunul dintre astea nu e un motiv să nu migrezi. E un motiv să tratezi migrarea în sine ca livrabilul principal, nu ca pe o anexă adăugată la o redesign.

Trei moduri de a face trecerea, comparate

Niciuna dintre astea nu e alegerea „corectă” în abstract — decizia ține de cât de mult tolerează organizația o perioadă lungă de tranziție față de cât tolerează o singură zi de trecere cu miză mare, nu de ce preferă Google.

De ce harta redirecturilor e toată migrarea

Fiecare URL pe care CMS-ul vechi l-a avut vreodată indexat are nevoie de un redirect explicit, individual, către cel mai apropiat echivalent din sistemul nou — nu de o regulă generală care trimite totul spre pagina principală. Recomandarea proprie Google despre mutarea site-urilor e directă în privința asta: un redirect către o destinație nelegată sau prea generală e tratat ca un soft 404, iar pagina pierde orice istoric de poziționare pe care îl câștigase. Pe un sistem atât de vechi, harta de redirect rareori e o treabă curată de 1 la 1 — paginile s-au unit, s-au eliminat sau s-au restructurat de-a lungul a cincisprezece ani, iar fiecare dintre astea are nevoie de o decizie deliberată, nu de o presupunere automată.

Lanțurile de redirecturi sunt al doilea eșec ca frecvență, și sunt aproape mereu auto-provocate: o pagină redirecționată în urmă cu trei ani, în timpul unui rebranding, apoi redirecționată din nou anul trecut, la o actualizare de platformă, primește acum un al treilea redirect la această migrare — trei sărituri înainte ca un vizitator sau un crawler să ajungă la pagina reală. Google urmărește lanțurile, dar fiecare săritură adaugă latență și risc, iar o buclă oriunde în lanțul respectiv (o greșeală de copy-paste reală, nu rară) pur și simplu strică pagina. Reparația e mecanică, dar obligatorie: rezolvă fiecare redirect către destinația lui finală înainte de migrare, nu prin lanțul vechi.

Dezastrul de pe staging: cum un singur tag noindex îți dărâmă lansarea

Cel mai frecvent mod în care o migrare bine planificată tot mai merge prost n-are nicio legătură cu conținutul sau redirecturile. Un mediu de staging sau development are aproape mereu un `Disallow: /` general în robots.txt, sau un tag noindex pe tot site-ul, special ca motoarele de căutare să nu indexeze vreodată copia neterminată. Când exact acel cod ajunge în producție în ziua trecerii — pentru că pipeline-ul de deploy copiază și configurația de staging odată cu restul — blocajul devine live odată cu el. Google poate acționa pe un semnal nou de noindex în câteva zile, iar până observă cineva că traficul organic a căzut brusc, o parte semnificativă din site e deja scoasă din index.

Măsura de siguranță e plictisitoare, și exact de-asta funcționează: checklist-ul de deploy în producție are nevoie de un pas explicit, separat, care verifică robots.txt și tagurile meta robots pe domeniul live, după lansare, înainte ca cineva să declare migrarea încheiată — nu de un pas care presupune că pipeline-ul de deploy s-a ocupat corect de asta. Tratează-l la fel cum un pilot tratează checklist-ul dinainte de zbor: nu pentru că avionul are de obicei o problemă, ci pentru că, în singura dată când o are, prinderea ei la sol nu costă nimic, iar prinderea ei în aer costă totul.

Trecerea fără downtime, în practică

Abordările Strangler Fig și blue-green din tabelul de mai sus sunt cum evită de fapt migrările mari downtime-ul, și ambele se bazează pe același truc: sistemul vechi și cel nou rulează simultan, iar traficul se mută între ele fără ca vreun vizitator să vadă vreodată o pagină de mentenanță. O trecere blue-green ține sistemul nou complet live, în umbră, îl verifică pe tipare reale de trafic, apoi comută o setare DNS sau de load balancer odată ce încrederea e suficient de mare — cu sistemul vechi lăsat să ruleze, accesibil instant dacă e nevoie de un rollback. Strangler Fig face același lucru la o granulație mai mică: secțiuni sau subdomenii individuale trec pe rând, în spatele unui reverse proxy care rutează fiecare cerere către oricare sistem deține momentan calea respectivă.

Detaliul care scapă cel mai des e TTL-ul DNS — durata de cache pe înregistrările DNS ale domeniului trebuie scăzută cu zile înainte de trecere, nu chiar în ziua respectivă, pentru că un TTL rămas la 24 de ore înseamnă că o parte din vizitatori tot ajung pe sistemul vechi încă o zi întreagă după schimbare, indiferent cât de curată a fost trecerea în sine. E o schimbare de cinci minute, făcută cu o săptămână devreme, iar sărirea ei e unul dintre motivele frecvente pentru care o migrare reușită tehnic tot are o zi de lansare grea.

Ce chiar va fluctua, și pentru cât timp

O anumită mișcare în clasamente în timpul și imediat după o migrare e normală și așteptată — documentația proprie Google despre mutarea site-urilor spune asta direct: sistemul are nevoie să recraweleze și să reevalueze URL-urile noi, iar asta durează chiar și atunci când fiecare redirect e corect. Google pune și o cifră orientativă: ca regulă generală, un site mic sau mediu are nevoie de câteva săptămâni ca majoritatea paginilor să se mute, iar site-urile mari durează mai mult. Un CMS enterprise de cincisprezece ani, cu sute de mii de URL-uri indexate, intră clar în a doua categorie, deci așteptarea se stabilește în luni de așezare treptată, nu în săptămâni. Ce nu ar trebui să se întâmple e un platou — o migrare care a încetat să-și mai revină, nu una care încă își revine încet, are aproape mereu în spate unul dintre cele două eșecuri de mai sus, nu o penalizare algoritmică misterioasă.

Merită stabilită așteptarea asta cu stakeholderii înainte de migrare, nu după: o scădere temporară în primele două-trei săptămâni nu e dovadă că ceva a mers prost, iar reacția la cifrele din a treia zi, prin repunerea la îndoială a strategiei de redirect, de obicei face mai multă pagubă decât scăderea în sine.

Decide ce nu se mută, înainte să mapezi ce se mută

Cincisprezece ani de publicat lasă un site cu o coadă lungă de pagini la care nu s-a mai uitat nimeni de ani buni: linii de produs scoase din ofertă, pagini de evenimente pentru conferințe care nu se mai țin, trei versiuni ale aceluiași document de politică, comunicate de presă de la o achiziție cu doi proprietari în urmă. Migrarea acelei cozi în bloc e felul în care o schimbare de platformă se dublează ca preț — fiecare dintre paginile alea are nevoie de un template, de o revizuire de conținut și de o regulă de redirect, iar majoritatea nu vor mai fi citite niciodată. Fă inventarul întâi: fiecare URL indexat, pus lângă ultimele douăsprezece luni de trafic organic, conversii și linkuri interne, împărțit în păstrează, unifică și retrage, înainte să fie scris vreun redirect.

Retragerea unei pagini e o decizie, nu o omisiune, iar cele două opțiuni se comportă diferit. O pagină cu autoritate acumulată reală sau cu linkuri primite ar trebui unificată cu cel mai apropiat echivalent viu și redirectată acolo — niciodată spre homepage, pe care Google îl tratează ca soft 404 și care aruncă exact istoricul pe care încercai să-l păstrezi. O pagină fără trafic, fără linkuri și fără succesor e mai bine returnată ca un 410 Gone curat decât redirectată undeva aproximativ, pentru că un redirect aproximativ e un soft 404 cu încetinitorul și poluează harta de redirecturi pe care se bazează restul migrării ca să fie de încredere.

Ce urmărești în primele 72 de ore, și în anul de după

Verificările din ziua lansării sunt puține și obligatorii: robots.txt și meta robots pe domeniul live, un crawl pe un eșantion din harta de redirecturi care confirmă 301-uri într-un singur pas către pagini 200 vii, sitemap-ul XML nou trimis, și logurile de server care confirmă că Googlebot primește URL-urile noi, nu erori. Search Console dă cea mai clară imagine în săptămânile următoare — raportul Sitemaps ar trebui să arate numărul de pagini indexate scăzând pe setul vechi de URL-uri și crescând pe cel nou, iar raportul de performanță ar trebui să arate afișările transferându-se, nu dispărând. Dacă una dintre cele două curbe se mișcă și cealaltă nu, ăsta e semnalul să te oprești și să depanezi.

Două detalii sunt greșite frecvent la margini. Instrumentul Change of Address se aplică mutărilor între domenii — dacă URL-urile se schimbă pe același domeniu, nu el e mecanismul, iar așteptarea ca el să „proceseze” e așteptare degeaba. Iar redirecturile nu sunt o schelă temporară: recomandarea Google e să le păstrezi cât de mult posibil, în general cel puțin un an, ca semnalele să se transfere complet. Ștergerea stratului de redirecturi la următoarea curățenie de infrastructură, la opt luni după o migrare reușită, e un mod chiar frecvent de a pierde pozițiile pe care migrarea le salvase deja.

Cum abordăm asta în practică

O migrare de dimensiunea asta pornește cu un Audit tehnic al sistemului existent — fiecare URL indexat, fiecare integrare care citește din CMS, fiecare comportament nedocumentat pe care altfel cineva îl descoperă pe calea grea, în mijlocul migrării. Auditul respectiv devine harta reală de redirect și planul de trecere, nu un checklist generic.

Reconstrucția în sine e de obicei încadrată ca un Website Upgrade sau, acolo unde brandul și arhitectura informației se schimbă odată cu platforma, un Redesign pentru conversie complet. Oricum ar fi, Mentenanță lunară în săptămânile imediat după trecere e unde chiar se întâmplă verificarea robots.txt, monitorizarea redirecturilor și urmărirea fluctuației de clasament de mai sus — nu e un proiect de tipul „îl lansezi și pleci”.

Surse

Recomandările despre redirecturi, robots.txt și fluctuația clasamentelor de mai sus vin din acestea, verificate în august 2026.

• Google Search Central — Site moves with URL changes ↗

  Un redirect către o pagină nelegată sau prea generală (de exemplu pagina principală) e tratat ca soft 404 și pierde istoricul de poziționare; o anumită fluctuație temporară de clasament în timpul unei mutări e așteptată cât timp Google recrawlează și reevaluează URL-urile noi. Tot aici: „un site mic sau mediu poate avea nevoie de câteva săptămâni ca majoritatea paginilor să se mute, iar site-urile mari durează mai mult”; păstrarea redirecturilor „cât de mult posibil, în general cel puțin 1 an”; instrumentul Change of Address se aplică mutărilor de la un domeniu la altul; iar rapoartele Sitemaps, Index Coverage și performanță sunt modul recomandat de a monitoriza o mutare.

• Google Search Central — 301 redirects and Google Search ↗

  Recomandări despre lanțuri și bucle de redirect, și despre rezolvarea unui redirect către destinația lui finală, nu lăsarea mai multor sărituri în loc.

• Google Search Central — Introduction to robots.txt ↗

  Cum controlează o regulă Disallow sau o directivă noindex crawling-ul și indexarea — mecanismul din spatele unui blocaj de pe staging care ajunge din greșeală în producție.

• McKinsey Digital — Tech debt: Reclaiming tech equity ↗

  Directorii chestionați estimează datoria tehnică la aproximativ 20-40% din valoarea întregului patrimoniu tehnologic, înainte de depreciere — presiunea de cost din spate, care face ca înlocuirea unui sistem vechi să devină, la un moment dat, inevitabilă.