O migrare de site se face fără promisiunea falsă că traficul nu va mișca deloc, dar cu un proces care reduce riscul: inventar de URL-uri, hartă de redirecționări, verificări tehnice înainte de lansare și monitorizare după. Pierderile apar când se schimbă structura fără să fie păstrate semnalele vechi.

Când preluăm un proiect de migrare, întrebarea vine aproape mereu la fel: „Putem schimba site-ul fără să pierdem traficul organic?” Răspunsul corect nu este „da”. Răspunsul corect este: putem reduce riscul dacă știm exact ce se schimbă, ce trebuie păstrat și ce trebuie testat înainte ca site-ul nou să fie public.

O migrare nu înseamnă doar mutarea unor fișiere. Poate însemna schimbare de domeniu, trecere de la HTTP la HTTPS, schimbare de platformă, refacere de structură, schimbare de hosting, redesign sau comasarea mai multor site-uri. Pentru Google, problema nu este că site-ul arată diferit. Problema apare când URL-urile, conținutul, linkurile interne, canonicalele și semnalele externe nu mai indică același lucru.

Ce se întâmplă în Google când schimbi site-ul

Google trebuie să recrawleze site-ul, să înțeleagă noile adrese și să le asocieze cu vechile pagini. Dacă pagina veche avea trafic, linkuri și istoric, migrarea trebuie să arate clar unde s-a mutat echivalentul ei. Fără această legătură, noua pagină este tratată ca o adresă diferită, nu ca o continuare firească.

Documentația Google Search Central despre mutările de site cu schimbări de URL recomandă verificarea proprietăților vechi și noi în Search Console, maparea URL-urilor vechi către cele noi, folosirea redirecționărilor permanente când este posibil și monitorizarea traficului după lansare. Aceeași sursă spune că redirecționările ar trebui păstrate cât mai mult, în general cel puțin 1 an, iar un site mic sau mediu poate avea nevoie de câteva săptămâni pentru ca majoritatea paginilor mutate să fie procesate.

Aceste intervale nu sunt o promisiune de recuperare a traficului. Sunt un indiciu despre ritmul în care Google poate procesa mutarea. Pozițiile se pot schimba temporar, iar uneori scăderea nu vine din migrare, ci din faptul că site-ul nou a schimbat intenția paginilor: o categorie care răspundea bine la o căutare devine o pagină vizuală, cu text puțin și filtre blocate.

Inventarul vechiului site se face înainte de design

Inventarul URL-urilor vechi este prima piesă care decide calitatea migrării. Nu începi cu tema, culorile sau meniul. Începi cu lista paginilor care există, primesc trafic, au impresii în Search Console, au backlinkuri sau sunt legate intern din zone vizibile ale site-ului.

În audituri vedem des aceeași greșeală: site-ul nou se construiește doar după meniul vizibil. Se pierd articole vechi, pagini de servicii secundare, categorii de produs, URL-uri de brand sau pagini locale care nu erau în meniu, dar aduceau trafic. Proprietarul vede doar homepage-ul și câteva servicii. Search Console vede mult mai multe.

Pentru inventar, verificăm în aceeași listă:

• URL-urile din sitemapul vechi;
• paginile cu clicuri și impresii în raportul Performanță din Search Console;
• paginile indexate și excluse din raportul Indexare pagini;
• URL-urile care primesc linkuri interne și externe;
• paginile care aduc conversii în Analytics, chiar dacă nu au trafic mare;
• URL-urile găsite prin crawl, inclusiv pagini orfane sau pagini vechi încă accesibile.

Scorul dintr-un tool de crawl nu este semnal Google. Este o listă de verificări. Dacă un crawler îți arată multe erori, nu le tratezi pe toate la fel. O redirecționare lipsă pentru o pagină cu trafic valorează mai mult decât zeci de atenționări minore pe pagini fără vizibilitate.

Harta de redirecționări este documentul pe care nu îl poți repara din memorie

Harta de redirecționări leagă fiecare URL vechi relevant de destinația corectă din site-ul nou. Nu este o formalitate pentru dezvoltator. Este documentul care îi spune lui Google că pagina veche nu a dispărut, ci are o adresă nouă.

Redirecționarea către homepage este o soluție slabă când pagina veche avea un corespondent clar. Dacă un service auto avea o pagină pentru „schimb distribuție”, iar site-ul nou are același serviciu, URL-ul vechi trebuie să ajungă acolo, nu în prima pagină. Dacă nu mai vinzi serviciul, decizia este diferită: redirecționezi spre cea mai apropiată pagină relevantă sau accepți că pagina trebuie să dispară și să returneze o stare corectă.

