Veebipoodide, broneerimis- ja ettevõtete veebisaitide uuendamise kontrollnimekiri

Sul on ees ootamas ümberkujundamine? Õnnitlused, et leidsid selle artikli. Järgmised selgitused võivad olla sinu jaoks otsustava tähtsusega, et su ümberkujundamine õnnestuks ja saavutaksid suurepärase tulemuse. Sest see pole alati nii. Olen agentuuri omanik ja avaldan sulle täpselt seda, mis võimaldab sul mind tüüpidega nagu mina äärmiselt hästi tööle panna ja vältida tavapäraseid vigu ümberkujundamistel. Alustame aga otsast peale.

Veebisaidi ümberkujundamine on olemasoleva veebisaidi ümberkujundamine ja üle vaatamine. Sealjuures võivad muutuda nii disain, sisu kui ka tehnoloogia. Veebisaidi ümberkujundamise eesmärk on parandada veebisaiti ja kohandada seda praeguste nõudmistega.

Teatud välised tegurid panevad ettevõtetes aluse "ümberkujundamise" eesmärgile: hiljuti tööle võetud töötaja toob kaasa suurepäraseid ideid, uus juht tuleb ja soovib ka digitaalselt korralikult tolmu pühkida, konkurendil on uus veebisait või müügitulu langeb. Võib-olla ei meeldi ettevõtte juhi abikaasale vana sait või põlvkonna Z jaoks pole veebisait piisavalt "lite". Sa tead seda ehk. Ka see, et on jälle aeg uue veebisaidi jaoks ning isiklikud arvamused pole põhjuseks ümberkujundamiseks.

Kuid on mõned paremad põhjused, miks ettevõtted või organisatsioonid soovivad veebisaidi ümberkujundamist teha. Nende hulgas on järgmised põhjused:

• Vananenud disain ja/või kaubamärgi uuendamine: Vananenud veebisait võib jätta mulje, et ettevõte ei käi ajaga kaasas või pole enam aktiivne. Seega peaks värske, kaasaegne disain parendama ettevõtte mainet. Ka siis, kui kaubamärgi kuvand või ettevõtte identiteet muutub, soovitakse sageli veebisaiti ümber kujundada selleks, et uut brandidesõnumit peegeldada.
• Parem kasutajakogemus: Kui veebisaidi kasutajasõbralikkus on kehv, võib see viia kõrge hüpatesageduseni. Ümberkujundamine võib aidata parandada kasutajakogemust ja muuta veebisait lihtsamini navigeeritavaks.
• Mobiilne optimeerimine: Kuna üha rohkem inimesi pääseb veebisaitidele juurde mobiilsete seadmete kaudu, on oluline tagada, et veebisait toimib erinevatel ekraanisuurustel ja seadmetel sujuvalt.
• Otsingumootori optimeerimine (SEO): Vananenud veebisaidil võivad tekkida probleemid SEO-tulemuslikkusega. Ümberkujundamine pakub võimalust teha SEO-sõbralikke muudatusi ja parandada nähtavust otsingumootorites.
• Sisu ajakohastamine: Kui ettevõtte teave, teenused või tooted muutuvad, tuleb veebisait ajakohastada nende muudatuste peegeldamiseks.
• Julgeoleku parandused: Vanemad veebisaidid on sageli vastuvõtlikumad turvariskidele. Ümberkujundamine võib aidata parandada veebisaidi turvalisust ja kaitsta küberrünnakute eest.
• Tehnoloogiline ajakohastamine: Vananenud tehnoloogiate kasutamine võib mõjutada veebisaidi jõudlust. Ümberkujundamine võib pakkuda võimalust üle minna kaasaegsetele veebitehnoloogiatele ja -platvormidele.
• Barjääritus: Barjääriparandus on paljude veebisaitide jaoks oluline küsimus, et tagada nende juurdepääsetavus puuetega inimestele.
• Konkurentsivõime: Konkurentsi sammu pidamiseks on oluline omada kaasaegset ja tõhusat veebisaiti. Ümberkujundamine võib aidata säilitada või suurendada konkurentsivõimet.
• Analüütilised parandused: Parematest analüütikatööriistadest rakendamine ja andmete kogumine võimaldab ettevõtetel paremini mõista ja optimeerida oma veebisaidi jõudlust.
• Vastavus õiguslikele nõuetele: Andmekaitse, barjäärituse ja turvalisuse valdkonna seadused ja eeskirjad muutuvad regulaarselt. Ümberkujundamine võib olla vajalik, et tagada veebisaidi vastavus nendele nõuetele.

Need põhjused võivad esineda üksikult või kombinatsioonis ning varieeruda sõltuvalt ettevõtte eesmärkidest ja vajadustest. Veebisaidi ümberkujundamine on sageli strateegiline otsus, et parendada online kohalolekut ja saavutada ettevõtte elevkirge. Kui vaadata ülaltoodud punkte eraldi, siis saab selgeks, et enamik põhjusi saab rakendada väiksemate sprintsidena ning ei vaja suurt ümberkujundamist.

Eristame seega, mis on ümberkujundamine ja mis mitte: Uus disain olemasoleva tehnilise alusega on pigem igapäevane elukorraldus. Ümberkujundamine toimub alles siis, kui ümberkujundamise eesmärgiga toimub tõeline muutus kasutajakogemuses, funktsionaalsuses ja tehnilises aluses. 

Ümberkujundamine peaks alati põhinema faktidel (nt tehnika on tupikteel ja seda ei saa enam uuendada), numbrites, mõõtmistes ja võrdlusandmetel.

See on minu esimene soovitus selles punktis, mida sooviksin jagada: Evolutisoon enne revolutsiooni! Vältige ümberkujundamist nii kaua kui võimalik ja proovige kõik punktid, mis seni ümberkujundamiseks esitatud on, rakendada ükshaaval või järk-järgult. Parandage ühte asja, viige see kasutusse, analüüsige, mida juhtub, kohandage uuesti või minge järgmise punkti juurde. Parim näide on Amazon, kes muutub ja paraneb tegelikult minimaalselt ning on suurte ümberkujundusmuudatusteta juba aastaid. 

Ümberkujundamine on alati suur oht sinu nähtavusele Google'is. Kõik jälgivad parendusi, kuid vähesed riski. Loomulikult saab kasutajaliides paremaks, positiivne kasutajakogemus suureneb, tehnoloogiliselt olete taas ajakohane. Siiski: Kui teie äriline edu sõltub tugevast orgaanilisest nähtavusest, on ümberkujundamine viimane abinõu ja tuleks otsustada ainult siis, kui teie valu on piisavalt suur mitme ülaltoodud põhjuse kombinatsiooni läbi, mis pole enam üksikute sprintsidena lahendatavad. Miks? Vaadake siin, mis juhtus nende nelja veebisaidi ümberkujundamise järel nende online-nähtavusega:

Kavanda oma uusversiooni hoolikalt ja taga edukas teostamine läbi kontrollnimekirja. Eelkõige seadke endale ka kaks eesmärki: esiteks oma veebisaidi nähtavuse säilitamine ja teiseks võimaluste leidmine, et relansseerimise käigus luua veebisaidi nähtavuse suurendamise alus. Just selleks on see artikkel, et anda sulle relansi juhend, et sinu riskid relansseerimisel oleksid piiratud ja sa saavutaksid tõepoolest väljapaistva töötulemuse potentsiaaliga jätkusuutlikeks, orgaanilisteks SEO-eduks.

