Svetainės atnaujinimo kontrolinis sąrašas B2B komandoms

Brangiausios svetainės atnaujinimo klaidos paprastai įvyksta dar prieš pradedant kurti dizainą. Šis sąrašas sudėlioja verslo, turinio, SEO ir techninius sprendimus teisinga tvarka.

Rhino Automotive svetainė studijos monitoriuje, šalia planšetė

Dauguma svetainės atnaujinimo sąrašų prasideda nuo spalvų, išdėstymo ir funkcijų. Iki tol jau būna praleisti keli sprendimai, nuo kurių priklauso, ar projektas pavyks. Atnaujinta svetainė gali atrodyti gerokai geriau ir vis tiek susilpninti žinutę, suklaidinti esamus klientus, prarasti naudingą matomumą paieškoje arba palikti komandai svetainę, kurios niekas nesugeba prižiūrėti.

B2B svetainė vienu metu yra ir pardavimo pokalbis, ir vieta, kur pirkėjas ieško įrodymų, ir techninis produktas. Būtent todėl, kad atnaujinimas laikomas vien vizualiniu perdažymu, tiek daug svetainių paleidžiama laiku ir nuvilia po pusmečio. Dvylika sprendimų žemiau padeda suformuluoti aiškesnę užduotį dar prieš prasidedant dizainui.

1. Apibrėžkite, ką atnaujinimas turi pakeisti

Vietoj „pagerinti svetainę“ įvardykite vieną verslo problemą, kurią galite išmatuoti. Svetainė pritraukia ne tas užklausas. Pirkėjai nesupranta pasiūlymo be skambučio. Nauja paslauga neturi aiškios vietos. Pardavėjai kiekviename pasiūlyme iš naujo rašo tą patį paaiškinimą. Prekės ženklas atrodo mažesnis nei darbai, kuriems jis atstovauja.

Pasirinkite vieną pagrindinį tikslą ir kelis papildomus rodiklius. Naudingi atskaitos taškai gali būti kokybiškos užklausos, užpildytos formos, demonstracijų prašymai, organinis srautas į nukreipiamuosius puslapius, laikas pagrindiniuose paslaugų puslapiuose arba tai, kiek kartų pardavėjams tenka aiškinti tą patį dalyką. Atnaujinimo neįmanoma įvertinti, jei sėkmė reiškia tik tai, kad komandai svetainė labiau patinka.

2. Užfiksuokite dabartinę padėtį

Prieš ką nors keisdami, užfiksuokite dabartinius duomenis. Išsaugokite svarbių puslapių analitiką, Search Console užklausas, dabartines pozicijas, atgalines nuorodas, formų konversiją, dažniausius įėjimo puslapius, įrenginių pasiskirstymą ir klausimus, kuriuos potencialūs klientai užduoda apsilankę svetainėje. Išsaugokite dabartinį svetainės žemėlapį ir nuskenuokite kiekvieną indeksuojamą adresą.

Tikslas ne išsaugoti kiekvieną puslapį, o žinoti, kas jau veikia. Vizualiai silpnas straipsnis gali atvesti kokybišką srautą. Nemadingas paslaugos puslapis gali atsakyti būtent į tą klausimą, kuris užbaigia sandorį. Be atskaitos taško naudingus dalykus lengva ištrinti, nes senoje navigacijoje jie neatrodė svarbūs.

3. Įvardykite pagrindinį lankytoją

Pagrindinis puslapis, parašytas visiems, virsta vestibiuliu su dvylika durų ir be registratūros. Nuspręskite, kieno sprendimą svetainė turi palengvinti. B2B įmonei tai gali būti įkūrėjas, rinkodaros vadovas, pirkimų komanda ar techninis vertintojas. Apsilankyti gali visi, bet pirmas ekranas negali būti skirtas visiems.

Užrašykite, ką pagrindinis lankytojas jau žino, ką bando nuspręsti, kas jį verčia dvejoti ir kokie įrodymai tą dvejonę mažina. Tai tampa praktiniu filtru žinutėms, navigacijai, projektų aprašymams ir raginimams veikti.

