Momentul în care un website devine public este important, dar nu este punctul în care proiectul poate fi considerat automat închis.
În primele ore și zile după lansare apar situații care nu pot fi simulate întotdeauna perfect în mediul de dezvoltare: cache-ul real, DNS-ul, formularele care trimit către adresele finale, traficul utilizatorilor și indexarea motoarelor de căutare.
La Standard Web avem o etapă de verificare după publicarea proiectului. Nu ne limităm la faptul că homepage-ul se deschide și arată corect.
Un website trebuie testat ca sistem.
Prima verificare pare evidentă, dar trebuie făcută metodic.
Parcurgem meniul principal, footerul și paginile importante. Verificăm dacă imaginile se încarcă, dacă nu au rămas texte temporare și dacă legăturile duc la destinațiile corecte.
Unele erori apar doar după schimbarea domeniului.
O imagine poate utiliza încă adresa mediului de dezvoltare, un buton poate trimite către un URL temporar, iar un script poate fi blocat de politica de securitate a domeniului final.
Pe WordPress, o înlocuire incompletă a URL-urilor din baza de date poate produce astfel de probleme chiar dacă prima pagină pare în regulă.
Un formular care afișează mesajul „Mulțumim” nu garantează că emailul a fost primit.
Trimitem solicitări reale și verificăm atât mesajul din inbox, cât și datele înregistrate în sistem, dacă formularul le salvează.
Testăm adrese diferite și, unde este relevant, atașamente sau câmpuri condiționale.
Trebuie verificat și reply-to-ul.
Un formular poate trimite mesajul corect, dar răspunsul echipei să ajungă din greșeală la o adresă tehnică în locul clientului.
Pentru proiectele Standard Web preferăm să aflăm aceste lucruri imediat după lansare, nu după câteva săptămâni când cineva observă că nu au mai venit solicitări.
În timpul dezvoltării, blocarea indexării este normală.
Problema apare dacă aceleași reguli rămân după lansare.
Verificăm robots.txt, meta robots și setările WordPress. Paginile care trebuie să fie publice nu trebuie să aibă noindex.
În același timp, nu orice pagină tehnică trebuie indexată.
Arhivele inutile, paginile de test, rezultatele anumitor filtre și alte URL-uri fără valoare proprie pot necesita tratament separat.
Sitemap-ul XML trebuie să conțină adresele finale.
Într-un proiect refăcut, verificăm și redirecturile de la vechile URL-uri. Procesul este detaliat în articolul despre cum refaci un site fără să pierzi trafic organic.
Un redesign poate arăta perfect și, în același timp, să piardă complet măsurarea traficului dacă scripturile nu au fost mutate corect.
Verificăm dacă instrumentul de analytics primește vizite și dacă evenimentele importante funcționează.
Pentru un site de prezentare poate fi relevantă trimiterea formularului.
Pentru un magazin online trebuie testat fluxul complet: produs, coș, checkout și comandă.
Conversiile nu trebuie înregistrate de două ori la refresh sau la întoarcerea din procesatorul de plăți.
Google Search Console trebuie să aibă proprietatea corectă, iar sitemap-ul final poate fi trimis după lansare.
Nu este necesar să solicităm indexarea manuală a fiecărei pagini dacă site-ul este construit și legat corect.
DevTools este foarte util în dezvoltare, dar nu înlocuiește complet testarea pe telefon.
Folosim dispozitive reale pentru a verifica meniul, formularele, sticky elements, tastatura și comportamentul browserului.
Pe mobil pot apărea probleme care sunt greu de observat într-o simulare.
Un buton fix poate acoperi un câmp. Bara browserului poate schimba înălțimea viewportului. Un input poate face zoom neașteptat.
Verificăm și viteza pe o conexiune care nu este cea din birou.
Un site care pare instant pe fibră poate avea o experiență complet diferită pe rețeaua mobilă.
Rezultatele din mediul de dezvoltare nu sunt întotdeauna reprezentative.
După lansare, serverul final, DNS-ul, cache-ul și eventual CDN-ul intră în ecuație.
Rulăm din nou testele și verificăm dacă pagina principală și câteva tipuri diferite de pagini funcționează cum ne așteptăm.
Nu ne uităm doar la homepage.
O pagină de articol, una de serviciu și, în cazul WooCommerce, pagina de produs pot avea comportamente diferite.
Dacă apar probleme, articolul despre de ce se încarcă greu un site WordPress explică principalele zone pe care le analizăm.
După lansare trebuie să știm că există o copie de siguranță a proiectului final.
Nu ne bazăm doar pe backupul mediului de dezvoltare.
Configurăm politica de backup în funcție de tipul proiectului și verificăm că fișierele și baza de date sunt incluse.
Pentru magazinele online, frecvența trebuie să țină cont de comenzi și de modificarea permanentă a datelor.
Hostingul și strategia de backup sunt discutate mai detaliat în articolul Cum alegi hostingul potrivit pentru WordPress și WooCommerce.
Pentru WooCommerce sau Shopify nu este suficient să verificăm paginile.
Facem comenzi cu metodele principale de plată și livrare.
Verificăm emailurile clientului și administratorului, statusurile, stocul, factura și AWB-ul, acolo unde există integrări.
Dacă magazinul comunică cu ERP sau marketplace, verificăm și transferul acolo.
O problemă aparent mică poate avea efect comercial direct. Un status greșit poate împiedica emiterea facturii, iar o configurare incorectă a transportului poate aplica un tarif greșit tuturor comenzilor.
În articolul despre integrările unui magazin online am explicat de ce fiecare flux trebuie testat ca proces, nu doar ca modul instalat.
În timpul dezvoltării pot exista conturi temporare pentru designeri, dezvoltatori sau client.
După lansare verificăm cine mai are nevoie de acces.
Conturile inutile trebuie eliminate sau dezactivate, iar administratorii trebuie să folosească parole solide. Pentru proiectele unde riscul justifică măsura, poate fi activată autentificarea suplimentară.
Eliminăm și instrumentele de test care nu mai sunt necesare.
Un mediu de staging trebuie protejat separat dacă rămâne online.
Lansarea este un moment bun pentru a documenta cine deține domeniul, hostingul, conturile externe și licențele importante.
Unele probleme apar abia după ce site-ul începe să primească trafic real.
Monitorizăm disponibilitatea și erorile importante. Verificăm mesajele și feedbackul clientului și corectăm eventualele situații care au scăpat în testare.
După această perioadă, proiectul intră în regimul normal de mentenanță și suport.
La Standard Web considerăm lansarea începutul perioadei de utilizare a website-ului, nu momentul în care încetăm să ne mai uităm la el.
Un proiect bine pregătit are nevoie de mai puține intervenții după publicare, dar verificarea post-lansare rămâne una dintre etapele importante ale procesului nostru de creare site-uri web.