Relansiplaani teekond

Veebisaidi relansiplaan tuleks läbi viia hoolikalt. Selle käigus on oluline arvesse võtta järgmisi samme:

• Olemasoleva veebisaidi analüüs ja praeguse seisundi protokollimine: Algselt tuleks analüüsida olemasolevat veebisaiti, et tuvastada tugevused ja nõrkused.
• Eesmärkide määratlemine: Veebisaidi relanssi eesmärgid tuleks selgelt määratleda. Selle hulka võib kuuluda näiteks konversioonimäära parandamine, külastajate arvu suurendamine või üleminek uuele CMS-ile parema sisuhalduse ja hõlpsama hooldatavusega.
• Kontseptsiooni arendamine: Analüüsi, eesmärkide ja konkureeriv analüüsi alusel tuleks välja töötada veebisaidi relanssi kontseptsioon. Kontseptsioon peaks hõlmama järgmisi aspekte: disain, sisu, tehnoloogia ja SEO/ turundus.
• Rakendamine: Seejärel viiakse kontseptsioon ellu, sealhulgas disaini arendamine, sisu loomine / kohandamine ja tehnoloogiliste muudatuste rakendamine.
• Testimine: Enne veebisaidi avaldamist tuleks uus veebisait põhjalikult testida, et tagada selle veatu toimimine. Selle hulka kuulub ka määratletud kontrollnimekiri.
• Avaldamine: Uus veebisait avaldatakse seejärel. Ja seda jätkatakse reaalajas testimise, hindamise ja kohandamisega.

Eesmärkide ja relanssi strateegia määramine

Määra täpselt, milliseid eesmärke relanss taga ajab. Eesmärgid võivad olla (lisaks eespool nimetatud põhjustele): 

• Kasutajakogemuse parandamine
• Ülevaatlikkuse suurendamine
• Sisu pakkumise laiendamine
• Disaini moderniseerimine
• Müügitulu ja ostukorvi suuruse suurendamine 
• Üleminek muule CMS-ile hõlpsama sisuhalduse ja tehnilise hooldatavusega
• Tulevikus lihtsam laiendatavus ja värskendussuvu tagamine.

Ettepanek: Pärast esimesi meeskonnaalguskoosolekuid ettevõttena - enne kui alustate agentuuridega kõnelusi -, peaks iga projektis osalev isik märkima relanssi eesmärke paberilehele või sisestama need suhtlusvahendi (näiteks Slack) sisestusaknasse. Kui siis kõik näitavad samal ajal oma eesmärke, siis olete üllatunud, kui laialtlevinud on erinevad arvamused, kuigi eesmärk on juba eelnevalt läbi arutatud koosolekutel sõnaliselt. Seetõttu on oluline, et eesmärgid oleksid ka kirjalikult fikseeritud. Kui teate oma eesmärke täpselt, saate juba varases staadiumis kontrollida UI-prototüüpi, kas need on kontseptuaalselt arvesse võetud.

Töömahtumäärus selgitab relanssi ülesannet

Agentuur vajab pakkumise koostamiseks ulatuslikku projekti esitlust kliendilt. Ettevõttel on tavaliselt olemas Wordi dokument või PDF-fail, kus kliendi kavandatud tegevus on enamasti skitseeritud. Sellele järgnevad küsimustikud või toimuvad töötoad, mille abil agentuurid paremini tuvastavad kliendi valu punktid, et saaksid pakkumise teha. Suuremate projektide korral koostatakse töömahtumäärus. Mida üksikasjalikum, seda parem. 

Töömahtumäärus on dokument, mis mängib olulist rolli veebisaidi relanssil. Selle eesmärk on fikseerida kirjalikult relanssi nõuded, eesmärgid ja ootused. Tulemuslikult koostatud töömahtumäärus aitab tagada, et kõik osapooled - olgu selleks arendustiim, disainitiim või klient - mõistaksid selgelt, mida relanssi käigus saavutada soovitakse. See on samuti algusmaterjaliks hästi kalkuleeritud ja kohustuslikule pakkumisele tehtavale agentuurile. Siin on teave ja elemendid, mis võivad tavaliselt olla veebisaidi relansile loodud töömahtumääruses:

• Eesmärgid ja eesmärk: Peamiste relanssi eesmärkide kirjeldus, näiteks kasutajakogemuse parandamine, nähtavuse suurendamine otsingumootorites või CMS-i vahetus disaini uuendamisega.
• Projekti maht: Selge definitsioon, mis relanssi raames on kaasatud ja mis mitte. See võib hõlmata lehtede arvu, kolmandate osapoolte tööriistade integratsiooni või sisu ülevaatamist.
• Disaininõuded: Teave soovitud visuaalse veebilehe kujunduse kohta, sealhulgas paigutused ja ettevõtte kujunduse juhtnöökavad, nagu värvid, fondid ja pildid.
• Funktsionaalsuse nõuded: Soovitud funktsioonide ja interaktsioonide üksikasjalikud nõuded veebisaidil, näiteks kontaktvormid, otsingufunktsioonid, e-kaubanduse funktsioonid jne.
• Tehnilised nõuded: Teatavus tehnoloogiate spetsifikatsioonide kohta, mida tuleks relanssi käigus kasutada, näiteks Content-Management-System (CMS) valik või konkreetsete funktsioonide rakendamine. Samuti kuulub sinna ka kaasaegsete piltide ja graafikaformaatide (WebP, AVIF, SVG) kasutamine.
• Käsitsi ja automaatsed varundused ja muudatuste läbivaatamine sisu redigeerimisel.
• Sisu nõuded: Selged suunised sisu ülevaatamise, ajakohastamise või uuesti koostamise kohta, sealhulgas tekstid, pildid, videod ja muud meediumid. Meta-andmete ja struktureeritud andmete käsitlemine.
• SEO-nõuded: selle kohta saate rohkem järgnevas sisuvaldkonnas.
• Ajakava ja verstapostid: Ajakava, mis määrab planeeritud alustamis- ja lõpukuupäevad relanssi jaoks ning olulised verstapostid.
• Eelarve: Teave relanssi eelarve kohta, sealhulgas disaini, arenduse, majutuse ja võimalike kolmandate osapoolte teenuste kulude kohta.
• Kvaliteedi tagamine testitööriistadega: Kirjeldus testidest ja kvaliteedikontrolliprotseduuridest, mis tuleks relanssi käigus läbi viia, et tagada veebisaidi veatu toimimine.
• Hoolduse ja toetu vajadused pärast relanssi.

Hästi struktureeritud tehniline kirjeldus on otsustava tähtsusega, et vältida arusaamatusi, juhtida projekti tõhusalt ja tagada, et kõigi osapoolte ootused on täidetud. See tegutseb juhendina ja viitena kogu projektimeeskonnale ning aitab tagada veebisaidi ümberkujundamise õnnestumist.

Kui me planeerisime TutKit.com ümberkujundamist alates raamistiku täielikust vahetamisest CodIgniter'ilt Laravelini, hõlmas meie tehniline kirjeldus 220 lehekülge - (e)i just kutsub agentuuri seda läbi töötama.

