Cui aparține site-ul tău, de fapt

Ai plătit pentru site, deci e al tău. Așa pare, și de obicei nimeni nu minte.

Numai că „site-ul" nu e un obiect. Sunt șapte lucruri separate, fiecare cu contul lui și cu procedura lui. Iar întrebarea la care se ajunge de obicei — „pe numele cui e?" — e întrebarea greșită. Pe cele mai multe dintre ele e perfect practic să le țină cine construiește și administrează site-ul, și de cele mai multe ori așa și e mai bine.

Întrebarea utilă e alta: se poate muta la tine, cum anume, și cât costă?

Asta e o listă mai scurtă și o discuție mult mai concretă.

Două aranjamente, ambele corecte

În practică există două feluri de clienți, și niciunul nu greșește.

Unii vor totul centralizat la dezvoltator. Domeniul, găzduirea, conturile — toate ținute de firma care administrează site-ul, plătite din bugetul ei, iar clientul le achită într-o singură factură, împreună cu mentenanța. Avantajul e real: nu ai de urmărit șase reînnoiri pe trei carduri, și nu-ți cade nimic pentru că un card a expirat în februarie și nimeni nu s-a uitat la mailul de avertizare.

Condiția e una singură, și se confirmă în scris de la început: la plecare primești tot, în așa fel încât să nu mai depinzi în niciun fel de ei.

Alții vor să fie proprietari pe tot, de la prima zi, și să aibă controlul direct asupra fiecărui cont. E la fel de validă ca alegere. Costă puțin mai multă atenție administrativă, și atât.

Ce contează cu adevărat e ca firma cu care lucrezi să fie flexibilă la amândouă. Una care poate lucra doar într-un singur fel — fie „ținem noi tot, altfel nu se poate", fie „nu ne atingem de conturile tale, descurcă-te" — îți impune modelul ei de operare în locul celui care ți se potrivește.

Lista de mai jos funcționează identic în ambele cazuri. Se schimbă doar cine apasă butoanele zi de zi, nu ce trebuie să poți obține.

Cele șapte

1. Domeniul

În practică, cel mai comod e ca domeniul să fie ținut de firma care face site-ul. Ei configurează DNS-ul, ei prind reînnoirea, ei vorbesc cu registratorul când e ceva de schimbat. Domeniile care expiră sunt aproape întotdeauna domeniile pe care nu le urmărea nimeni în mod special.

Ce face aranjamentul ăsta sigur nu e să ții tu cheile, ci faptul că transferul către alt titular e o operațiune obișnuită, care se face la cerere către registrator, și se face de fiecare dată.

Cum se face, la general

Sunt două operațiuni diferite, care se confundă des:

• Schimbarea titularului — domeniul rămâne la același registrator, se schimbă numele înscris în registru.
• Transferul între registratori — titularul rămâne același, se schimbă firma la care e ținut domeniul.

Poți avea nevoie de una, de cealaltă, sau de amândouă.

Mecanismul, în ambele cazuri, e un cod de autorizare (numit și cod de transfer, auth code sau cod EPP). Titularul actual îl cere din contul lui de la registrator și îl transmite. Partea care preia îl introduce la ea, iar ambele adrese de e-mail din dosar confirmă. Atât.

• Pentru .md, registrul e nic.md, administrat de Serviciul Tehnologia Informației și Securitate Cibernetică. Codul de autorizare se cere direct din contul de utilizator de pe nic.md, iar procedura de transfer către alt deținător se face online.
• Pentru .com, .net, .org și celelalte domenii internaționale: domeniul se deblochează întâi (unlock), apoi același cod de autorizare. Durează câteva zile, nu săptămâni.

Un singur lucru de planificat: după anumite schimbări, registratorii refuză un transfer nou pentru o perioadă — de regulă 60 de zile. Nu e o problemă, doar un motiv să nu schimbi și furnizorul, și registratorul în aceeași săptămână.

Ce merită stabilit dinainte

Două propoziții, în scris: că transferul se face la cerere, și cât costă. Costul corect e taxa registratorului plus puțin timp de om. Nimic mai mult.

Singurul lucru care chiar contează aici

Domeniul să fie înregistrat pe firmă, nu pe numele personal al cuiva din ea. O firmă poate semna o cerere de transfer și peste patru ani. Un angajat care a plecat între timp și nu mai răspunde la telefon, nu.

2. Găzduirea

Aceeași logică. Un server ținut de firma care administrează site-ul e un aranjament normal și de obicei mai bun decât alternativa: o singură mașină pe care o cunosc, o actualizează, o monitorizează și pe care au copii de rezervă pe care chiar le-au încercat.

Iar migrarea pe serverul tău, dacă vine ziua în care o vrei, e muncă de rutină: codul, baza de date, fișierele, o înregistrare DNS. O zi, în mare parte de așteptat propagarea.

Deci întrebarea nu e „stă pe serverul meu?". Întrebarea e ce rulează acolo și se poate reproduce în altă parte. Dacă răspunsul e „un runtime standard și o bază de date standard", ești liber oricând. Dacă e „o platformă a noastră, care nu se instalează nicăieri altundeva", ai cumpărat altceva — poate un lucru bun, dar prețul și contractul ar trebui să spună asta explicit.

O excepție care contează: aplicațiile făcute la comandă. Un CRM propriu, un ERP intern, un soft construit special pentru firma ta depind în mod real de un server și de un mediu anume — sunt legate de integrări, de servicii care rulează în fundal, de o bază de date și de o configurație gândite odată cu aplicația. Nu e blocaj comercial, e natura produsului.

