Jums reikalingas svetainės atnaujinimas? Sveikiname, kad radote šį straipsnį. Šios išvados gali būti svarbus indėlis siekiant, kad jūsų atnaujinimas pasisektų ir pasiektumėte puikų rezultatą. Nes tai ne visada yra atvejis. Esu agentūros savininkas ir tau atskleisiu tuos dalykus, kurie leis tau mane ir panašius asmenis nustebinti puikiu darbu bei išvengti įprastų klaidų atnaujinimų metu. Bet pradėkime visiškai iš naujo.
Turinio sąrašas
Svetainės atnaujinimas yra esamoje svetainėje vykstantis pertvarkymas ir peržiūra. Jame gali būti keičiamas tiek dizainas, tiek turinys, tiek technologija. Svetainės atnaujinimo tikslas yra patobulinti svetainę ir pritaikyti ją dabartiniams reikalavimams.
Tam tikri išoriniai signalai įmonėse skatina skelbti tikslą „atnaujinimas“: Neseniai įdarbintas darbuotojas atneša puikias idėjas, naujas viršininkas ateina ir nori taip pat digitaliai padoriai pasisukti, konkurentas turi naują svetainę arba nuosprendį mažina pardavimus. Galbūt šefė netgi nemėgsta senos svetainės arba „Z“ karta nelaiko svetainės pakankamai „ūmaus“. Galbūt tai jums pažįstama. Taip pat tai, kad vėl laikas atnaujinti svetainę, kaip ir asmeniniai nuomonės, nėra pagrindas atnaujinimui.
Vis dėlto yra keletas geresnių priežasčių, kodėl įmonės ar organizacijos norėtų atlikti svetainės atnaujinimą. Pagrindiniai tarp jų yra:
- Senas dizainas ir/arba peržiūra: Sena svetainė gali sukelti įspūdį, kad įmonė nevykdo laiko ir nėra aktyvi. Naujas, modernus dizainas turėtų pagerinti įvaizdį. Net jei pasikeičia prekės ženklas arba įmonės tapatumas, dažnai norima atnaujinti svetainę, kad ji atspindėtų naują prekės žinutę.
- Geresnis naudotojo patirtis: Jei svetainės našumas yra blogas, tai gali sukelti didelį praleidimų procentą. Svetainės atnaujinimas gali būti skirtas pagerinti naudotojo patirtį ir palengvinti svetainės naršymą.
- Perjungimas į mobiliąją technologiją: Kadangi vis daugiau žmonių naudojasi svetainėmis mobiliais įrenginiais, svarbu užtikrinti, kad svetainė gerai veiktų skirtingo dydžio ekranuose ir įrenginiuose.
- Paieškos sistemos optimizavimas (SEO): Sena svetainė gali turėti problemas dėl paieškos sistemos našumo. Svetainės atnaujinimas suteikia galimybę padaryti draugiškus paieškos sistemoms pakeitimus, siekiant pagerinti matomumą paieškos sistemose.
- Turinio atnaujinimas: Jei įmonės informacija, paslaugos ar produktai pasikeičia, svetainė turi būti atnaujinta, kad būtų atspindėtos šios pakeitimai.
- Saugumo patobulinimai: Senos svetainės dažnai jautresnės dėl saugos rizikų. Svetainės atnaujinimas gali padėti pagerinti svetainės saugumą ir apsaugoti nuo internetinių atakų.
- Technologinis atnaujinimas: Naudojant pasenusias technologijas, svetainės veikla gali būti paveikta. Svetainės atnaujinimas gali suteikti galimybę pereiti prie naujausių interneto technologijų ir platformų.
- Barjero prieinamumas: Barjero prieinamumo gerinimas yra svarbus daugeliui svetainių siekiant užtikrinti, kad jos būtų prieinamos neįgaliesiems asmenims.
- Konkurencingumas: Norint išlaikyti žingsnį su konkurencija, svarbu turėti modernią ir našią svetainę. Svetainės atnaujinimas gali prisidėti prie konkurencingumo palaikymo ar didinimo.
- Analiziniai patobulinimai: Taikant geresnes analitikos priemones ir duomenų rinkimą įmonės gali geriau suprasti ir optimizuoti savo svetainės veiklą.
- Atitikimas teisinėms reikalavimams: Duomenų apsaugos, barjero prieinamumo ir saugumo srityse teisės aktai ir nuostatos nuolat keičiasi. Svetainės atnaujinimas gali būti būtinas, siekiant užtikrinti, kad svetainė atitiktų šiuos reikalavimus.
Šios priežastys gali pasireikšti atskirai arba kombinuotai ir gali skirtis pagal įmonės tikslus ir poreikius. Svetainės atnaujinimas dažnai yra strateginis sprendimas, siekiant pagerinti internetinę buvimą ir pasiekti įmonės tikslus. Jei išsamiai apsvarstysite aukščiau pateiktus punktus, taptų aišku, kad dauguma priežasčių gali būti įgyvendinamos mažesniais žingsniais ir nereikalauja didelio svetainės atnaujinimo.
Todėl išskiriame, kas yra atnaujinimas ir kas nėra: Naujas dizainas su esamu techniniu pagrindu yra greičiau gimdinė operacija. Atnaujinimas įvyksta tik tada, kai siekiant atnaujinimo tikrai vyksta pokytis naudotojui patiriant, veikimo būde ir techniniame pagrindu.
Atnaujinimas visada turėtų būti pateisinamas faktais (pvz., technologija įstrigo aklaviete ir jos nebeįmanoma atnaujinti), rodikliais, matavimais ir palyginimo duomenimis.
Štai mano pirmasis rekomenduojamas dalykas šiuo klausimu: Evoliucija prieš revoliuciją! Venkite atnaujinimo, kol tai yra būtina, ir stenkitės įgyvendinti visus iki šiol pristatytus atnaujinimo argumentus atskirai arba palaipsniui. Patobulinkite vieną dalyką, paleiskite jį, išanalizuokite, kas nutinka, tinkamai prisitaikykite arba eikite prie kito dalyko. Geriausias pavyzdys yra „Amazon“, kuris tikrai minimaliai keičiasi ir tobulėja bei jau daugelį metų atsisako didelių atnaujinimo pokyčių.
Atnaujinimas visuomet yra didelė rizika jūsų matomumui „Google“. Visi žiūri į patobulinimus, bet nedaugelis - į riziką. Aišku, vartotojo sąsaja tampa geresnė, teigiama vartotojo patirtis auga, techniškai vartotojas vėl atsiduria šiuolaikiškame lygyje. Vis dėlto: Jei jūsų verslo sėkmė priklauso nuo stipraus organinio matomumo, atnaujinimas yra paskutinis pasirinkimo būdas, ir jis turi būti sprendžiamas tik tada, kai jūsų skausmas dėl kombinacijos aukščiau minėtų priežasčių, kurios nėra išspręstos atskirais žingsniais, yra pakankamai didelis. Kodėl? Pažvelkite čia, kas įvyko po šių keturių svetainių atnaujinimų internetiniame matomum...
Planuokite savo perdizainavimą kruopščiai ir užtikrinkite sėkmingą įgyvendinimą, turėdami atliktų punktų sąrašą. Svarbiausia yra nustatyti du tikslus: išlaikyti savo interneto matomumą ir, antra, rasti būdų sukurti relanso metu pagrindą internetinio matomumo didinimui. Būtent tai šiame straipsnyje aptariama - jums pateikiamas perdizainavimo vadovas, kuris padės apriboti įsipareigojimus perdizainavimo metu ir gausite išties gerą darbo rezultatą su tvariais, organinius SEO sėkmes turinčiais potencialais.
Perdizainavimo maršrutas
Internetinio puslapio perdizainavimo planavimas turėtų būti atliekamas kruopščiai. Svarbu įtraukti šiuos žingsnius:
- Analizuoti esamą svetainę ir protokoluoti esamą būklę: Pirmiausia turėtumėte išanalizuoti esamą svetainę, kad nustatytumėte stiprybes ir silpnybes.
- Patirti tikslus: Internetinio puslapio perdizainavimo tikslai turi būti aiškiai apibrėžti. Tai gali apimti, pavyzdžiui, konversijos rodiklių pagerinimą, lankytojų skaičiaus didinimą arba perkėlimą į naują turinio valdymo sistemą su patobulinta turinio priežiūra ir priežiūra.
- Koncepcijos kūrimas: Remiantis analize ir tikslais bei konkurentų analize turėtų būti sukurtas puslapio perdizainavimo konceptas. Koncepcija turėtų apimti šiuos aspektus: dizainą, turinį, technologiją ir SEO/maketavimą.
- Vykdymas: Koncepcija tada įgyvendinama. Tai apima dizaino kūrimą, turinio kūrimą/pritaikymą ir techninių pakeitimų įgyvendinimą.
- Testavimas: Prieš svetainės paskelbimą ji turėtų būti kruopščiai išbandyta, kad būtų užtikrinta, jog ji veikia be klaidų. Tai apima ir nustatytą punktų sąrašą.
- Paskelbimas: Tada nauja svetainė bus paskelbta. Ji toliau gyvai testuojama, vertinama ir pritaikoma.
Tikslų ir perdizainavimo strategijos nustatymas
Preciziškai nustatykite, kokių tikslų siekia perdizainavimas. Tikslai gali būti (išskyrus jau minėtus priežastis):
- Vartotojo patirties pagerinimas
- Peržiūrėjimo aiškumo didinimas
- Turinio pasiūlos plėtra
- Dizaino modernizavimas
- Pajamų ir krepšelio aukščio didinimas
- Perėjimas prie kito CMS su lengvesne turinio priežiūra ir technine priežiūra
- Perspektyvinė lengvas praplėtimas ir atnaujinimų funkcionalumas.
Pasiūlymas: Po pirmųjų komandos kaip įmonės pažangos susitikimų - dar prieš pradedant pokalbius su įgyvendinimo agentūromis - kiekvienam projekto dalyviui rekomenduotina užrašyti savo perdizainavimo tikslus ant popieriaus arba įvesti į savo komunikavimo priemonę (pvz., „Slack“) įvesties langą. Jei visi vienu metu parodys savo nurodytus tikslus, būsite nustebinti, kaip skiriasi nuomonės, nors tikslai buvo aptarti pokalbiuose. Todėl svarbu raštu tvirtai užfiksuoti tikslus. Jei tikslus žinote tiksliai, jau ankstyvoje fazėje galite patikrinti per UI tipo modelį, ar jie buvo konceptualiai nagrinėti.
Perdizainavimo užduotis suteikia aiškumą dėl perdizainavimo užsakymo
Agentūra norėdama parengti pasiūlymą iš kliento reikalauja išsamios projekto aprašo. Įmonės dažnai turi „Word“ dokumentą arba PDF failą, kuriame mažiau ar daugiau išsamiai nubrėžtas planas. Tada vyksta apklausos arba rengiami seminarai, kuriuose agentūros geriau pabrėžia kliento skausmingas vietas, kad galėtų pateikti pasiūlymą. Dideliuose projektuose sukurtas perdizainavimo užduotis. Kuo išsamiau, tuo geriau.
Perdizainavimo užduotis yra dokumentas, kuris vaidina svarbų vaidmenį svetainės perdizainavimo procese. Ji padeda užfiksuoti reikalavimus, tikslus ir lūkesčius, susijusius su perdizainavimu raštu. Gerai parengta perdizainavimo užduotis padeda užtikrinti, kad visi suinteresuoti asmenys - ar tai būtų plėtros komanda, dizaino komanda arba klientas - aiškiai supranta, ką turi būti pasiektas per perdizainavimą. Tai taip pat yra pradinis taškas siekiant gerai apskaičiuoto ir privalomo pasiūlymo galininko agentūrai, kuri vykdo. Čia yra informacijos ir elementų, kurie dažniausiai būna perdizainavimo užduotyje:
- Tikslai ir paskirtis: Apibūdinamas pagrindinių perdizainavimo tikslų aprašymas, pvz., vartotojo patirties gerinimas, matomumo padidinimas paieškos sistemose ar CMS keitimas su dizaino atnaujinimu.
- Projekto apimtis: Aiškus apibrėžimas, kas yra įtraukta į perdizainavimą ir kas ne. Tai gali apimti puslapių skaičių, trečiųjų šalių įrankių integravimą ar turinio peržiūrą.
- Dizaino reikalavimai: Informacija apie norimą vizualinį svetainės dizainą, įskaitant maketus ir laikymąsi korporatyvinių dizaino gairių spalvų, šrifto rūšių ir atvaizdų.
- Funkciniai reikalavimai: Norimų svetainės funkcijų ir sąveikų, tokių kaip kontaktinių formų, paieškos funkcijų, el. prekybos funkcijų ir kt., atskirstymas.
- Techniniai reikalavimai: Specifikacijos technologijoms, naudojamoms perdizainavimo metu, pvz., turinio valdymo sistemos (CMS) pasirinkimas ar tam tikrų funkcijų įgyvendinimas. Taip pat šių laikanty vėlesniam paveikslui ir grafinio formato naudojimo (WebP, AVIF, SVG) įgalinimas.
- Rankinis ir automatinis turinio redagavimo atnaujinimų ir revizijų kopija.
- Turinio reikalavimai: Aiškūs reikalavimai siekiant peržiūrėti, atnaujinti ar kurti iš naujo turinį, įskaitant tekstą, atvaizdus, vaizdo įrašus ir kitus medijos formatus. Su meta duomenimis ir struktūrizuotus duomenis susijusi tvarka.
- SEO reikalavimai: apie tai daugiau sekančiame straipsnio skyriuje.
- Terminas ir Meilenšteinai: Laiko planas, kuriame nustatyti planuojami perdizainavimo pradžios ir pabaigos terminai bei svarbūs etapai.
- Biudžetas: Informacija apie biudžetą perdizainavimui, įskaitant išlaidas dėl dizaino, kūrimo, talpinimo ir galininių trečiųjų šalių paslaugų.
- Kokybės užtikrinimas testavimo įrankiais: Testų ir kokybės kontrolės procedūrų aprašymas, kurios turėtų būti atliktos perdizainavimo metu, kad būtų užtikrinta, jog svetainė veikia be priekaištų.
- Priežiūros ir palaikymo reikalavimai: Reikalavimai dėl nuolatinės svetainės priežiūros ir palaikymo po perdizainavimo.
Gerai struktūrizuotas reikalavimų specifikacija yra lemiamas veiksnys, kad būtų išvengta nesusipratimų, projektas būtų efektyviai valdomas ir užtikrintas visų suinteresuotųjų lūkesčių įvykdymas. Tai tarnauja kaip projektui vadovaujančioji linija ir nuoraminis dokumentas visai projekto komandai, prisidėdamas prie svetainės atnaujinimo sėkmės užtikrinimo.
Kai planavome Pakeisti svetainės TutKit.com karkasą iš CodIgniter į Laravel, mūsų reikalavimų specifikacija apėmė 220 puslapių - neįtikimą perspektyvą agentūrai kovoti su tuo.
Pastaba: Šiame straipsnyje neišsamiai neaptariamas koncepcija, dizainas, funkcionalumas ir naudojama technologija. Naujoji svetainė tikrai bus graži. Didžiausia pavojus atnaujinimo metu iš tikrųjų slypi ne techninės vartotojų patirties ir OnPage kokybės blogėjime dėl trūkstamų 301 nukreipimų ir kt., kas galiausiai sukelia reitingo ir matomumo praradimą. Kad būtų pašalintas šis pavojus, šiuo atnaujinime bus teikiama pirmenybė projektų sėkmės užtikrinimui iš vartotojo patirties ir SEO perspektyvos.
SEO reikalavimų apibrėžimas naujai svetainei
Kliento reikalavimo pristatymas arba išsamus reikalavimų specifikacija jau nustato, kas yra pageidaujama iš dizaino, turinio, funkcionalumo ir techninės perspektyvos bei yra pagrindas, kad agentūra galėtų parengti apskaičiavimą.
Siekiant svetainės atnaujinimo tikrinimo sąrašui užtikrinti projektų sėkmę privalo būti aiškiai įvertintos atskiros nuostatos iš SEO perspektyvos. Iškyla specialūs SEO reikalavimai dėl:
- keičiančiosi URL struktūros (URL nukreipimo žemėlapis!) ir keičiančiose nuorodų keliuose
- keičiančiosi navigacijos (svarbu dėl vidinio susiejimo ir nuorodų hierarchijos)
- keičiančiosi technologijos (tinklavietės valdymo sistema, JavaScript karkasas, serveris, …)
- keičiančio turinio (galimų gerai reitinguojamų puslapių matomumo nuostatų)
Puslapiai gerai reitinguojasi Google dėl savo turinio atitikties, todėl svarbūs klausimai, ar turinys keičiasi ar sujungiamas, ar turinys išnyksta ir/arba naujas turinys pridedamas? Ar keičiasi kategorijų ar puslapių turinio struktūra? Iš šių punktų turi būti išplėtotos SEO reikalavimų nuostatos, kurios turi būti įtrauktos į atnaujinimo tikrinimo sąrašą.
Ar senų turinio metaduomenų tiekimas taip pat perkeltas ir ar jie keičiasi? Kaip atliekama turinio priežiūra redagavimo metu ir ar puslapiai sujungti su struktūrizuotais duomenimis?
Ar egzistuojantys ar nauji paveikslėliai užtikrinti šiuolaikiniais tinklalapio paveikslėlių formatuo pratęsimais (WebP/Avif) ir ar tikrinama paveikslėlių SEO atsargiai su kalbančiais URL mažosiomis raidėmis, t. y. vietoj 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.
Taip pat reikia atkreipti dėmesį, kad Paveikslėlių failai per struktūrizuotus duomenis (ImageObject) ir <meta>-miniatiūros perduodami Google, siekiant padidinti paveikslėlio įterpimo į paieškos snippetus tikimybę ir jo įrašymą į Google paveikslėlių sąrašą.
CMS keitimas atnaujinimo metu paprastai sukelia keičiamą URL struktūrą ir naujus nuorodų kelius. SEO perspektyvos tai yra kontraproduktyvu ir turėtų būti gerai apgalvota.
Taip pat įdomu šiuo klausimu yra, kaip leidžiama gerinti naudotojų signalai. Taip, pavyzdžiui, turinio puslapiuose gali būti įdėti vaizdo klipai, aiškinamieji ir pagalbos vaizdo klipai. Paspaudžia naudotojas, kuris atkeliauja iš „Google“ į šalutinį puslapį, ant vaizdo ir žiūri jį, padidėja laikas, kai naudotojas buvo puslapyje (geras naudotojų signalas), grįžimas dar taip pat pagerėja (geras naudotojų signalas).
Taip pat reikėtų patikrinti, kaip turinio skiltys yra integruojamos į puslapius, kurie atitinka Google reikalavimus naudingam turiniui ir E-E-A-T principą.
„Google“ požiūriu „Naudingas Turinys“ yra turinys, kuris yra svarbus ir naudingas naudotojams. Jis atsako į naudotojų klausimus išsamiai ir informatyviai, siūlo sprendimus problemoms ir teikia vertę, viršijančią grynai reklamines žinutes.
Čia yra keli pavyzdžiai naudingam turiniui:
- Vaizdo pamokos ir instrukcijos: Šis turinys padeda naudotojams išmokti naujų užduočių ar spręsti esamas problemas.
- Apžvalgos ir palyginimai: Šis turinys padeda naudotojams rasti tinkamiausią produktą ar paslaugą.
- Naujienos ir atnaujinimai: Šis turinys laiko naudotojus informuotais apie dabartinius įvykius ir tendencijas.
- Infografikai ir diagramos: Šis turinys padeda vizualizuoti sudėtingus duomenis ir informaciją.
- Blogų įrašai ir straipsniai: Šis turinys suteikia išsamesnį įžvalgą į konkretų klausimą.
„Google“ naudoja įvairius signalus, norėdama atpažinti naudingą turinį. Tai apima, bet neapsiriboja tuo:
- Naudotojo elgsena: „Google“ stebi, kaip naudotojai sąveikauja su turiniu, pvz., kiek laiko jie praleidžia puslapyje, kiek kartų jį bendrina ir kiek kartų įvertina.
- Kokybės signalai: „Google“ vertina turinio kokybę remdamasis faktoriais, tokių kaip aktualumas, pilnatvė ir naujumas.
- Naudotojų atsiliepimai: „Google“ taip pat atsižvelgia į naudotojų atsiliepimus, pvz., įvertinimus ir komentarus.
- Įvertindami šiuos signalus, tinklalapių administratoriai gali padidinti savo šansus, kad jų turinys būtų laikomas naudingas.
EEAT principas yra „Google“ sukurtas koncepcija, vertinanti svetainių ir internetinių turinių kokybę. Tai reiškia Ekspertizę, Patirtį, Autoritetą ir Patikimumą, tai yra Ekspertizė, Patirtis, Autoritetas ir Patikimumas.
- Ekspertizė susijusi su žiniomis ir asmenų patirtimi, kurie kuria turinį. „Google“ ekspertizę vertina remdamasis veiksniais, tokiais kaip išsilavinimas, darbo patirtis ir apdovanojimai.
- Patirtis patvirtinama, kai turinys sukurtas ir su tam tikra patirtimi, pvz., pagrįstas realiu produkto naudojimu, realiu vietos apsilankymu ar patirties aprašymu asmeninis?
- Autoritetas susijęs su svetainės ar internetinio turinio reputacija ir gerbimu. „Google“ autoritetą vertina remdamasis veiksniais, tokiais kaip atgaliniai ryšiai, socialinių tinklų veikla ir vartotojų vertinimai.
- Patikimumas reiškia svetainės ar internetinio turinio patikimumą ir patikimumą. „Google“ patikimumą vertina remdamasis veiksniais, tokiais kaip privatumas, saugumas ir skaidrumas.
Kokios SEO reikalavimai yra susiję su esamomis ir naujomis savybėmis fointendo ir užpakalio atžvilgiu? Šiame kontekste apžvelgiama:
- Pervestumo galimybė (reikalingas turinys turėtų būti matomas ir pervestumas neturint JavaScript)
- Svetainės tikslo aiškumas ir aiškumas dėl veiksmo, kurį nori atlikti „aukščiausios kokybės klientas“ svetainėje
- Dubliuoto turinio vengimas pvz., automatizuotos kategorijų puslapiai ar puslapių dubliai dėl variantų straipsnių
- Aukšto puslapio greičio užtikrinimas vengiant pernelyg daug JavaScript ir CSS failų, naudojant modernius vaizdo formatų (WebP/AVIF)
Šie SEO reikalavimai turi būti įtraukti į projekto santrauką ar į užduočių sąrašą, tačiau taip pat turėtų būti įtraukti į testinį įrankių sąrašą ar kaip IST-SOLL palyginimas projekto kokybės užtikrinimui ir papildomai kaip agentūros paslaugų priėmimo kriterijus. Apie tai žemiau.
Vidinių ir išorinių projekto dalyvių nustatymas
Nustatykite projekto dalyvius - čia iš kliento arba svetainės savininko perspektyvos:
- Kas atsakingas už projektų vadovavimą ir priima galutinius sprendimus?
- Kas atsakingas už agentūros koordinavimą ir komunikaciją su klientu arba agentūra?
- Kas atsakingas už vidinį projekto valdymą?
- Kas viduje ruošia turinį ir pasiruošimą agentūrai?
- Kas vykdo vartotojo patirties dizainą?
- Kas vykdo kūrimą?
- Kas agentūrai reguliariais intervalais praneša klientui?
- Kas atsakingas už agentūros ar kliento pusi testavimą ir kokybės užtikrinimą?
- Ar įtrauktas išorinis konsultantas (pvz., SEO ar teisiniai reikalavimai)?
- Kas leidžia užduotis? Kas patikrina užduotis po tvarkymo sistemoje?
- Kam ir kokiu metu reikia pranešti (darbuotojai, klientai, partneriai, reklamos kampanijų tvarkytojai, ...)?
Pasirinkus išorinius projekto partnerius, svarbūs keturi aspektai
- Ar agentūra įgyvendino vieną ar daugiau šios rūšies projektų? Ar yra Referencijos? Ar yra klientų atsiliepimų ir ar galimas klientų atsiliepimų pokalbis su agentūra - tai rekomenduojama dideliuose individualių kūrimų atveju?
- Ar su pasiūlymo ir techninės įgyvendinimo paslaugomis (CMR/parduotuvės sistema/amlapis) jau yra įgyvendintos visos reikalavimai, susiję su atnaujinimu? Ar yra individualūs funkcionalumai ar reikalavimai, kurie turi būti papildomai sukuriami (taip pat naudojant programinę įrangą ar modulius)? Ar pasiūlyme yra tam tikros paslaugos, kurios yra išskirtos arba pažymėtos vėlesniam laikotarpiui, bet kurios yra lemiamos projekto sėkmės? Svarbu užtikrinti, kad neatsirastų naujų problemų, kurios būtų didesnės nei tikrasis atnaujinimo priežastis.
- Ar atitinka įgyvendinanti agentūra ar paslaugų teikėjas tiek komandos dydžio, tiek regioninio buvimo vietos ir darbuotojų pašalinimo (galimos patikrinimo įmonės per Kununu atsiliepimų būdai) ir tai ilgainiui atitinka įmonės poreikius?
- Ar yra tiesioginis kontaktas su įgyvendinimu vykdančia dizaino ir kūrimo komanda? Svarbu susipažinti su faktine, įgyvendinimu vykdančios agentūros komanda. Gerai nusiteikę ir dangų pažadantys pardavimų profesionalai gali gauti užsakymą ir vėliau nebeturės įgaliojimų. Todėl tinkama susisiekti su įgyvendinimo komanda.
Keturi patarimai savo nesaugumui šiuo aspektu
- Kaip klientas norėčiau atkreipti dėmesį į paslaugų teikėjo naudojamą technologiją. Ko siūlo pasiūlyme, tiesiog paieškokite „CMR + trūkumai“ ar „CMS + patirtys“. Turėtumėte žinoti, į ką tiksliai sutinkate įsipareigojimams. Pritaikytas atviro kodo sprendimams laikytis. Suprantu, tai ne visada įmanoma. Geriausiai pasirūpinti, kad būtų kuo daugiau kūrėjų bendruomenės prie pasirinktos technikos, kad galų gale nenusileistumėte prie agentūros savo sprendimo, kurį gali tvarkyti tik jūsų agentūra, kas vėliau tam tikru būdu susilpnins jus.
- Pagrindinis dėmesys turėtų būti skiriamas tam, kad galėtumėte gauti neribojamus naudojimo ir redagavimo teises prie paslaugų. Tokiam atvejui visada turėtumėte turėti teisę vidiniams ar išoriniams tobulinti svetainę. Toks nuostatas turi būti įtrauktas į sutartį.
- Jeigu jūsų įmonė turi techninių žinių darbuotojų, kuriuose yra sistemos administratoriai, programuotojai ar panaši būklė, būtų gerai pats pastatyti GIT versijų kontrolės sistemai sutarties valdymui ir JIRA (ar panašų įrankį) projektų valdymui arba atsekamųjų duomenų valdymui sukurti savo paskyroje. Tada atliekate visus agentūros atliktus darbus.Erą, kur kuo didesnis projektas, tuo didesnis jis gali gresbti ir skaudėti. Tai gera, jei yra reikšmingi galutinių prieigos ir paskyrų prie metodu atsižvelgiant. Bet aišku, šis rekomendacija techniškais požiūriais galioja tik kelioms klientams.
- Kartais taip yra, kad agentūros tiesiog siūlo svetainės talpinimą klientams. Mes patys nesame jo gerbėjai, nes tai padidina priklausomybę klientų santykiuose, kita vertus sakome sau, kad Tinklavietės talpyklos teikėjai geriausiai tinka tinklių talpinimui, nes jie yra specializuoti šiose srityse. Turėjome netgi patys suklijuoti serverių ir valdyti labai daug personalo ir laiko išteklių. Mes grįžome. Dabar mūsų sistemos veikia debesijos serveriuose vienoje iš didžiųjų vokiečių tinklo talpyklos ir mes laimingi. Kreipkitės į tarnybas, kuriose jau yra tinklavietės atsarginiai kopijavimo serveriai, kurie gali būti įvykdyti poromis paspaudimais.
Laiko trukmės ir paleidimo datos nustatymas
Relaunch vykdomas keleto projektų etapais. Remiantis mūsų agentūros patirtimi, šie etapai gali būti:
- Dabartinė būsena fiksuojama (per bandymo įrankius, tačiau taip pat raštu su pastebėjimais, kas klientui gerai veikia ir kur reikia pagerinti)
- Tyrimų faza su konkurentų analize ir sprendimų/įkvėpimo paieška
- Struktūros koncepcija
- Naudotojo sąsajos dizainas
- Frontend ir Backend plėtra
- Duomenų perkėlimas arba turinio importavimas (automatiškai/arba rankiniu būdu)
- Struktūriniai ir turininiai turinio optimizavimai (tekstas ir paveikslai) & SEO etapas
Dėl to projektų etapai persikloja, nes kūrimo procese įsitraukia nauji projektų dalyviai.
Svarbu nustatyti laiko trukmę kiekvienam projektų etapui ir susiderinti su dalyviais.
Ar agentūra kuria klientui, jei projektas didesnis, savo Slack kanalą greitesniai komunikacijai?
Čia vienas patarimas: būtų gerai, jei agentūra jau labai ankstyvoje stadijoje dirbtų su kliksnančiais prototipais, pavyzdžiui, jau struktūrinės koncepcijos etape, ir dar labiau dėl naudotojo sąsajos dizaino pristatymo ir patikrinimo. Taip klientai geriau jaučiasi svetainės patirties atžvilgiu. Paprastos JPG ar PNG bylos kaip maketo pasiūlymas šiandien nėra laikui būdinga. Tai turėtų būti kliksnami prototipai, sukuriami su Sketch, Figma, Adobe XD arba kitu profesionaliu įrankiu.
Šioje ankstyvoje stadijoje pakeitimai lengvai įgyvendinami. Jei svetainės funkcijos ir skyriai jau sukurti, pakeitimai yra žymiai sudėtingesni ir gali lemti galimus papildomas derybas, kurios visiškai nepritraukia.
Čia yra matoma, kaip atrodo toks prototipas mobiliajam naudotojo sąsajos dizainui su paspaudimų takais peržiūros:
Reikia išsiaiškinti, nuo kurios stadijos klientas yra Beatatesterys! Ar yra prieiga prie Agentūros bilietų sistemos apskritai?
Taip pat turėtų būti raštu apibrėžta, kad agentūros ataskaitos klientui būtų pateikiamos tam tikra dažniu. Pavyzdžiui, kiekvieną penktadienį gali būti gauta ataskaita el. paštu apie dabartinį darbų progresą, būtinas atsiliepimo ciklas ar pageidavimai dėl papildomų darbų. Tai taip pat yra patarimas iš mūsų agentūros patirties: geriau neleisti klientui nepatikrinto likti savaitgalį. Jis tik atneštų kvailų idėjų. Geriau gerai informuoti, kas įvyko ir kas laukia ateinančią savaitę. Skaidrumas padeda, kad visi liktų patenkinti dalyvaujantys.
Paleidimo datos taip pat turėtų būti nustatytos. Darbo tęstinumas prisitaiko prie prieinamo laiko jo atlikimui. Kitaip tariant, kuo daugiau laiko yra skirta užduočiai atlikti, tuo daugiau laiko reikalauja, nepriklausomai nuo faktinės sudėtingumo ar darbo apimties. Planuota užbaigimas turi būti įtrauktas į sutartį. Terminas gali būti pažeistas su sutarties bauginimu. Vadovaudamasi gairėmis, sutarties baudos pridedamos pirmadienį (0,2% užsakymo sumos už kiekvieną darbo dieną pavėluotai atliktą darbą ir iki 5% užsakymo sumos). Įgyvendinus sutarties baugas galima nereikia jų taikyti klientui, bet suteikia jums galimybę išvengti papildomų užsakymų kaip kompensavimo iš agentūros.
Svarbu: Nepaleidžiama sekmadienį. Net ne tarp švenčių ar pagrindinės įmonės darbo laikas. Mes tikrai rekomenduojame dideliems atnaujinimams naudoti nakties valandas nuo sekmadienio iki pirmadienio, ypač jei keičiasi IP, kadangi daugumoje tiekėjų DNS parametrai darbą atliko pirmadienį, dažnai jau vėlyvą ryto, jei DNS įrašai buvo keičiami nakties valandomis. Taigi, faktiškai likę 4,5 darbo dienos gyvų bandymų ir sutrikimų taisymo atveju.
Esamos jūsų svetainės būklės protokoliazas
Prieš pradedant darbus, reikia nustatyti esamą būseną. Esamoje būsenoje fiksuojamas techninių matavimų rezultatas pagal parametrus. Dešinėje pusi galite įvesti tikslinius rodiklius:
Kas? | Trumpas aprašymas | Bandomasis įrankis | Esama (Šiuo metu) | Turėtų būti (Tikslinis rodiklis) |
Tech. & Meta | Puslapio pavadinimas, antraštės, meta-duomenys, alternatyvūs tekstai, … | Seobility | ||
Struktūra | Nukreipimai, klaidingi nuorodos, svetainijos?(nežinomas žodis)Seobility | | ||
Turinys | Raktinių žodžių atitikimas, klaidų taisymas, per mažai tekstų, … | Seobility | ||
Paveikslų SEO | Kalbantys URL, modernios internetinio formato bylos (WebP/AVIF), <meta>-miniatūros | be | ||
OG-duomenų įgyvendinimas | Open Graph-duomenys socialiniams tinklams | Open Graph Checker | ||
Struktūruoti duomenys (Markup Schema) | Schema-Markup / struktūruoti duomenys | Schema.org | ||
PageSpeed Pradžios puslapis | PageSpeed mobiliajam/vaizdo pločiui | PageSpeed Insights | ||
PageSpeed Našumo puslapis | PageSpeed mobiliajam/vaizdo pločiui | PageSpeed Insights | ||
PageSpeed Kategorijos puslapis | PageSpeed mobiliajam/vaizdo pločiui | PageSpeed Insights | ||
PageSpeed Produktas puslapis | PageSpeed mobiliajam/vaizdo pločiui | PageSpeed Insights | ||
PageSpeed Tinklaraščio puslapis | PageSpeed mobiliajam/vaizdo pločiui | PageSpeed Insights | ||
Prieinamumas pagal puslapio tipus | Prieinamumas užtikrintas su sutrikusiomis naudotojų grupėmis | Accessibility Checker und/oder wave.webaim.org | ||
Hreflang checken | Daugiakalbių svetainių atveju | Hreflang Validator | ||
Saugumo antraštės | Pasitikėjimas & Saugumas | SecurityHeaders.com | ||
Sveikatos patikrinimas | Pasitikėjimas & Saugumas | Security Audit (Astra) | ||
Naršyklės & Įrenginiai testavimas | Edge, Firefox, Safari, Chrome stalinėms & mobiliesiems įrenginiams, iOs & Android | Dev-Tools / Lambdatest | ||
Trintukų taisyklė & DSGVO | Consent-Cookie-Policy & DSGVO-Suderinimas | Cookie Metrix | ||
Kratai: Svetainės būsena | Robots.txt ištrauka, DNS rezoliucija, serverio jungtis | Google Search Console | ||
Kratymo statistika | Užklausos, Atsisiuntimo dydis, vidutinis atsakymo laikas | Google Search Console | ||
Klavišų spaudimai SERPs | Pagal laiko tarpą (mėnesį/90 dienų, ...) | Google Search Console | ||
Įspūdžiai SERPs | Pagal laiko tarpą (mėnesį/90 dienų, ...) | Google Search Console | ||
Vidutinis CTR SERPs | Pagal laiko tarpą (mėnesį/90 dienų, ...) | Google Search Console | ||
Vidutinė SERP pozicija | Pagal laiko tarpą (mėnesį/90 dienų, ...) | Google Search Console | ||
Pagrindinio tinklo vitalijos išlikimas | Rangavimo faktorius vartotojų patirties atžvilgiu (PageSpeed, mobilioji optimizacija, ...) | Google Search Console | ||
Ivertinkite GA4 duomenis | Laiko leidimas, puslapiai/lankytojai, ... | Google Analytics 4 | ||
Verčių konversijos norma | Rezervavimo svetainėms ar prekybos vietoms | Savo
Sąraše rasite mūsų dažnai naudojamą Seobility SEO įrankį, skirtą tikrinti OnPage veiksnius, į kurį taip pat išleidžiau SEO mokymą. Yra daug panašių įrankių, tokie kaip Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog ir pan. Su SEO įrankiu svarbu ypač identifikuoti ir ištaisyti įprastus OnPage klaidas. Čia būtent trys pagrindiniai sritys, Techninės ir Meta informacijos, Struktūra ir Turinys, kuriais Seobility grindžia savo analizes. Panašia forma ši informacija pateikta ir kituose SEO įrankiuose. Svarbu, kad visada būtų atliekamas pilnas patikrinimas, tai yra, nuskaitytos VISOS puslapiai, o ne tik pradinis, ir taip pat, kad būtų nustatomas reikšmės arba klaidų vertės dabartiniui būsenai, ir tikslinė vertė, kurią reikia pasiekti po optimizavimo. Seobility atveju norima, kad reikšmė būtų 90 arba aukštesnė. Taip pat rasi ir alternatyvių įrankių kitais tikslais. Svarbu, kad būtų naudojamas bent vienas įrankis norint užtikrinti išskirtinius duomenis. Štai, pavyzdžiui, mūsų dabartinė vertė OnPage kokybei: Naudotojų signalai gali būti statistiškai matuojami naudojant Google Analytics 4 vertindamas rodiklius, tokius kaip Bounce rate, Puslapiai/naudotojas, Susilaikymo trukmė ir kt. Jei Google Analytics ar kitas analizės įrankis naudojamas duomenims pateikti atitinkamai, šie duomenys turėtų būti atsižvelgti į esamą būklę. Turėtų būti sukurtas atgalinio ryšio nuorodų sąrašas, kuris pvz., gali būti nemokamai sugeneruotas čia: https://www.seobility.net/de/backlinkcheck/ Be to, turėtų būti saugoma senoji sitemap.xml, taip pat Pilnas atsarginis kopijavimas svetainės. Visi reikšmingi puslapiai taip pat turėtų būti perkelti sąrašu į Google lapą, kuris sudaro pagrindą URL-redirect žemėlapiui. Tokį CSV sąrašą lengvai galima eksportuoti į SEO įrankį, pvz., Seobility. URL-redirect žemėlapyje atsižvelgta į visus reikšmingus puslapius ir per išorinius atgalinius ryšius susietus puslapius (žr. atgalinio ryšio nuorodų sąrašą), kurie vėliau turės būti nukreipti dėl besikeičiančių puslapių URL. Dingusius URL būtina nukreipti į naujus, atitinkančius senus URL. Svarbu vengti nukreipimo grandinių! Seni, dar egzistuojantys nukreipimai turi būti tiesiogiai nukreipti į naują galinį URL. Taip pat, atsižvelgti į PDF failus ir paveikslus, į kuriuos yra nuorodos, kad šie būtų tinkamai nukreipti ir nevirstų į 404-ąjį nuorodą. Nukreipimai kuriami kaip 301-nukreipimai, pagrįsti URL-redirect žemėlapiu .htaccess, per Redirect-Maps naudojant Vhost konfigūraciją arba duomenų bazės sprendimą. Klientas turėtų galėti pats prižiūrėti juos. Be to, svarbu, kad nukreipimai būtų ilgalaikiai. Pre-relansavimo patikrinimo sąrašas:Kai vartotojo sąsajos dizainas patvirtintas ir agentūra yra kūrimo etape, šis chronologiškai iki relansavimo dienos išvardina svarbiausius punktus:
|