Atjaunošanas pārbaudes saraksts tiešsaistes veikaliem, rezervēšanas un korporatīvajām vietnēm.

Tevis gaida pārstrukturēšana? Apsveicam, ka atradi šo rakstu. Šajos izklāstos varbūt slēpjas spēcīgs ieguldījums tavs pārstrukturēšanas veiksmes nodrošināšanā un lai iegūtu izcilu rezultātu. Jo tas nenotiek vienmēr. Es esmu aģentūras īpašnieks un tev izpaudīšu tieši to, kas ļaus tev rasties situācijai, kas prasa, lai cilvēki kā es strādā labi, un novērstu tipiskus kļūdas pārstrukturēšanas procesā. Bet sāksim visu no sākuma.

Tīmekļa vietnes pārstrukturēšana ir esošas tīmekļa vietnes pārstrādāšana un uzlabošana. Tas var ietvert gan dizaina, saturu, gan tehnoloģiju izmaiņas. Tīmekļa vietnes pārstrukturēšanas mērķis ir uzlabot vietni un pielāgot to jaunajām prasībām.

Uzņēmumos noteikti ārējie stimuli rada situāciju, kad tiek pasludināts mērķis "pārstrukturēt": nesen pieņemtais darbinieks nes līdzi lieliskas idejas, ienāk jauns vadītājs, kurš vēlas digitali pamatīgi uzkopties, konkurencei ir jauna vietne vai ienākumi samazinās. Varbūt arī šefam nav patikusi vecā vietne vai Z paaudzei vietne nav pietiekami moderna. Tu, iespējams, zini par to. Bet tas, ka ir pienācis laiks atsvaidzināt vietni, un personiskas viedokļi nav pamatojums pārstrukturēšanai.

Tomēr pastāv daži labāki iemesli, kāpēc uzņēmumi vai organizācijas vēlas veikt tīmekļa vietnes pārstrukturēšanu. Būtiskākie no tiem ir:

• Novecošs dizains un/vai prezentācijas maiņa: Veca vietne var radīt iespaidu, ka uzņēmums nespēj attiecīgi pielāgoties laikam vai vairs nav aktīvs. Tāpēc svaigs, moderns dizains ir paredzēts, lai uzlabotu uzņēmuma tēlu. Ja mainās zīmola tēls vai uzņēmuma identitāte, bieži vien tiek vēlams veikt vietnes pārstrukturēšanu, lai atspoguļotu jauno zīmola vēstījumu.
• Labāka lietotāju pieredze: Ja tīmekļa vietnes lietotājiem pieejamība ir slikta, tas var izraisīt augstu atskrējumu līmeni. Pārstrukturēšanai var pienākt noderīgais darbs, lai uzlabotu lietotāju pieredzi un padarītu vietni vieglāk pārvietojamu.
• Mobilā optimizācija: Tā kā cilvēki arvien vairāk piekļūst tīmekļa vietnēm, izmantojot mobilo ierīču, ir svarīgi nodrošināt, lai vietne labi darbotos dažādos ekrāna izmēros un ierīcēs.
• Meklētājdraudzīgais mārketinga meklēšanas optimizēšana (SEO): Vecai vietnei var būt problēmas ar SEO veiktspēju. Pārstrukturēšana piedāvā iespēju veikt SEO draudzīgas izmaiņas, lai uzlabotu redzamību meklētājprogrammās.
• Satura atjaunināšana: Ja uzņēmuma informācija, pakalpojumi vai produkti mainās, vietnei jābūt atjauninātai, lai atspoguļotu šīs izmaiņas.
• Drošības uzlabošanas: Vecākas vietnes bieži vien ir pakļautas drošības riskiem. Pārstrukturēšana var kalpot, lai uzlabotu vietnes drošību un aizsargātu pret tiešsaistes uzbrukumiem.
• Tehnoloģiskā atjaunināšana: Veco tehnoloģiju lietošana var ietekmēt vietnes veiktspēju. Pārstrukturēšana var dot iespēju pāriet uz aktuālām tīmekļa tehnoloģijām un platformām.
• Barjēru neesamība: Barjēru uzlabošana ir svarīga daudzām vietnēm, lai nodrošinātu to pieejamību cilvēkiem ar ierobežotībām.
• Konkurences spēja: Lai būtu pretim konkurencei, ir svarīgi izveidot modernu un efektīvu tīmekļa vietni. Pārstrukturēšana var palīdzēt saglabāt vai palielināt konkurences spēju.
• Analītiskie uzlabojumi: Izmantojot labākus analīzes rīkus un datu savākšanu, uzņēmumi var labāk saprast un optimizēt savas vietnes veiktspēju.
• Saskaņa ar tiesiskām prasībām: Tiesību akti un reglamenti par datu aizsardzību, pieejamību un drošību regulāri mainās. Pārstrukturēšana var būt nepieciešama, lai nodrošinātu, ka vietne atbilst šīm prasībām.

Šie iemesli var būt individuāli vai kombinēti un mainīties atkarībā no uzņēmuma mērķiem un vajadzībām. Tīmekļa vietnes pārstrukturēšana bieži vien ir stratēģiska izvēle, lai uzlabotu tiešsaistes klātbūtni un sasniegtu uzņēmuma mērķus. Kad aplūko šos punktus atsevišķi, kļūst skaidrs, ka lielākā daļa iemeslu ir realizējami ar mazākiem sprintiem un neprasa lielu pārstrukturēšanu.

Šķiriet, kāda ir pārstrukturēšana un kas tā nav: jaunais dizains ar esošu tehnisko bāzi ir drīzāk klusa atjaunošana. Pārstrukturēšana rodas tad, kad ar pārstrukturēšanas mērķi notiek patiesas izmaiņas lietotāja pieredzē, darbībā un tehniskajā pamatā.

Pārstrukturēšanai vienmēr jābalstās uz faktiem (piemēram, tehnika nonāk nāvējos, un vairs nav iespējams atjaunināt), mērķa rādītājiem, kā arī mērīšanas un salīdzināšanas datiem.

Šeit ir mans pirmais ieteikums: Evolution bevor Revolution! Izvairies no pārstrukturēšanas tik ilgi, cik vien iespējams, un cenšies realizēt visus punktus, kuri līdz šim ir uzstādīti pārstrukturēšanas vajadzībām, individuāli vai inkrementāli. Uzlabo vienu lietu, izlaid to, novērtē, kas notiek, atkal pielāgojas vai pieiet nākamajam punktam. Labākais piemērs ir Amazona vietne, kas tiešām minimāli mainās un uzlabo savu vietni jau daudzus gadus, izvairoties no lielām pārstrukturēšanas izmaiņām.

Pārstrukturēšana vienmēr ir liela risks tevai redzamībai Google. Visi pievēršas uzlabojumiem, bet daži pievēršas riskiem. Skaidrs, ka lietotāja interfeiss kļūst labāks, pozitīvā lietotāju pieredze palielinās, tehniski atkal esi laikposmā. Tomēr: ja tavs uzņēmējdarbības panākumu pamats ir atkarīgs no spēcīgas organiskās redzamības, pārstrukturēšana ir pēdējais līdzeklis izvēlē. un izvēle ir jādara tikai tad, ja tavai sāpei ir pietiekami liela kombinācijā ar iepriekš minētajiem iemesliem, kas vairs nav izlabojami atsevišķos sprintos. Kāpēc? Apskati šeit, kas noticis pēc četru vietņu pārstrukturēšanām ar šīm faktorēm:

Plāno savu relauci rūpīgi un nodrošini veiksmīgu realizāciju, izmantojot pārbaudes sarakstu. It sevišķi uzstādi sev divus mērķus: vienādā laikā uzturi savu tiešsaistes redzamību un atradīsi iespējas radīt pamatu relauces ietvaros tiešsaistes redzamības paaugstināšanai. Īpaši šī raksta nolūks ir sniegt tev relauca vadlīnijas, lai tavi riski relaucē būtu ierobežot, un lai tu tiešām gūtu izcilu darba rezultātu ar potenciālu ilgtspējīgiem, organiskiem SEO panākumiem.

Relauca plāns

Tīmekļa vietnes relauca plānošanai jānotiek rūpīgi. Šajā procesā ir svarīgi ņemt vērā sekojošos soļus:

• Esošās tīmekļa vietnes analīze un esošā stāvokļa protokolēšana: Pirmkārt, jāveic esošās tīmekļa vietnes analīze, lai identificētu stiprās un vājās puses.
• Mērķu noteikšana: Tīmekļa vietnes relauca mērķiem jābūt skaidri definētiem. To skaitā var būt konversijas likmes uzlabošana, apmeklētāju skaita palielināšana vai pāreja uz jaunu CMS ar uzlabotu saturu un uzturēšanu.
• Koncepcijas izstrāde: Pamatojoties uz analīzi un mērķiem, kā arī konkurentu analīzi, jāizstrādā tīmekļa vietnes relauca koncepcija. Koncepcijā jāiekļauj šādi aspekti: dizains, saturs, tehnika un SEO/mārketings.
• Ieviešana: Pēc tam tiek īstenota koncepcija. Tas ietver dizaina izstrādi, saturu izveidošanu/pielāgošanu un tehnisko izmaiņu ieviešanu.
• Pārbaude: Pirms tīmekļa vietnes publicēšanas rūpīgi jāpārbauda, lai nodrošinātu, ka tā darbojas kļūdaini. Tas ietver arī noteiktu pārbaudes sarakstu.
• Publicēšana: Pēc tam jaunā tīmekļa vietne tiek publicēta. Un turpinās dzīva pārbaude, novērtēšana un pielāgošana.

Mērķu un relauca stratēģijas noteikšana

Noteik precīzi, kādus mērķus vēlies sasniegt ar relauci. Mērķi var būt (papildus minētajiem iemesliem): 

• Lietotāju pieredzes uzlabošana
• Pārskatāmības palielināšana
• Satura piedāvājuma paplašināšana
• Dizaina modernizācija
• Ieņēmumu un iepirkumu grozu palielināšana 
• Pāreja uz citu CMS ar vieglāku satura uzturēšanu un tehnisko uzturēšanu
• Perspektīva par labāku paplašināmību un atjaunojamību.

Ieteikums: Pēc pirmajām sākuma sapulcēm komandā uzņēmumā—vēl pirms sarunu ar īstenojošajām aģentūrām—katrs projekta dalībnieks varierakstīt uz papīra vai ievadīt savos komunikācijas rīkos (piemēram, Slack) jūsu relauca mērķus. Ja tad visi vienlaikus parāda savus minētos mērķus, būsi pārsteigts, cik plaši atšķiras viedokļi, lai gan jau iepriekš mērķi tika apspriesti sarunās. Tāpēc ir svarīgi arī precīzi nostiprināt mērķus rakstiski. Zinot savus mērķus precīzi, jau agrīnā posmā vari pārbaudīt UI prototipu, vai tie ir konceptuāli ņemti vērā.

Specifikācija sniedz skaidrību par relauca uzdevumu

Aģentūra vajag plašu projektu plānojuma iesniegumu no klienta. Uzņēmumi parasti rīkojas ar Word dokumentu vai pieejā ir PDF fails, kur tā vai citādi tiek skicēts uzdevums. Tad ir anketas vai notiek darbnīcas, kurās aģentūras labāk izceļ klienta sāpes, lai varētu sniegt piedāvājumu. Lielākiem projektiem tiek izstrādāta specifikācija. Jo detalizētāka, jo labāk. 

Specifikācija ir dokuments, kas ir būtiska loma tīmekļa vietnes relaucā. Tā ir paredzēta, lai rakstiski fiksētu prasības, mērķus un cerības attiecībā uz relauca. Labi izstrādāta specifikācija palīdz nodrošināt, ka visi iesaistītie — vai nu izstrādes komanda, dizaina komanda vai klienti — skaidri saprot, ko vajadzētu sasniegt relaucā. Tā ir arī sākuma punkts labiizstrādātam un savstarpēji saistošam aģentūras piedāvājumam . Šeit ir informācija un elementi, kas parasti var būt iekļauti tīmekļa vietnes relauca specifikācijā:

• Mērķi un nolūki: Galveno relauca mērķu apraksts, piemēram, lietotāju pieredzes uzlabošana, redzamības palielināšana meklētājos vai CMS maiņa ar dizaina atjaunināšanu.
• Projekta apjoms: Skaidra definīcija tam, kas ietilpst relaucā un kas nē. Tas var būt lapu skaits, trešo pušu rīku integrēšana vai saturu pārveidošana.
• Dizaina prasības: Informācija par vēlamo vizuālo izkārtojumu tīmekļa vietnei, ieskaitot maketus un Corporate Design vadlīniju ievērošanu krāsās, fontos un attēlos.
• Funkcionalitātes prasības: Norāde uz vēlamo funkciju un mijiedarbību tīmekļa vietnē, piemēram, kontaktformas, meklēšanas funkcijas, e-komercijas funkcijas u.c.
• Tehniskās prasības: Specifikācijas par tehnoloģijām, kas būtu jāizmanto relaucā, piemēram, Content Management System (CMS) izvēle vai noteiktu funkciju ieviešana. Iezīmējot attīstību modernos attēla un grafikas formātos (WebP, AVIF, SVG) ir arī iekļauts.
• Manuāli un automātiski rezerves kopijas un pārskatīšanas par uzlabojumu saturu.
• Satura prasības: Skaidri norādījumi par saturu pārveidošanu, atjaunināšanu vai jaundibināšanu, ietverot tekstus, bildes, video un citas medijiem. Meta datu un strukturēto datu apstrāde.
• SEO prasības: vairāk par to nākamajā sadaļā.
• Laika grafiks un posmi: Plānotais sākuma un pabeigšanas datumi relaucam kā arī svarīgie posmi.
• Budžets: Informācija par budžetu relaucam, ietverot izmaksas par dizainu, attīstību, uzturēšanu un eventuālajiem trešās puses pakalpojumiem.
• Kvalitātes kontrole ar testēšanas rīkiem: Apraksts par pārbaudēm un kvalitātes kontroles procedūrām, kuras būtu jāveic relaucā, lai nodrošinātu, ka tīmekļa vietne darbojas bez problēmām.
• Uzturēšanas un atbalsta prasības: Prasības par turpmāko uzturēšanu un vietnes atbalstu pēc relauca.

Labi strukturēts prasību specifikācijas dokuments ir ļoti svarīgs, lai izvairītos no neskaidrībām, efektīvi vadītu projektu un nodrošinātu visu iesaistīto personu cerību izpildi. Tas kalpo kā vadlīnija un atsauce visam projektu komandai, palīdzot nodrošināt mājas lapas atjaunošanas veiksmi.

Mūsu prasību specifikācijas dokuments TutKit.com atjaunošanai ar pilnīgu pāreju no CodIgniter uz Laravel ietver 220 lapaspuses - ne pārāk iedvesmojošs redzējums kādai aģentūrai, kas ar to jāiztiekas.

