Un site care a migrat pe un domeniu nou la începutul lui 2026 a fost reindexat pe domeniul vechi după aproximativ patru luni, iar peste 5.000 de pagini de pe domeniul nou au trecut în „Crawled, currently not indexed". Google recomandă Change of Address pentru ambele versiuni, www și non-www, și spune că unele tranziții se procesează neobișnuit de lent.
Ce s-a întâmplat, pe scurt
Punctul de plecare este un fir de discuție de pe Reddit, semnalat de Search Engine Roundtable într-un articol din 13.10.2026 (sursa). Un proprietar de site spune că a schimbat numele și domeniul la începutul anului 2026, ca să acopere un subiect suplimentar. A implementat redirectări și a folosit instrumentul Change of Address din Google Search Console. Până în aprilie, traficul își revenise, domeniul nou era indexat și strângea în jur de 5.000 de afișări pe zi.
Apoi, patru luni mai târziu, lucrurile s-au inversat. Google a scos din index peste 5.000 de pagini de pe domeniul nou, marcându-le ca „Crawled, currently not indexed", iar afișările pe domeniul nou au căzut la circa 20 pe săptămână. În același timp, domeniul vechi a fost reindexat complet, iar impresiile și clicurile apar acum acolo, în Search Console.
John Mueller a răspuns în fir și i-a cerut utilizatorului să îi scrie în privat. A adăugat două lucruri. Primul: uneori procesarea durează neobișnuit de mult până se finalizează complet. Al doilea: merită verificat că Change of Address este configurat atât pentru versiunea www, cât și pentru cea non-www, pentru ca migrarea să se încheie corect.
Autorul articolului sursă își exprimă îndoiala că a doua explicație s-ar aplica aici, pentru că, atunci când cauți explicit domeniul vechi, Google îl va arăta oricum. Este o observație rezonabilă, dar nu exclude problema.
Ce este măsurat și ce rămâne ipoteză
Aici e locul unde majoritatea discuțiilor SEO o iau razna. Din materialul sursă avem câteva fapte clare: există un fir Reddit, există relatararea lui, există răspunsul public al lui Mueller cu cele două sugestii. Atât. Nu avem acces la proprietatea din Search Console, nu știm cum arată profilul de backlinkuri, nu știm dacă redirectările sunt corecte pe toate tiparele de URL, nu știm dacă sitemap-ul nou a fost curățat, nu știm dacă există conținut duplicat rămas pe vechiul domeniu.
Ce nu avem deloc: o confirmare că aceasta este o problemă sistemică de indexare la Google. Un singur caz nu dovedește un pattern. Nu avem nici dovada că lipsa configurării pe ambele versiuni www și non-www este cauza reală. Mueller a spus că ajută, nu că este explicația.
Deci separăm:
- Constatare din sursă: migrare, recuperare aparentă, reversie bruscă după patru luni, reindexare a domeniului vechi.
- Recomandare Google: Change of Address pentru www și non-www.
- Ipoteză nesusținută: că Google are un bug de atribuire pe scara largă.
- Ce verificăm noi: tot restul lanțului tehnic, pentru că e singurul lucru controlabil.
O verificare incompletă nu dovedește absența unei funcții sau a unui element. Dacă nu ai acces la date, nu poți concluziona că redirectarea funcționează sau nu.
Lista de verificare pentru migrări de domeniu
Ordinea de mai jos nu este o garanție. Este o secvență logică pe care o poți rula fără să presupui nimic.
1. Redirectări la nivel de URL, nu doar la nivel de domeniu. Verifică un eșantion de 50 până la 100 de URL-uri vechi, inclusiv cele cu trafic istoric, și urmărește lanțul complet. Redirectare către redirectare, sau redirectare către 404, sunt clasice.
2. www și non-www, tratate separat. Exact punctul ridicat de Mueller. Dacă ambele versiuni au răspuns istoric, fiecare are nevoie de propria configurare. Lasă un singur canonical și un singur set de redirectări.
3. Change of Address, confirmat activ. Verifică dacă proprietatea veche este încă verificată în Search Console. Dacă pierzi verificarea pe domeniul vechi, semnalul se poate stinge fără să observi.
4. Sitemap-uri și canonical pe domeniul nou. Sitemap nou, doar URL-uri noi, fără amestec. Canonical auto-referențial pe noul domeniu.
5. Conținut rămas accesibil pe domeniul vechi. Dacă vechiul domeniu încă servește pagini, chiar și parțial, ai un semnal contradictoriu. Verifică site:domeniu-vechi periodic.
6. Profilul de linkuri. Linkurile externe către domeniul vechi se transferă prin redirectare, dar viteza de recunoaștere nu este instantanee și nu o controlezi.
7. Alerte pe Search Console. Setează notificări pentru acoperire și pentru probleme de securitate. Nu descoperi o cădere de 5.000 de pagini din raportul lunar.
Ce înseamnă pentru tine
Dacă ești antreprenor sau marketer în România și ai un magazin online, un site de servicii sau un blog cu trafic organic, migrarea de domeniu este unul dintre puținele momente în care poți pierde în câteva zile ceea ce ai construit în ani.
Scenariul cel mai probabil pentru un business mic din România nu este exact cel din firul Reddit. Este un scenariu mai banal: schimbi domeniul, pui o redirectare globală 301 din vechi în nou, consideri că ai terminat, iar peste trei luni observi că anumite pagini de categorie nu mai apar în căutări. Nu ai pierdut tot, ai pierdut un segment, iar segmentul respectiv aducea comenzile.
Concret, ce faci:
În prima săptămână după migrare, documentează baseline-ul. Exportă din Search Console performanța pe ultimele 16 luni, pe pagini și pe interogări. Fără acest export, peste două luni nu vei ști ce ai pierdut, pentru că datele se mută și rapoartele se amestecă.
În primele 30 de zile, monitorizează săptămânal acoperirea pe noul domeniu. Nu te uita doar la trafic. Uită-te la numărul de pagini indexate și la categoria „Crawled, currently not indexed". O creștere bruscă acolo este un semnal timpuriu, nu un rezultat final.
Pe termen lung, păstrează domeniul vechi activ și redirectat cel puțin 12 luni. Costă un domeniu și o configurare, te scutește de reconstrucția unor linkuri. Bonus: dacă apar situații de tipul celei din firul Reddit, ai un canal clar de comparat.
Și, important, nu muta migrarea în același sprint cu o schimbare de structură de URL-uri, cu o replatformare sau cu o schimbare de template. Un singur eveniment major o dată. Altfel, când ceva scade, nu mai știi ce anume a cauzat.
Dacă lucrezi cu SEO tehnic, subiectul ăsta se leagă direct de discuția mai largă despre cum se mișcă prioritățile în stack-ul de marketing, pe care am atins-o în analiza despre martech legacy și viteza în B2C. Migrarea de domeniu este exact genul de sarcină în care un proces simplu și repetabil bate un setup sofisticat pe care nimeni nu îl rulează până când e prea târziu.
Există și o latură de măsurare. Când impresiile și clicurile se mută de pe un domeniu pe altul în rapoarte, atribuirea în analytics se rupe. Dacă folosești UTM-uri pe domeniul vechi și nu le actualizezi, vei vedea trafic organic nou în tool-uri, dar cu sursă greșită. Merită să verifici cum arată datele în analytics după o astfel de mutare, pentru că automatizările de raportare preiau adesea date vechi fără să semnaleze inconsistența.
Ce poți face dacă ți se întâmplă
Pași propuși, nu garanții:
- Deschide un fir în comunitatea de SEO cu date concrete: numărul de pagini afectate, data migrării, ce arată Search Console pe ambele proprietăți. Fără date, nimeni nu poate ajuta.
- Contactează Google prin canalele oficiale. Mueller a cerut mesaj privat în cazul din fir. Nu presupune că se va întâmpla la fel pentru tine.
- Rulează un audit tehnic complet, cu accent pe redirectări, canonical și sitemap-uri.
- Nu schimba nimic major timp de două săptămâni după ce ai înregistrat problema. Ai nevoie de o perioadă curată de observație, altfel amesteci variabile.
- Continuă să publici conținut nou pe domeniul nou. Un site activ dă semnale de prospețime și de funcționare normală.
Ce nu face: nu adăuga noindex pe domeniul vechi ca soluție de forță. Nu bloca crawl-ul domeniului vechi în robots.txt dacă redirectările sunt încă în tranziție. Nu șterge proprietatea veche din Search Console. Toate acestea pot face mai rău, pentru că rupi canalele prin care Google poate procesa migrarea.
Scenarii ipotetice
Ipoteza 1: Google procesează semnalul de migrare în valuri, iar un val ulterior a reevaluat domeniul vechi. Nu avem dovezi, doar un caz.
Ipoteza 2: există conținut duplicat rămas pe vechiul domeniu, iar Google a ales versiunea pe care o considera mai puternică în acel moment. Verificabil.
Ipoteza 3: profilul de linkuri către vechiul domeniu era suficient de puternic încât, la o re-evaluare, vechiul domeniu să fie preferat. Verificabil parțial.
Niciuna dintre acestea nu este confirmată. Sunt enumerate ca puncte de plecare pentru verificare, nu ca explicații.
FAQ
Cât durează o migrare de domeniu la Google? Nu există un termen standard. Din cazul relatat, recuperarea a durat aproximativ trei luni, iar reversia a apărut patru luni mai târziu. Google spune doar că unele tranziții se procesează neobișnuit de lent. Tratează migrarea ca pe un proces de luni, nu de zile.
Este obligatoriu Change of Address pentru www și non-www? Mueller recomandă configurarea pentru ambele versiuni, ca migrarea să se încheie complet. Dacă doar una dintre versiuni a avut trafic istoric, verifică oricum ce se întâmplă cu cealaltă. O configurare incompletă nu dovedește că funcția nu există, dar lasă un canal deschis.
Ce fac dacă domeniul nou pierde indexarea brusc? Documentează totul înainte să schimbi ceva. Exportă datele, verifică redirectările, canonical și sitemap-urile, apoi contactează Google prin canalele oficiale. Nu aplica măsuri de forță pe domeniul vechi.
Concluzie
Un caz singular nu este o lege. Dar este un semnal că migrările de domeniu rămân una dintre cele mai fragile operațiuni din SEO, iar verificarea completă, pe ambele versiuni de hostname, cu redirectări curate și date exportate, rămâne singurul lucru pe care îl controlezi cu adevărat.
AI-ul te ajută la analiză și planning: poate grupa URL-urile, poate compara exporturile din Search Console, poate semnala unde redirectările se rup. Dar decizia de a muta sau nu domeniul, de a amâna o migrare sau de a schimba structura în același timp, rămâne a unui om care înțelege businessul. Iar execuția, verificarea tehnică pas cu pas și responsabilitatea rezultatului rămân la media buyer și la echipa care răspunde de trafic.
Dacă vrei să treci de la teorie la un plan concret de migrare sau de audit tehnic, cu pași, responsabili și termene reale, discută cu echipa ALLSoft Agency. Fără promisiuni de poziții și fără cifre inventate, doar verificare pe datele tale.
Comentarii
Ca sa lasi un comentariu, conecteaza-te sau fa-ti un cont gratuit.
Niciun comentariu inca. Fii primul.