Stabiliți exact ce se mută
O migrare de site înseamnă transferarea website-ului către o infrastructură, platformă sau adresă nouă. Poate părea o operațiune simplă, dar paginile reprezintă numai o parte din proiect. Imaginile, baza de date, comenzile, conturile, e-mailul și integrările pot avea locuri și responsabili diferiți. Planul trebuie să arate ce se transferă, ce rămâne unde este și cine confirmă fiecare componentă.
Faceți diferența între schimbarea hostingului cu aceleași adrese, schimbarea domeniului și reconstruirea site-ului pe altă platformă. Ultima variantă poate modifica funcții și conținut, nu doar locul fișierelor. Dacă obiectivul este un server mai potrivit, evitați să introduceți simultan un redesign și o reorganizare completă a paginilor. Pentru infrastructură, vedeți serviciul de migrare hosting pentru website.
Inventarul trebuie să includă și lucrurile care nu se văd
Începeți cu lista paginilor, fișierelor descărcabile și funcțiilor folosite de clienți. Adăugați proprietarul domeniului, contul de hosting, serviciul de e-mail, certificatele, accesul la platformă și sistemele conectate. Nu presupuneți că mutarea website-ului mută automat și căsuțele poștale. Cereți o confirmare separată despre mesajele vechi și despre primirea mesajelor noi.
Documentul de lucru poate avea câte o linie pentru fiecare componentă: sursă, destinație, responsabil, verificare și rezultat. Înregistrați unde se păstrează accesul, fără să copiați parole în documente distribuite tuturor. Pentru paginile importante salvați o referință vizuală și informațiile esențiale. Astfel puteți compara concret noua versiune cu cea aprobată, inclusiv programul, telefoanele, prețurile și textele comerciale.
O copie de siguranță trebuie să poată fi restaurată
Pentru WordPress, documentația oficială cere pregătirea atât a fișierelor, cât și a bazei de date. O arhivă cu imagini și teme nu înlocuiește baza de date; nici exportul articolelor nu reprezintă o copie completă a instalației. La un site static, inventarul și procedura de recuperare sunt diferite. Stabiliți ce conține copia pentru platforma dumneavoastră și unde este păstrată.
Verificați restaurarea într-un mediu separat înainte de intervenție. Notați data copiei, versiunea aplicației și pașii care au funcționat. Restricționați accesul la arhivele care pot conține date personale. O bifă lângă «backup realizat» nu arată dacă fișierul este complet, dacă parola este disponibilă sau dacă echipa poate readuce serviciul în funcțiune. Aceste răspunsuri trebuie obținute înaintea mutării.
Protejați datele care se schimbă în timpul mutării
Un site de prezentare cu informații stabile are alte nevoi decât un magazin care primește comenzi. Pentru magazin, copia pregătită dimineața poate să nu mai includă tranzacțiile de după-amiază. Stabiliți momentul ultimului transfer, sursa considerată corectă și modul în care sunt reconciliate comenzile, stocurile și notificările. Regula se aplică și rezervărilor sau solicitărilor salvate în platformă.
De exemplu, într-un scenariu ilustrativ, echipa poate conveni o fereastră de întreținere și poate transfera modificările apărute după copia inițială. Procedura depinde de sistem; nu este o recomandare de a opri arbitrar vânzările. Persoana responsabilă trebuie să decidă când este permisă intervenția și cum sunt informați clienții. Lista operațiunilor recurente apare în ghidul despre administrarea magazinului online.
Testați traseele reale, nu numai pagina principală
Copia de test trebuie protejată de accesul public și separată de serviciile reale de plată, notificare sau livrare, în măsura permisă de platformă. Nu activați o comandă de test înainte să știți ce efecte produce. Stabiliți scenariile cu administratorul: ce se simulează, ce se verifică efectiv și cine elimină datele de test prin procedura aprobată.
Dacă anumite integrări nu pot fi separate de producție, nu executați acțiuni care pot încasa bani, trimite mesaje sau porni livrări. Cereți furnizorului o metodă de test aprobată și consemnați ce nu poate fi verificat în siguranță. O copie de test accesibilă public sau conectată automat la servicii reale nu este un mediu izolat.
- Pagini principale, imagini și documente: conținutul aprobat este prezent.
- Telefon, e-mail și linkuri de contact: destinațiile sunt cele convenite.
- Funcții existente: autentificare, căutare, coș sau rezervare, după caz.
- Afișare pe mobil și desktop: texte, meniuri și elemente interactive utilizabile.
- Integrări și notificări: teste documentate, fără efecte comerciale necontrolate.
Când adresele se schimbă, pregătiți corespondența lor
La schimbarea URL-urilor, pregătiți corespondența pagină veche–pagină nouă. Google recomandă redirecturi permanente pe server, precum 301 sau 308, direct către destinația relevantă. Nu trimiteți toate paginile dispărute la homepage. Verificați linkurile interne, adresele canonice și sitemapul pentru noile adrese și eliminați restricțiile de test de pe paginile destinate indexării. Google recomandă păstrarea redirecturilor, în general, cel puțin un an.
Dacă adresele publice rămân aceleași, lista de corespondență servește în primul rând verificării că nu au fost schimbate accidental. Titlul unei pagini care arată identic nu confirmă și adresa ei. Pentru partea tehnică și editorială, intervenția de optimizare SEO poate fi delimitată separat de transferul infrastructurii.
Planul de revenire trebuie scris înainte de lansare
Stabiliți ce probleme opresc lansarea: date lipsă, comenzi neînregistrate, plăți cu statut greșit sau funcții esențiale indisponibile. Definiți cine decide revenirea, ce copie se folosește și cum sunt păstrate datele primite între timp. Restaurarea unei baze de date vechi peste un magazin activ poate șterge comenzile noi; revenirea necesită reconciliere, nu doar apăsarea unui buton.
La predare, cereți inventarul final, rezultatele verificărilor și lista eventualelor probleme rămase. Notați separat observațiile fără impact imediat și defectele care cer intervenție. Un plan bine documentat nu elimină orice risc, dar permite echipei să recunoască problema și să ia o decizie pe baza unor informații verificabile.
Urmăriți funcționarea după transfer
După mutare, verificați înregistrarea comenzilor sau solicitărilor, primirea mesajelor și paginile accesate frecvent. La schimbarea URL-urilor, urmăriți erorile și indexarea în Search Console. Pot apărea fluctuații temporare ale vizibilității; acestea nu stabilesc singure dacă transferul a reușit. Comparați aceleași intervale și separați funcționarea tehnică de rezultatele comerciale.
Înainte de schimbarea DNS, verificați certificatul HTTPS și funcționarea pe infrastructura nouă prin metoda de test convenită cu furnizorul. După schimbare, verificați adresa publică și trimiterea și primirea e-mailului, dacă serviciul de e-mail este afectat. Păstrați vechiul hosting și copiile protejate până când transferul este validat, datele sunt reconciliate și responsabilul aprobă închiderea mediului vechi. Modificările DNS pot fi preluate la momente diferite; stabiliți cine urmărește traficul și datele apărute în această perioadă, fără să presupuneți că toți vizitatorii ajung imediat la același server.
Pentru o evaluare, pregătiți domeniul, platforma actuală, motivul mutării și funcțiile care trebuie păstrate. Prin canalele noastre de contact putem discuta ce intră în intervenție și ce necesită coordonarea cu furnizorul platformei. Pentru întreținerea ulterioară, consultați serviciul de administrare website.
Documentație oficială pentru verificările tehnice
Consultați Google Search Central: mutarea unui site cu schimbarea URL-urilor și WordPress: migrarea instalației. Procedura concretă trebuie adaptată configurației existente.