Märkus: Minu artiklis ei käsitleta detailsemalt kontseptsiooni, disaini, funktsiooni ega kasutatavat tehnoloogiat. Uus veebisait saab kindlasti ilus olema. Suurim oht ​​ümberkujundamisel seisneb tegelikult tehnilise kasutajakogemuse halvenemises ja OnPage-kvaliteedi languses puuduvate 301 edasisuunamiste jne tõttu, mis toob kaasa edetabeli ja nähtavuse kaotuse. Selle vältimiseks keskendutakse järgnevalt eelkõige projektiõnnestumise tagamisele kasutajakogemuse ja SEO seisukohast.

SEO-nõuete määratlemine uuele veebisaidile

Kliendi ülesanne või ulatuslikum tehniline kirjeldus reguleerib juba seda, millist disaini, sisu, funktsionaalsust ja tehnikat soovitakse ning see on aluseks, et agentuur saaks koostada arvutusi.

Relaunch-kontrollnimekirja projekti edukuse tagamiseks tuleks SEO seisukohast vaadata erinevaid lõike. SEO-nõuete spetsialiseerumine tuleneb näiteks järgmistest:

• muutuv URL-struktuur (URL-asisuunamiskaart!) ja muutuvad lingiteed
• muutuv navigeerimine (sisemise linkimise ja lingi hierarhia tõttu oluline)
• muutuvad tehnoloogiad (CMS, JavaScripti raamistik, server, ...)
• muutuv sisu (hästi seotud lehtede potentsiaalsed nähtavuskadud)

Lehed reastuvad Google'is hästi nende sisu asjakohasuse tõttu, seetõttu on oluline küsida, kas olemasolev sisu muutub või ühendatakse, kas sisu kaob ja/või lisandub uut sisu? Kas kategooriate või lehtede sisu struktuur muutub? Nendest punktidest tulenevad SEO-nõuded, mis peaksid kuuluma ümberkujundamise kontrollnimekirja.

Kas vanade sisuosade metandmed kanduvad samuti üle ja kas need muutuvad? Kuidas sisu hooldus toimub töötleja poolt ja kas lehtede sisud on seotud struktureeritud andmetega?

Kas olemasolevad või uued pildid salvestatakse veebisaitide jaoks kaasaegsetesse pildivormingutesse (WebP/Avif) ja kas pööratakse tähelepanu piltide SEO-le rääkivate URL-idega, seega mitte 1234.jpg => hotel-ostsee-warnemuende_suite-nachtigall.avif.

Lisaks tuleks pöörata tähelepanu sellele, et pildifailid oleksid seotud struktureeritud andmetega (pildiobjekt) ja meta-pisipiltidega edastatakse Google'ile, et suurendada pildi lisamise tõenäosust otsingueelvaadetes ja Google'i piltide loendis.

Huvitav on ka küsimus, kuidas parandada kasutajate märke. Näiteks saaks sisulehtedele lisada pildivideoid, selgitavaid ja abistavaid videoid. Kui Google'ilt maandumislehele tulnud kasutaja klõpsab videot ja vaatab seda, suureneb viibimisaeg (hea kasutajamärk), ka tagasipöördumise kiirus SERP-le paraneb (hea kasutajamärk).

Samuti tuleks kontrollida, kuidas sisuosad lehtedele integreeritakse, mis vastaks Google'i nõuetele kasuliku sisu loomisel ja E-A-T põhimõttele.

Google'i jaoks on „kasulik sisu” sisu, mis on kasutajatele asjakohane ja kasulik. See vastab kasutajate küsimustele põhjalikult ja informatiivselt, pakub lahendusi probleemidele ja pakub lisaväärtust, mis ulatub kaugemale lihtsatest reklaamisõnumitest.

Siin on mõned näited kasulikust sisust:

• Õpetused ja juhendid: Need sisud aitavad kasutajatel õppida uusi ülesandeid või lahendada olemasolevaid probleeme.
• Arvustused ja võrdlused: Need sisud aitavad kasutajatel valida õige toote või teenuse.
• Uudised ja värskendused: Need sisud hoiavad kasutajad kursis hetkeseisuga sündmuste ja trendidega.
• Infograafikud ja diagrammid: Need sisud aitavad visualiseerida keerulisi andmeid ja teavet.
• Blogipostitused ja artiklid: Need sisud pakuvad sügavamat ülevaadet konkreetsest teemast.

Google kasutab erinevaid märke, et ära tunda kasulikku sisu. Nende hulka kuuluvad muu hulgas:

• Kasutaja käitumine: Google jälgib, kuidas kasutajad sisudega suhtlevad, näiteks kui kaua nad lehel viibivad, kui tihti jagavad ja hinnanguid annavad.
• Kvaliteedimärgid: Google hindab sisu kvaliteeti faktorite nagu asjakohasus, täielikkus ja ajakohasuse alusel.
• Kasutajate tagasiside: Google arvestab ka kasutajate tagasisidega, nagu hinnangud ja kommentaarid.
• Veebisaidi omanikud, kes neid märke arvesse võtavad, saavad suurendada võimalusi, et nende sisu peetakse kasulikuks.

EEAT-põhimõte on Google'i välja töötatud kontseptsioon, mis hindab veebisaitide ja veebisisu kvaliteeti. See tähistab ekspertiisi, kogemust, autoriteeti ja usaldusväärsust, st ekspertiis, kogemus, autoriteet ja usaldusväärsus.

• Ekspertiis viitab sisu loojate teadmistele ja kogemustele. Google hindab ekspertiisi faktorite, nagu haridus, töökogemus ja auhinnad, põhjal.
• Kogemus tunnistab, et sisu on loodud teatud kogemusega, näiteks põhineb tegelikul toote kasutusel, tegelikul kohavisiidil või isiklikul kogemuse kirjeldusel?
• Autoriteet viitab veebisaidi või veebisisu mainele ja mainele. Google hindab autoriteeti faktorite, nagu tagasilingid, sotsiaalmeedia tegevus ja kasutajate hinnangute, põhjal.
• Usaldusväärsus viitab veebisaidi või veebisisu usaldusväärsusele ja usaldusväärsusele. Google hindab usaldusväärsust faktorite, nagu privaatsus, turvalisus ja läbipaistvus, põhjal.

Millised SEO-nõuded on olemasolevatel ja uutel funktsioonidel seoses esiriba ja tagapõhjaga? Siin on näiteks:  

• Läbipaistvus (oluline sisu peab olema nähtav ja läbitav ka ilma JavaScriptita)
• Veebisaidi eesmärgi selgus ja selgus toimingu kutsega (soovitud käitumine sihtkliendilt lehtedel)
• Dubleeritud sisu vältimine näiteks automatiseeritud kategoorialehtede või mitmete artiklite koopiate kaudu
• Kõrge lehekiiruse tagamine, vältides liiga paljude JavaScripti- ja CSS-failide kasutamist, kasutades kaasaegseid pildiformaate (WebP/AVIF)

Need SEO-nõuded kuuluvad projektikirjeldusse ja koormatööde tellimustesse, kuid lisaks kuuluvad need ka testtööriista kontrollnimekirja või IST-SOLL-võrdlusena projekti kvaliteedikontrolli ning agentuuri töö vastuvõtmise kriteeriumina. Rohkem sellest allpool.

Interneti- ja välisprojektides osalejate määratlemine

Määra projekti osalejad - siin kliendi või veebisaidi omaniku vaatepunktist: 