Google explică în documentația despre redirecționări și Google Search diferența dintre redirecționările permanente și cele temporare: redirecționările permanente, cum sunt 301 și 308, indică faptul că noua adresă ar trebui tratată ca destinație canonică, în timp ce redirecționările temporare păstrează mai mult semnalul pe URL-ul sursă.

Nu aș lansa o migrare fără un fișier cu trei coloane: URL vechi, URL nou, observație. Observația contează când nu există echivalent direct: „serviciu eliminat”, „categorie comasată”, „produs indisponibil”, „articol rescris”. Fără această coloană, deciziile dificile se iau în ziua lansării, când presiunea este mare și verificarea este slabă.

Ce trebuie testat pe site-ul nou înainte să devină public

Site-ul nou trebuie testat într-un mediu de staging, blocat de la indexare, dar accesibil echipei care verifică. Testarea bună nu se oprește la „se încarcă pagina”. Trebuie verificate indexarea, template-urile, conținutul, linkurile interne, canonicalele, formularele, trackingul și redirecționările.

În proiectele WordPress, o schimbare de temă poate rupe mai multe lucruri fără să se vadă în design: titluri H1 generate greșit, breadcrumbs lipsă, schema eliminată, meta descrieri suprascrise, pagini de categorie fără text, filtre care creează URL-uri indexabile. De aceea, când migrarea include platformă sau temă, o tratăm ca proiect de mentenanță WordPress și SEO tehnic, nu ca simplă lansare vizuală.

Înainte de lansare, verificarea minimă include:

• starea fișierului robots.txt și eliminarea blocărilor accidentale;
• prezența sau absența corectă a tagurilor noindex;
• canonicale către URL-urile noi, nu către vechiul domeniu;
• linkuri interne actualizate către adresele noi;
• sitemap nou, curat, fără URL-uri redirecționate sau neindexabile;
• tracking Analytics și verificare Search Console păstrate sau refăcute;
• pagini de conversie testate: formulare, checkout, butoane de apel, cereri de ofertă;
• pagini locale, categorii și servicii păstrate în structură, dacă aduceau trafic.

Nu există confirmare oficială că fiecare element de mai sus este factor de ranking separat. Unele țin de crawling, altele de înțelegerea paginii, altele de măsurare. Le verifici împreună pentru că migrarea e un lanț: dacă măsurarea lipsește, nu știi ce s-a întâmplat; dacă redirecționarea lipsește, semnalul se întrerupe; dacă pagina nouă răspunde mai slab la intenție, traficul poate scădea chiar cu redirecționări corecte.

Ordinea lansării contează mai mult decât ora lansării

Lansarea unei migrări trebuie făcută într-o ordine controlată. Ora contează doar ca să ai echipa disponibilă pentru verificări. Dacă alegi o oră cu trafic mic, dar lansezi fără checklist, nu ai redus riscul. Ai mutat riscul într-un moment mai comod.

1. Se face backup complet pentru site, bază de date și reguli de redirecționare.
2. Se publică site-ul nou și se elimină blocările de crawling sau indexare folosite în staging.
3. Se activează redirecționările vechi-nou, testate pe eșantion și apoi în masă.
4. Se verifică homepage-ul, paginile cu trafic, paginile de conversie și sitemapul.
5. Se trimite sitemapul nou în Search Console.
6. Se verifică proprietățile relevante din Search Console, inclusiv variantele de domeniu când se schimbă domeniul.
7. Se testează în Analytics dacă traficul și conversiile sunt înregistrate.
8. Se rulează un crawl post-lansare pentru erori 404, lanțuri de redirecționări și canonicale greșite.

La schimbare de domeniu, instrumentul Change of Address din Search Console intră în discuție. La migrarea de la HTTP la HTTPS, Google Search Central precizează că nu se folosește acest instrument, chiar dacă se aplică regulile pentru mutări cu schimbări de URL.

Migrarea de hosting nu este aceeași problemă ca migrarea de URL-uri

O schimbare de hosting fără modificări vizibile de URL are alt risc. În acest caz, Google trebuie să ajungă la același conținut prin aceleași adrese, dar servit din infrastructură nouă. Problema principală nu este maparea URL-urilor, ci accesibilitatea, viteza, DNS-ul și capacitatea serverului.

Google Search Central are un ghid separat pentru schimbarea infrastructurii de hosting fără modificări de URL, unde recomandă copierea și testarea site-ului pe noua infrastructură, verificarea accesului Googlebot, actualizarea DNS și monitorizarea traficului pe vechiul și noul server.

Aici vedem alt tip de problemă: firewall-ul sau protecția anti-bot blochează Googlebot, serverul nou răspunde lent sub crawl, imaginile nu sunt servite corect sau mediul nou nu include fișierele de verificare Search Console. Pentru utilizator, site-ul pare funcțional. Pentru Google, accesul poate fi inconsistent.

