Muți site-ul? Ordinea în care nu pierzi emailul și nici Google

Când site-ul se mută la un alt developer sau pe altă găzduire, partea vizibilă e site-ul. Partea care doare e emailul. Dacă o înregistrare DNS se pierde pe drum, mesajele nu mai pleacă sau nu mai ajung, iar de multe ori observi abia după câteva zile, când nu mai legi problema de mutare.

Am mutat recent propriul domeniu la alt furnizor de DNS și am trecut prin aceeași listă pe care o găsești mai jos. Nu trebuie să o execuți tu. Trebuie doar să știi ce să ceri și în ce ordine, ca să poți ține pe oricine la ea.

Înainte să atingă cineva DNS-ul: cinci întrebări

1. Unde e înregistrat domeniul și cine are acces la contul acela? (Registrarul, nu găzduirea.)
2. Unde e emailul? La aceeași firmă cu site-ul, la Google, la Microsoft, la altcineva? Dacă emailul rămâne unde e, mutarea trebuie să-l lase neatins.
3. Există o copie a tuturor înregistrărilor DNS de acum? Dacă nu, aceea e primul lucru pe care îl ceri.
4. Ce adrese ale paginilor se schimbă? Dacă se schimbă, cine face redirecționările?
5. Care e planul de întoarcere dacă ceva nu merge?

Dacă developerul nu are un răspuns clar la a treia și la a cincea, mai așteaptă.

Ordinea care ține emailul în viață

1. Lista completă a înregistrărilor, salvată

Zona DNS e lista care spune internetului unde e site-ul și unde e emailul. Pentru email contează în special:

• MX: serverele care primesc mesajele tale;
• SPF (un TXT): cine are voie să trimită în numele domeniului;
• DKIM (tot un TXT, lung): semnătura mesajelor trimise;
• DMARC (un TXT pe _dmarc): ce fac ceilalți cu mesajele care nu trec verificările;
• TXT-urile de verificare pentru Google, Microsoft și alte servicii.

Toate se copiază exact, caracter cu caracter, înainte de orice schimbare. O copie text, păstrată și de tine, nu doar de developer.

2. Emailul primul, verificat

La noul furnizor de DNS, înregistrările de email se pun primele și se compară cu lista salvată. Atenție la un lucru: importul automat al zonei, pe care multe panouri îl oferă, poate sări peste înregistrări. Cheia DKIM, fiind lungă, e un candidat clasic. Importul arată complet, dar lipsește exact rândul care contează. De aceea ceri o comparație rând cu rând, nu un „s-a importat”.

Încă două reguli simple. Cheia DKIM se copiază, nu se transcrie de pe o captură de ecran: un singur caracter greșit o strică fără niciun mesaj de eroare. Iar dacă noul furnizor are un proxy (Cloudflare îl marchează cu un nor portocaliu), înregistrările de email, cum ar fi mail, rămân doar DNS. Proxy-ul acela trece doar trafic web, iar programul tău de email nu s-ar mai putea conecta.

Dacă domeniul are o politică DMARC strictă (p=reject), o greșeală aici nu trimite mesajele în spam. Le respinge de tot.

3. TTL scăzut, din timp

TTL e cât timp păstrează alte servere un răspuns DNS înainte să întrebe din nou. Dacă e scăzut cu o zi sau două înainte de mutare, schimbarea ajunge mai repede la toată lumea, la fel și o eventuală corectură.

4. DNSSEC oprit înainte de schimbarea nameserverelor

Dacă domeniul are DNSSEC activ, semnătura înregistrată la registrar trebuie să se potrivească cu furnizorul de DNS. Dacă schimbi furnizorul cu DNSSEC pornit, rețelele care verifică semnătura pot refuza domeniul de tot. Se oprește înainte și se pornește din nou după ce noul furnizor e activ.

5. Întâi nameserverele, abia apoi site-ul

Aici e trucul. Nameserverele se schimbă cât timp noua zonă e o copie fidelă a celei vechi. În momentul acela, pentru vizitatori și pentru email nu se schimbă nimic, și exact asta vrei: pasul cel mai greu de întors nu schimbă nimic.

Abia după ce noul furnizor confirmă că zona e activă se schimbă înregistrările site-ului (de obicei cea de pe domeniul principal și www) spre noua găzduire. Un pas separat, mic și ușor de întors.

6. HTTPS înainte de anunț

Certificatul de securitate trebuie emis și verificat pe noua găzduire, atât pe domeniu cât și pe www, înainte să trimiți linkul cuiva. Altfel primul vizitator vede un avertisment de securitate în locul site-ului.

Ordinea care ține Google de partea ta

Schimbarea găzduirii în sine nu e problema. Adresele care dispar sunt.

• Păstrează adresele paginilor unde se poate. Aceeași adresă, același conținut, nimic de explicat.
• Unde o adresă se schimbă, fiecare adresă veche primește o redirecționare permanentă (301 sau 308) spre cea nouă. Nu spre prima pagină, ci spre pagina echivalentă.
• O singură formă a domeniului: fie cu www, fie fără, iar cealaltă redirecționează permanent spre ea.
• În Google Search Console: domeniul verificat (TXT-ul de verificare e unul dintre rândurile salvate la pasul 1), sitemap-ul trimis din nou, cerere de indexare pentru prima pagină.

„Site-ul a picat!” în prima zi

După schimbare poți vedea site-ul vechi, o pagină de eroare sau nimic, în timp ce site-ul merge perfect. Routerul de acasă sau de la birou ține minte vechiul răspuns DNS încă o vreme, uneori ore.

Înainte să suni pe cineva, deschide site-ul de pe telefon, pe date mobile, cu Wi-Fi-ul oprit. Dacă merge acolo, nu e nimic stricat: rețeaua ta încă se uită la adresa veche. Un restart al routerului rezolvă de obicei problema pentru toate dispozitivele din casă. Pentru o vreme poți vedea chiar site-ul vechi pe o pagină și pe cel nou pe următoarea. E tot întârziere, nu o eroare.

Ce ceri, pe scurt

• copia completă a DNS-ului, la tine;
• emailul mutat primul și comparat rând cu rând;
• TTL scăzut din timp;
• DNSSEC oprit înainte, pornit după;
• nameservere întâi, site după;
• redirecționări pentru fiecare adresă veche;
• HTTPS gata înainte de anunț;
• Search Console actualizat.

Dacă vrei pe cineva care face mutarea în ordinea asta și îți dă la final lista cu tot ce s-a verificat, vezi cum lucrez la migrări sau scrie-mi direct.