4. Susitarkite dėl žinutės prieš sąsają

Pirmas ekranas turėtų greitai atsakyti į tris klausimus: kas tai, kam tai skirta ir ką man daryti toliau? Jei komanda negali sutarti dėl šių atsakymų paprastu tekstu, vizualinis dizainas nesutarimą tik paslėps.

Pirmiausia sudėliokite žinučių hierarchiją, tik tada puslapių. Pradėkite nuo pagrindinio pažado, priežasčių juo tikėti, pasiūlymų, kurie jį įgyvendina, ir įrodymų kiekvienam pasiūlymui. Tada sąsaja gali dėlioti akcentus, o ne bandyti išgalvoti prasmę.

5. Peržiūrėkite kiekvieną turinio dalį

Kiekvienam esamam puslapiui priskirkite vieną sprendimą: palikti, pagerinti, sujungti, pašalinti ar peradresuoti. Patikrinkite, ar turinys tikslus, naudingas numatytam lankytojui, pagrįstas įrodymais ir susietas su kitu žingsniu. Tą patį padarykite su PDF failais, uždaru turiniu ir nuotraukomis, kurios gali gauti srauto ar nuorodų.

Čia išryškėja ir turinio spragos. Paslauga be projekto pavyzdžio, projektas be išmatuojamo rezultato ar techninis produktas be paaiškinimo netechniniam pirkėjui nėra išdėstymo problema. Trūkstamus įrodymus įtraukite į turinio rengimo planą.

6. Apsaugokite adresus ir paieškos matomumą

Prieš programavimą sudarykite adresų žemėlapį, kuriame kiekvienas senas adresas susietas su nauju. Kiekvienam vertingam senam adresui reikia tinkamos vietos naujoje svetainėje. Google rekomenduoja persikėlusiems puslapiams nuolatinius serverio peradresavimus, įspėja nesiųsti daugybės nesusijusių adresų į pagrindinį puslapį ir pataria peradresavimus išlaikyti bent metus.

Išsaugokite naudingas puslapių temas, metaduomenis, vidines nuorodas ir kanoninių adresų taisykles. Prieš paleidimą pašalinkite kūrimo metu naudotas noindex instrukcijas, pateikite naują svetainės žemėlapį, o jei keičiasi domenas, patvirtinkite abu domenus Search Console. Tikėkitės laikinų svyravimų, kol paieškos sistemos iš naujo nuskaitys svetainę. Perkėlimas yra procesas, o ne vienas mygtuko paspaudimas.

7. Numatykite kitą lankytojo žingsnį

Nuspręskite, ką turėtų daryti pasiruošęs lankytojas ir ką dar nepasiruošęs. Vienas gali pradėti projektą arba paprašyti demonstracijos. Kitas gali paskaityti projekto aprašymą, palyginti paslaugas ar išsisaugoti naudingą vadovą. Vienodas kontaktų mygtukas kiekvienam lankytojui ignoruoja tai, kaip žmonės apsisprendžia.

Formos ilgis turi atitikti sprendimo svorį. Prašykite tik tos informacijos, kurią žmogus tame etape pagrįstai gali pateikti, paaiškinkite, kas vyksta po pateikimo, ir įvardykite, per kiek laiko atsakysite. Konversijai dažniausiai labiausiai padeda aiškumas.

8. Nustatykite prieinamumo standartą

Prieinamumą nuo pradžių laikykite dizaino ir programavimo reikalavimu. WCAG 2.2 yra dabartinė W3C rekomendacija. Praktinis minimumas: logiškos antraštės, pakankamas kontrastas, aiškios nuorodos, valdymas klaviatūra, matomos fokuso būsenos, formos laukai su susietais pavadinimais, prasmingi alternatyvūs tekstai ir mažiau judesio tiems, kas nustatymuose jį išjungia.

Jei šie sprendimai priimami jau patvirtinus dizainą, atsiranda nereikalingų kompromisų. Prieinamumas taip pat pagerina svetainę žmonėms su mažais ekranais, lėtu ryšiu, laikina trauma ar nepažįstama sąsaja. Tai kokybės dalis, o ne atitikties sluoksnis, pridedamas pabaigoje.

