Cum muți un business pe alt domeniu fără să-l pierzi

Un domeniu nou poate marca un rebrand, o fuziune sau intrarea pe altă piață. Pentru client, schimbarea pare simplă. Pentru Google, pentru platformele de publicitate și pentru instrumentele de măsurare, fiecare URL, semnal și integrare trebuie mutat sau reconectat corect.

Articolul ăsta nu e al optulea ghid general de migrare. Este cronologia unei migrări pe care am făcut-o pe propriul business — cu cifrele ei, cu data ei și cu ce anume nu i se poate atribui — plus procedura care a produs acele cifre.

Răspunsul scurt: nu poți garanta că pozițiile nu vor fluctua temporar — Google spune explicit că fluctuațiile în timpul unei mutări sunt normale. Poți însă preveni majoritatea pierderilor evitabile prin inventar complet, mapare 1:1, redirecturi 301, testare înainte de lansare și monitorizare după lansare.

Cazul Grindout: ce s-a mutat, când și ce a rezultat

Cutover: 26 mai 2026. Business mutat: kboosting.com → grindout.com. Toate cifrele de mai jos sunt publicate, cu grafic, în studiul de caz Grindout, extrase din Google Search Console pe 12 iulie 2026.

Ipoteza: ce anume era în joc

Un business online de 7 ani, cu peste 1.000 de comenzi pe lună și 150.000–200.000 de vizitatori organici lunar, din care circa 80% din venit venea din Google organic, nu din reclame. Asta făcea mutarea periculoasă: aproape tot businessul stătea pe pozițiile din Google ale domeniului vechi. Ipoteza de lucru a fost că traficul se poate muta fără să se piardă, dacă fiecare semnal are o destinație explicită înainte de ziua mutării.

Ce s-a schimbat, în ordine

1. inventarul complet — fiecare pagină, fiecare poziție, fiecare sursă de trafic, documentate înainte de mutare;
2. maparea 1-la-1 — fiecare adresă veche redirecționată către echivalentul exact de pe domeniul nou, fără pagini lăsate în urmă;
3. anunțarea mutării către Google prin canalele oficiale, cu site-ul nou verificat și pregătit dinainte;
4. monitorizare zilnică, timp de 3 săptămâni, pe poziții, trafic și erori, cu plan de reacție pregătit.

Ce a rezultat, și în cât timp

Ce nu poate fi atribuit migrării

Cifrele de mai sus descriu un singur site, o singură piață și o singură perioadă. Trei lucruri din fereastra de măsurare nu au legătură cu mutarea: sezonalitatea industriei (graficul are un vârf de trafic în 19–25 mai, chiar înainte de cutover, dintr-un sezon de lansare), schimbările de algoritm care se suprapun peste aceeași fereastră, și stingerea treptată a notorietății numelui vechi, care nu se oprește la data mutării.

Ce arată cazul nu e o promisiune de curbă. Arată ce se poate obține când migrarea e tratată ca operațiune de business, nu ca task de IT — și de aici încolo articolul descrie exact procedura care a produs cifrele.

Ce muți, de fapt, și ce poți pierde

Patru proiecte diferite, toate numite „migrare”

Cu cât schimbi mai multe simultan, cu atât devine mai greu să identifici cauza unei scăderi. Documentația Google pentru mutări de site recomandă direct: schimbă câte un lucru pe rând — întâi domeniul, apoi layoutul, nu amândouă în aceeași lansare.

Dacă rebrandul cere totuși domeniu, CMS, design și structură noi deodată — cazul clasic e mutarea pe altă platformă de magazin online, cu altă structură de URL — tratează proiectul ca schimbare cu risc ridicat și păstrează cât mai stabile conținutul, intenția paginilor și structura care funcționează deja.

Ce poate pierde businessul

O migrare incompletă atinge deopotrivă activele pe care SEO le construiește în ani și infrastructura pe care merge businessul zilnic:

• pozițiile și clickurile organice;
• traficul de brand către numele vechi;
• autoritatea transmisă de linkurile externe;
• campaniile care trimit spre URL-uri vechi;
• trackingul conversiilor și atribuirea;
• formularele, checkoutul, plățile și conturile;
• emailul pe domeniu și autentificarea mesajelor;
• profilurile locale, directoarele și materialele partenerilor.

