Atnaujinimo patikrinimas internetinėms parduotuvėms, rezervavimo ir įmonės tinklalapiams.

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.

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šą.

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

1. 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?
   
2. 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.
   
3. 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?
   
4. 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

1. 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.
2. 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į.
3. 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.
4. 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. Be to, rekomenduojama saugoti kiekvieno puslapio tipo pilną ekrano nuotrauką. Tai viena vertus yra senųjų duomenų atsarginė kopija, jei po būsimo spustelėjimo kyla klausimas, ar turinio tipai nebuvo perkelti ir kt. Bazės puslapių, funkcijų ir turinio pagrindu ir remiantis matavimų rezultatais galima nurodyti, kas jau gerai veikia ir kas nustatomas kaip sritis, kurioje yra optimizavimo galimybės, kas turėtų pagerėti iš naujo išleidus. 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: Dev-aplinka, prieinama visiems suinteresuotiems testuoti Dev-aplinka vyksta noindex Testavimo įrankių prieinamumas Dev-aplinkoje (IP atvir Struktūrizuotų duomenų naudojimas svetainėse nebebuvo neįgalumas, tai yra būtina sąlyga. „Google“ iš tavęs nori patikimų ir patikimų turinio. Jei nenorite atsilikti nuo dirbtinio intelekto paremtų paieškos rezultatų, rūpinkitės schemų žymėjimu savo puslapiuose! 16 punkte šiame straipsnyje Pristeinamumas pasirodyti pirmą kartą. „PageSpeed Insights“ jau turinio pristatinio metu turi „Pristeinamumo“ sekciją, kurioje pageidaujamos žalios skaičiavimo. Pristdocumento svetainės pristatymo įgalumas ar neįgalumas turėtų būti patikrintas ne tik per „PageSpeed Insights“, bet ir per https://www.accessibilitychecker.org ir/arba wavewe.webaim.org. Ypač jei kils keitimas, tai punktas turėtų būti privalomas, nes nuo 2025 metų svetainėms su pinigų straipsnio įgyvendinimo įstaiga kyla aktualumas šia tema. Tikrinkite naudodamiesi šiuo įrankiu ne tik pagrindinį puslapį, bet ir kiekvienam puslapio tipui – tas pats pasakytina ir apie „PageSpeed“ testus! Per naują srautą dažnai kyla galimybės ir Teisinių tekstų atnaujinimai. Svarbu tai įsivertinti anksti, kad galbūt tekstai būtų paruošiami per teisininką arba per teisines generacijas. Taip pat reikia prisiminti sutarties tvarkymą, jei pavyzdžiui bus naudojamas naujas tinklalapių talpytojas ar keisis naujienlaiškio tarnyba. 18 punktas su turinio tvarkymu, naudojamomis JavaScript bibliotekomis, įdiegtomis moduliais ir įskiepiais yra lygiai toks svarbus, kaip nusimano. Naują srautą gali nusavinti keletas mėnesių ar ilgiau. „WordPress“ sistemoje lengva matyti, kad galbūt jau prieš naujo srauto dieną prieinami daug atnaujinimų. Klientai turėtų užtikrinti, kad naujausi versijos yra naudojamos „Going-Live“ metu. Pasikeitusiems išoriniams paslaugoms atsiranda papildomų užduočių, kurios turėtų būti aprašytos patikrinimo sąraše, pavyzdžiui, pakeitus naujienlaiškio tarnybą:  Naujienlaiškio kontaktų duomenų importavimas į naują NL tarnybą Jungtis prie naujienlaiškio tarnybos svetainėje registracijos formoje AV sutartis Naujų Mailingų šablonų kūrimas ir t.t. Viso kūrimo spurtu prastos funkcijos ir t.t. nesiliaujantį bandymus. Svarbu sukurti labai išsamų patikrinimo sąrašą, kad nieko nepasiskolintumėte. Nepakanka klaviškai „Taip“ ir klaviške „Naršyti“ spustelėti nei vykdant agentūrą nevykdant kliento. Po mūsų TutKit.com naujo srauto mums priėmimo patikrinimo sąrašui tikriausiai buvo 1 000 eilučių. Taip mes laikome iki šiol: po svarbių didelių atnaujinimų mes patikriname apie 70 sąveikų naudojant patikrinimo sąrašą „Chrome, „Safari“ ir „Android“. Patikrinimo sąrašas: naujo srauto diena ir sekantys dienomis Naujo srauto diena atėjo ir tai ne sekmadienis, taip pat ne šventinė diena. Naujas tinklalapis tampa gyva, DNS nustatymai yra pritaikyti. Dabar svarbu pradėti nuo pradžių patikrinti ir vertinti viską iš naujo. Patirkite šiuos punktus:  robots.txt patikrinkite, kad robotai nebūtų blokuoti  Gyva aplinka naudoja „index, sek„  Garso signalai nustatyti teisingai Puslapių tekstas patikrina absoliutus keliai (testinės aplinkos nuorodų keliai gyvam puslapiui) Nukreipimas nuo http į https su/arba be www į pradinį puslapį ir po puslapiu taip pat veikia Testuokite nukreipimus per URL nukreipimo žemėlapį, taip pat dėl egzistavimo nukreipimo grandinių OnPage patikrinimas gyvam puslapiui naudojant Seobility technikai ir Meta, struktūra ir turinį … ypatingai tikrinant, ar „Noindex“ puslapiai, kurie yra pateikiami per Seobility, yra tikri „Open-Graph-Daten“ yra patikimos Struktūrizuoti duomenys yra patikimi Pagespeed tikrinimas visiems puslapių tipams yra baigtas, siekiamos reikšmės Slapukų taisyklė su sutikimo slapuku veikia, kaip turi Saugumo antraštės yra nustatytos Pristeinamumas Daugiakalbės svetainės „Hreflang“ tikrina (https://app.sistrix.com/de/hreflang-validator) Galiausias naršyklės ir įrenginių testas nerado klaidų Naują „sitemap.xml“ Google paieškos konsoleje Nauji tiksliniai puslapiai Google reklamos kampanijose atnaujinami Atlikus tam tikrus domeno pakeitimus reikia pagalvoti apie ryšius socialiniuose tinkluose, el. laiškų parašuose ir t.t. Mūsų „Dev“ aplinkoje naudojame Mailhog, kad būtų galima testuoti el. laiškus vietiniame pagalbos centrut. Tokiais atvejais yra svarbu, kad „SMTP“ duomenys „Gavimo el. pašte realiame sistemoje“ būtų saugomi, kad laiškai nukreiptų ten, kur jie turėtų eiti. Litininkai turi įsitikinti, kad mokėjimo tiekėjai, tokiu kaip „Paypal“, dev sistema turi „Smėsbergą“, o gyvos sistemos metu žinoma, kad sudaroma tinkama sąveika. Sekančiose dienose svarbu stebėti Google paieškos konsolę. Ypač įdomu, kaip kinta jūsų reitingai. Savo dėmesį sutelkite į netikėtus pokyčius ir pranešimus apie klaidas: Robokasymo statusas ... robots.txt pažymėjimas, DNS išsprendimas, serverio ryšys Robokasymo statistika ... užklausos, atsiuntimo dydis, vidutinis reakcijos laikas Spustelėjimai SERP Parodymai SERP Vidutinis CTR SERP Vidutinė SERP pozicija Pagrindiniai tinklapio veikimo matavimai  Ypač „Google Search Console“ nurodo jums klaidas, pvz., URL-klaidos, „Href-Lang“ klaidos, puslapių indeksavimas su išplėtimu/nėra indeksavimo. Neteisingam indeksavimo turėtu būti priežastis (nukreipimas, nėra indekso)... Ten jūs taip pat pamatysite dublikuotą turinį arba kitus problemas. Jei „Search Console“ praneša apie problemas su struktūrizuotais duomenimis arba pagrindiniais tinklalapio veikimo matavimais, jas ištirkite. Tik iš gyvų duomenų, pavyzdžiui, išsiaiškinsite, kad jūsų puslapiai, nepaisant aukšto puslapio greičio, turi problemų su pagrindiniais tinklalapio veikimo matavimais, pavyzdžiui, dėl CLS klaidų. Čia aiškiai matyti, kokie pokyčiai galimi atliekant svetainės pakeitimus: Gali tiesiogiai matyti blogus arba optimizuotinus URL adresus. Paimkite URL adresą ir atlikite su juo puslapio greičio testavimą naudodamiesi „PageSpeed Insights“. Ten gausite rekomendacijas, kodėl pagrindiniai tinklalapio veikimo matavimai nėra įvykdyti ir ką galite padaryti, kad ištaisytumėte klaidas. Norėdami sužinoti daugiau informacijos, paspauskite mažą rodyklę žemyn. Šias rekomendacijas dažniausiai patariama įgyvendinti tik programuotojams. Tačiau svarbu, kad galėtumėte identifikuoti problemas, kad vėliau galėtumėte jas spręsti su savo agentūra. Taip pat analizuokite duomenis iš savo analizės įrankių, pvz., iš „Google Analytics 4“. Taip pat stebėkite palyginamąsias analizės matavimo vienetus, kuriuos galite sekti sistemos lygiu, pvz., rezervacijos, konversijų norma, pirkinių krepšelio vertė, pardavimai/pelnas per dieną, naujienlaiškio prenumeratos, kontaktų užklausos, tam tikrų turinių atsisiuntimai arba vaizdo peržiūros.  Robokasymo statistika „Google Search Console“ yra būtina patikrinimams ateityje. Ją rasite per nustatymus, esančius kairėje meniu pusėje. Turi matytis daugiau Robokasymo veiklos. Jei nėra, ar yra klaidų dėl roboko veiklos? Tiesiogiai matote netikslumus dėl hosto būsenos, pvz., kaip galime matyti čia po atnaujinimo, kai robokų užklausos failui „robots.txt“ buvo nesėkmingos ir taip pat serverio ryšys daug kartų būdavo nutrauktas: Taip pat įdomu, ką sako Robokasymo statistika. Po atnaujinimo, kaip taisyklė, pastebima veikla Robokasymo užklausose. Ten taip pat pamatysite, ar vis dar yra 404 puslapiai, kurie pernelyg neatitinka. Jei kai kurie neatitinka konteksto, aptarkite juos su programuotojais. Matuosite, ar jūsų serveris, jūsų puslapio greitis ir jūsų kodas yra santykinai geri, jei jūsų puslapio reakcijos laikas yra mažesnis nei 400. Kuo arčiau šis skaičius priartėja prie 1000 ms, tuo rekomenduotina atlikti puslapio greičio optimizavimą, pvz., sumažinant duomenų bazės užklausas ir sustiprinant serverio galios (pvz., daugiau skaičiavimo galios, atnaujinti naujausią serverio programinę įrangą, persijungti į HTTP2 ar HTTP3 (naudojant Nginx)). Ilgalaikis kur kas didesnių (AI-)svetainių turinių melžimas per dešimtmečius tikėtinai apribos kuriamų tinklalapių skaičių apsistojimą, todėl čia taip pat turėtų būti siekiama gerai vertės puslapio atsakų laiks, kad tie bokšteliai streprumčiau užpildytų kiekvieną iš turinių puslapių, esančių jūsų puslapiuose, pagal prieinamą laiką. Atnaujinimo patikros sąrašas atsisiuntimui Įdėti patikros sąrašai atnaujinimui taip pat pateikiami kaip PDF failai atsisiuntimui čia. Atsisiųskite juos ir užtikrinkite savo projekto sėkmę! Kontoros savininko išpažintys Seo reikalavimai sąraše taip pat gali būti išsamios instrukcijos, pavyzdžiui, atsižvelgiant į antraštės struktūrą nuo H1 iki H6 ir t. t. Ketinimų nustatymas testavimo įrankiais sutaupo iš esmės visą atnaujinimo patikros sąrašą, nes geriausių rezultatų pasiekimas iš sąraše paminėtų testavimo įrankių priklauso tik nuo tvarkingų kodo laikymosi, naujosios technologijos naudojimo, atsižvelgiant į SEO svetainės viduje veikiančius veiksnius ir kt. Jei agentūrai reikia pasiekti aukštus rezultatus testavimo įrankiuose, ji turi veikti pagal geriausias praktikas – tai naujas patyrimas net ir agentūrų darbuotojams :-) Laikas išpažinti. SEO reikalavimų apibrėžimas ir patikros sąrašu panašus požiūris su įsipareigojimu ir įvairiais testavimo įrankiais nustatytų tikslų pasiekimu yra idealus, bet realybe retai aptinkamas. Tai priklauso nuo: klientų biudžeto apribojimai agentūros pelno optimizavimo interesai Ribojimai, susiję su naudojamomis technologijomis ir, deja, nežinojimas ir nekompetencija abiejose pusėse Klientams sunku kaltinti. Jie ieško profesionalios pagalbos, ir beveik kiekviena skaitmeninė agentūra savo svetainėje ir baltuosiuose dokumentuose rašo, kad paieškos sistemos optimizavimas yra viena iš jų pagrindinių kompetencijų. Visada yra nuorodų, kurios įrodo, kad po atnaujinimo internetinis matomumas padidėjo tris, penkis ar net dešimt kartų. Tai, kad iš 10 lankytojų atėjo 100 per dieną, nors ir yra 1000% padidėjimas, vis tiek nėra sėkmė. Daugelis paieškos sistemų sėkmės priklauso nuo to, kad kitaigi tiesiog yra daug silpnesni skaitmeniškai. Agentūros ir toliau dirba vidutiniškai naudodamos pasenusias metodus, nes iki šiol jos nenaudoja modernių įrankių kokybės kontrolėi, net jei preziumuojama jų SEO kompetencija skelbimuose, nuorodose, geriausiąse praktikose ir pan. Šios agentūros galbūt yra žiniatinklio milžinės, tačiau tuo pat metu vykdytojai nykštukai. Tai skamba griežtai, tačiau taip yra įprasta. Tiksliai. Rūpestingai įvertinkite tai! Atlikite viršuje esančią patikrinimo sąrašo procedūrą ir įveskite geriausią agentūrą iš savo regiono, iš kur kilote, kartu su jos interneto svetainės nuoroda į aukščiau minėtus įrankius. Tada pasirinkite naujausią interneto svetainės nuorodą, kurią suradote iš agentūros, ir pakartokite. Kokių rezultatų tikimės pamatyti? Tiksliai tokius, kokių galite tikėtis bendradarbiaujant. Taip pat galite patikrinti mūsų pačių nuorodas ir pastebėsite, kad patys savo klientų projektuose nepasiekiate visur aukštų rezultatų. Toks darbo srautas, grindžiamas duomenų pagrindu kokybei užtikrinti, pas mus įsitekęs tik nuo projekto iki projekto ir, svarbiausia, iš solidžių darbų TutKit.com. Tokias patikrinimus galite atlikti su beveik bet kuria agentūra, nes tik kelios iš tikrųjų naudoja duomenų pagrindą kokybės užtikrinimui, nes nė viena, turėdama nuosavus projektus rinkoje, per kelias metas nebuvo konkurencinga su tarptautiniais veikėjais siekdama kovoti už interneto matomumą, nes agentūrų beveik nerūpi, ar projektas pasiseks ar ne, tiek, kiek tik reikia sumokėti už agentūros sąskaitą ir klientai gali pasigrožėti gražiomis (bet kokybiškai vidutinėmis) svetainėmis savo įrašuose ir apdovanojimais. Ypatingoji ironija yra tai, kad pagal aukščiau minėtus testavimo įrankius dažnai paaiškėja, kad SEO agentūros su savo pačių svetainėmis pasirodo blogiausiai, nes dažnai jos kaip vienintelę galią turi tik vieną metodą… turinio paketą, pritaikytą kliento raktažodžiams. Senu irgi pritrūksta kvalifikuotų kūrėjų techninėms reikmėms. Privalumas yra tai, kai agentūra yra kitoje vietoje, ir klientų atstovas nebebus sutiktas parduotuvėje, kaip atsakingas agentūros darbuotojas, kuris atsakingas už santykinį matomumo nuostolį dvigubų skaitmenų procentais po atnaujinimo. Tačiau klientai tikrai retai savo patirties nuostolių tikrina, nors daugelis turi slapukų sutikimo juostas, tačiau tik nedaugelis tikrai išanalizuoja šias skaitmenis ir daro išvadas, kaip reikia veikti. Jeigu abejonių, paprasčiausiai reikės padidinti skelbimo išlaidas. Dabar aišku, kad šiandien organinis reitingavimas dėka perteklio panašių turinių turtingų tinklalapių, ypač priklauso nuo techninių parametrų, vartotojų signalų ir (vis dar) nuorodų, klientams, laimei, nepasiseka taip žinoti. Ir kūrybiniai teksto įrankiai padidins tinklapių turinį niekada nemačiu kiekybėje ir kokybėje ir greitai galėsime pasveikinti daugybę naujų užsienio kalbų tinklapių savo gimtąja kalba paieškos rezultatuose, nes kūrybiniais vertimo įrankiais bus vis lengviau vertinti elektroninius parduotuves, portalus, SAAS ir kitus tinklapius ir užimti digitalinį tėvynės rinką. Teks ruoštis sunkiam konkursui. Tai tik prasideda… Išvados apie duomenų pagrindu grindžiamą tinklalapių atnaujinimo patikrinimo sąrašą Toks duomenų pagrindu grindžiamas patikrinimas yra vienas iš nedaugelio efektyvių būdų, verčiančių agentūras užtikrinti kokybišką darbą. Netgi rekomenduojama padaryti tam tikrų testavimo įrankių rezultatų siekimą abipusiško susitarimo dėl priėmimo kriterijų. Turi būti sutartas, kad dalis mokėjimo bus išsiųsta tik po keturių savaičių po atnaujinimo, kai visi svarbūs duomenys yra pateikti ir patvirtina, kad pasiekti viršūnių rezultatai (pvz., pagrindiniai svetainės gyvavimo rodikliai ir patvirtinti produktų ištraukos pagal Schema-Markup paieškos konsolėje). Taikant šį darbo srautą - kaip aprašyta šiame įraše - tavo matomumo praradimas po atnaujinimo su stipriais turinio, struktūros ir techniniais pokyčiais bus apribotas, ir sukursi pagrindą, kad Google greitai padarytų tavo tinklapį ar internetinę parduotuvę labiau reitinguojamą. Jei šis straipsnis buvo jums įdomus, patikrinkite ir mūsų kitus turinio elementus: 1101,908,1066,1086