Ai decis să schimbi agenția, hostingul sau designul. Toată lumea îți spune că e simplu: se copiază fișierele, se schimbă DNS-ul, gata. La două săptămâni după mutare observi că nu mai primești emailuri de la clienți, că traficul din Google a scăzut și că formularul de contact trimite pe o adresă care nu mai există.
Niciuna dintre aceste probleme nu apare în ziua mutării. Apar treptat, de obicei după ce vechiul server a fost oprit și nu mai ai de unde recupera ce lipsește. Un site nu e doar un folder cu fișiere. E un domeniu, un DNS, cutii poștale, certificate, chei API către curier și facturare, sarcini programate și conturi de Google legate de un email pe care poate nici nu îl controlezi.
Mai jos găsești ce se pierde de obicei și de ce, ce inventariezi înainte, cum decurge mutarea și ce verifici după, plus lista în trei etape pe care o poți folosi indiferent cine face mutarea.
Patru feluri de mutare, patru feluri de riscuri
Merită să știi în care situație ești, pentru că riscurile diferă.
- Schimbi hostingul (același site, alt server). Riscurile sunt tehnice: fișiere lipsă, DNS, email, cron-uri, certificat.
- Schimbi agenția (de obicei și hostingul). Se adaugă problema accesului: conturi pe numele agenției, licențe, integrări configurate de ei.
- Refaci designul (același domeniu, alt site). Riscul principal e SEO: adrese schimbate fără redirecționări, pagini șterse.
- Muți pe alt domeniu. Toate cele de mai sus, plus schimbarea de adresă în Search Console și o perioadă în care Google reînvață site-ul.
Ce se pierde de obicei și de ce
Redirecționările
După un redesign, pagina /servicii/consultanta-fiscala/ devine /consultanta/. Adresa veche era în Google de trei ani și aducea clienți. Fără o redirecționare 301 spre cea nouă, Google vede un 404 și, după câteva săptămâni, scoate pagina din index. Poziția nu se transferă singură.
Emailurile
Cea mai dureroasă pierdere, pentru că nu o vezi. Când DNS-ul se mută la alt administrator, înregistrările MX, SPF, DKIM și DMARC lipsesc din zona nouă. Emailurile clienților nu mai ajung, iar ale tale ajung în spam. Dacă în plus cutiile poștale stăteau pe același server cu site-ul, ele rămân acolo, cu tot istoricul, și dispar când serverul e închis.
Integrările
Cheile API pentru curier, plăți, facturare sau newsletter stau în configurația veche. La copiere unele nu ajung, altele sunt legate de IP-ul vechiului server și refuză conexiunile de pe cel nou. Magazinul merge, dar nu mai generează AWB-uri sau facturi.
Cron-urile
Sincronizarea de stocuri, backup-ul, rapoartele, ștergerea coșurilor abandonate: toate rulează din sarcini programate pe server, nu din fișierele site-ului. Pe serverul nou nu există până nu le recreează cineva.
Certificatul SSL
Certificatul e legat de server. Dacă DNS-ul a fost mutat înainte ca serverul nou să aibă certificatul lui, vizitatorii primesc avertismentul de securitate exact în primele ore după mutare.
Fișierele încărcate
Folderul cu imagini și documente e cel mai mare și se copiază cel mai des incomplet: transferul se întrerupe sau arhiva depășește o limită. Site-ul arată bine pe prima pagină și are imagini lipsă pe produsele de la pagina 40.
Comenzile din timpul mutării
La un magazin, între copierea bazei de date și momentul în care DNS-ul indică serverul nou pot trece ore. Comenzile plasate în acest interval intră pe serverul vechi și nu există pe cel nou. Clientul a plătit, tu nu ai comanda.
Formularele și conturile Google
Formularul de contact trimite pe adresa configurată de agenție, uneori una de pe vechiul server. După mutare, mesajele pleacă spre nicăieri. Iar Analytics și Search Console, create din contul agenției, rămân la ei odată cu istoricul de trafic.
Inventarul de dinainte de mutare
Nu poți muta ce nu știi că există. Notează, pentru fiecare element, unde e, cine are acces și pe numele cui e contul.
- Domeniul: la ce registrar e, pe numele cui, când expiră.
- DNS-ul: cine administrează zona și un export complet al înregistrărilor, inclusiv MX, SPF, DKIM, DMARC, subdomenii, verificări de proprietate.
- Hostingul: furnizor, versiuni de PHP și bază de date, ce altceva mai rulează acolo.
- Emailul: unde stau cutiile poștale, câte sunt, dacă sunt pe același server cu site-ul.
- Certificatul SSL: emis de cine, automat sau plătit, când expiră.
- Integrările: curier, plăți, facturare, SMS, newsletter, CRM, cu contul și cheile fiecăreia și dacă sunt restricționate pe IP.
- Licențele de temă și plugin-uri: pe contul cui sunt, dacă sunt transferabile.
- Conturile Google: Analytics, Search Console, Business Profile, Ads, Tag Manager. Cine e proprietar, cine e doar editor.
- Sarcinile programate: ce rulează din cron și la ce interval.
Apoi exportă lista de adrese indexate: raportul de pagini din Search Console plus toate adresele din sitemap. Cu ea verifici după mutare că nimic nu a rămas pe 404.
Fă un backup complet și verifică-l: dezarhivează-l în altă parte, numără fișierele din folderul de încărcări, compară numărul de comenzi din baza de date cu ce vezi în administrare.
Accesul la domeniu, DNS și hosting trebuie să fie pe numele firmei tale înainte de a începe mutarea. Dacă vreunul e pe numele agenției, cere transferul acum. După ce relația s-a încheiat, e mult mai greu.
Cum decurge mutarea propriu-zisă
Copia pe serverul nou, testată pe o adresă temporară
Site-ul se copiază pe serverul nou și pornește acolo, fără să atingi DNS-ul. Îl testezi pe un subdomeniu temporar sau modificând fișierul hosts de pe calculatorul tău, ca domeniul real să indice serverul nou doar pentru tine. Aici verifici tot: pagini, imagini, formular, coș, autentificare, viteză.
TTL-ul DNS redus cu o zi înainte
TTL-ul spune furnizorilor de internet cât timp să țină minte adresa IP a site-ului. Dacă e 24 de ore, o parte din vizitatori ajung încă o zi pe serverul vechi. Cu o zi înainte, reduci TTL-ul la 300 de secunde. La mutare, schimbarea se propagă în minute.
Fereastra de mutare
Alegi un interval cu trafic mic, dar verifică în Analytics: un magazin poate avea vârful exact duminica seara. În acel interval nimeni nu modifică nimic pe site.
Comenzile, la magazine
Ai două variante. Prima: „îngheți” magazinul pe durata mutării, cu un mesaj clar la checkout, faci copia finală a bazei de date și abia apoi schimbi DNS-ul. A doua, când nu îți permiți pauza: faci copia, schimbi DNS-ul, apoi compari comenzile de pe cele două servere și le aduci manual pe cele intrate între timp. Prima e mai sigură.
Serverul vechi rămâne pornit
Îl ții pornit câteva zile, ideal o săptămână. E singurul loc de unde poți recupera un fișier lipsă, o comandă rătăcită sau o cutie poștală uitată.
Emailul se tratează ca un proiect separat. Cutiile se copiază cu tot istoricul, se verifică pe serverul nou, iar MX-ul se schimbă abia când noul server primește corect. Dacă emailul stă la un furnizor dedicat, nu îl atingi, doar copiezi înregistrările în noul DNS.
Ce verifici după mutare
Mutarea nu s-a terminat când site-ul se încarcă, ci când ai bifat tot ce urmează.
- Redirecționările: iei lista exportată înainte și verifici că fiecare adresă răspunde cu 200 sau cu 301 spre o pagină echivalentă. Există unelte care fac asta pentru o listă întreagă.
- Sitemap-ul: îl retrimiți în Search Console. Schimbarea de adresă din Search Console se folosește doar când te muți pe alt domeniu.
- Emailul: trimiți de pe fiecare cutie importantă către un cont extern și primești unul înapoi. Dacă mesajul trimis nu ajunge în spam, SPF, DKIM și DMARC sunt corecte.
- Formularele: completezi fiecare formular și confirmi că mesajul ajunge la adresa corectă.
- Checkout-ul: plasezi o comandă de test cu plată reală de valoare mică. Verifici că apare în administrare, că se generează factura și AWB-ul, că emailul de confirmare ajunge.
- Cron-urile: confirmi că există pe serverul nou și că au rulat cel puțin o dată.
- Certificatul: niciun avertisment în browser, inclusiv pe subdomenii.
- Viteza: compari cu cea de dinainte. Un server nou nu e automat mai rapid dacă lipsește cache-ul de pe cel vechi.
- Monitorizare 48 de ore: jurnalele de erori ale serverului și raportul de 404 din Search Console. Adresele care apar acolo sunt cele ratate la redirecționări.
Dacă site-ul rămâne pe un plan de întreținere și actualizări după mutare, o parte din verificările de mai sus intră în rutina lunară și nu mai depind de memoria cuiva.
Redesign: unde se pierd pozițiile cel mai des
Un redesign nu e o mutare tehnică, dar e cauza cea mai frecventă de pierdere de trafic din Google. Motivul e aproape mereu același: adresele paginilor se schimbă odată cu designul, iar nimeni nu face redirecționările.
A doua cauză e ștergerea paginilor „pentru că erau urâte”. Un articol vechi poate fi exact pagina care aduce cele mai multe vizite din căutare. Înainte de redesign, uită-te în Analytics la paginile cu trafic din Google în ultimul an. Acelea se păstrează, se rescriu sau se redirecționează spre o pagină cu același subiect. Nu se șterg.
Regula pentru adrese: le păstrezi neschimbate dacă se poate. Dacă nu, redirecționezi una la una: vechea pagină de serviciu spre noua pagină de serviciu, vechiul articol spre noul articol. Redirecționarea tuturor adreselor vechi spre prima pagină e tratată de Google ca un 404 mascat.
Cine deține ce, și ce ceri la plecarea de la o agenție
Domeniul, hostingul, DNS-ul și conturile de Google trebuie să fie pe firma ta. Agenția primește acces, nu proprietate. Diferența pare formală până în ziua în care relația se strică și domeniul expiră pe contul lor.
Când pleci de la o agenție, cere în scris:
- Export complet al site-ului: fișiere, bază de date, fișiere încărcate, într-o arhivă pe care o poți deschide.
- Acces de administrator (nu de editor) la site, hosting, domeniu, DNS.
- Transferul de proprietate pentru Analytics, Search Console, Business Profile, Tag Manager și Ads pe un cont al firmei.
- Lista serviciilor și abonamentelor plătite pe numele lor: licențe, CDN, email, monitorizare, cu data de expirare a fiecăruia.
- Documentația integrărilor și a sarcinilor programate: ce se leagă de ce, cu ce cont, unde stau cheile.
Dacă agenția a scris cod propriu care leagă magazinul de curier sau de facturare, cere codul și o descriere a lui. Fără ele, la mutare va trebui refăcută legătura cu fiecare serviciu extern de la zero.
Lista de verificare
- Înainte: inventar complet (domeniu, DNS, hosting, email, certificat, integrări, licențe, conturi Google, cron-uri), cu proprietarul fiecăruia.
- Înainte: tot ce e pe numele agenției se transferă pe firmă.
- Înainte: export al adreselor indexate din Search Console și din sitemap.
- Înainte: backup complet, dezarhivat și verificat în altă parte.
- Înainte: TTL DNS redus la 300 de secunde cu o zi înainte.
- În timpul: copia pe serverul nou testată pe adresă temporară, inclusiv formular și coș.
- În timpul: certificat emis pe serverul nou înainte de schimbarea DNS-ului.
- În timpul: magazin înghețat sau plan de sincronizare a comenzilor intrate între copie și mutare.
- În timpul: înregistrările de email (MX, SPF, DKIM, DMARC) copiate identic în noul DNS.
- După: lista de adrese verificată, sitemap retrimis, email, formulare și checkout testate cu o comandă reală.
- După: cron-uri recreate, viteză comparată, monitorizare 48 de ore pe jurnale și pe raportul 404.
- După: serverul vechi închis abia după o săptămână fără probleme.
Verifică azi pe numele cui e înregistrat domeniul și cine administrează DNS-ul. Intră în contul de la registrar (sau caută emailul de la ultima reînnoire) și uită-te la datele de proprietar și la serverele de nume. Dacă vreunul nu e pe firma ta, ăsta e primul lucru de rezolvat, înainte de orice mutare.