Monitorizarea după lansare nu înseamnă să te uiți doar la trafic

După migrare, verifici separat crawlul, indexarea, pozițiile, traficul și conversiile. O singură linie din Analytics nu îți spune cauza. Traficul poate scădea din cauza indexării, a redirecționărilor, a schimbării conținutului, a pierderii unor pagini sau a unei probleme de tracking.

În primele verificări ne uităm la:

• raportul Indexare pagini din Search Console, pentru creșteri de 404, soft 404, pagini excluse sau redirecționate;
• raportul Performanță, comparând query-urile și paginile vechi cu cele noi;
• sitemapul trimis, pentru URL-uri care nu ar trebui să fie acolo;
• logurile serverului, dacă sunt disponibile, pentru accesul crawlerelor;
• Analytics, pentru diferența dintre trafic organic și conversii;
• paginile cu backlinkuri, ca să vedem dacă destinațiile lor sunt încă relevante.

Lucrăm în SEO din 2007 și am văzut migrații care păreau reușite în primele zile, apoi au început să piardă trafic pe categorii. Cauza nu era redirecționarea, ci template-ul nou: toate categoriile de magazin online aveau aceleași texte scurte, fără explicații, iar filtrele importante fuseseră ascunse. Redirecționarea ducea unde trebuie, dar pagina nouă era mai slabă decât pagina veche.

Ce rămâne în sarcina ta, chiar dacă lucrezi cu o echipă SEO

O echipă SEO poate face auditul, harta de redirecționări, verificările tehnice și monitorizarea. Nu poate decide în locul tău ce servicii rămân în ofertă, ce produse dispar, ce orașe deservești sau ce informații comerciale sunt corecte.

Înainte de migrare, ai nevoie să confirmi câteva lucruri: care servicii se păstrează, ce categorii nu mai au sens, ce pagini trebuie rescrise, ce produse nu mai revin în stoc, ce formular contează pentru vânzări și cine aprobă textele tehnice. Un cabinet medical, o firmă de construcții sau un magazin online au informații pe care nu le poate inventa nimeni din afară fără risc.

Mai ai o responsabilitate de proces: să anunți înainte când dezvoltatorul schimbă tema, pluginurile, structura URL-urilor sau platforma. Cea mai scumpă frază într-o migrare este „am lansat aseară, poți verifica?”. Se poate verifica, dar nu se mai poate preveni.

Când migrarea nu este momentul potrivit pentru schimbări mari

O migrare devine riscantă când încerci să schimbi totul simultan: domeniu nou, platformă nouă, structură nouă, texte noi, meniuri noi și strategie nouă de categorii. Unele schimbări sunt necesare, dar fiecare modificare adaugă o cauză posibilă dacă traficul scade.

Abordarea slabă este să folosești migrarea ca pretext pentru a șterge istoricul site-ului. Abordarea mai bună este să păstrezi ce funcționează, să schimbi ce are motiv clar și să notezi fiecare decizie. Dacă pagina veche aduce trafic potrivit, nu o elimini doar pentru că nu se potrivește în noul meniu. Îi găsești un loc în structură sau îi construiești un echivalent mai bun.

Dacă site-ul nu are conținut suficient și nici buget pentru conținut, optimizare SEO tehnică nu rezolvă singură problema. Poți migra corect un site slab și tot să nu câștigi vizibilitate. Migrarea păstrează sau reorganizează semnale. Nu creează automat autoritate, cerere sau conținut util.

Întrebări frecvente

Se poate face migrarea fără nicio scădere de trafic?

Nu se poate garanta o migrare fără nicio scădere. Poți reduce riscul prin mapare, redirecționări, testare și monitorizare, dar Google recrawl-ează și reevaluează paginile. Dacă paginile noi sunt mai slabe sau structura se schimbă mult, fluctuațiile sunt posibile.

Când ar trebui implicată echipa SEO în proiect?

Echipa SEO trebuie implicată înainte de aprobarea structurii site-ului nou. Dacă intră doar înainte de lansare, multe decizii sunt deja greu de schimbat: URL-uri, template-uri, meniuri, pagini eliminate și conținut comasat fără criteriu.

Ce se întâmplă dacă am lansat deja și traficul a scăzut?

Prima verificare este tehnică: redirecționări, 404, canonicale, noindex, robots.txt, sitemap și tracking. După aceea compari paginile vechi cu cele noi. Dacă redirecționările sunt corecte, cauza poate fi conținutul, intenția de căutare sau o schimbare de structură.

O migrare bună nu începe în ziua lansării. Începe când încă poți schimba structura fără cost mare. Dacă ai lista URL-urilor vechi, harta de redirecționări, staging testat și acces la Search Console, lansezi cu control. Dacă le reconstruiești după ce traficul a scăzut, nu mai faci migrare. Faci recuperare.