Piezīme: Konceptam, dizainam, funkcionalitātei un izmantotajai tehnoloģijai manā rakstā netiks pievērsta detalizēta uzmanība. Jaunā mājaslapa noteikti būs pievilcīga. Vislielākā risks atjaunošanā patiešām slēpjas tehniskās lietotāju pieredzes pasliktināšanā un lapas kvalitātes samazināšanā nespējamu 301 pāradresāciju utt. dēļ, kas var novest pie vērtējuma un redzamības zaudējumiem. Lai to novērstu, nākamajā tiks pievērsta uzmanība galvenokārt mājaslapas atjaunošanas projekta panākumu nodrošināšanai no lietotāju pieredzes un SEO puses.

SEO prasību definēšana jaunajai mājaslapai

Klienta norādījumi vai plašāka prasību specifikācijas dokumenta izstrāde jau nosaka, kas ir vēlams no dizaina, saturiskā, funkcionalitātes un tehniskā viedokļa, un ir pamats, lai aģentūra varētu veikt izmaksu kalkulāciju.

Jaunajai mājaslapas atjaunošanas veiksmes nodrošināšanas pārpalikumu pārbaudes sarakstam jāapsver atsevišķie punkti no SEO perspektīvas. Īpašas SEO prasības rodas no piemēram:

• mainīga URL struktūra (URL Redirect Map!) un mainīgie saites ceļi
• mainīga navigācija (svarīga iekšējās saites un saites hierarhijas dēļ)
• mainās tehnoloģijas (CMS, JavaScript Framework, serveris, ...)
• mainās saturs (iespējamas redzamības zaudes labi rangotajām lapām)

Lapas rangs Google tieši kopā ar saturiskās nozīmes dēļ uzlabojas, tāpēc ir svarīgas šādas jautājums - vai esošais saturs mainās vai tiek apvienots, vai saturs tiek izņemts un/vai pievienots? Vai mainās kategoriju vai lapu saturiskā struktūra? No šiem punktiem jāizriet SEO prasības, kas jāiekļauj atjaunošanas pārbaudes sarakstā.

Vai veco saturu tiek pārnesti metadati un tie mainās? Kā notiek satura uzturēšana no redaktora puses un vai lapas satura ir saistīts ar strukturētiem datiem?

Vai esošie vai jaunie attēli tiek saglabāti jaunākos attēlu formātos mājaslapām (WebP/Avif), un vai tiek pievērsta uzmanība attēlu SEO, izmantojot runājošas vietrākstzīmes mazajos burtos, tātad nevis 1234.jpg => viesnīca-jūras-krasts-suite-naktiņa.avif.

Tāpat jāņem vērā, ka attēlu faili satur strukturētus datus (Attēla objekts) un <meta>-sīktēlus nosūta Google, lai palielinātu attēlu iegulšanas iespējamību meklēšanas fragmentos un iekļaušanu Google Attēlu sarakstā.

Interesants aspekts šajā sakarā ir jautājums, kā padarīt lietotāju signālus labākus. Tādējādi uz saturu ievietojot attēlu video, izglītojošus un palīdzības video, tiek uzlabots lietotāju uzturēšanās laiks (labi lietotāju signāli), kā arī uz return-to-SERP rāti tiek uzlabota ietekme (labi lietotāju signāli).

Tāpat ir jāpārbauda, kā iekļaut satura sekcijas lapās, kas atbilst Google prasībām par noderīgu saturu un par E-E-A-T principu.

Google uzskata, ka "noderīgs saturs" ir saturs, kas ir būtisks un noderīgs lietotājiem. Tas sniedz plašas un informatīvas atbildes uz lietotāju jautājumiem, piedāvā risinājumus problēmām un sniedz vērtību, kas pārsniedz vienkāršas reklāmas ziņojumus.

• Rādītāji un rokasgrāmatas: šis saturs palīdz lietotājiem mācīties jaunas uzdevumus vai risināt esošas problēmas.
• Atsauksmes un salīdzinājumi: šis saturs palīdz lietotājiem izvēlēties pareizo produktu vai pakalpojumu.
• Jaunumi un atjauninājumi: šis saturs informē lietotājus par aktuālajām notikumiem un tendencēm.
• Infografika un diagrammas: šis saturs palīdz vizualizēt sarežģītus datus un informāciju.
• Bloga ieraksti un raksti: šis saturs nodrošina dziļāku ieskatu konkrētā tēmā.

Google izmanto dažādas pazīmes, lai atpazītu noderīgu saturu. Tajās ietilpst, piemēram:

• Lietotāju uzvedība: Google novēro, kā lietotāji mijiedarbojas ar saturu, piemēram, cik ilgi paliek lapā, cik bieži to kopīgo un kā bieži to novērtē.
• Kvalitātes pazīmes: Google novērtē saturs kvalitāti, ņemot vērā faktorus kā piemēram relevanci, pilnību un aktualitāti.
• Atsauksmes no lietotājiem: Google ņem vērā arī lietotāju atsauksmes, piemēram, vērtējumus un komentārus.
• Veicot šīs pazīmes, mājas lapas īpašnieki var palielināt iespējas, ka viņu saturs tiks uzskatīts par noderīgu.

EEAT-Principu ir Google izgudrots koncepts, kas novērtē tīmekļa vietņu un saturu kvalitāti. Tas nozīmē Eksperti, Pieredze, Autoritāti un Uzticamību, tātad Eksperti, Pieredze, Autoritate un Uzticamība.

• Ekspertīze attiecas uz personu zināšanām un pieredzi, kas veido saturu. Google novērtē ekspertīzi, ņemot vērā faktorus, piemēram, izglītību, darba pieredzi un apbalvojumus.
• Pieredze ir apliecināta, ja saturs ir izveidots ar noteiktu pieredzi, piemēram, balstoties uz reālu produkta izmantošanu, faktisku vietu apmeklējumu vai pieredzes aprakstu no personas?
• Autoritāte attiecas uz vietnes vai tīmekļa satura reputāciju. Google vērtē autoritāti, ņemot vērā faktorus, piemēram, atpakaļsaites, sociālo mediju aktivitātes un lietotāju vērtējumus.
• Uzticamība attiecas uz vietnes vai tīmekļa satura uzticamību un ticamību. Google vērtē uzticamību, ņemot vērā faktorus, piemēram, privātumu, drošību un pārredzamību.

Kādas SEO prasības ir esošajām un jaunajām funkcijām attiecībā uz frontālo un aizmugurējo galu? Šeit ir piemēri:  

• Indeksa-veiktspējai (atbilstoši saturi jābūt redzamiem un indeksējamiem arī bez JavaScript)
• Vietnes mērķa skaidrība un darbības izsaukuma skaidrība (vēlamo uzvedību no mērķa klienta vietnēs)
• Dublētā satura novēršana, piemēram, ar automatizēti izveidotām kategoriju lapām vai lapu dublikātiem, kas izveidoti ar variantiem
• Augstu PageSpeed nodrošināšana, izvairoties no pārāk daudzu JavaScript un CSS failu izmantošanas, izmantojot mūsdienu attēlu formātus (WebP/AVIF)

Šīs SEO prasības ir jāiekļauj projektu aprakstā vai specifikācijā, tāpat tās ir svarīgas kā testēšanas rīka kontrolsarakstā vai kā esošās situācijas un kā vēlamās situācijas salīdzinājumā projektakvalitātes nodrošināšanai un kā agentūras sniegtā pakalpojuma pieņemšanas kritērijiem. Par to vairāk zemāk.

Iekšējo un ārējo projekta dalībnieku noteikšana

Noteik projekta dalībniekus - šeit no klienta vai vietnes īpašnieka skatupunkta: 