Lista explică de ce proiectul are nevoie de un singur owner pe rezultat, chiar dacă execuția implică SEO, development, marketing, analytics și IT. În cazul de mai sus, ownerul a fost cel care putea autoriza o reparație în aceeași zi, nu cel care raporta săptămânal.

Condițiile fără de care nu lansezi

Amână migrarea dacă nu poți bifa toate condițiile de mai jos:

1. Ai acces la vechiul domeniu, hosting, DNS, Search Console, analytics și platformele de publicitate.
2. Poți păstra domeniul vechi activ pentru redirecturi.
3. Ai un backup și o procedură de revenire.
4. Noul site poate fi testat și crawlat integral înainte de lansare.
5. Există o mapare pentru fiecare URL important.
6. Există un owner care poate urmări problemele și poate autoriza remedierea imediat după lansare.
7. Perioada aleasă nu coincide cu vârful comercial pe care nu îți permiți să îl riști.

Dacă răspunsul e „nu” la acces, la redirecturi sau la monitorizare, lansarea nu e pregătită. O dată anunțată intern nu transformă un plan incomplet într-un plan sigur.

Faza 1: inventarul și reperul de business

Înainte să construiești maparea, salvează imaginea completă a site-ului vechi. E singura fază la care nu poți reveni după lansare: ce n-ai măsurat înainte nu se mai poate reconstrui după.

Inventarul URL-urilor

Nu folosi o singură sursă. Combină:

• crawlul complet al site-ului;
• sitemapurile;
• paginile cu clickuri și impresii din Search Console;
• landing page-urile din analytics;
• URL-urile cu backlinkuri;
• URL-urile din campanii și feeduri;
• paginile indexate care nu mai apar în navigație;
• fișiere importante, imagini și documente descărcabile.

Google recomandă explicit includerea conținutului încorporat — imagini, video, fișiere JavaScript și CSS — în planul de mutare, nu doar a paginilor HTML. Un URL absent din navigație poate avea trafic, linkuri sau conversii; dacă nu apare în inventar, dispare fără ca echipa să observe la testarea vizuală.

Reperul de performanță

Salvează înainte de lansare:

• clickuri, impresii și interogări pe landing page;
• pozițiile pentru grupurile comerciale importante;
• sesiuni și conversii pe canal și pagină;
• venit, leaduri și rata de conversie;
• erori de indexare și pagini excluse;
• backlinkurile către paginile prioritare;
• viteza și disponibilitatea paginilor-cheie;
• performanța campaniilor și conversiile raportate.

Comparația utilă se face pe pagini și grupuri de intenție, nu pe totalul site-ului. Un total stabil poate ascunde pierderea exactă a paginilor care produc venit — și fără reper, discuția de după lansare devine o chestiune de impresii.

Faza 2: maparea 1:1

Maparea e documentul central al migrării. Fiecare URL vechi primește o decizie explicită.

Regula de bază

Trimite fiecare pagină către echivalentul cu aceeași intenție:

• produs vechi către același produs pe domeniul nou;
• categorie veche către categoria echivalentă;
• articol vechi către versiunea mutată a articolului;
• pagină de serviciu către același serviciu;
• pagină eliminată către alternativa cea mai apropiată, numai dacă e cu adevărat relevantă.

Dacă nu există un echivalent util, un status 404 sau 410 e mai corect decât un redirect înșelător — Google cere explicit ca acele URL-uri să returneze 404 sau 410 pe site-ul nou. Și nu trimite toate URL-urile spre homepage: documentația avertizează că redirecționarea multor adrese vechi către o singură destinație irelevantă poate fi tratată ca soft 404.

Cum arată tabelul de lucru

Redirecturile trebuie să fie permanente și directe. Google recomandă 301 sau 308, server-side, și avertizează asupra lanțurilor: Googlebot urmează până la 10 salturi, dar recomandarea e redirect direct către destinația finală, iar dacă nu se poate, sub 3 salturi. Testează automat fiecare pereche, nu câteva pagini alese manual.

Notă: nu-ți face griji pentru „pierderea de link juice”. Documentația Google spune direct că redirecturile permanente de tip 301 nu cauzează pierdere de PageRank. Ce se pierde la o migrare prost făcută sunt URL-urile omise, nu autoritatea transferată corect.