9. Iš anksto susitarkite, kiek greita turi būti svetainė

Nuspręskite, kokia greita ir stabili turi būti svetainė, dar prieš tai, kai dizainas prisipildys didelės raiškos nuotraukų, vaizdo įrašų ir animacijų. Dabartiniai Google Core Web Vitals tikslai: LCP ne daugiau kaip 2,5 sekundės, INP ne daugiau kaip 200 milisekundžių ir CLS ne daugiau kaip 0,1, vertinant 75-ąjį apsilankymų procentilį.

Šie skaičiai nėra kūrybos apribojimas. Jie verčia priimti naudingus sprendimus: ekranui pritaikyto dydžio nuotraukos, iš anksto rezervuoti medijos matmenys, mažiau šriftų failų, apgalvotas judesys ir mažiau JavaScript, apkraunančio pagrindinę giją. Po paleidimo matuokite tikrų naudotojų duomenis, nes greitas nešiojamasis kompiuteris biuro Wi-Fi tinkle nėra jūsų auditorija.

10. Nuspręskite, kas už svetainę atsakingas po paleidimo

Įvardykite žmogų, atsakingą už publikavimą, tvirtinimą, analitiką, techninius atnaujinimus ir pasenusį turinį. Pagal tai ir kurkite turinio modelį. Tobula turinio valdymo sistema, kuria niekas nepasitiki, tik skatins ją apeiti. Lankstus puslapių konstruktorius be taisyklių atkurs tą patį nenuoseklumą, kurį atnaujinimas turėjo išspręsti.

Nustatykite, kiek mažiausiai puslapių tipų, komponentų ir redagavimo taisyklių komandai reikia. Mokymai, dokumentacija ir prieigos teisės yra projekto apimties dalis, o ne optimistiško perdavimo laiško tema.

11. Sudarykite paleidimo patikros planą

Testuokite visus puslapių tipus, ne tik pagrindinį puslapį. Patikrinkite turinį, nuorodas, formas, laiškų pristatymą, analitikos įvykius, sutikimo veikimą, metaduomenis, struktūrinius duomenis, peradresavimus, kanoninius adresus, svetainės žemėlapio pasiekiamumą, robots.txt taisykles, antraščių tvarką, navigaciją klaviatūra ir prisitaikantį išdėstymą.

Testuokite tikruose telefonuose ir bent tose naršyklėse, kurias pagal analitiką naudoja žmonės. Įsitikinkite, kad klaidų būsenos suprantamos ir kad serveris trūkstamiems puslapiams grąžina tikrus būsenos kodus. Kiekvienai paleidimo problemai priskirkite atsakingą žmogų ir terminą, kad paskutinė savaitė nevirstų bendra lentele be sprendimų.

12. Suplanuokite pirmas 30 dienų

Stebėkite Search Console indeksavimo ataskaitą, peradresavimų klaidas, formų pateikimus, analitikos įvykius, Core Web Vitals ir tai, kaip lankytojai naudojasi pagrindiniais nukreipiamaisiais puslapiais. Paklauskite pardavėjų, ar žmonės kreipiasi geriau supratę pasiūlymą ir ar pasikeitė pirkėjų abejonės. Klaidas taisykite greitai, bet nekeiskite visos svetainės dėl kelių neįprastų apsilankymų.

Suplanuokite peržiūrą po 30 dienų, kol projekto komanda dar pasiekiama. Palyginkite naujus duomenis su atskaitos tašku, užfiksuokite, kas pasikeitė, ir kitus patobulinimus paverskite planu su atsakingais žmonėmis.

Visas sąrašas viena eilute

Sėkmingas svetainės atnaujinimas juda tokia tvarka: verslo problema, auditorija, žinutė, turinys, struktūra, dizainas, programavimas, perkėlimas, matavimas. Kai tvarka apverčiama, sprendimus, kurie turėjo kilti iš strategijos, nulemia išvaizda.