• Kurš ir atbildīgs par projektu vadību un pieņem gala lēmumus? 
• Kurš ir atbildīgs par sadarbības un komunikācijas koordinēšanu ar aģentūru vai klientu? 
• Kurš nodrošina iekšējo projektu vadību?
• Kurš sagatavo iekšējos saturus un palīdzības materiaļus aģentūrai?
• Kurš īsteno lietotāja pieredzes dizainu? 
• Kurš veic izstrādi? 
• Kurš pārskata aģentūras darbību klientam noteiktos intervālos?
• Kurš pārņem aģentūras/pušu testēšanu un kvalitātes nodrošināšanu?
• Vai tiek iesaistīts ārējais konsultants (piem., SEO vai juridiskie jautājumi)?
• Kurš atbrīvo uzdevumus? Kurš pēc uzdevuma pabeigšanas pieņem uzdevumus sistēmā?
• Kurš jāinformē par pienākšanas laiku (darbinieki, klienti, partneri, reklāmkampaņu vadītāji, …) 

Piecu svarīgu aspektu noteikšana ārējo projektu vadītāju atlasē

1. Vai aģentūra ir nodrošinājusi vienu vai vairākus šāda veida projektus? Vai ir atsauces? Vai ir klientu atsauksmes un vai ir iespējams veidot atkārtotas saziņas ar klientiem aģentūrā - kas ir ieteicams lielām individualizētām attīstībām?
   
2. Vai piedāvātie pakalpojumi un tehniskā izpilde (vadības sistēma veikaliem/sistēmai/Framework) jau nodrošina visus saistītos prasības, kas ir saistītas ar pārveidošanu? Vai ir individuālas funkcijas vai prasības, kas vēl jāizstrādā (arī ar spraudņu vai moduļu palīdzību)? Vai ir noteiktas pakalpojumu izslēgšanas vai vēlākā rezervācija un kas ir būtiskas projekta veiksmes nodrošināšanai? Svarīgi, lai nav jaunu problēmu, kas ir lielākas par patieso pārveidošanas iemeslu.
   
3. Vai īstenošanas aģentūra ir piemērota gan pēc komandas izmēra, gan pēc reģionālās atrašanās vietas, gan (iespējams izdarāmo Kununu novērtējumu pamatā) darbinieku apgrozījuma uzņēmumam ilgtermiņā?
   
4. Vai ir tiešs kontakts ar dizaina un izstrādes komandu, kas to realizē? Ir saprātīgi iepazīties ar faktisko, aģentūrās darbojošos projektu komandu. Izaicinājumi un pagrūtējumi var kļūt arī lielāki, jo lielākā projekta apjoms ir. Tāpēc ir svarīgi, lai būtu tiešs kontakts ar realizējošo komandu.

Četri padomi savas aizsardzības nodrošināšanai saistībā ar to

1. Kā klientam, tev vajadzētu rūpīgi uzmanīt aģentūras izmantoto tehnoloģiju. Ko piedāvā, vienkārši izmantojot "vadības sistēma + trūkumi" vai "vadības sistēma + pieredze". Tev vajadzētu zināt, uz ko tieši tuiesi. Praktisks ir likt likmi uz atvērtā koda risinājumiem. Man zināms, ka tas ne vienmēr ir iespējams. Labāk ir nodrošināt, ka izmantotajai tehnoloģijai ir iespējami liela izstrādātāju kopiena, lai tu galu galā neatkarīgi neiegūtu aģentūras izstrādātu izolētu risinājumu, kurš vēlāk ierobežo jūsu iespējas, saskaroties ar nopietnām problēmām.
   
2. Uzmanies, lai saņemtu neierobežotas lietošanas un rediģēšanas tiesības aģentūras darbam, lai vienmēr būtu tev tiesības interni vai eksterni turpmāk attīstīt vietni. Tāds punkts jāiekļauj darbu līgumā.
   
3. Ja tava uzņēmējdarbība ir nedaudz tehniski attīstīta un jums komandā ir sistēmaadministratori, programmatūras izstrādātāji vai līdzīgi, būs saprātīgi, ja patstāvīgi ieviesīsiet GIT versiju vadībā un JIRA (vai līdzīgu rīku) projektu vadībai vai tiketu sistēmai, vispirms izveidojot paši sevišķu kontu. Tad jūs sniedzat aģentūrai pilnvaras un darbi var sākties. Jo lielāks projekts, jo rupjāki un sāpīgāki var būt notikumi. Tāpēc jums ir jābūt kontroli pār nozīmīgajiem piekļuves un kontu datiem. Man zināms, ka šo ieteikumu praktiski var izmantot tikai daži klienti tikai no profesionālā skatpunkta.
   
4. Daudzreiz notiek, ka aģentūras piedāvā tieši klientiem mājinstrumentu pakalpojumus. Mēs paši neesam šīs idejas piekritēji, jo tas palielina atkarību klientu attiecībās, līdz ar to mēs uzskatām, ka tīmekļa hostēšanas pakalpojumus ir vislabāk piedāvāt tieši tīmekļa hostēšanas pakalpojumu sniedzējos, jo viņi ir specializējušies šajā jomā. Mēs paši esam izveidojuši un pārvaldījuši serverus un patērējuši daudz personāla un laika resursus. Mēs atkal atgriezāmies. Tagad mūsu sistēmas darbojas uz viena no lielajiem tīmekļa hostēšanas pakalpojuma sniedzējiem Vācijā un esam laimīgi. Neradījiet hostēšanu, ņemot vērā, ka jau iekļauti servera puses rezerves kopijas, kas var tikt atjaunotas dažu klikšķu laikā.

Laika posma un starta termiņa noteikšana

Relaunch tiek veikts vairākos projekta sprintos. Saskaņā ar mūsu aģentūras pieredzi, šie var būt:

• Pastāvības stāvoklis tiek protokolēts (izmantojot testa rīkus, kā arī rakstiski ar iespaidiem, kas norāda, kas strādā labi no klienta puses un kurās vietās uzlabojumi ir nepieciešami)
• Pētījumu fāze ar konkurentu analīzi un risinājumu/iedvesmas meklēšanu
• Virszemes plānojums
• Lietotāja saskarnes dizaina izveide
• Frontenda un backend izstrāde
• Datu migrācija vai kontenta importēšana (automatizēta/manueli)
• Strukturālas un saturīgas satura optimizācijas (teksts un attēli) & SEO sprint

Projekta sprinti pārklājas, jo darbā iesaistās jauni projekta dalībnieki.

Svarīgi ir definēt laika posmu atsevišķiem projekta sprintiem un koordinēt to ar iesaistītajiem. 

Vai aģentūra, īstenojot projektu klienta labā, lielam projektam izveido savu Slack kanālu ātrai komunikācijai?

klikšķināmiem prototipiem, tātad jau virszemes plānojumā, un īpaši svarīgi, kad tiek veikta lietotāja saskarnes dizaina prezentācija un pārbaude. Tā klienti labāk var sajust vietnes izpratni. Vienkārši JPG vai PNG faili kā izkārtojuma priekšlikums šodien vairs nav laikmetīgi. Tie ir jābūt klikšķināmiem prototipiem, kas tiek izstrādāti ar Sketch, Figma, Adobe XD vai kādu citu profesionālu rīku.