Faza 3: pregătirea noului site și ziua lansării

Pregătirea

Construiește și verifică versiunea nouă într-un mediu de testare protejat. Accesul cu parolă e mai sigur decât încrederea într-un singur fișier robots.txt. Dacă folosești noindex în staging, pregătește dinainte lista de URL-uri de pe care îl scoți la lansare — e recomandarea explicită din documentația Google.

Pe noul site:

1. actualizează linkurile interne direct către URL-urile noi;
2. folosește canonicale autoreferențiale pe domeniul nou;
3. actualizează hreflang, datele structurate și URL-urile absolute;
4. construiește sitemapul numai cu URL-uri noi, canonice și indexabile;
5. verifică accesul la imagini, CSS și JavaScript;
6. păstrează conținutul, titlurile și intenția paginilor care performează;
7. instalează și testează analytics, consent mode și conversiile;
8. testează formulare, conturi, căutare internă, checkout, plăți și emailuri;
9. verifică SSL, DNS, SPF, DKIM și DMARC dacă se schimbă și infrastructura de email.

Rulează un crawl complet pe staging și compară-l cu inventarul vechi. Orice pagină prioritară care lipsește trebuie să aibă o decizie înainte de lansare, nu o explicație după.

Pentru același business, păstrează proprietatea GA4 ca să menții istoricul; actualizează URL-ul fluxului web și configurația de măsurare între domenii dacă traseul clientului trece prin mai multe domenii — pașii unei configurări GA4 corecte rămân aceiași, doar că aici se aplică pe o proprietate cu istoric. Verifică în Search Console toate variantele — www și non-www, HTTP și HTTPS — pentru ambele domenii, pentru că verificarea de proprietate nu se transferă automat. Dacă măsurarea corectă e partea care te îngrijorează cel mai mult, aici intră munca de măsurare.

Ziua lansării

Alege o fereastră cu trafic redus — Google recomandă direct sincronizarea mutării cu perioadele de trafic scăzut — cu echipa tehnică și cu ownerul disponibili.

1. fă backupul final și salvează configurația veche;
2. publică noul site și elimină blocajele de staging;
3. activează redirecturile 301;
4. testează automat toate URL-urile din mapare;
5. verifică paginile prioritare, formularele, plățile și evenimentele;
6. confirmă că verificarea ambelor proprietăți din Search Console e încă validă;
7. trimite sitemapul nou;
8. folosește Change of Address după ce site-ul și redirecturile funcționează;
9. actualizează URL-urile din Google Ads, feeduri, profiluri și instrumente;
10. verifică logurile, erorile 404 și răspunsurile 5xx.

Nu declara migrarea terminată pentru că se încarcă homepage-ul. Homepage-ul e o singură destinație dintr-un inventar care poate avea mii de adrese.

Faza 4: monitorizarea care protejează businessul

În cazul de la începutul articolului, asta a însemnat 3 săptămâni de urmărire zilnică, cu plan de reacție pregătit dinainte. Ferestrele de mai jos sunt aceleași pentru orice migrare; se schimbă doar volumul de verificat.

Regula de citire a tabelului: investighezi clusterele care nu se recuperează, nu media întregului site. Un total care revine poate ascunde un grup de pagini care nu revine deloc.

Pe termen lung, păstrează domeniul vechi și redirecturile active. Google recomandă să le menții cât mai mult, în general cel puțin un an, pentru ca toate semnalele să fie transferate, inclusiv relinkarea de pe alte site-uri; din perspectiva utilizatorului, documentația sugerează chiar păstrarea lor pe termen nedefinit.

Fluctuațiile temporare sunt normale în timpul reprocesării. Pentru site-urile mici și medii, Google estimează câteva săptămâni până când majoritatea paginilor se mută în index; proiectele mari durează mai mult. Viteza depinde de numărul de URL-uri și de capacitatea serverului.

Dacă scade, diagnostichează după simptom

Folosește tabelul ca ordine de verificare, nu ca listă de cauze probabile. Nu repara o scădere agregată prin schimbări masive de conținut imediat după lansare: izolează grupul afectat și verifică întâi cauzele tehnice și diferențele față de pagina veche.