• Kes vastutab projektijuhtimise eest ja teeb lõplikud otsused? 
• Kes vastutab agentuuri või kliendiga koordineerimise ja kommunikatsiooni eest? 
• Kes vastutab sisemise projektijuhtimise eest?
• Kes valmistab sisu ette ja annab agentuurile abi?
• Kes viib kasutajakogemuse disaini ellu? 
• Kes viib arenduse ellu? 
• Kes teatab agentuuripoolsele kliendile kindlaksmääratud intervallides?
• Kes vastutab agentuuri/kliendi testimise ja kvaliteedikontrolli eest?
• Osutatakse väline konsultant (nt SEO või õigusnõuded)?
• Kes vabastab ülesanded? Kes kontrollib töö korrasolekut pärast töötlemist?
• Kes peab millal olema teadlik (töötajad, kliendid, partnerid, reklaamikampaania juhid jne) 

Välise projektimeeskonna valimisel on olulised neli punkti

1. Kas agentuur on teostanud ühe või mitu sellesugust projekti? Kas on olemas viited? Kas on kliendi ülevaated ja kas oleks võimalik korraldada kliendiga tagasisidevestlus - mis on suurte individuaalsete arenduste puhul soovituslik?
   
2. Kas pakkumise ja tehnilise rakenduse (sisuhaldussüsteem/veebipood/raamistik) puhul on juba kõik nõuded, mis seotud veebisaidi uuendusega, juba olemas loomulikult? Kas on individuaalseid funktsioone või nõudeid, mis tuleb veel programmeerida (ka pistikmoodulite või moodulite kaudu)? Kas pakutakse kindlaid teenuseid, mis on välja arvatud või märgitud hilisemaks ajaks, kuid mis on otsustava tähtsusega projekti edule? Oluline on, et uusi probleeme ei lisanduks, mis oleksid suuremad kui uuenduse tegelik põhjus.
   
3. Toimetav agentuur või teenusepakkuja sobib nii meeskonna suuruse kui ka piirkondliku asukoha ning (Kununu ülevaadete abil võimaliku) töötajate vahetuse järgi ettevõtte jätkusuutlikuks teenindamiseks?
   
4. Kas on võimalik otsekontakt teostava disaini- ja arendustiimiga? Mõistlik on tutvuda tegeliku agentuuri meeskonnaga. Heatahtlikud ja tühje lubadusi tegevad müügiprofid võivad lepingu saada ja hiljem mitte vastutada. Seetõttu peaks otsekontakt teostava meeskonnaga olema kokku lepitud.

Neli soovitust enda kindlustamiseks selles kontekstis

1. Kliendina peaksin tähelepanu pöörama agentuuri kasutatavale tehnoloogiale. Mida pakkumisel on, seda võiks guugeldada märksõnadega "CMS + puudused" või "CMS + kogemused". Peaksid teadma, millesse täpselt sekkud. Mõistlik on panustada avatud lähtekoodiga lahendustele. Ma saan aru, et see pole alati võimalik. Parim on veendumaks, et kasutataval tehnoloogial on võimalikult suur arendajate kogukond, et vältida sattumist agentuuri ainuõiguslikku lahendusse, mida saab hallata ainult sinu agentuur, mis võib jätta sind hiljem suurtesse kitsendustesse.
   
2. Veendu, et sa saad piiramatud kasutus- ja kohandusõigused agentuuri tööle, nii et sul oleks alati õigus veebisaiti sisemiselt või väliselt edasi arendada. Selline punkt tuleks lisada töölepingusse.
   
3. Kui sinu ettevõte on tehniliselt pisut paremini korraldatud ja meeskonnas on süsteemiadministraatoreid, tarkvaraarendajaid või muud taolist, on mõistlik seadistada ise GIT-iga versioonihalduse ja JIRA-ga (või mõne muu tööriista) projektijuhtimise jaoks või ticketsüsteemiks oma konto. Seejärel annate agentuurile täielikud juurdepääsuõigused ja töö võib alata. Mida suurem on projekt, seda karikamalt ja valusamalt võib see projekt olla. Seetõttu on hea, kui teil on otsustavad juurdepääsud ja kontod. Olen teadlik, et see soovitusel on puhtalt tehnilises mõttes vähe kliente, kes saavad järgida.
   
4. Mõnikord pakuvad agentuurid kliendile ka otse hostimist. Meie ise pole selle fännid, sest see suurendab ühelt poolt sõltuvust kliendiga suhtes, teiselt poolt mõtleme, et veebimajutus on kõige paremini sobiv veebimajutuseks, sest spetsialiseeruvad sellele. Oleme ise ka juba servereid seadistanud ja haldanud ning kulutanud ära palju tööjõu- ja ajalisi ressursse. Nüüd jooksevad meie süsteemid Saksamaa ühe suure veebimajutaja pilververitel ja me oleme õnnelikud. Pidage veebimajutust valides kindlasti silmas, et pakett sisaldaks juba serveripoolseid varukoopiaid, mis saab paari klõpsuga taastada.

Aja kestvuse ja käivitamise kuupäeva määramine

Ümberlülitus toimub mitmes projekti kiiruses. Need võivad meie agentuurikogemuse kohaselt olla järgmised:

• Olevolukord protokollitakse (testivahendid kaudu, aga ka kirjalikult koos muljetega, mis kliendi poolt hästi toimib ja kus on vaja parandusi)
• Uuringufaas koos konkurentsi analüüsi ja lahenduste/inspiratsiooni otsimisega
• Jooniselahendus
• Kasutajaliidese disaini kujundamine
• Esikülje- ja tagaküljearendus
• Andmete migreerimine või sisu importimine (automaatne/käsitsi)
• Struktuurilised ja sisulised sisuoptimeerimised (tekst ja pilt) ja SEO-kiirendamine

Projekti kiirused kattuvad, kuna töö käigus hakkavad uued projektiosalised aktiivselt osalema.

On oluline määratleda aja kestvus üksikute projekti kiiruste jaoks ja koos osalejatega kooskõlastada. 

Kas agentuur seab kliendi jaoks projekti jaoks suurema korral Slacki kanali kiirema suhtluse jaoks?

Siinkohal üks soovitus: On hea, kui agentuur töötab juba väga varajases staadiumis klõpsatavate prototüüpidega, seega juba jooniselahenduse etapis ja eriti kasutajaliidese kujunduse esitlemisel ja kontrollimisel. Nii saavad kliendid paremini aimu veebisaidi kogemusest. Lihtsad JPG- või PNG-failid kujundusettepanekuna pole tänapäeval enam asjakohased. Nende asemel peaksid olema klõpsatavad prototüübid, mida luuakse Sketch, Figma, Adobe XD või mõne muu professionaalse tööriista abil.

Selles varases staadiumis on muudatused kergesti teostatavad. Kui veebisaidi funktsioonid ja jaotised on juba välja arendatud, on muudatused oluliselt keerukamad ja võivad viia täiendavate läbirääkimisteni, mis pole sugugi atraktiivsed.

Siin on üks näide sellest, milline näeb välja selline prototüüp mobiilse kasutajaliidese disainiga koos klõpsutrassidega ülevaates:

Tuleb lahendada küsimus, millal on klientide poolt jooksvad testid võimalikud. Arendajad peaksid katma oma kohalikud tööd ka pärast ühinemist etapikeskkonnaga. Tundub banaalne, kuid igaüks, kes töötab arendajatega, saab kohe aru, mida ma mõtlen. Pärast seda peaks keegi, kes vastutab agentuuris kvaliteedikontrolli eest, testimistõendi või -funktsiooni testima. Alles seejärel antakse testimine kliendi jaoks vabaks. Klient ei peaks end kunagi tundma kui alfa-tester, vaid peaks leidma juba nelja silma läbi kontrollitud süsteemi. Agentuur on alfa-tester, klient on beeta-tester! Kas kliendil on üldse juurdepääs agentuuri ticket-süsteemile?

Samuti tuleks kirjalikult määratleda, et agentuuripoolsed aruanded kliendile peavad toimuma kindlas sageduses. Näiteks võiks reedeti saata e-kirja teel aruande projekti praegusest seisust, vajalike tagasiside silmuste või abistavate soovide kohta. See on samuti soovitus meie agentuurikogemusest: Hea on mitte jätta klienti nädalavahetuse eel teadmatusse. Ta võib siis saada rumalaid ideid. Pigem hea teada, mis on toimunud ja mida järgmisel nädalal oodata. Läbipaistvus aitab kõigil protsessiga heas tundes jätkata.

Käivitamise kuupäeva tuleks samuti kindlaks määrata. Parkinsoni seaduse kohaselt laieneb töö niimoodi, et see täidab selle täitmiseks saadaoleva aja. Teiste sõnadega, mida kauem on aega ülesande täitmiseks saadaval, seda rohkem aega selleks võetakse, sõltumata tegelikust keerukusest või töötasust. Planeeritud lõpetamine peaks olema ka töövõtulepingus. Tähtaja ületamine võiks isegi olla karistusega lepingusse lisatud. Juhendina kehtib, et lepingurikkumise trahvid, mis moodustavad 0,2% tellimuse summast igal viivituse tööpäeval ja maksimaalselt 5% tellimuse summast, on efektiivsed. Trahvi ei pruugi tingimata kliendi poolt nõuda, kuid see annab sulle ruumi küsida agentuurilt mõned erisoovid kompensatsiooniks.

Oluline: Ära käivita reedel. Mitte ka mitte pühade ajal ega ettevõtte põhiajal. Me soovitame tegelikult suuremate uuenduste puhul öötunde pühapäevast esmaspäeva, eriti kui IP-aadress muutub, et enamus teenusepakkujatel oleksid DNS-i seaded esmaspäeval veel ajakohastatud, mis juhtub sageli juba hilisel hommikutunnil, kui DNS-i kirje on öötundides kohandatud. See annab praktikas veel 4,5 tööpäeva elus testimiseks ja vigade lahendamiseks, kui neid ilmnema peaks.

Veebisaidi praeguse seisundi protokollimine

Seisukord tuleb fikseerida enne tööde algust. Olevolukorras määratakse tehnilised mõõtmistulemused parameetrite jaoks. Paremale saate sisestada sihtväärtused:

Mis?	Lühikirjeldus	Testivahend	On (Praegune väärtus)	Pead (Sihtväärtus)
Tehnika ja Meta	Lehekülje pealkiri, pealkirjad, metaandmed, Alt-tekstid, …	Seobility
Struktuur	Ümbersuunamised, vigased lingid, saidikaardid, ...	Seobility
Sisu	Märksõna-võrdlus, kirjavigad, liiga vähe tekste, ...	Seobility
Pildid-SEO	Rääkivad URL-id, kaasaegsed veebiformaadid (WebP/AVIF), <meta>-pisipildid	ilma
OG-andmed rakendatud	Avatud graafi andmed sotsiaalmeediale	Avatud Graafi Kontrollija
Struktureeritud andmed (Märkimisskeem)	Skeemi märkimine / struktureeritud andmed	Schema.org
PageSpeed Avalehekülg	PageSpeed mobiilsele/lauaarvutile	PageSpeed Insights
PageSpeed Maandumisleht	PageSpeed mobiilsele/lauaarvutile	PageSpeed Insights
PageSpeed Kategooria leht	PageSpeed mobiilsele/lauaarvutile	PageSpeed Insights
PageSpeed Toodete leht	PageSpeed mobiilsele/lauaarvutile	PageSpeed Insights
PageSpeed Blogileht	PageSpeed mobiilsele/lauaarvutile	PageSpeed Insights
Ühilduvus erivajadustega vastavalt lehetüüpidele	Ühilduvuse tagamine puuetega kasutajate rühmadele	Ligipääsetavuse Kontrollija ja/või wave.webaim.org
Hreflang kontrollimine	Multi-keelesaitidel	Hreflang Kontrollija
Turbepeatükid	Usaldus ja turvalisus	SecurityHeaders.com
Tervisekontroll	Usaldus ja turvalisus	Turbakontroll (Astra)
Brauseri ja seadme testimine	Edge, Firefox, Safari, Chrome lauaarvutis ja mobiilis, iOs ja Android	Arendajatööriistad / Lambdatest
Küpsiseeeliit ja DSGVO	Nõusolekuküpsise ja DSGVO-vastavus	Küpsise Metrix
Kravimine: Hosti olek	Robotid.txt päring, DNS-i lahendus, serveri ühendus	Googlei Otsingukonsool
Kravimise statistika	Päringud, Allalaadimise suurus, keskmine reageerimisaeg	Googlei Otsingukonsool
Klikid otsingutulemustes	Ajaperioodi järgi (kuus/90 päeva, ...)	Googlei Otsingukonsool
Impressioonid otsingutulemustes	Ajaperioodi järgi (kuus/90 päeva, ...)	Googlei Otsingukonsool
Keskmine CTR otsingutulemustes	Ajaperioodi järgi (kuus/90 päeva, ...)	Googlei Otsingukonsool
Keskmine SERP-positsioon	Ajaperioodi järgi (kuus/90 päeva, ...)	Googlei Otsingukonsool
Core Web Vitalsi üleelamine	Rankingufaktor kasutajakogemuse jaoks (PageSpeed, mobiilne optimeerimine, ...)	Googlei Otsingukonsool
GA4-andmete hindamine	Viibimisaeg, Lehekülje külastused/külastaja, ...	Google Analytics 4
Konversioonimäär	Broneerimissaitide või veebipoodide jaoks	Omad mõõdikud
Keskmine ostukorvi väärtus	Veebipoodidele	Omad mõõdikud
Ostude/ümbruskäive päevas	Veebipoodidele	Omad mõõdikud
Uudiskirjalehtedele registreerumise arv	Vajaduse järgi	Uudiskirjakiri
Kontaktipäringud	Vajaduse järgi	Omad mõõdikud
Allalaadimised	Vajaduse järgi	Omad mõõdikud
Videovaatamised	Vajaduse järgi	Omad mõ Nimekirjas leiate SEO-tööriista Seobility, mida me sageli kasutame, et kontrollida on-page-faktoreid, mille hulgas on ka SEO-koolitus, mille ma ka avaldasin. On palju samalaadseid tööriistu nagu Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog jne. SEO-tööriistaga on peamine eesmärk tuvastada ja parandada tüüpilised on-page vead. Siin on kolm põhivaldkonda: tehnika & meta, struktuur ja sisu, mille alusel Seobility hindamised koostab. Sarnaselt leiate need ka teistest SEO-tööriistadest. Oluline on, et alati tehakse täielik kontroll, mille käigus kontrollitakse KÕIKI lehti mitte ainult avalehte ja samuti peate sisestama hinna või veaväärtuse praeguse olukorra ja sihtväärtuse jaoks, mis tuleks saavutada pärast optimeerimist. Seobility puhul on soovitatav väärtus 90 või kõrgem. Samuti leiate teisi alternatiivseid tööriistu erinevateks otstarveteks. Oluline on kasutada ühtegi nendest, et tagada silmapaistvad andmed. See on näiteks meie praegune väärtus on-page kvaliteedile: Kasutajamärgid on tuvastatavad Google Analytics 4 mõõdikutega, nagu näiteks hüpperate, lehekülgede/arvukordajad, kasutajate viibimisaeg jne. Juurdepääsul Google Analytics'ile või muule analüüsitööriistale tuleks tagada, et neid andmeid arvestataks praeguse olukorra protokollis.  Samuti tuleks koostada tagasilinki sisaldav loend, mille saate luua näiteks siin: https://www.seobility.net/de/backlinkcheck/ Lisaks tuleks kindlustada vana sitemap.xml'i ja ka veebisaidi täielik varundus. Kõik asjakohased lehed tuleks samuti Google'i aruandesse teisaldada, mis moodustab algse baasi URL-i suunamiskaardi jaoks. Selline CSV-loend on kerge eksportida SEO-tööriista nagu Seobility abil. URL-i suunamiskaardis arvestatakse kõiki asjakohaseid lehti ja väliseid tagasilinke (vt tagasilinki sisaldav loend), mis tuleb hiljem suunata muutuvate lehe-URL-ide tõttu. Kaduvad URL-id tuleb suunata uutele, vanadele vastavatele URL-idele. Siin on oluline edasisuunamisahelate vältimine! Vanad veel eksisteerivad edasisuunamised tuleb suunata otse uuele lõpp-URL-ile. Samuti tuleks arvestada ka PDF-failide ja piltidega, millele lingid viitavad, nii et need suunatakse korrektselt ega muutu 404-lingiks. 301-Edasisuunamised põhinevad URL-Redirect-Map'il .htaccess'is, Vhosti konfiguratsiooni kaudu suunamiskaartide või andmebaasilahendusena. Klient peaks neid ise hooldama saama. Samuti tuleks tagada, et edasisuunamised oleksid püsivad. Lisaks soovitatav igat liiki lehe täieliku pildi ekraanitõmmise tegemine. See on ühest küljest endise sisu varundamine, kui pärast käivitamist tekib küsimusi, kas sisutüübid pole üle viidud jne. Olemasolevate lehtede, funktsioonide ja sisu põhjal ning mõõtmistulemuste põhjal saab nimetada, mis juba hästi toimib ja millist ala tuleks täiustada, mis peaksite Relaunchi käigus paremaks muutma. Kontrollnimekiri: Enne uue versiooni käivitamist Kui kasutajaliidese disain on kinnitatud ja agentuur on arendusseisundis, muutub järgmine ajakava asjakohaseks, mis loetleb peamised punktid krooniliselt kuni uue versiooni käivitamiseni: Dev-keskkond on testimiseks saadaval kõikidele osalistele Dev-keskkond on noindexis Juurtõrje jaoks on testimisvahenditele Dev-keskkondas juurdepääs (IP-luba või http-login) on seatud Dev-keskkonna konfiguratsioon sarnaneb võimalikult elussüsteemi omale Dev-keskkonna lehe struktuur vastab tulevase live-lehe struktuurile Vanade andmete migratsioon on lõpule viidud Sisu kohandused on tehtud Pildi-SEO on tehtud 301-Edasisuunamised põhinevad URL-Redirect-Map'il OnPage-kontroll Seobility abil on läbi viidud, vead on parandatud, eesmärgid on saavutatud Open-Graph-andmed on kehtivad Struktureeritud andmed on kehtivad Kõikide lehetüüpide jaoks on lehekiiruse kontroll läbi viidud, eesmärgid on saavutatud Sisu-küpsisepoliitika töötab Turbepeatükid on seadistatud Barjääri puudumine, eesmärgid on saavutatud Hreflang on kehtiv (mitmekeelsetel saitidel) Õigustekstid (tingimused, üldtingimused, taganemisteade, privaatsuspoliitika) on ajakohastatud, GDPRi ühilduvus on saavutatud CMS-i, raamistikud, kasutatavad pistikprogrammid ja moodulid on uuendatud Lõpliku brauseri- ja seadmeülese funktsionaalsuse testi tulemused ei tuvastanud vigu Lõplik olek ja käivitamiskuupäev on teada antud  Täielik varundus on tehtud Struktureeritud andmete kasutamine (skeemi märgistamine) - vt nimekirja punkt 12 - seda ei võeta endiselt piisavalt arvesse. Tegelege teemaga ja lugege, mida Google skeemiandmete kohta Google'i otsingus ütleb. Google kaalub järjest enam valideeritud andmeid SGE raames, mis on tehisintellekti loodud otsingutulemused. Samuti tingib Google'i abistavat sisu uuendus, et sisud on palju paremini varundatud ekspertteadmise, kogemuste, asjatundlikkuse ja usaldusväärsuse kaudu. Struktureeritud andmed on üks osa lahendusest, mis lihtsustab selle andmete valideerimise Google'ile. Pärast struktureeritud andmete lisamist kasutage Skeemi märgistuse valider, kuid kontrollige oma lehti ka Struktureeritud andmete Linter abil, mida soovitatakse ja linkitakse ka Google'i PageSpeed Insightsi. Saate sealt ulatuslikumat teavet ajaveaohtude kohta, mis on seotud teie struktureeritud andmete kasutusega. Struktuuritudandmete kasutamine veebisaitidel ei ole enam valik, vaid tingimus. Google soovib sinult usaldusväärseid ja usaldusväärseid sisu. Kui te ei soovi tehisintellekti toetatud otsingutulemustest maha jääda, hoolitsege skeemi märgistuste eest oma lehtedel! Punktis 16 ilmub esimest korda sõna Ligipääsetavus selles artiklis. Juba PageSpeed Insights'is on ligipääsetavusel omaette valdkond ja seal on soovitavad rohelised numbrid. Test, kas leht on ligipääsetav või mitte, peaks toimuma lisaks PageSpeed Insights'ile ka läbi https://www.accessibilitychecker.org ja/või https://wave.webaim.org. Eriti kui ees ootab uusversioon, tuleks see punkt kohustuslikult arvesse võtta, kuna veebisaitidele muutub teema alates 2025. aastast kohustuslikuks seadusega ligipääsetavuse tugevdamise kohta. Kontrolli sellise tööriistaga mitte ainult avalehte, vaid igat lehetüüpi - sama kehtib ka PageSpeed-testide kohta! Relanseerimise raames tekivad sageli ka kohandused ja õigustekstide värskendused. Tuleks varakult mõelda sellele, et tekstid võib-olla tuleb esitada spetsialisti või õigusgeneraatorite kaudu. Samuti tuleks mõelda tellimislepingute töötlemise lepingutele juhul, kui kasutatakse näiteks uut veebimajutusteenuse pakkujat või muutub uudisteenus.  Punkt 18 koos CMS-i, kasutatavate JavaScripti raamatukogude, installitud moodulite ja pluginatega on sama alahinnatud kui oluline. Relansseerimine võib võtta mitu kuud ja kauem. WordPressi süsteemis on lihtne näha, et võib-olla enne relansseerimispäeva on juba saadaval arvukalt uuendusi. Kliendid peaksid tagama, et uusimaid versioone kasutatakse Going-Live'i korral.  Muutuvate väliste teenuste puhul lisanduvad veel ülesanded, mida tuleks samuti kontrollnimekirjades nimetada, näiteks uudisteenuse muutmisel:  Uudiskirja kontaktandmete andmete importimine uude uudiskirjateenusesse Uudiskirjateenus website'is liitmiseks anmlda AV-leping Uute postitemplate'ide loomine ja nii edasi  Arendustsükli jooksul toimuvad loomulikult pidevad funktsioonide jms testimised. On mõistlik koostada testide jaoks ka äärmiselt üksikasjalik kontrollnimekiri, et midagi ei ununeks. Ei piisa vaid natuke veebiarendusagentuuri ja kliendina ringi klõpsamisest. Pärast meie TutKit.com'i relansseerimist oli meie vastuvõtunimekiri kindlasti 1000 rida. Ja nii hoiame seni: pärast olulisi põhiuuendusi kontrollime umbes 70 interaktsiooni kontrollnimekirja kaudu Chrome'i, Safari ja Androidi jaoks. Checkliste: Relansseerimispäev ja järgmised päevad Relansseerimispäev on kätte jõudnud ega ole reede ega püha vahel. Uus veebisait läheb avalikkusele kättesaadavaks, DNS-seaded on kohandatud. Nüüd tuleb kõike uuesti kontrollida ja hinnata. Kontrolli järgmist:  robots.txt kontroll, et robotid ei oleks blokeeritud  Livekeskkond käib indeksimise ja järgimisega.   Kanoni-sildid on õigesti seatud Absoluutsete linkide polte kontrollitakse lehtede testkeskkonna linkide poltide põhjal HTTP-st HTTPS-le edasisuunamine koos/ilma www-ita sihtmääras veebisaidil ja alamlehtedel toimib Edasisuunamiste testimine URL-ümbersuunamiskaardi kaudu, samuti suunatakse juuresolekul edasisuunamise ahelad Liveveebilehe OnPage kontroll Seobility jaoks tehnika ja meta, struktuuri ja sisu jaoks ... eriti kontrollitakse Seobility kaudu väljastatud Noindex-lehti Open-Graphi andmed on valideeritud Struktureeritud andmed on valideeritud Pagespeedi kontroll kõigile lehetüüpidele on läbi viidud, eesmärgiväärtused on saavutatud Küpsise eeskiri koos nõusoleku küpsise tööriistaga töötab nii, nagu vaja Turvalisuse päised on seadistatud Ligipääsetavus on tagatud Hreflangi kontroll on läbi viidud mitmekeelsetel veebisaitidel (https://app.sistrix.com/de/hreflang-validator) Lõplik brauseri- ja seadmeülene funktsionaalsustesti ei tuvastanud vigu Uus sitemap.xml esitada Google'i otsingukonsoolile Uued sihtlehed uuendada Google Ads kampaaniates Konkreetsel domeenimuudatusel mõtle linkitele sotsiaalmeedias, e-kirja allkirjades jne Kasutame oma arenduskeskkonnas Mailhog e-kirjade kohalikuks testimiseks. Sellistel juhtudel on oluline tagada, et õiged SMTP andmed on rakendatud e-kirjade vastuvõtuks Live-süsteemis, et e-kirjad jõuaksid sinna, kuhu nad peaksid minema. Samuti tuleb tähelepanu pöörata Makseteenusepakkujatele nagu Paypal, et arenduskeskkonnas oleks Liivakast otsetõlge, samal ajal kui Live-süsteemis tuleb loomulikult luua õige ühendus. Järgnevate päevade jooksul on eriti oluline jälgida Google'i otsingukonsooli. Eriti huvitav on muidugi jälgida oma reitingute muutusi. Pane oma fookus eriti ootamatute muudatuste ja vigadeteadele: Ronimine: Hosti olek ... Robots.txt päring, DNS lahendamine, serveri ühendus Ronimise statistika ... Päringud, allalaadimiste arv, keskmine reageerimisaeg Klõpsud SERP-ides Impressioonid SERP-ides Keskmine CTR SERP-ides Keskmine SERP asend Core Web Vitalsi edukas sooritamine  Eriti Google'i Otsingukonsool juhib tähelepanu vigadele, nagu nt URL-vead, href-lang-vead, lehtede indekseerimine, kus on lehti indekseeritud/mittendekseeritud. Mittendekseerimisele peab olema mingi põhjus (edasisuunamine, noindex)...). Seal näed ka duplikaatsisu või muid probleeme. Kui Otsingukonsool teavitab sind probleemidest struktureeritud andmete või Core Web Vitalsi osas, siis uuris nende põhjust. Elusandmete kaudu avastad näiteks, et su lehtedel on kõrge kiiruse tõttu probleeme Core Web Vitalsitega, nt CLS-vigade tõttu. Seal on hästi näha, millised hüpped on võimalikud veebisaidi muudatuste korral: Sa võid otse näha halbu või optimeerimist vajavaid URL-e. Võta URL ja tee sellest PageSpeed Insightsi abil PageSpeedi test. Seal saad teavet selle kohta, miks Core Web Vitalsid ei vasta nõuetele ja mida saad teha vigade parandamiseks. Lisateabe saamiseks klõpsa allapoole suunatud noolele. Need soovitused saavad tavaliselt rakendada ainult arendajad. Siiski on oluline, et sa oleksid võimeline probleeme tuvastama, et saaksid need seejärel oma agentuuri abiga lahendada. Hinda ka analüüsitööriistadest saadud andmeid, nt Google Analytics 4-st. Jälgi süsteemiga kogutavaid mõõdikuid, nt broneeringuid, konversioonimäära, ostukorvi summat, oste/käivet päevas, uudiskirjadele registreerumisi, kliendipäringuid, konkreetsete sisude allalaadimisi või videovaatamisi. Google Otsingukonsooli ronimisestatistikad on olulised järgmiste päevade kontrolle. Saad neile juurde pääseda menüüs vasakul asuvate seadete kaudu. Ronimistegevus peaks olema nähtavam. Kui pole, siis kas on ronimisvigu? Hosti olek annab sulle kohe näha vigu, nagu näiteks siin, peale ümberlansseerimist, kui robotite robots.txt-le tehtud päringud ebaõnnestusid ning serveriühendus oli osaliselt katkendlik: Huvitav on ka see, mida ronimise statistika räägib. Pärast ümberlansseerimist toimub tavaliselt suurem ronimisaktiivsus. Seal näed ka, kas ronitakse endiselt lehekülgi, mis annavad tagasi 404 vea. Kui mõned neist ei sobi, arutage neid arendajatega läbi. Sa märkad, kas sinu server, PageSpeed ning kood on üsna head, kui su lehe reageerimisaeg on alla 400 ms. Mida lähemal see on 1000 ms-le, seda soovitatavam on PageSpeedi optimeerimine, näiteks vähendades andmebaasipäringuid ning tugevdades serveri jõudlust (nt rohkem arvutusvõimsust, uuendamine uusimale serveritarkvarale, üleminek HTTP2 või HTTP3 peale (Nginxis)). Tulevikus võib üksikute veebisaitide ronimise eelarve piiratuse tõttu (tehisintellekti) sisu kasvades olla mõistlik hoida lehe reageerimisaeg heas seisus, et robotid suudaksid kättesaadavaloleva aja jooksul võimalikult palju sinu lehtedel ronida. Ümberlansseerimise kontrollnimekiri allalaadimiseks Ülalolevad kontrollnimekirjad ümberlansseerimiseks on saadaval ka PDF-failina allalaadimiseks. Laadi need alla ja taga endale projekti edukus! Ühe agentuuri omaniku tunnistused Kontrollnimekirjas olevad SEO-nõuded võiksid saada ka üksikasjalikke juhiseid, nagu H1 kuni H6 pealkirjastruktuuri järgimine ja nii edasi. Ziilväärtuste määramine testtööriistades lühendab õnneks tervet ümberlansseerimise kontrollnimekirja sisu, sest testtööriistades määratud parimate tulemuste saavutamine eeldab korrektset koodi, kaasaegsete tehnoloogiate kasutamist ja SEO-OnPage faktorite järgimist jne. Muidu tuleks uusimad veebistandardid ja tehnilised ning SEO-nõuded väga üksikasjalikult määratleda, milleks kliendid reeglina puhttehniliselt võimelised ei ole. Kui agentuurid peavad testtööriistades saavutama kõrged tulemused, siis neil ei jää muud üle, kui tegutseda parima tavaga – see on ka agentuuridele uus kogemus :-) On saabunud aeg tunnistada. SEO-nõuete määratlemine ja kontrollnimekirjade põhjalik rakendamine, mille puhul on seatud kindlad eesmärgid erinevates testtööriistades, moodustavad ideaalsete, kuid reaalsuses harvaesinevate stsenaariumidega olelusvõitlust. See sõltub: kliendirahaliste eelarvealaste piirangute agentuuripoolsete kasumioptimeerimise huvide piirangud kasutatavaid tehniliste lahenduste poolt ja kahjuks ka: teadmatus ning ebapädevus mõlemal poolel Klientidele on raske etteheidet teha. Nad otsivad professionaalset abi ning peaaegu iga digitaalne agentuur kirjutab oma veebisaidil ja valgetes paberites, et otsingumootori optimeerimine on nende põhikompetentsiks. Alati on ka viiteid, mis tõestavad, et pärast uuendamist on veebis nähtavust suurendatud 3, 5 või isegi 10 korda. Et kui enne oli 10 külastajat päevas, siis 100 on mõistagi 1000-protsendiline tõus, kuid see pole siiski veel edu. Paljud otsingumootori edulood eeldavad, et konkurendid digitaalselt on veel palju nõrgemini esindatud. Agentuurid jätkavad keskpärast tööd vananenud meetoditega, sest nad pole siiani kasutanud moodseid tööriistu kvaliteedi tagamiseks, hoolimata sellest, et oma postitustes, viidetes, heades tavades jne on rõhutanud SEO kompetentsi olemasoluga. Võib-olla on sellised agentuurid teadmistetargad, kuid teostuspojad. See kõlab karmilt, kuid see on tavaline. Täiesti tõsiselt. Uuri seda julgelt! Võta ülalolev kontrollnimekiri ja sisesta oma piirkonna parim agentuur koos nende URL-iga eespool mainitud tööriistadesse. Seejärel võta kõige uuem veebisaidi viide, mille agentuuri leiad, ja korrake protsessi. Millised tulemused sa näed? Just need, mida võid oodata koostöös. Ka meie enda uuendused saad niimoodi üle vaadata ja märkad, et isegi meie klientide projektides ei saavuta me igal pool tipptulemusi. Selline töövoog suhtumisega andmepõhisesse kvaliteedikindlustusse on arenenud meil projektist projektini ja on märgitud eelkõige meie töödega TutKit.com-is. Enamus agentuure ei tööta tõeliselt andmepõhiselt kvaliteedikindlustuse nimel, kuna pole ise oma projektidega aastaid turul püsinud ja pole karmis võitluses online-nähtavuse eest pidanud mõõtu võtma rahvusvaheliste mängijatega ning neil võib olla põhimõtteliselt ükskõik, kas projekt on edukas või mitte, seni kuni arve on tasutud ja kliendid saavad nautida ilusaid (kuid kvaliteedilt keskpäraseid) veebilehti oma postitustes ja auhindade puhul. Eri paradoks seisneb selles, et just sellised SEO-agentuurid oma enda veebisaitidele langevad sageli testtööriistadest kõige halvemini läbi, sest neil on sageli ainult üks trikiga poni ... kliendi võtmesõnadele toetuv sisupakett veebisaidile. Teiste tehniliste nõudmiste jaoks puuduvad lihtsalt pädevad arendajad. Eelis on ka siis, kui agentuur asub mujal ja klient ei kohta vastutavat agentuuri töötajat oma kodupoe ostureisil ning ei pea taluda kahekohalist protsendimärgiga nähtavuse kadu pärast uuendamist. Kuid kliente praktiliselt ei huvita see nähtavuse kaotus, sest kuigi kõigil on küpsise nõusoleku bänner, väheste tegelikult analüüsivad numbreid ja teevad neist tegevuskavasid. Kahtluse korral tuleb lihtsalt reklaamikulutusi suurendada. Õnneks ei tea kliendid täna õnneks ka seda, et otsingutulemuste reastamine sõltub eelkõige tehnilistest parameetritest, kasutajamärkidest ja (endiselt) tagasilinkidest suure hulga sisuliselt võrdselt hästi esindatud veebisaitide kaudu, ja KI teksttööriistadega tõsta veebilehed sisuliselt enneolematu koguse ja kvaliteediga ning võime peatselt tervitada meie riigikeelsete SERP-ide seas paljusid uusi veebisaite välismaalt, sest KI tõlketööriistadel on aina lihtsam vefikanwe, porteale, SaaS-tooteid ja muid veebisaite tõlkida ning vallutada digitaalne koduturg. Peame end valmis seadma karmiks konkurentsiks. See algab alles... Kokkuvõte andmepõhisest veebisaidi uuendamise kontrollnimekirjast Selline andmepõhine kontrollnimekiri on üks väheseid tõhusaid viise, kuidas sundida agentuure kvaliteetset tööd tegema. Soovitatav on isegi teha testtööriistides saavutatud väärtuste jõudmisi vastu võtmiseks kriteeriumiks. See peaks lepinguliselt reguleeritud olema, et osamakse võib esitada alles nelja nädala möödudes uuendamisest, kui kõik olulised andmed on olemas ja tipptulemuste olemasolu on kinnitatud (näiteks Core Web Vitals ja valideeritud tootetükid skeemimärgendusega Otsingu konsoolis). Selle töövooga, nagu selles postituses kirjeldatud, jääb su nähtavuskadu uuenduse järel, millega kaasnevad tugevad sisulised, struktuurilised ja tehnilised muudatused, piiratuks ning lood tingimused, mille korral Google jätab su veebisaidi või e-poe peagi kõrgemale kohale reastamiseks. Kui artikkel oli sinu jaoks huvitav, vaata meie teisi sisu: 1101,908,1066,1086