kontroles testi no klienta puses. Attīstītājiem ir jāteste savas lokālās darbības arī pēc saplūšanas ar stabiņa sistēmu. Šķiet banāli, bet ikviens, kas strādā kopā ar izstrādātājiem, uzreiz sapratīs, ko es domāju. Pēc tam persona, kas atbild par aģentūras kvalitātes pārbaudi, pārbauda biļeti jeb funkciju. Tikai tad biļete tiek atbrīvota klienta pusei testēšanai. Klientam nevajadzētu justies kā alfa testētājam, bet drīzāk piekrišana jokā atbruņotam sistēmai. Aģentūra ir alfa testētājs, kamēr klients ir beta testētājs! Vai vispār ir piekļuve aģentūras biļešu sistēmai?

Arī rakstiski būtu jānosaka, ka ituras puses ziņojumi klientam ir jāsniedz noteiktā biežībā. Piemēram, katru piektdienu varētu nosūtīt ziņojumu pa e-pastu par pašreizējo darbu stāvokli, nepieciešamajām atsauksmēm vai palīdzības pieprasījumiem. Tas ir atkal ieteikums no mūsu aģentūras pieredzes: ir labi, ja klientu neuzliekat gaidīt neskaidrībās nedēļas nogalē. Tas viņam tikai rada negatīvas domas. Labāk ir labi paskaidrot, kas noticis un kas gaidāms nākamajā nedēļā. Pārredzamība palīdz, lai visi paturētu pozitīvu sajūtu par lietu.

Starta termiņu ir jānosaka arī. Pēc Parkinsona likuma darbs izplatās tādā veidā, ka tas aizpilda pieejamo laiku savā izpildes gaitā. Citos vārdos, jo vairāk laika ir pieejams uzdevuma izpildei, jo vairāk laika tam tiek pievērsts neatkarīgi no faktiskās sarežģītības vai darba apjoma. Plānoto pabeigšanu arī jāiekļauj darba līgumā. Termiņa nenovērošana var tikt pat sankcionēta ar soda naudu līgumā. Pamatnostādne ir tāda, ka soda naudas, kas ir 0,2 % no pasūtījuma summas par darba kavējuma katru darba dienu un maksimāli 5 % no pasūtījuma summas, ir efektīvas. Sodanauda var nebūt nepieciešama no klienta puses, bet dod jums elastīgumu, lai aģentūrai noķertu vēl dažas izņēmuma vēlmes.

Svarīgi: Nikad nemēģiniet sākt jaunumu ceturtdienā. Arī ne starp brīvdienām vai darba laika sākumu uzņēmumā. Tiešām iesakām, ka lielu jaunumu gadījumā labākais laiks ir svētdienas naktī uz pirmdienu, īpaši ja IP adrese mainās, lai DNS iestatījumi būtu atjaunoti daudziem pakalpojuma sniedzējiem pirmdienā, kas bieži vien jau notiek vēlu no rīta, ja DNS ieraksts tika pielāgots naktī. Tādēļ faktiski paliek 4,5 darba dienas dzīvā testēšanai un kļūdu labošanai, ja rodas kļūdas.

Jūsu vietnes esošā stāvokļa protokolēšana