Pentru proiectele în care rebrandul, domeniul și protecția SEO trebuie coordonate, pagina de rebrand și migrare explică ce ține de Amplify și ce ține de developer. Iar dacă înainte de mutare vrei să știi ce ai de protejat, asta e munca din serviciul SEO.

Când nu merită să schimbi domeniul

Amână sau renunță dacă:

• motivul e doar preferința pentru un nume „mai frumos”;
• nu poți păstra domeniul vechi pentru redirecturi;
• nu ai datele necesare pentru un reper;
• noul site nu e complet sau nu poate fi testat;
• schimbi simultan domeniul, CMS-ul, structura și conținutul fără un motiv clar;
• nu există buget și oameni pentru monitorizare și reparații;
• lansarea trebuie făcută în vârful sezonului comercial.

Un domeniu nou trebuie să rezolve o problemă de business suficient de importantă încât să justifice costul, riscul și munca de tranziție. În cazul descris mai sus, motivul a fost un rebrand strategic, nu o preferință estetică — și chiar și așa, riscul a cerut trei săptămâni de monitorizare zilnică.

Întrebări frecvente

Cât a durat revenirea traficului după migrarea de domeniu?

La migrarea kboosting.com → grindout.com, cu cutover pe 26 mai 2026, 85% din trafic a revenit în prima săptămână și 93% din poziții în 3 săptămâni, fără cădere de business pe perioada tranziției (Google Search Console, date extrase pe 12 iulie 2026). Cifrele descriu un singur site și nu se pot generaliza.

Ce nu poate fi atribuit migrării în cifrele de după lansare?

Sezonalitatea, actualizările de algoritm care se suprapun peste fereastra de măsurare și stingerea treptată a notorietății numelui vechi. De aceea reperul se face pe pagini și grupuri de intenție, nu pe totalul site-ului, și de aceea comparația corectă e an-la-an, nu săptămâna dinainte cu săptămâna de după.

Redirect 301 sau 302 la schimbarea domeniului?

301. Google recomandă redirecturi permanente server-side — 301 sau 308 — pentru mutări de site. 302 înseamnă „temporar” și nu comunică o schimbare definitivă de adresă. Documentația precizează și că redirecturile permanente nu cauzează pierdere de PageRank.

Cât timp păstrezi redirecturile 301?

Google recomandă să le păstrezi cât mai mult, în general cel puțin un an, ca toate semnalele să fie transferate. Operațional, e mai sigur să le menții cât timp controlezi domeniul vechi: utilizatorii, linkurile externe și crawlerele pot accesa adresele vechi mult după lansare.

Trebuie folosit Change of Address în Search Console?

Da, la mutarea de la un domeniu la altul, după ce noul site e public și redirecturile funcționează. Pentru migrări de domeniu, Google cere cereri de Change of Address pentru toate subdomeniile și pentru variantele www și non-www ale domeniului vechi, chiar dacă nu le folosești activ. Nu e necesar pentru trecerea de la HTTP la HTTPS și nu înlocuiește redirecturile, maparea sau sitemapul.

Poți schimba domeniul și CMS-ul în aceeași zi?

Tehnic, da. Din perspectiva riscului, e mai greu de controlat, iar Google recomandă explicit schimbarea câte unui lucru pe rând. Dacă nu poți separa schimbările, păstrează stabile cât mai multe elemente și pregătește un plan de testare și de reacție mai riguros.

Concluzie: migrarea se câștigă înainte de ziua mutării

Modelul mental util e că ziua lansării nu decide nimic. Decide inventarul, pentru că îți spune ce ai de protejat. Decide maparea, pentru că spune unde merge fiecare semnal. Decide reperul, pentru că fără el nu poți face diferența între o fluctuație normală și o pierdere reală. Ziua lansării doar execută ce s-a decis deja.

De aici iese și singura promisiune onestă: nu „nu vei pierde nimic”, ci „pierderile evitabile vor fi eliminate, iar cele inevitabile vor fi vizibile și explicabile”. Cifrele din cazul de la începutul articolului nu s-au obținut pentru că mutarea a fost norocoasă, ci pentru că fiecare adresă avea o destinație și fiecare zi de după avea un om care se uita la ea.

Dacă proiectul are miză comercială și mai multe echipe implicate, începe cu un owner, un reper și o mapare completă. Pentru o evaluare a riscului și a responsabilităților înainte de mutare, cere un Growth Diagnosis.