Acolo întrebarea se schimbă. Nu „de ce nu merge oriunde", ci dacă mediul e documentat și se poate ridica din nou: ce rulează, în ce versiuni, cu ce variabile, și cu cât efort. Un răspuns bun descrie efortul, în zile și în pași. „Nu se poate nicăieri altundeva" nu e un răspuns tehnic.

Întreabă totuși pe ce cont stă și cine plătește, ca să nu afli într-o zi nepotrivită.

3. Codul

Al tău la final. Nu neapărat pe parcurs — și motivul e legitim.

O ramură în lucru conține parole temporare scrise direct în cod pentru testare, chei care duc spre conturi de test, date pe jumătate migrate. Așa se validează lucrurile repede. A preda asta în mijlocul dezvoltării nu e transparență, e o problemă de securitate și o sursă de întrebări la care nimeni nu are timp să răspundă.

Codul rulează pe server — acolo trăiește. Ce trebuie să existe în plus e o copie într-un sistem de gestiune a versiunilor — în practică Git — găzduit pe o platformă externă: GitHub, GitLab, Bitbucket sau o instanță proprie de tip GitLab ori Gitea.

Diferența nu e formală. Un sistem de versiuni păstrează istoricul fiecărei modificări, permite revenirea la o stare anterioară în câteva minute și face proiectul independent de o singură mașină. Fără el, „codul" înseamnă conținutul de acum al unui director de pe server: fără istoric, fără cale de întoarcere și fără nimic de predat mai departe în afară de o arhivă.

Ce se stabilește, deci: că proiectul e ținut pe o astfel de platformă de la început, și că la predare primești acces la el, complet și curățat de valorile temporare.

Cum verifici: întreabă pe ce platformă de gestiune a versiunilor se ține codul și din ce moment. E o întrebare tehnică, la care există un răspuns scurt și verificabil.

4. Conturile de plată

Contractul cu banca sau cu procesatorul de plăți trebuie să fie pe firma ta, cu banii intrând în contul tău. Asta de obicei e în regulă, fiindcă banca cere oricum documentele firmei.

Ce se ratează mai des e accesul la panoul de comerciant — cel de unde vezi tranzacțiile și faci retururile. Se întâmplă să rămână doar la dezvoltator, fără ca cineva să fi decis asta.

5. Conturile de măsurare

Google Analytics, Search Console, profilul de business, contul de reclame.

Astea se creează repede, adesea pe adresa de mail a celui care face treaba, și rămân acolo. Accesul se dă ușor; ce nu se reface e istoricul, dacă un cont trebuie recreat de la zero. Doi ani de date nu se recuperează.

Cum verifici: intră în fiecare și uită-te cine e proprietar, nu cine are acces.

6. Conținutul

Textele, pozele, ilustrațiile.

Dacă pozele au fost cumpărate dintr-o bibliotecă, licența e pe cineva și are condiții. Merită să știi pe cine și care, mai ales dacă vrei să folosești aceleași imagini într-o broșură sau pe un panou.

7. Cum se pornește

Documentul care spune cum se instalează, ce variabile de mediu cere, cum se publică o versiune nouă. E cel mai ieftin lucru de făcut la momentul potrivit și cel mai scump de reconstituit doi ani mai târziu.

Semnalele de alarmă

Nu „domeniul îl ținem noi" — asta e situația normală. Patru lucruri, în schimb, merită o discuție:

• „Nu se poate transfera", sau un răspuns care nu poate spune cum se face. E o procedură obișnuită la registrator. Semnalul nu e că domeniul e ținut de ei, ci că nimeni nu știe să descrie pasul următor.
• Transferul cotat ca o penalizare. Migrarea e muncă de câteva ore și taxa registratorului. O cifră care arată a răscumpărare descrie relația, nu munca.
• Domeniul pe numele unei persoane, nu al firmei. Riscul real din tot articolul ăsta.
• Cod care rulează doar pe infrastructura lor — la un site sau un magazin obișnuit. Asta e dependență adevărată, și e cu totul altceva decât faptul că, deocamdată, serverul e al lor. Excepția e cea de la punctul 2: o aplicație făcută la comandă depinde legitim de mediul ei, iar acolo se cere documentația mediului, nu portabilitatea.
• Un singur aranjament posibil. Dacă nu poți alege între „țineți voi tot" și „vreau conturile pe firma mea", alegerea a fost făcută pentru tine.

Cum arată o predare completă

Un singur mesaj, șapte puncte, fiecare cu un link sau o dovadă:

1. Domeniul — titular firma ta sau transfer confirmat la cerere, cu procedura scrisă
2. Găzduirea — cont, panou, cine plătește, ce rulează acolo
3. Codul — acces la platforma de gestiune a versiunilor, valori temporare scoase
4. Plățile — contract pe firma ta, acces la panoul de comerciant
5. Măsurarea — proprietar pe firma ta la fiecare cont
6. Conținutul — ce e cumpărat și cu ce licență
7. Pornirea — documentul de instalare

Lista e utilă și înainte de a semna, alături de celelalte lucruri de întrebat când alegi cine îți face site-ul.

Răspunsul la întrebarea din titlu e mai plictisitor decât pare. Site-ul e al tău din momentul în care fiecare din cele șapte se poate muta la tine la cerere — nu din momentul în care ții tu cheile. Cine construiește și administrează are, de obicei, motive bune să le țină. Ce nu are niciun motiv bun e să nu poată explica cum se dau mai departe.