Kas?	Īss apraksts	Testa rīks	Pašreizējā vērtība	Mērķa vērtība
Tehnika & Meta	Lapas nosaukums, virsraksti, meta dati, alt-teksti, …	Seobility
Struktūra	Pāradresācijas, kļūdaini saiti, sītēmpas, ...	Seobility
Saturs	Aptuveno vārdu saskaņošana, drukas kļūdas, pārāk maz teksti, ...	Seobility
Attēlu SEO	bez
OG dati ievietoti	Open Graph dati sociālajiem tīkliem	Open Graph pārbaudītājs
Strukturētie dati (uzskaites shēma)	Uzskaites marķēšana / strukturētie dati	Schema.org
Lapas ātrdarbība	Lapas ātrdarbība mobilajā/desktop versijā	Lapu ātruma analizētājs
Landing page ātrdarbība	Lapas ātrdarbība mobilajā/desktop versijā	Lapu ātruma analizētājs
Kategorijas lappuses ātrdarbība	Lapas ātrdarbība mobilajā/desktop versijā	Lapu ātruma analizētājs
Produkta lapas ātrdarbība	Lapas ātrdarbība mobilajā/desktop versijā	Lapu ātruma analizētājs
Blogs lappuses ātrdarbība	Lapas ātrdarbība mobilajā/desktop versijā	Lapu ātruma analizētājs
Pieejamība pēc lappušu veidiem	Pieejamības nodrošināšana ierobežotiem lietotāju grupām	Pieejamības pārbaudītājs un/vai wave.webaim.org
Hreflang pārbaude		Hreflang pārbaudes rīks
Srodes galvene	Uzticībai un drošībai	SecurityHeaders.com
Veselības pārbaude	Uzticībai un drošībai	Drošības auditu (Astra)
Parveidotājs & Ierīces tests	Edge, Firefox, Safari, Chrome desktop & mobilie, iOs & Android	Dev rīki / Lambdatest
Sīkdatņu politika & GDPR	Atļaujas sīkdatņu politika un GDPR atbilstība	Cookie Metrix
Robota & sistēmas statuss	Robota.txt izraisīšana, DNS risinājums, servera savienojums	Google meklēšanas konsole
Rasējumu statistika	Pieprasījumi, lejupielāžu izmērs, vidējais reakcijas laiks	Google meklēšanas konsol
Klikšķi SERP'os	Pēc laika perioda (mēneša/90 dienas, ...)	Google meklēšanas konsol
Iespējamā SERP'u iespaida	Pēc laika perioda (mēneša/90 dienas, ...)	Google meklēšanas konsol
Vidējā CTR SERP'os	Pēc laika perioda (mēneša/90 dienas, ...)	Google meklēšanas konsol
Vidējā SERP pozīcija	Pēc laika perioda (mēneša/90 dienas, ...)	Google meklēšanas konsol
Galveno web svaru testējums	Rankinga faktors priekš lietotāju pieredzes (PageSpeed, mobilā optimizācija, ...)	Google Sarakstā atradīsi SEO rīku Seobility kā OnPage faktoru pārbaudes rīku, ko mēs izmantojam, un par to ir publicēts arī SEO apmācība. Ir daudz līdzīgu rīku kā Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog utt. SEO rīka galvenais nolūks ir identificēt un novērst tipiskas OnPage kļūdas. Šeit svarīgākie ir trīs pamata aspekti - Tehnika & Meta, Struktūra un Saturs, kā Seobility veido analīzes. Līdzīgā veidā to varēsi atrast arī citos SEO rīkos. Svarīgi ir, lai vienmēr notiktu pilns pārbaude, tāpēc JŪS saiti, kuras tiek indeksētas, un ne tikai sākumlapu, un, no otras puses, lai ievadītu rezultātu vērtējumu vai kļūdu vērtību pašreizējai situācijai un mērķa vērtību, kas jāsasniedz pēc optimizācijas. Seobility gadījumā vēlams vērtība virs 90. Tāpat arī citi noderīgi rīki ir pieejami citiem mērķiem. Svarīgi ir izmantot kādu no šiem rīkiem, lai nodrošinātu izcilus datus. Šeit ir piemērs par mūsu pašreizējo OnPage kvalitātes novērtējumu: Lietotāju signālus var statistiski reģistrēt, izmantojot rādītājus no Google Analytics 4, piemēram, nokļūšanas līmeni, lapas/apmeklētāju skaitu, uzturēšanas laiku u.c. Ja Google Analytics vai kāds cits analīzes rīks tiek izmantots atbilstoši datu aizsardzībai, šie dati arī jāiekļauj pašreizējā situācijas protokolā.  Nepieciešams sagatavot backlinku sarakstu, kas var piemēram, bez maksas tikt veidots šeit: https://www.seobility.net/de/backlinkcheck/ Papildus nepieciešams saglabāt veco sitemap.xml, kā arī pilnīgu rezerves kopiju lapas. Visas svarīgās lapas arī jāpārvērš sarakstā Google Sheet formātā, kas kļūst par izvērstās URL pāradresācijas kartes sākumpunktu. Šāds CSV saraksts var viegli tikt eksportēts izmantojot SEO rīku Seobility. URL pāradresācijas kartē ietvertas visas svarīgās un linkotas lapas, kas vēlāk būs jānovirza uz jaunām lapas URL sakritībām. Nozūdījušās URL lapas jānovirza uz jaunajām, atbilstošajām vecajām URL lapām. Tāpēc ir svarīgi novērst pāradresācijas ķēdes! Vecās, joprojām pastāvošās pāradresācijas jānovirza tieši uz jauno galējo URL saiti. Līdzīgi, būtu jāņem vērā arī PDF failu un attēlu saites, uz kurām eksistē saites, lai arī tās tiktu pareizi novirzītas un nekļūtu par 404 saiti. Pāradresācijas tiek iestatītas kā 301-redirects, pamatojoties uz URL pāradresācijas karti .htaccess, arī pāradresācijas kartes izmantojot Vhost konfigurāciju vai datubāzes risinājumu. Klientam būtu jāspēj pats veikt šo uzturēšanu. Svarīgi ir nodrošināt, ka pāradresācijas ir ilgtermiņā stabili. Tāpat ir ieteicams saglabāt katru sadaļu ar pilnu lapas satura ekrānuzņēmumu. Tas ir, pirmkārt, jaunu datu saglabāšanas veids, ja pēc publiskošanas rodas jautājumi, vai saturu veidi netika pārnesti utt. Pamatojoties uz esošajām lapām, funkcijām un saturu un mērķtiecīgu datu analīzes rezultātiem, ir iespējams nosaukt, kas jau darbojas labi un kas ir jāuzlabo jomā, kur slēpjas optimizācijas potenciāls, kas būtu jāuzlabo pēc atjaunošanas. Checkliste: Pirms atjaunošanas Kad lietotāja saskarnes dizains ir apstiprināts un aģentūra strādā attīstības sprintā, noderēs šāda pārbaudes sarakste, kas hronoloģiski uzskaita galvenos punktus līdz atjaunošanas dienai: Attiecīgai testēšanai pieejama izstrādes vide, kurai ir piekļuve visiem iesaistītajiem Attiecīgai izstrādes videi nav piekļuves indeksam Attiecīgās izstrādes vides testēšanas rīkiem ir piekļuve (IP atļauja vai http ienākšana) ir iestatīta Izstrādes videi ir konfigurācija, kas pēc iespējas atbilstīga dzīvās sistēmas konfigurācijai Izstrādes vides lapu struktūra atbilst vēlākās dzīvās lapas struktūrai Matadata no vecajām datnēm ir pārnesta Satura pielāgojumi ir veikti Tika veikta attēlu SEO optimizācija 301 pāradresācijas, pamatojoties uz URL pāradresācijas karti, ir iestatītas  Veikts OnPage pārbaudi ar Seobility, kļūdas ir novērstas, un mērķa vērtības ir sasniegtas Open-Graph dati ir derīgi Strukturētie dati ir derīgi Visu lapu tipu Pagespeed pārbaude ir veikta, un mērķa vērtības ir sasniegtas Satura sīkdatņu politika darbojas Drošības galvenes ir iestatītas Pieejamība ir nodrošināta, un mērķa vērtības ir sasniegtas Hreflang ir derīgi (pie daudzvalodu lapām) Juridiskie teksti (Lietošanas noteikumi, Par mums, Atsaukšanas tiesības, Konfidencialitāte) ir atjaunoti, un tie atbilst GDPR prasībām CMS, ietvaru, izmantoto spraudņu un moduļu atjaunināšana uz jaunāko versiju ir veikta Beigu browsera un ierīču funkciju pārbaude nav atklājusi kļūdas Beigu statuss un starta datums ir zināmi  Pilnīga rezerves kopija ir izveidota Strukturēto datu (Schema-Markup) izmantošana - skat. saraksta 12. punktu - joprojām tiek pārāk maz ņemta vērā. Iepazīsties ar šo tēmu un lasi, kā Google stāsta par strukturēto datu atzīmi Google meklēšanā. Google arvien vairāk vērtēs derīgus datus SGE ietvaros, tātad, arī caurvietotus rezultātus, kas radīti ar īstenošanas palīdzību, ka saturu ļoti cieši pārbauda ekspertīze, pieredze, autoritāte un uzticamība. Strukturētie dati ir daļa no risinājuma, lai šo validāciju vienkāršotu Google labā. Pēc strukturēto datu iekļaušanas izmantošanas iespējams Schema-Markup validētāju, bet pārbaudi arī ar Structed Data Linter, ko Google iesaka un kurš ir iekļauts PageSpeed Insights. Tā tiek sniegti plašāki pārskati par kļūdām, kas saistītas ar strukturēto datu izmantošanas kļūdām. Strukturēto datu izmantošana vietnēs vairs nav opcija, bet nosacījums. Google prasa no tevis derīgu un uzticamu saturu. Ja nevēlies atpalikt no AI atbalstītajiem meklēšanas rezultātiem, rūpējies par shēmu iezīmēšanu savos lapas! 16. punktā tagad pirmo reizi šajā rakstā parādās pieejamība . Jau PageSpeed Insights pieejamībai ir sava joma, un zaļās skaitļi šeit ir vēlams. Pārbaude, vai lapa ir pieejama, jāveic ne tikai, pamatojoties uz PageSpeed Insights, bet arī caur https://www.accessibilitychecker.org un/vai https://wave.webaim.org. It īpaši, ja gatavojas atjaunošana, šim punktam jābūt obligāti jāņem vērā, jo tīmekļa vietnēm jau no 2025. gada ar pieejamības stiprināšanas likumu šis jautājums kļūs aktuāls. Pārbaudiet ar šādu rīku ne tikai sākumlapas, bet arī katru lapas veidu – tas pats attiecas uz PageSpeed testiem! Atjaunojot, bieži mainās un notiek atjauninājumi attiecībā uz juridiskajiem tekstiem. Šim jautājumam ir jābūt aktualizētam laicīgi, ir jāņem vērā, ka tekstus varētu nodrošināt kompetents jurists vai juridisko ģeneratoru. Tāpat ir jāapsver arī uzsākamo datu apstrādes līgumu, ja, piemēram, tiek izmantots jauns tīmekļa izmitinātājs vai mainās biļetenu pakalpojums.  18. punkts ar CMS atjauninājumu, izmantotajām JavaScript bibliotēkām, uzstādītajiem moduļiem un spraudņiem, ir tikpat novērtēts kā svarīgs. Atjaunošanai var paiet vairāki mēneši un ilgāk. Ar WordPress sistēmu ir viegli pārliecināties, vai pirms atjaunošanas dienas jau ir pieejamas daudzas atjauninājumu versijas. Šeit klientiem vajadzētu nodrošināties, ka jaunākie versijas tiek lietotas darbības sākumā.   Uzņemoties atbildību par mainīgiem ārējiem pakalpojumiem, parādās papildu uzdevumi, kuriem vajadzētu tikt minētiem arī kontrolsarakstā, piemēram, kad tiek veiktas izmaiņas biļetenu pakalpojumā:  Biļetenu kontaktinformācijas importēšana jaunajā biļetenu pakalpojumā Savienošana ar biļetenu pakalpojumu vietnē reģistrēšanās veidlapā AV līgums Jaunu mērķpasta veidņu izveide un tā tālāk  Visu attīstības laikā turpinās nepārtrauktas funkciju u.c. pārbaudes. Ir saprātīgi izveidot ļoti detalizētu pārbaudes sarakstu, lai nekas netiktu aizmirsts. Nav pietiekami tikai nedaudz pārbaudīt kā izpildītājam aģentūrā, tā arī klientam. Pēc mūsu TutKit.com atjaunošanas mūsu pieņemšanas pārbaudes sarakstā noteikti bija 1 000 rindiņas. Un tā mēs turpinām darīt līdz šai dienai: pēc svarīgiem lielajiem atjauninājumiem mēs pārbaudām aptuveni 70 interakcijas, izmantojot pārbaudes sarakstu Chrome, Safari un Android lietojumprogrammas. Atjaunošanas dienas un nākamās dienas kontrolsaraksts Atjaunošanas diena ir pienākusi, un tā nav ne pirmdiena, ne arī diena starp svētkiem. Tiek publicēta jauna vietne, DNS iestatījumi ir pielāgoti. Tagad jāpārbauda un jānovērtē viss no jauna. Pārbaudiet šādus punktus:  Pārbaudiet robots.txt, lai roboti nebūtu bloķēti  Tiešsaistes videi jādarbojas ar indeksu un seko   Kanoniskie tagi ir pareizi iestatīti Pārlūkprogrammas tekstuālajā saturā pārbaudiet absolūtos ceļus (Testvides saites no testa vide uz dzīvajām lapām) Pārvietojums no http uz https ar/bez www uz galamērķlapu sākumlapā un apakšlappās darbojas Pārbaudiet pāradresācijas caur URL pāradresācijas karti, kā arī pārbaudiet pāradresāciju ķēdes klātbūtni Uz vietnes dzīvajā lapā veiciet Seobility OnPage pārbaudi tehniskajam & Meta, struktūrai un saturam ... jo īpaši pārbaudiet lappuses, kur liek Noindex un kas tiek izlikts caur Seobility Open-Graph dati ir derīgi Strukturētie dati ir derīgi Pārbaude Pagespeed visiem lappušu veidiem ir veikta, sasniegti ir mērķa rādītāji Sīkdatņu politika ar piekrišanas sīkdatņu rīku darbojas tāpat kā jā Drošības galvenes ir iestatītas Ir pieejama pieejamība Hreflang pārbaude daudzvalodu tīmekļa vietnē (https://app.sistrix.com/de/hreflang-validator) Pabeidziet pārlūkprogrammas un ierīču funkcijas pārbaudi un nesaņemiet kļūdas Iesniedziet jaunu sitemap.xml Google Search Console Atjauniniet jaunās mērķlapas Google Ads kampaņās Noteiktos domēnu maiņu gadījumos domājiet par saitēm sociālajos tīklos, e-pastu parakstos utt. Mēs savā izstrādes vidē izmantojam Mailhog, lai lokāli pārbaudītu e-pastus. Šādos gadījumos ir svarīgi, lai pareizie SMTP dati būtu uzstādīti dzīvajā sistēmā e-pasta saņemšanai, lai e-pasta ziņojumi nonāktu tur, kur tie ir paredzēti. Līdzīgi ar to ir jārūpējas par maksājumu sniedzējiem kā PayPal izstrādes sistēmā ir Sandbox iekļauts, bet, protams, dzīves sistēmā jānoslēdz pareizais savienojums. Nākamajās dienās ir svarīgi uzmanīgi seko darbībai Google Search Console. Galvenokārt ir interesanti, kā mainās tavi reitingi. Savu uzmanību īpaši veltiet negaidītam maiņām un kļūdu paziņojumiem: Rašotņu varoņa statuss ... robots.txt izgūšana, DNS izšķirtspēja, servera savienojums Rašotņu statistika ... Pieprasījumi, lejupielādes izmērs, vidējais reakcijas laiks Noklikšķinājumi SERP Impresijas SERP Vidējais CTR SERP Vidējā SERP pozīcija Kodola tīmekļa svarīgāko sasniegumu  Galvenokārt Google meklēšanas konsolē tiek uzrunātas kļūdas, piemēram, URL kļūdas, href-lang kļūdas, lapu indeksēšana ar madžora indeksu/nē indeksu. Ja lapa ir nē indeksēta, tam jābūt iemeslam (pāradresēšana, noindex)...). Tur tu redzi dublētu saturu vai citus problēmas. Ja Meklēšanas konsole ziņo par problēmām ar strukturētiem datiem vai kodola tīmekļa svarīgākiem sasniegumiem, izpēti to. Tikai dzīvie dati sniegs tev informāciju, piemēram, ka tavām lapām, neskatoties uz augsto lapas ātrumu, ir problēmas ar kodola tīmekļa svarīgākajiem sasniegumiem, piemēram, ar CLS kļūdām. Šeit labi redzams, kādas izmaiņas ir iespējamas vietnes veiktajos uzlabojumos: Tu vari uzreiz redzēt sliktās vai optimizējamas URL. ņem URL un veic ar to PageSpeed testu izmantojot PageSpeed Insights. Tur tu saņemsi norādes, kāpēc kodola tīmekļa svarīgākie sasniegumi nav izpildīti un ko vari darīt, lai novērstu kļūdas. Lai saņemtu plašāku informāciju, norāmčīt uz leju mazo bulti labajā pusē. Parasti šīs ieteikumus var realizēt tikai izstrādātāji. Bet ir svarīgi, lai tu būtu spējīgs identificēt problēmas, lai ar to pēc tam nodarbotos kopā ar savu aģentūru. Tāpat izvērtē savus datus no analīzes rīkiem, piemēram, no Google Analytics 4. Arī seko līdzi mērījumiem, ko vari sistēmiski saglabāt, tātad piemēram, rezervācijas, konversiju ātrums, iepirkumu grozs, pirkumi/ievārce dienā, abonēšanās ziņu vārdiem, saziņas pieprasījumi, noteikta satura lejupielādes vai video skatījumi.  Rašotņu statistika Google meklēšanas konsolē ir būtiska turpmākajām pārbaudēm. Tu vari atrast šos iestatījumus kreisajā izvēlnē. Tas patlaban vajadzētu rādīt vairāk cīņas aktivitātes. Ja tas nenotiek, vai pastāv cīņas kļūdas? Hoststatus tev uzreiz parāda kļūdas, piemēram, te bija saskatāmas pēc Relaunch, kad crawlprasības uz robots.txt bija neveiksmīgas un servera savienojums daļēji vai pilnībā pārtraucās: Interesanti ir arī tas, ko norāda rašotnes statistika. Pēc Relaunch parasti notiek dzīvošās aktivitātes pašreizē's. Tur tu vari redzēt, vai tiek rašoti vēl 404 lapas. Ja daži nesakrīt ar kopējo plūsmu, pārrunā tos ar attīstītājiem. Tu sapratīsi, vai tavs serveris, tavs PageSpeed un tava koda relatīvi ir labi, ja tavu lapu reakcijas laiks ir zem 400. Jo tuvāk tam, ka tas sasniedz 1000 ms, jo vairāk iesakāma ir PageSpeed optimizācija, piemēram, samazinot datu bāzes vaicājumus un pastiprinot servera jaudu (piemēram, vairāk skaitļotāju jauda, atjaunināšana uz jaunāko servera programmatūru, pāreja uz HTTP2 vai HTTP3 (izmantojot Nginx)). Perspektīvā vienāda vietņu krieviskumaār naudas plūsmas budžets var tikt robežots, tādēļ arī šeit vajadzētu mērķēt uz labu vērtību lapas atbildes laikam, lai robota būtu iespējams pēc iespējas vairāk celt uz jūsu lapām pieejamajā laikā. Relaunch-Checkliste zum Download Iepriekš iegultās Reģistrēšanās sarakstu atjaunošana ir pieejama arī kā PDF failu, lai varētu to lejupielādēt. Lejupielādē to un nodrošini savu projekta veiksmi! Bekentnisse eines Agenturinhabers SEO prasības sarakstā varētu būt arī detalizētas instrukcijas, piemēram, uzmanību pievēršana virsrakstu struktūrai no H1 līdz H6 un tā tālāk. Testa rīku testu vērtību noteikšana saīsina visu atjaunošanas kochecklistē ietvaru, jo šīs vērtības sasniegšana testa rīkos, kas minēti sarakstā, var notikt tikai, ja tiek iestrādāts tīrs kods, izmantojot jaunākās tehnoloģijas, ievērojot SEO lapā ierīces faktorus utt. Otrādi, ja tiek formulēti visjaunākie tīmekļa standarti un tehnikas, kā arī SEO prasības ļoti detalizēti, tas lietas plānošanā izmaksu aprēķināšanā iespējams visu precīzu, tāpēc klienti pat tehnisko ziņā nav spējīgi pasūtīt. Agentūrām ir jāsasniedz augstas vērtības teste, tāpēc viņiem nav citas iespējas darboties kā darba prakse - šī ir jauna pieredze arī aģentūrām :-) Ir laiks atzīt. SEO prasību definēšana, kā arī saraksta veida darbības ar mērķa vērtību nodrošināšanu dažādos testa rīkos ir ideāls risinājums, kas realitātē reti sastopams. Tas atkarīgs no: klientu budžeta ierobežojumi aģentūras peļņas optimizācijas intereses ierobežojumi, kas radušies sakarā ar izmantotajām tehnoloģijām un, diemžēl, nezināšanas un nekompetence no abām pusēm Klientiem es nevaru uzlikt vainu. Viņi tieši meklē profesionālu palīdzību, un praktiski katrs digitālā aģentūra savā mājas lapā un baltajos papīros norāda, ka SEO ir viens no tās pamata jomām. Viņi vienmēr parāda atsauces, kas pierāda, ka pēc izlaides tiešsaistes redzamība ir pieaugusi par faktoru 3, 5 vai pat 10. Tas, ka no 10 apmeklētājiem tagad nāk 100 dienā, ir 1000% palielinājums, bet tas vēl nenozīmē veiksmi. Daudzus SEO panākumus nosaka tas, ka digitālie konkurenti ir vienkārši daudz vājāk pozicionēti digitāli. Aģentūras turpina veikt viduvēju darbu ar novecojušām metodēm, jo līdz šai dienai tās nelieto modernas kvalitātes nodrošināšanas rīkus, lai gan tie ir lieloši ierakstos, atsauces, labās prakses ziņojumos utt., ka tām ir SEO kompetence. Varbūt šādas aģentūras ir zināšanu milzu, bet tajā pašā laikā tās ir rīcības cīņas zemnieki. Tas skan stingri, bet tā ir realitāte. Tiešām. Iepazieties ar to vēl rūpīgāk! Izvērtējiet augstāk minēto pārbaudes sarakstu un ievietojiet savā reģionā labāko aģentūru ar tās vietni minētajos rīkos. Un pēc tam izvēlieties jaunāko vietnes atsauces, ko atradīsit no aģentūras, un atkārtoti to darīt. Kādus rezultātus jūs redzēsiet? Tieši tos, ko jūs varētu sagaidīt sadarbībā. Arī mūsu pašu atsauces varat pārbaudīt un secināt, ka mēs pati savos klientu projektos nesasniedzam augstākos rādītājus visur. Tāds darbplūsmas veids, attieksme pret datorpamatotu kvalitātes nodrošināšanu mūsu gadījumā ir augusi no projekta uz projektu, un tas ir nostabilizējies īpaši pateicoties mūsu darbam pie TutKit.com.  Tādas pārbaudes varat veikt ar gandrīz jebkuru aģentūru, jo tikai paraugi patiesībā strādā ar datiem kvalitātes nodrošinas jomā, jo neviena no tām nav stratēģiski kārtīgi darbojusies ar saviem projektiem tirgū gadu gaitā un nesalīdzinās sevi ar starptautiskiem spēlētājiem cīņā par tiešsaistes redzamību, un tāpēc aģentūrai gandrīz vienalga, vai projekts ir veicies vai ne, kamēr tikai maksā aģentūras rēķinu un klienti var priecāties par skaistajām (bet kvalitātes ziņā viduvējajām) vietnēm savos ierakstos un ar balvām. Neparastā ironija šeit ir tāda, ka, atbilstoši minētajiem pārbaudes rīkiem, bieži vien tieši SEO aģentūras ar savām pašu vietnēm sniedz sliktākos rezultātus, jo tās bieži vien darbojas kā viengalvainīgie ... kā saturpakete, kas veidota klienta atslēgvārdiem vietnei. Citām tehniskajām prasībām bieži vien vienkārši trūkst kompetentu programmētāju. Par priekšrocībām būtu arī tas, ja aģentūra atrastos citā vietā, un klientam nevajadzētu sastapties ar kādu no aģentūras darbiniekiem veikalu būvniecības noliktuvē, kurš vienkārši atbildē par divciparu procentuālu redzamības zaudējumu pēc izlaides. Tomēr šādu redzamības zaudējumu klienti parasti nemēra pēc, jo, lai arī visiem ir sīkdatņu piekrišanas josla, maz ticami, ka daudzi patiesi analizē skaitļus un izdara darbības plānus. Ja rodas šaubas, tad vienkārši jāpalielina AdSpend budžets. Tas, ka šodien organiskais reitings ir atkarīgs no liela skaita saturiski salīdzinoši labi pozicionētu vietņu, galvenokārt no tehniskajiem parametriem, lietotāju signāliem un (joprojām) saitēm, klienti, par laimi, parasti nenojauš. Un caur AI teksta rīkiem vietnes saturisks līmenis palielināsies nebijušā apjomā un kvalitātē, ļaujot mums tuvākajā nākotnē sveikt daudzas jaunas ārzemju vietnes mūsu valsts valodā SERP, jo caur AI tulkošanas rīkiem kļūs arvien vieglāk tulko arī tiešsaistes veikalus, portālus, SAAS un citas vietnes un iebrukt digitālajā mājvietē. Noslēgums par datiem balstītai vietnes atjaunošanas pārbaudes sarakstam Tāds datiem balstīts pārbaudes saraksts ir viens no retajiem efektīvajiem veidiem, kā piespiest aģentūras veikt labu darbu. Pat ieteicams noteikt, ka noteiktu vērtību sasniegšanai testa rīkos ir jābūt pieņemamo nosacījumu. Līgumā būtu jānosaka, ka daļēju maksājumu par projektu var izrakstīt tikai pēc četrām nedēļām pēc izlaides, ja ir pieejami visi svarīgie dati un augstie rādītāji, piemēram, Core Web Vitals un validētie produkta fragmenti pēc shēmas iestatījumiem Search Console. Izmantojot šo darbplūsmu - kā aprakstīts šajā rakstā - jūsu redzamības zudums pēc izlaides ar būtiskām saturiskām, strukturālām un tehniskajām izmaiņām būs ierobežots, un jūs radīsit pamatu tam, ka Google drīzāk pakāros jūsu vietni vai tiešsaistes veikalu augstāk. Ja šis raksts bija interesants, droši aplūko arī citus mūsu satura materiālus: 1101,908,1066,1086