Újraindítási lista az online áruházak, foglalási és vállalati webhelyek számára.

Egy weboldal újraindítása előtt állok? Gratulálok, hogy megtaláltad ezt a cikket. A következő megjegyzések talán döntő hozzájárulást jelenthetnek ahhoz, hogy a weboldalad újraindítása sikerüljön, és fantasztikus eredményt érj el. Mert ez nem mindig a helyzet. Ügynökségvezető vagyok, és pontosan azt árulom el neked, ami lehetővé teszi, hogy olyan emberekkel, mint én, kiemelkedően jó munkát végezz, és megakadályozza a weboldalak újraindításánál tipikus hibákat. De kezdjük elölről.

Egy weboldal újraindítása a meglévő weboldal átdolgozását és megújítását jelenti. Ezen folyamat során megváltoztatható a design, a tartalom és a technika is. A weboldal újraindításának célja a weboldal javítása és az aktuális követelményekhez való igazítása.

Bizonyos külső okok hatására indul el az "újraindítás" folyamata az üzleti szférában: az újonnan felvett munkatárs jó ötletekkel érkezik, új főnök érkezik és digitális téren is rendet akar rakni, a versenytársak új weboldallal rukkolnak elő, vagy csökken az árbevétel. Lehet, hogy a főnök feleségének sem tetszik az régi oldal vagy a Z generációnak nem elég vonzó a webhely. Talán te is ismered ezt. Az sem indok azonban, hogy új weboldalra legyen szükség, ahogy a személyes vélemény sem.

Azonban vannak ennél jóval jobb okok, amiért egy vállalat vagy szervezet weboldal-újraindítást szeretne végrehajtani. A legfontosabb okok közé tartoznak:

• Elavult design és/vagy rebranding: Egy elavult weboldal azt a benyomást kelti, hogy a vállalat nem lépést tart a korral, vagy már nem aktív. Egy friss, modern design javítja a vállalat imázsát. Ha egy márkaarculat vagy vállalati azonosság változik, gyakran a weboldal újraindítása is kívánatos, hogy tükrözze az új márkakommunikációt.
• Jobb felhasználói élmény: Ha egy weboldal felhasználóbarát szerkezetűtlen, ez magas lemorzsolódási arányhoz vezethet. Az újraindítás arra szolgálhat, hogy javítsa a felhasználói élményt és könnyen navigálhatóvá tegye a weboldalt.
• Mobileszközökön való optimalizálás: Mivel egyre többen mobil eszközökről férnek hozzá webhelyekhez, fontos, hogy a weboldal jól működjön különböző kijelzőméreten és eszközökön.
• Keresőmotormarketing (SEO): Az elavult weboldalak új kihívások elé állíthatják az SEO-teljesítményt. Az újraindítás lehetőséget teremthet SEO-barát változtatások végrehajtására, hogy javítsa a weboldal láthatóságát a keresőmotorokban.
• Tartalmi frissítések: Ha az egy vállalat információi, szolgáltatásai vagy termékei megváltoznak, a weboldalt frissíteni kell ezeknek a változásoknak megfelelően.
• Biztonságjavítások: Az idősebb weboldalak gyakran sebezhetőbbek a biztonsági kockázatokra. Az újraindítás a webhely biztonságának javítására és a kiberbűnözés elleni védelemre szolgálhat.
• Technológiai frissítések: Az elavult technológiák használata befolyásolhatja a weboldal teljesítményét. Az újraindítás lehetőséget kínál a friss webtechnológiákra és -platformokra való áttérésre.
• Hozzáférhetőség: A hozzáférhetőség javítása sok webhely számára fontos szempont, hogy biztosítsa a fogyatékkal élő emberek számára való hozzáférést.
• Versenyképesség: A versenytársakkal lépést tartani fontos, ezért fontos, hogy egy modern és hatékony weboldal legyen. Az újraindítás hozzájárulhat a versenyképesség megőrzéséhez vagy növeléséhez.
• Analitikai javítások: A jobb elemzőeszközök bevezetése és az adatgyűjtés révén a vállalatok jobban megérthetik és optimalizálhatják a webhelyük teljesítményét.
• Összhang a jogi követelményekkel: Az adatvédelem, hozzáférhetőség és biztonság területén érvényes törvények és előírások rendszeresen megváltoznak. Az újraindítás szükséges lehet annak biztosításához, hogy a weboldal ezeknek a követelményeknek megfeleljen.

Ezek az okok egymagukban vagy kombinációban jelentkezhetnek, és változhatnak a vállalat céljai és igényei szerint. A weboldal újraindítása gyakran stratégiai döntés, hogy az online jelenlétet javítsa és elérje a vállalat céljait. Ha megnézed az idézett pontokat egyenként, akkor világossá válik, hogy a legtöbb ok kisebb sprintekkel is megvalósítható, és nem igényel nagy jelentőségű weboldal-újraindítást.

Ezért különbséget kell tennünk, hogy mi a weboldal-újraindítás, és mi nem: Az új design a meglévő technikai alapokkal inkább csak egy arculatfelújítás. Az újraindítás csak akkor történik meg, ha a weboldal újraindításának céljával valódi változás következik be a felhasználói élményben, a működésben és a technikai alapokon.

A weboldal-újraindítást mindig tények (pl. a technika zsákutcába került, és már nem frissíthető), mutatók, valamint mérési és összehasonlítási adatok alapján kell alátámasztani.

Ez az első ajánlásom ezen a ponton: Evolúció forradalom előtt! Kerüld el az oldal újraindítását addig, amíg csak lehet, és próbáld megvalósítani minden olyan pontot, amelyeket eddig weboldal-újraindításra hoztak fel, egyenként vagy inkrementálisan. Javíts meg egy dolgot, tegye közzé, értékelje ki, mi történik, módosítsa újra vagy folytassa a következő ponttal. A legjobb példa az Amazon, akik csak minimális változásokat hajtanak végre és javítanak, és már évek óta nem hajtanak végre nagy jelentőségű weboldal-újraindításokat.

A weboldal-újraindítás mindig nagy kockázatot jelent a Google-láthatóságod szempontjából. Mindenki az előnyöket figyeli, de kevesen a kockázatot. Természetesen javul az felhasználói felület, nő a pozitív felhasználói élmény, technikailag ismét naprakész leszel. Mégis: ha az üzleti sikered erős organikus láthatóságtól függ, akkor az újraindítás az utolsó eszköz és csak akkor döntsd el, ha a fájdalmad elég nagy az említett okok kombinációja által, amelyek már nem egyenként megoldhatók külön sprintekben. Miért? Nézd meg itt, mi történt a négy weboldal ilyen jellegű újraindítását követően az online láthatóságukkal:

Tervezd meg alaposan az újraindítást, és biztosítsd a sikeres megvalósítást egy ellenőrzőlista segítségével. Főként állítsd be az alábbi két célt: egyrészt tartsd fent online láthatóságodat, másrészt találj módot a megújulás keretein belül az online láthatóság növelésére. Ez az a cikk pontosan arról szól, hogy biztosítson egy újraindítási útmutatót, hogy a kockázatok a minimumon maradjanak, és tényleg olyan kiváló munkát végezz, amely hozzájárul a fenntartható, organikus SEO-sikerek eléréséhez.

Az újraindítás menetrendje

A weboldal újraindításának tervezése alaposan kell, hogy történjen. Fontos figyelembe venni a következő lépéseket:

• A meglévő webhely elemzése és az aktuális állapot feljegyzése: Elsőként érdemes elemző alá vetni a meglévő webhelyet, hogy az erősségeket és gyengeségeket azonosítani lehessen.
• Célok meghatározása: A webhely újraindításának céljait világosan meg kell határozni. Ilyenek lehetnek például a konverziós arány javítása, a látogatottság növelése vagy az áttérés egy új CMS-re, javított tartalomkezeléssel és karbantarthatósággal.
• Koncepció kidolgozása: Az elemzés és célok, valamint az versenytárselemzés alapján kidolgozandó egy koncepció a webhely újraindítására. A koncepciónak magába kell foglalnia a következő elemeket: dizájn, tartalom, technika és SEO/marketing.
• Megvalósítás: A koncepciót ezután meg kell valósítani. Ide tartozik a design kidolgozása, a tartalmak létrehozása/módosítása és a technikai változtatások végrehajtása.
• Tesztelés: Az új weboldalt ki kell próbálni a közzététel előtt annak érdekében, hogy biztosítsuk a hibamentes működést. Ehhez tartozik egy meghatározott ellenőrzőlista is.
• Közzététel: Az új weboldalat ezután közzéteszik. És továbbra is élőben tesztelik, kiértékelik és alkalmazzák a szükséges korrekciókat.

Az újraindítás céljainak és stratégiájának meghatározása

Határozd meg pontosan, hogy milyen célokat kívánsz elérni az újraindítással. A célok lehetnek (a fent említett okokon kívül): 

• Felhasználói élmény javítása
• Átláthatóság növelése
• Tartalomkínálat bővítése
• Dizájn modernizálása
• Bevétel és kosárérték növelése 
• Áttérés egy másik, könnyített tartalomkezelést és technikai karbantarthatóságot biztosító CMS-re
• jövőbeni könnyített bővíthetőség és frissíthetőség biztosítása.

Javaslat: A csapaton belül céges szinten az első kick-off találkozókat követően, még mielőtt megkezdenétek a végrehajtó ügynökségekkel való megbeszéléseket, minden projekt résztvevőjének fel kell jegyeznie az újraindítás céljait egy papírra vagy a kommunikációs eszközbe (pl. Slack). Ha ezután egyszerre mindenki bemutatja a megfogalmazott célokat, meglepődsz majd, mennyire különböznek a vélemények, holott már korábban beszéltek a célokról az egyeztetéseken. Ezért fontos, hogy a célokat írásban is rögzítsétek. Ha pontosan ismered a céljaidat, akkor már korai fázisban is ellenőrizheted a felhasználói felület prototípusát, hogy koncepcionálisan meg lett-e számítva.

Az újraindítási megbízásról szóló specifikáció kitűzettséget ad

Az ajánlatkészítéshez az ügynökségnek egy részletes projektbemutatóra van szüksége az ügyféltől. A vállalatok általában rendelkeznek egy Word-dokumentummal vagy egy PDF-fájllal, ahol többé-kevésbé részletesen szerepel a tervezet. Itt találhatók kérdőívek vagy munkacsoportok, amelyekkel az ügynökségek jobban kiemelhetik az ügyfél fájdalompontjait, hogy ajánlatot adhassanak. Nagyobb projektek esetén egy specifikációs táblázatot kell elkészíteni. Minél részletesebb, annál jobb. 

A specifikációs táblázat döntő szerepet játszik egy weboldal újraindításakor. Az a célja, hogy a követelményeket, célokat és elvárásokat írásban rögzítse a relaunch során. Egy komolyan kidolgozott specifikációs táblázat segít biztosítani, hogy minden érintett fél - akár a fejlesztőcsapat, a design csapat vagy az ügyfél - egyértelmű képet kapjon arról, hogy mely célokat kell elérni a relaunch során. Ez egyben a kiindulópont egy jól kalkulált és kötelező ajánlat a végrehajtó ügynökségtől. Itt találhatók azok az információk és elemek, amelyek általában egy specifikációs táblázatban szerepelhetnek egy weboldal újraindításához:

• Célok és cél: A relaunch fő célainak leírása, például a felhasználói élmény javítása, a láthatóság növelése a keresőkben vagy a CMS váltás a design frissítésével.
• Projekt terjedelme: Egyértelműen meghatározni, hogy mit tartalmaz a relaunch és mi nem. Ez magában foglalhatja az oldalak számát, a harmadik fél által biztosított eszközök integrálását vagy a tartalmak módosítását.
• Dizájnkövetelmények: Információk a webhely kívánt vizuális kialakításáról, beleértve a elrendezéseket és a vállalati arculat irányelveinek betartását a színekben, betűtípusokban és képekben.
• Funkcionalitási követelmények: A kívánt funkciók és interakciók részletes felsorolása a webhelyen, például kapcsolatfelvételi űrlapok, keresési funkciók, e-kereskedelem funkciók stb.
• Technikai követelmények: Műszaki specifikációk a megújítás során használt technológiákra vonatkozóan, mint például a tartalomkezelő rendszer (CMS) kiválasztása vagy bizonyos funkciók implementálása. Ebbe a modern kép- és grafikaformátumok (WebP, AVIF, SVG) használata is beleértendő.
• Manuális és automatikus tartalombiztonsági mentések és verziók az időbeli tartalomszerkesztéseknél.
• Tartalommegújítási követelmények: Világos utasítások a tartalmak felülvizsgálatához, frissítéséhez vagy újraindításához, beleértve a szövegeket, képeket, videókat és egyéb médiaelemeket. A metaadatok és a strukturált adatok kezelése.
• SEO-követelmények: róluk bővebben a következő tartalmi területben.
• Időterv és mérföldkövek: Egy időbeosztás, amely meghatározza a relaunch tervezett indulási és befejezési dátumait, valamint a fontos mérföldköveket.
• Költségvetés: Információk a relaunch költségvetéséről, beleértve a design, fejlesztés, tárhely és esetleges harmadik fél által nyújtott szolgáltatások költségeit.
• Minőségbiztosítás teszteszközökkel: A relaunch során alkalmazandó tesztek és minőségbiztosítási eljárások leírása a webhely hibamentes működésének biztosítása érdekében.
• Karbantartás és támogatási követelmények: Követelmények a webhely folyamatos karbantartására és támogatására a relaunch után.

Egy jól strukturált követelményspecifikáció elengedhetetlen a félreértések elkerülése érdekében, a projekt hatékony irányításához, valamint annak biztosításához, hogy az összes érintett felek elvárásai teljesüljenek. Ez iránymutatásként és referenciadokumentumként szolgál az egész projektcsapat számára, hozzájárulva a weboldal felújításának sikeréhez.

Mikor a TutKit.com felújítását terveztük, teljesen átváltottunk a CodIgniter keretrendszerről a Laravelre, követelményspecifikációnk 220 oldalt tartalmazott – nem túl csábító kilátás egy ügynökség számára, hogy nekivágjon ennek.

Jegyzet: A koncepcióra, dizájnra, funkcionalitásra és alkalmazott technológiákra nem térünk ki részletesen cikkemben. Az új weboldal biztosan gyönyörű lesz. A legnagyobb veszély a felújítás során a technikai felhasználói élmény és az OnPage minőség romlásában rejlik a hiányzó 301-es átirányítások miatt stb., ami azután rangsorolás- és láthatósági veszteséghez vezet. Ezt megelőzve a projektsiker biztosítására fókuszt kell helyezni a felhasználói élmény és az SEO szempontjából.

Az új weboldal SEO követelményeinek meghatározása

Ügyfél oldali megbízás vagy egy részletes követelményspecifikáció már szabályozza, hogy milyen tervezési, tartalmi, funkcionális és technikai igények vannak, és alapja annak, hogy egy ügynökség kalkulációt készíthessen. Az Felújítás Ellenőrzőlistája a projektsiker biztosítása szempontjából SEO szempontjából kell megvizsgálni az egyes részeket. Különleges SEO követelmények merülnek fel például:

• változó URL-struktúra (URL-átirányítási térkép!) és változó linkútvonalak
• változó navigáció (fontos az belső hivatkozások és linkhierarchia miatt)
• változó technológiák (CMS, JavaScript-Framework, kiszolgáló, ...)
• változó tartalmak (a jól rangsorolt oldalak potenciális láthatóságának elvesztése)

Az oldalak jó rangosok a Google-ben a tartalmi relevancia miatt, így fontosak a kérdések, hogy változnak-e a meglévő tartalmak, vagy összeolvadnak, eltűnnek-e tartalmak és/vagy új tartalmak kerülnek-e be? Változik-e a kategóriák vagy oldalak tartalmi szerkezete? Ebből a pontból kiindulva a SEO követelményeknek részei lesznek a Felújítás Ellenőrzőlistában.

Átkerülnek-e az általános metadatak az öregebb tartalmakról, és változnak-e? Hogyan történik a tartalomkezelés a szerkesztőnél, és kapcsolódnak-e a lapok szerkezetelt adatokhoz?

A meglévő vagy új képek modern webes képformátumokban (WebP/Avif) lesznek-e tárolva, és figyelembe veszik-e a képek SEO-ját beszédes URL-ekkel kisbetűkkel, például helyett 1234.jpg => hotel-ostsee-warnemuende_szobaterasz.avif.

Érdemes megfigyelni, hogy a képfájlokat strukturált adatokkal (képobjektum) és -bontva adják át a Google-nek, hogy növeljék a kép beágyazásának valószínűségét az értesítésekben, és a Google képek listájában való szereplést.

Érdekes kérdés ezen a területen, hogyan lehet a felhasználói jeleket javítani. Így az oldalakon lehetnek képvideók, magyarázó és segítő videók beágyazva. Ha egy felhasználó, aki a Google-ről érkezik a céllapra, rákattint a videóra és megtekinti, akkor növekszik a tartózkodási idő (jó felhasználói jel), és a visszatérés a keresési találati oldalra is javul (jó felhasználói jel).

Hasonlóképpen érdemes megvizsgálni, hogy hogyan lehet a tartalmi szekciókat az oldalakon integrálni, amelyek megfelelnek a Google jó tartalom létrehozására vonatkozó követelményeinek és az E-E-A-T elvnek.

A Google számára az „Hasznos Tartalom” olyan tartalom, amely releváns és hasznos a felhasználók számára. Átfogó és informatív válaszokat ad a felhasználók kérdéseire, megoldásokat nyújt problémákra, és értékkel szolgál, ami túlmutat a puszta reklámüzeneteken.

Íme néhány példa a hasznos tartalomra:

• Útmutatók és útmutatások: Ezek a tartalmak segítenek a felhasználóknak új feladatokat tanulni vagy meglévő problémákat megoldani.
• Vélemények és összehasonlítások: Ezek a tartalmak segítenek a felhasználóknak a megfelelő termék vagy szolgáltatás kiválasztásában.
• Hírek és frissítések: Ezek a tartalmak naprakészen tartják a felhasználókat az aktuális eseményekről és trendekről.
• Infografikák és diagramok: Ezek a tartalmak segíthetnek bonyolult adatok és információk vizualizálásában.
• Blogbejegyzések és cikkek: Ezek a tartalmak mélyebb betekintést kínálnak egy adott témába.

A Google különböző jelzéseket használ a hasznos tartalom felismerésére. Ezek közé tartoznak többek között:

• Felhasználói viselkedés: A Google figyelemmel kíséri, hogyan interakcióznak a felhasználók a tartalmakkal, például mennyi ideig tartanak az oldalon, milyen gyakran osztják meg és értékelik őket.
• Minőségi jelek: A Google értékeli a tartalmak minőségét olyan tényezők alapján, mint a relevancia, teljesség és aktualitás.
• Felhasználói visszajelzések: A Google figyelembe veszi a felhasználók visszajelzéseit, például értékeléseket és hozzászólásokat.
• A webhelytulajdonosok ezeket a jeleket figyelembe véve növelhetik annak esélyeit, hogy tartalmukat hasznosnak ítéljék meg.

A EEAT-elv egy olyan Google által kifejlesztett koncepció, amely értékeli a webhelyek és webes tartalmak minőségét. Az EEAT rövidítés a szakértelem, tapasztalat, autoritás és megbízhatóság kulcsszavakból tevődik össze, azaz szakértelem, tapasztalat, autoritás és megbízhatóság.

• A szakértelem a tartalmak létrehozására szolgáló személyek tudására és tapasztalatára vonatkozik. A Google a szakértelmet olyan tényezők alapján értékeli, mint a képzettség, a szakmai tapasztalat és az elismerések.
• A tapasztalat akkor igazolt, ha a tartalom létrehozása során is bizonyos tapasztalat szerepelt, például a termék tényleges használatának alapján, egy hely tényleges látogatásának alapján vagy valaki által átélt élmény leírásán alapulóan?
• Az autoritás a webhely vagy webes tartalom hírnevére és jó hírére vonatkozik. A Google az autoritást olyan tényezők alapján értékeli, mint a visszahivatkozások, a közösségi média tevékenységek és a felhasználói értékelések.
• A megbízhatóság a webhely vagy webes tartalom megbízhatóságára és hitelességére vonatkozik. A Google a megbízhatóságot olyan tényezők alapján értékeli, mint a adatvédelem, biztonság és átláthatóság.

Milyen SEO követelmények társulnak a meglévő és új funkciókhoz a frontend és backend vonatkozásában? Itt példaképpen arról van szó:  

• Behatolhatóság (az értékes tartalmaknak JavaScript nélkül is láthatóknak és átjárhatóknak kell lenniük)
• A webhely céljának és a Call-to-Action (a célközönség kívánt viselkedési módszerének) világossága
• Kerülje a duplikált tartalmat, például automatikusan létrehozott kategóriasorokat vagy oldalpéldányokat variáns elemekkel
• Biztosítson magas PageSpeed-et a túl sok JavaScript- és CSS-fájl elkerülésével, valamint a modern képformátumok (WebP/AVIF) használatával

Ezeket az SEO követelményeket be kell illeszteni a projekttervetbe vagy a követelmények specifikációjába, továbbá be kell építeni egy tesztelési lista vagy az IST-SOLL összehasonlítási folyamatba a projekt minőségbiztosításának részeként és továbbá az ügynökség teljesítményének elfogadási kritériumaként. Erről később bővebben.

A belső és külső projektrésztvevők meghatározása

Határozd meg a projektrésztvevőket - itt a megrendelő vagy a webhely tulajdonosa szemszögéből:

• Ki vállalja a projektkoordinációt és hozza meg a végső döntéseket?
• Ki felelős az ügynökséggel vagy a megrendelővel történő koordinációért és kommunikációjért?
• Ki látja el a belső projektmenedzsmentet?
• Ki készít belső tartalmakat és segítséget az ügynökség számára?
• Ki valósítja meg a felhasználói élmény tervezését?
• Ki valósítja meg a fejlesztést?
• Ki jelent az ügynökség felé meghatározott időközönként?
• Ki végzi az ügynökségi/megrendelői tesztelést és minőségbiztosítást?
• Bevonunk-e külső tanácsadót (például SEO vagy jogi követelmények tekintetében)?
• Ki jóváhagyja a feladatokat? Ki veszi át a feladatokat a ticketrendszerben a feldolgozást követően?
• Kinek kell mely időpontban tájékoztatni (munkavállalók, ügyfelek, partnerek, hirdetéskezelők, …)?

Négy fontos szempont az externális projektrésztvevők kiválasztásakor

1. Révénnyel rendelkezik-e az ügynökség egy vagy több ilyen jellegű projektet? Vannak-e referenciák? Léteznek-e ügyfélmegjegyzések és lenne-e lehetséges egy ügyféllel történő visszajelzési beszélgetés - amely ajánlott a nagyobb egyedi fejlesztések esetében?
   
2. Le vannak-e fedve az ajánlatteljesítés és a technikai megvalósítás (CMS/Boltrendszerek/Framework) által már azok az összes követelmények, amelyek a rediszajn kapcsán felmerülnek? Ellenőrizzük, hogy vannak-e olyan egyedi funkciók vagy követelmények, amelyeket még be kell programozni (akár bővítmény vagy modul formájában)? Bizonyos szolgáltatások szerepeltek-e az ajánlatban, amelyeket kivettek vagy későbbi időpontban jelöltek ki, de mégiscsak döntő fontosságúak a projekt sikeréhez? Fontos, hogy ne jöjjenek elő új problémák, amelyek nagyobbak, mint maga a rediszajn indoka.
   
3. Megfelel-e az alkalmazott ügynökség vagy szolgáltató mind a csapat méretétől, mind a regionális helytől és a (esetlegesen a Kununu-értékelések alapján meghatározható) munkavállalófluktuációtól a cég fenntartására? Együttműködésre való ösztönzés?
   
4. Létezik-e direkt kapcsolat az alkalmazott design- és fejlesztőcsapatokkal? Jó ötlet megismerni a tényleges ügynökségi projektcsapatot. A mosolygó és az égig ígérő értékesítési szakemberek adják az ügynökletet, majd már többé nem viselik a felelősséget. Ezért fontos, hogy egyenes kapcsolattartás legyen megállapítva az alkalmazott csapattal.

Négy tanács a saját biztosításod érdekében ebben az összefüggésben

1. Mint ügyfél, érdemes figyelemmel kísérned az ügynökség által használt technológiát. Ami az ajánlatban szerepel, azt érdemes egyszerűen keresni a “CMS + hátrányok” vagy “CMS + tapasztalatok” kulcsszavak segítségével. Tudnod kell, mire készülsz pontosan. Érdemes nyílt forráskódú megoldásokra támaszkodni. Tudom, ez nem mindig lehetséges. Legjobb, ha arra figyelsz, hogy minél nagyobb fejlesztői közösség álljon rendelkezésre a használt technológiához, hogy ne ess be mégis az ügynökség által kezelt saját, zárt rendszerbe, ami hosszú távon komoly korlátokat jelenthet számodra.
   
2. Ügyelj arra is, hogy elérd a korlátlan felhasználási és szerkesztési jogokat az ügynökség által nyújtott szolgáltatáshoz, hogy meglegyen a jogod a webhely belső vagy külső fejlesztésére. Ezt a passzust be kell illeszteni a vállalkozási egyezménybe.
   
3. Ha a vállalatod technikai szempontból jól felkészült, és a csapatban rendelkeztek rendszergazdákkal, szoftverfejlesztőkkel stb., akkor érdemes GIT-et használni a verziókezeléshez és a JIRA-t (vagy hasonló eszközt) a projektmenedzsmentre vagy a ticketrendszerre először magatok hozzátok létre a saját fiókodban. Ezt követően a teljes hozzáférést megadhatjátok az ügynökségnek és elkezdhetik a munkát. Egy nagyobb projekt esetén a helyzet nagyon durva és fájdalmas lehet. Az jó, ha a döntésekre és az accountokra te állsz uralmat. Persze tudom, hogy ez a javaslat műszakilag nézve csak néhány ügyfél számára követhető.
   
4. Néha előfordul, hogy az ügynökségek az ügyfelek számára közvetlenül webtárhely-szolgáltatást kínálnak. Mi nem rajongunk érte, mert egyfelől növeli a kapcsolatban való függést, másfelől úgy gondoljuk, hogy a webtárhelyek a legjobbak a webtárhelyek számára, mert erre szakosodtak. Volt már, hogy magunknak állítottunk fel és kezeltünk szervereket, és nagyon sok személyzet- és időerőforrást elhasználtunk. Visszavonultunk. Most a rendszereink németországi nagy webtárhelyek cloudszerverein futnak, és boldogok vagyunk. A webtárhely-ügyek vonatkozásában mindenképpen ügyelj rá, hogy a szerveroldali biztonsági mentések már részét képezzék a csomagodnak, amelyek néhány kattintással visszaállíthatók.

Időtartam és indítás dátumának meghatározása

Az újraindítást több projektszakaszban hajtják végre. Ezek a szakaszok tapasztalataink szerint lehetnek:

• A jelenlegi állapot rögzítése (tesztelőeszközökkel, de írásban is megjegyzésekkel, hogy ügyfélszempontból mi működik jól és hol szükséges javításokat végezni)
• Kutatási fázis versenykörnyezet-elemzéssel és megoldások/inspiráció keresésével
• Drótváz koncepció
• Felhasználói felület tervezése
• Frontend és backend fejlesztés
• Adatmigráció vagy tartalom importálás (automatikusan/kézzel)
• Strukturális és tartalmi tartalomoptimalizálás (szöveg és kép) & SEO-sprint

A projektszakaszok átfedésben vannak egymással, mert a feldolgozási folyamat során új projekt résztvevők aktiválódnak.

Fontos az egyedi projektszakaszok időtartamának meghatározása és a résztvevőkkel történő egyeztetés. 

Az ügynökség a kliens számára a projekt esetén, amennyiben nagyobb, mielőbb beállít egy saját Slack-csatornát a gyorsabb kommunikáció érdekében?

Egy tipp ezen a ponton: Jó, ha az ügynökség már nagyon korai szakaszban kattintható prototípusokkal dolgozik, tehát már a drótváz-koncepcióban, és különösen az alkalmazás- és a felhasználói felület tervezésénél. Így a kliensek jobban megérthetik az oldal élményét. Az egyszerű JPG- vagy PNG-fájlok mint elrendezési javaslat már nem időszerűek. Kattintható prototípusoknak kellene lenniük, amelyeket Sketch, Figma, Adobe XD vagy más professzionális eszköz segítségével alkotnak.

Ebben a korai szakaszban a változtatások könnyen végrehajthatók. Amikor egy webhely funkciói és szekciói már kifejlesztettek, a változtatások sokkal időigényesebbek és esetlegesen további tárgyalásokhoz vezetnek, ami abszolút nem vonzó.

Itt látható, hogy milyen is egy ilyen mobil felület kattintható prototípusa a navigációs csoportokkal együtt összefoglalva:

A kérdés, hogy mióta lehetséges a folyamatos tesztelés az ügyfél oldaláról. A fejlesztőknek lokális munkáikat is a Stage-rendszerbe történő egyesítés után tesztelniük kell. Talán banálnak tűnik, de mindenki, aki fejlesztőkkel dolgozik, azonnal érti, hogy mit jelent. Ezt követően a minőségbiztosítáért felelős személy teszteli a jegyet vagy a funkciót az ügynökség részéről. Csak ezután engedélyezett a jegy az ügyfél számára történő tesztelésre. Az ügyfélnek sosem kellene magának alfa-tesztelőnek éreznie magát, hanem már egy négy szem által tesztelt rendszert kellene találnia. Az ügynökség az alfa-tesztelő, a ügyfél pedig béta-tesztelő! Van hozzáférés az ügynökségi jegyrendszerhez egyáltalán?

Emellett írásban meg kell határozni, hogy a ügynökségi jelentéseket milyen gyakorisággal kell elküldeni a kliens részére. Például péntekenként küldjön e-mailben egy jelentést az aktuális munkafolyamatról, szükséges visszajelzési hurkokról vagy együttműködési kérésekről. Ez egy másik tanács tapasztalataink alapján: Jó, ha nem hagyjuk a klienst tanácstalanul a hétvégére. Erre csak rossz ötletek jutnak az eszébe. Inkább tájékoztassuk jól, mi történt és mi a következő héten várható. A transzparencia segít abban, hogy mindenki jó érzéssel álljon hozzá a dologhoz.

A indítás dátuma szintén meg kell határozni. A Parkinson-törvény értelmében a munka kitolja a rendelkezésre álló időt az elvégzésre. Más szóval minél több idő áll rendelkezésre egy feladat elvégzésére, annál több időt vesz igénybe, függetlenül a tényleges bonyolultságtól vagy a munkaerőigénytől. A tervezett befejezési időpontot bele kell tenni a szerződésbe. A határidő letépése akár szerződésbírsággal is járhat a szerződésben. Az iránymutatás az, hogy a késedelmekre vonatkozó szerződésbírság 0,2% az ajánlati összegtől naponta és legfeljebb 5% az ajánlati összegtől hatékony. A szerződésbírságot nem feltétlenül kell érvényesíteni az ügyfél részéről, de lehetőséged van néhány extra kívánság kihúzására az ügynökségtől mint kompenzáció.

Fontos: Ne indítsuk el a projektet pénteken. Se ünnepnapok között, se a vállalat fő munkaidőszakában. Valójában azt javasoljuk, hogy nagy újraindítások esetén a vasárnap éjszakájától hétfőre virradóra indítsa, különösen akkor, ha az IP-cím megváltozik, hogy a DNS-beállítások a legtöbb szolgáltatónál hétfőn frissüljenek, ami gyakran már a késő délelőtt megtörténik, ha éjszakánként módosítják a DNS-bejegyzést. Így gyakorlatilag még 4,5 munkanap marad élő tesztelésre és hibajavításra az esetlegesen felmerülő hibákkor.

Az Ön webhelyének jelenlegi állapotának rögzítése

Az aktuális állapotot rögzíteni kell a munkák kezdete előtt. Az aktuális állapotban rögzítve van, hogyan néznek ki a műszaki mérési eredmények a paraméterek számára. E mellé a célértékeket is beírhatja:

Mi?	Rövid leírás	Tesztelőeszköz	Aktuális érték	Célérték
Technika & Meta	Oldalcím, fejlécek, meta-adatok, alternatív szövegek, …	Seobility
Struktúra	Átirányítások, hibás linkek, sitemap-ok, ...	Seobility
Tartalom	Kulcsszó-összehasonlítás, elírások, túl kevés szövegek, ...	Seobility
Képek-SEO	Értelmes URL-címek, modern webformátumok (WebP/AVIF), <meta>-képkivonatok	nélkül
OG-adatok implementálva	Open Graph-adatok közösségi médiához	Open Graph Checker
Strukturált adatok (Markup-Séma)	Séma-jelölés / strukturált adatok	Schema.org
PageSpeed Weboldal	PageSpeed mobilra/asztalra	PageSpeed Insights
PageSpeed Landing oldal	PageSpeed mobilra/asztalra	PageSpeed Insights
PageSpeed Kategóriai oldal	PageSpeed mobilra/asztalra	PageSpeed Insights
PageSpeed Termékoldal	PageSpeed mobilra/asztalra	PageSpeed Insights
PageSpeed Blogoldal	PageSpeed mobilra/asztalra	PageSpeed Insights
Hozzáférhetőség az oldaltípusokra nézve	Hozzáférhetőség biztosítása a fogyatékkal élő felhasználói csoportok számára	Accessibility Checker és/vagy wave.webaim.org
Hreflang ellenőrzése	Többnyelvű webhelyek esetén	Hreflang Validator
Biztonsági fejlécek	Bizalom & Biztonság	SecurityHeaders.com
Egészségügyi ellenőrzés	Bizalom & Biztonság	Security Audit (Astra)
Böngésző & Eszköz-teszt	Edge, Firefox, Safari, Chrome asztal & mobil, iOs & Android	Fejlesztőeszközök / Lambdatest
Sütikezelés & GDPR	Beleegyezés-süti szabályzat & GDPR megfelelősége	Cookie Metrix
Crawling: Host-státusz	Robots.txt lekérése, DNS-feloldás, Szerverkapcsolat	Google Keresési Konzol
Crawling-statisztika	Kérések, Letöltési méret, Átlagos válaszidő	Google Keresési Konzol
Kattintások az SERP-eken	Időszak szerint (havonta/90 nap, ...)	Google Keresési Konzol
Impressziók az SERP-eken	Időszak szerint (havonta/90 nap, ...)	Google Keresési Konzol
Átlagos CTR az SERP-eken	Időszak szerint (havonta/90 nap, ...)	Google Keresési Konzol
Átlagos SERP-pozíció	Időszak szerint (havonta/90 nap, ...)	Google Keresési Konzol
Core Web Vitals vizsgálata	Ranking tényező a felhasználói élményhez (PageSpeed, mobil optimalizálás, ...)	Google Keresési Konzol
GA4 adatok elemzése	Tartózkodási idő, oldalak/látogatók, ...	Google Analytics 4
Konverziós A listában SEO eszközként megtalálod a Seobility-t, amelyet gyakran használunk az OnPage tényezők ellenőrzésére, amire például egy SEO-tréninget is publikáltam. Rengeteg hasonló eszköz létezik, mint például a Sistrix, Semrush, Ryte, SE Ranking, Screamingfrog stb. Az SEO eszköznél főként arról van szó, hogy az általános OnPage hibákat azonosítsuk és javítsuk ki. Itt három fő területről van szó: Technika & Meta, Struktúra és Tartalom, ahogy a Seobility építi az értékeléseket. Hasonló formában megtalálod az más SEO eszközökben is. Fontos, hogy mindig Teljes ellenőrzés történjen, azaz AZ ÖSSZES oldalt becrawolják, és ne csak a kezdőoldalt, valamint hogy egy értéket vagy hibát rögzíts a Jelenlegi állapot és a Célérték számára, amit az optimalizáció után el kell érni. A Seobility esetében kívánatos, ha az érték 90 vagy annál magasabb. Hasonlóan más célokra találsz alternatív eszközöket is. Döntő az, hogy egyáltalán egy ilyen eszközt alkalmazzunk, hogy kiemelkedő adatokat biztosíthassunk. Például íme az aktuális értékünk az OnPage minőségben: A Felhasználói jelek számokkal mérhetők a Google Analytics 4-ben, például a Bounce arány, Oldalonként/Látogató, Átlagos idő stb. Amennyiben a Google Analytics vagy egy másik elemző eszköz adatvédelmi szempontból helyesen használva van, ezeket az adatokat is figyelembe kell venni az aktuális állapot naplózásánál.  Készíteni kell egy Visszalépések listát, amely például itt ingyenesen generálható: https://www.seobility.net/de/backlinkcheck/ Továbbá le kell menteni az öreg sitemap.xml-t, és egy Teljes biztonsági mentést is kell készíteni az oldalról. Az összes releváns oldalt listaként át kell vinni egy Google Táblázatba, amely az URL-átirányítási térkép kiindulási alapját képezi. Ilyen CSV-listát könnyen kiexportálhatsz egy SEO eszközzel, mint a Seobility. Az URL-átirányítási térképben minden releváns oldal és azokra mutató oldalak, amelyek külső visszahivatkozásokra vonatkoznak (lásd Visszalépések lista), figyelembe vannak véve, amelyeket később az oldal-URL-jeinek megváltozása miatt tovább kell irányítani. A megszűnő URL-eket az új, az öregnek megfelelő URL-ekre kell irányítani. Fontos, hogy a Továbbítási láncokat el kell kerülni! Az öreg továbbításoknak közvetlenül az új vég-URL-re kell irányítaniuk. Ezenkívül nincs kihagyható, hogy a PDF-fájlokról és képekről, amelyekre linkek mutatnak, is gondoskodj, hogy ezek helyesen továbbíttassanak, és ne váljanak 404-es hivatkozássá. A továbbításokat 301-átirányításokként hozzák létre az URL-átirányítási térkép alapján a .htaccess-ben, átirányítási térképekkel a Vhost konfiguráción keresztül, vagy adatbázis-megoldással. Fontos, hogy az ügyfél maga is karbantarthatja ezeket. Biztosítani kell, hogy a továbbítások tartósak legyenek. Érdemes minden típusú oldalt megmenteni egy Oldal-screenshot-tal. Ez egyrészt az Alt állományok mentése, ha a Going-Live után kérdések merülnének fel, hogy az anyagtípusokat nem vitték-e át stb. A meglévő oldalak, funkciók és tartalmak alapján, valamint az eredmények alapján nevezhető meg, mi működik jól már és mi az a terület, ahol az optimalizálásra való potenciál látszik, ami az újraindítással javítandó. Ellenőrzőlista: Az újraindítás előtt Amint a felhasználói felület designja jóváhagyásra került, és az ügynökség fejlesztési sprintben van, az alábbi ellenőrzőlista releváns lesz, amely a relaunch napjáig időrendben felsorolja a lényeges pontokat: Dev-környezet elérhető minden érintett fél számára teszteléshez Dev-környezet noindex-ben fut Hozzáférés a teszteszközöknek a Dev-környezeten (IP-feloldás vagy http-bejelentkezés) beállítva A Dev-környezet konfigurációja lehetőleg az élő rendszerének megfelelő A Dev-környezet oldalstruktúrája megfelel a későbbi élő oldaléhoz A régi adatok adattovábbítása megtörtént Tartalombeállítások elvégezve Képoptimalizálás elvégezve 301-átirányítások létrehozva az URL-átirányítási térkép alapján  OnPage ellenőrzés a Seobility segítségével, hibák kijavítva, céladatok elérték Open Graph adatok érvényesek Strukturált adatok érvényesek Pagespeed ellenőrzés minden oldaltípusra elvégezve, céladatok elérték Tartalom-sütikezelés működik Biztonsági fejlécek beállítva Akadálymentesség biztosítva, céladatok elérték Hreflang érvényes (többnyelvű oldalak esetén) Jogi szövegek (ÁSZF, Impresszum, Elállási nyilatkozat, Adatvédelem) frissítve, GDPR megfelelőség biztosítva A CMS, Frameworks, használt bővítmények és modulok frissítése a legújabb verzióra megtörtént Felhasználói szokások és eszközök átfogó funkciótesztele nincs hibával Végleges állapot és indítási dátum közzétéve  Teljes biztonsági mentés elkészítve A Strukturált adatok (Schema-Markup) alkalmazása - lásd a lista 12. pontját - még mindig nagyon kevéssé van figyelembe véve. Ismerkedj meg a témával, és olvasd el, mit mond a Google a strukturált adatok Markup-járól a Google keresésben. A Google egyre inkább elősegíti a megbízható adatokat az SGE-re vonatkozóan, azaz a KI által létrehozott keresési eredményekre. Ezt az is okozza, hogy a Google Helpful Content frissítése miatt a tartalmakat sokkal inkább ellenőrzik a szakértelem, tapasztalat, tekintély és hitelesség szempontjából. A strukturált adatok része ennek a megoldásnak, hogy egyszerűbbé tegye a Google számára ezeknek a validálását. Az integrálás után használd a Schema-Markup-Validátort, de ellenőrizd a oldalaidat a Strukturált Adatok Ellenőrzőjével is, amelyet a Google is ajánl az PageSpeed Insights-ben. Ezáltal részletesebb információkat kapsz a strukturált adatok használata során fellépő kódhelyes hibákról. Az strukturált adatok használata a webhelyeken már nem opcionális, hanem követelmény. A Google érvényes és hiteles tartalmakat vár tőled. Ha nem szeretnél lemaradni az AI-alapú keresési eredményeknél, foglalkozz a sémamarkupokkal az oldalaidon! A 16. pontban először jelenik meg a Hozzáférhetőség ebben a cikkben. Már a PageSpeed Insights esetében a Hozzáférhetőség saját területtel rendelkezik, és ott a zöld számok kívánatosak. Ellenőrizd azzal, hogy egy oldal hozzáférhető-e vagy sem, ne csak a PageSpeed Insights-nál, hanem a https://www.accessibilitychecker.org és/vagy a https://wave.webaim.org oldalon is. Különösen, ha egy relaunch előtt állsz, akkor ezt a pontot kötelezően figyelembe kell venni, mert a webhelyek esetében a Hozzáférhetőség megerősítéséről szóló törvény 2025-től aktuális lesz. Ne csak az kezdőoldalt teszteld le ilyen eszközzel, hanem minden oldaltípust - ugyanez igaz a PageSpeed-tesztekre is! Egy relaunch keretében gyakran előfordulnak módosítások és Frissítések a jogi szövegeknél. Fontos gondolni arra, hogy a szövegek esetleg szakértői ügyvéd vagy jogszabálygenerátorok által legyenek biztosítva. Emellett gondolni kell az adatfeldolgozási szerződésekre is, ha például egy új webtárhely vagy egy új hírlevél szolgáltató lesz használatban. A CMS, a használt JavaScript könyvtárak, telepített modulok és beépülő modulok frissítése a 18. pont ugyanolyan alábecsült és fontos, mint a többi. Egy relaunch akár hónapokig is eltarthat. A WordPress rendszer esetében könnyen látható, hogy talán a relaunch előtti napon már számos frissítés elérhető. Ügyfeleknek védeniük kell magukat, hogy a legújabb változatokat az élő oldalakon használják.   Az általán megváltozó külső szolgáltatások további feladatokat hoznak magukkal, amelyeket ugyanúgy meg kell nevezni a ellenőrzőlistában, mint például a hírlevél szolgáltatás módosításánál:  Hírlevél-kapcsolatok importálása az új NL-szolgáltatásba Kapcsolatok biztosítása a webhelyen a hírlevél szolgáltatásával az előfizetői űrlapon keresztül Adatfeldolgozási szerződés Új levélküldő sablonok készítése és így tovább  A fejlesztési követelmények egész sprintje során természetesen folyamatosan teszteljük a funkciókat stb. Érdemes részletes ellenőrzőlistát készíteni a tesztekhez is, hogy ne maradjon ki semmi. Nem elegendő csak kattintgatni egy kicsit, sem a végrehajtó ügynökségnek, sem az ügyfélnek. A TutKit.com relaunch-e után biztosan 1000 sornyi volt az elfogadási ellenőrzőlistánk. És így tesszük ezt ma is: fontos nagy frissítések után körülbelül 70 interakciót ellenőrzünk ellenőrzőlistán keresztül Chrome, Safari és Android eszközökön. Ellenőrzőlista: A relaunch napja és a következő napok A relaunch napja eljött, és nem péntek és nem is egy ünnep közötti nap. Az új webhely él, a DNS beállítások módosítva lettek. Most újra mindent meg kell vizsgálni és kiértékelni. Küldd el a következőket:  robots.txt ellenőrzése, hogy a robotok ne legyenek blokkolva  Az élő környezet indexen fut index, követés.    Canonical-címkék megfelelően vannak beállítva Az oldal forráskódját abszolút elérési útvonalakra ellenőrizni (a teszt környezet linkeinek útvonalai a Live oldalra) Átirányítás az http-ről https-re, www-vel vagy anélkül a céloldalra a kezdőlap és az aloldalak esetében működik Az URL átirányítások tesztelése az URL-átirányítási térképen keresztül, valamint az átirányítási láncok jelenléte ellenőrzése Oldalkezelés az élő oldalon a Technikai & Meta, Struktúra és Tartalom tekintetében a Seobility-hez … különösen azok az oldalak ellenőrzése, amelyeket a Seobility bocsát ki Noindex-ként Az Open-Graph adatok érvényesek Az strukturált adatok érvényesek Az összes oldaltípus Pagespeed ellenőrzése megtörtént, a céleszközök elérték a célértékeket A Cookie-szabályzat a Hozzájárulási cookie-eszközzel működik, ahogyan azt kell A biztonsági fejlécek be vannak állítva A hozzáférhetőség biztosított Hreflang ellenőrzése a többnyelvű webhelyek esetében (https://app.sistrix.com/de/hreflang-validator) Végleges böngésző- és eszközfüggetlen funkcionális tesztelés nem mutat hibát Új sitemap.xml beadvány a Google Keresési konzolon Új céloldalak frissítése a Google-Ads kampányokban Ha bizonyos domain-módosítások vannak, a közösségi média linkekre, e-mail aláírásokra stb. is gondolj A Dev-környezetünkben a Mailhog-ot használjuk az emailek helyi teszteléséhez. Ilyen esetekben fontos, hogy a helyes SMTP adatokat beállítsd az Élő rendszerben az email-vevő számára, hogy az emailek oda is menjenek, ahova kell. Ugyanúgy ügyelni kell arra, hogy Fizetési szolgáltatóknál , mint a PayPal Dev-rendszerekben a Sandbox legyen implementálva, miközben a Live-rendszerben természetesen a megfelelő kapcsolatot kell létesíteni. A következő napokban különösen fontos figyelemmel kísérni a Google Keresési konzolt. Különösen érdekes az, hogyan változnak a rangsoraid. Fókuszálj különösen a váratlan változásokra és hibaüzenetekre: Crawling: Host-állapot … robots.txt lekérdezése, DNS-feloldás, szerverkapcsolat Crawling statisztika … Kérések, Letöltési méret, átlagos válaszidő Kattintások az SERP-eken Megjelenések az SERP-eken Átlagos CTR az SERP-eken Átlagos SERP-pozíció A Core Web Vitals sikeressége  Főként a Google Search Console hívja fel a figyelmedet hibákra, mint például az URL-hiba, a Href-Lang-hiba, az oldalindexelés Spread indexált/nem indexált. Az "indexált" esetén egy oknak kell lennie (átirányítás, noindex)…). Ott láthatod a másolttartalmakat vagy más problémákat. Ha a Search Console problémákról tájékoztat a strukturált adatoknál vagy a Core Web Vitals-nál, járj utána. Csak a valós idejű adatok segítségével jössz rá például, hogy bár oldalaid nagy PageSpeed-del rendelkeznek, problémák vannak a Core Web Vitals-nál például CLS-hibákkal. Itt jól látható, hogy milyen ugrások lehetségesek a weboldal módosításai során: Képes vagy közvetlenül megjeleníttetni a rossz vagy optimalizálandó URL-kat. Vegyél egy URL-t és végezz vele egy PageSpeed-tesztet a PageSpeed Insights-nél. Ott találod majd a javaslatokat arra, hogy miért nem felelnek meg a Core Web Vitals, és mit tehetsz a hibák kijavítása érdekében. Kattints a lefelé mutató nyílra további információkért. Általában ezeket a javaslatokat csak fejlesztők tudják végrehajtani. Fontos azonban, hogy képes legyél azonosítani a problémákat, hogy aztán az ügynökséged segítségével megfelelően kezeld azokat. Ezenkívül ki kell értékezned az analitikai eszközeid adatait, például a Google Analytics 4-jét. Továbbá figyelemmel kell kísérned a rendszerszinten mérhető mutatókat, például a foglalásokat, a konverziós arányt, a kosárértéket, a napi vásárlásokat/bevételeket, a hírlevél feliratkozásokat, a kapcsolatfelvételeket, valamint bizonyos tartalmak letöltéseit vagy a videó megtekintéseket.  A Crawling-statisztikák a Google Search Console-ban kulcsfontosságúak az előző napok ellenőrzéseihez. Ezeket a baloldali menüben található beállításokon keresztül meg tudod találni. Közvetlenül több Crawl-tevékenységnek kellene láthatóvá válnia. Ha nem, vannak Crawl-hibák? A Host-státusz közvetlenül megmutatja a hibákat, mint például itt egy átfogás után, amikor a robots.txt crawlkérései kudarcot vallottak, és a szerverkapcsolat részben folyamatosan megszakadt: Érdekes, hogy mit mutat a Crawling-statisztika. Átfogás után általában fellendülés következik a Crawling-kérések terén. Ott megfigyelheted, hogy 404 oldalakat is crawlolnak-e továbbra is. Ha néhány nem illeszkedik, beszéld meg ezeket a fejlesztőkkel. Láthatod, hogy mennyire jók a szervered, PageSpeed-ed és kódod, ha az oldal válaszideje 400 alatt van. Minél közelebb van ez az 1000 ms-hez, annál ajánlottabb a PageSpeed-optimalizálás, például adatbázis-lekérdezések csökkentésével és a szerverteljesítmény megerősítésével (például több számítási teljesítmény, frissítés a legújabb szoftverekre, áttérés HTTP2 vagy HTTP3 (Nginx esetén)). A jövőben az egyes webhelyek Crawling-limitjét egyre több (MI-) tartalommal való gazdagítás valószínűleg korlátozottabbá teszi, ezért itt is meg kell próbálni jó értéket elérni az oldalválaszidő területén, hogy a botok minél többet tudjanak crawlolni az oldalaidon az adott időkeretben. Relaunch-ellenőrzőlista letöltése A fent beágyazott ellenőrzőlisták a relaunch-hoz PDF-formátumban is rendelkezésre állnak letöltésre. Töltsd le azokat, és biztosítsd vele a projekt sikerét! Egy ügynök tulaj vallomásai A Checklist SEO követelményei részletes utasításokat is kaphatnak, például a H1-től H6-ig terjedő címstruktúrára figyelemmel kell lenni. Az Célérték meghatározása a tesztelőeszközökben szerencsére összegzi tartalmilag az egész Relaunch-ellenőrzőlistát, mert a lista által megnevezett tesztelőeszközök legjobb értékeinek elérését csak tiszta kód betartásával, a modern technológia alkalmazásával, a SEO-OnPage tényezők figyelembevételével stb. lehet elérni. Ellenkező esetben a legújabb webes szabványokat és technikai megközelítéseket, valamint SEO követelményeket igen részletesen kellene a követelmények listájába foglalni, amire az ügyfelek szakmailag nem lennének képesek. Ha az ügynökségek magas értékeket kell elérjenek a tesztelőeszközökben, nem marad más választásuk, mint az Adatokon alapuló gyakorlatok alkalmazása – ez az ügynökségek számára is új tapasztalat :-) Itt van idő a vallomásra. A SEO követelmények meghatározása és a checklista szerű megközelítés az egyes tesztelőeszközökben meghatározott célok elérésével az egy olyan ideál, amely a valóságban ritkán található meg. Ez attól függ: ügyféloldali költségkeretek ügynökségi nyereségoptimalizálási érdekek Korlátozások a használt technológiák által és sajnos: Ismeretlenség és inkompetencia mindkét oldalon Az ügyfelekkel nehéz foglalkozni egy panasszal. Ők pontosan szakmai segítséget keresnek, és majdnem minden digitális ügynökség hirdeti webhelyén és fehér könyveiben, hogy a keresőoptimalizálás az egyik fő kompetenciájuk. Mindig vannak referenciák is, amelyek azt bizonyítják, hogy a honlapfrissítést követően a láthatóság online növekedése 3, 5 vagy akár 10-szeresére nőtt. Hogy 10 látogató helyett most napi 100 jön, ez valóban egy 1000%-os növekedés, de ettől még nem nevezhető sikeresnek. Sok keresőoptimalizálási siker feltételezi, hogy a versenytársak digitalisan egyszerűen még sokkal gyengébb helyzetben vannak. Az ügynökségek továbbra is közepes munkát végeznek elavult módszerekkel, mert még mindig nem alkalmaznak modern eszközöket a minőségbiztosítás terén, még akkor sem, ha nagyvonalúan a bejegyzéseikben, referenciáikban, legjobb gyakorlataikban stb. azt állítják, hogy van SEO-szakértelmük. Talán ezek az ügynökségek tudásóriások, de végrehajtási törpék is lehetnek. Ez keményen hangzik, de ez a szabály. Komolyan. Nézd meg bátran! Vedd szemügyre a fenti ellenőrzőlistát, és add meg a régiód legjobb ügynökségét, amelynek URL-jét a fent említett eszközökbe másold be. Majd vedd a legújabb webhelyreferenciát, amelyet az ügynökségtől találsz, és ismételd meg. Milyen eredményeket fogsz látni? Pont azokat, amelyekre számíthatsz együttműködés esetén. Mi is saját referenciáinkat így ellenőrizheted, és rá fogsz jönni, hogy saját ügyfélprojektjeinkben is nem mindenhol értünk el csúcsértékeket. Az ilyen munkafolyamat a adatalapú minőségbiztosításhoz való hozzáállással nálunk is projektről projektre felnőtt, és főként a TutKit.com-on végzett munkáinkon keresztül lett elfogadott.  Az ilyen ellenőrzéseket majdnem minden ügynökséggel elvégezheted, mivel csak kevésik dolgozik valóban adatalapú minőségbiztosítással, mert egyik sem marad éveken át a piacon saját projektekkel, és nem kell versenyre kelnie az online láthatóságért szerte a világban, és az ügynökségek számára szinte mindegy, hogy egy projekt sikerül vagy sem, amíg az ügynökségi számla ki van fizetve, és az ügyfelek megünnepelhetik a szép (de minőségben közepes) webhelyeket a bejegyzéseikben és díjakkal. A különös ironia az, hogy az említett teszteszközök alapján gyakran pont a SEO ügynökségek saját webhelyei teljesítenek legrosszabbul, mert gyakran, mintegy egylábon táncoló lovak, csak egy módszerrel rendelkeznek … egy a ügyfél kulcsszavaira épülő tartalompakett a webhelyen. Az egyéb technikai követelményekhez gyakran hiányoznak a megfelelő fejlesztők. A másik előny, ha az ügynökség máshol van székelés akkor is jó, hogy az ügyfél nem a barkácsáruházban találkozik az ügynökség munkatársával, aki egy frissítés után felelős az online láthatóság kétszámjegyű csökkenéséért. De ezt a láthatósági csökkenést alig ellenőrzik az ügyfelek, mert bár mindenki rendelkezik süti-elfogadási szalaggal, de csak kevesen elemezik az adatokat, és vonnak le belőlük cselekvési tervet. Ha kérdéses, nyilvánvalóan meg kell növelni az AdSpendet. Hogy ma az organikus rangsorolás túl sok tartalmilag hasonlóan erősített webhely kínálata miatt elsősorban technikai paraméterektől, felhasználói jelektől és (még mindig) visszahivatkozásoktól függ, a szerencsére a legtöbben nem tudják. És a MI-szövegeszközök révén a webhelyek tartalmilag soha nem látott mennyiségben és minőségben fognak erősödni, és hamarosan sok új külföldi webhelyet üdvözölhetünk anyanyelvünkön a keresési találati listákban, mert a MI-fordítási eszközök révén egyre könnyebbé válik az online áruházakat, portálokat, SaaS és egyéb webhelyeket lefordítani és megtámadni a digitális otthoni piacot. Fel kell készülnünk a kemény versenyre. Épp most kezdődik … Összefoglaló a adatalapú webhelyfrissítés-ellenőrzőlistáról Egy ilyen adatalapú ellenőrzőlista az egyik kevés hatékony lehetőség, hogy az ügynökségeket kötelezzük jó munkára. Még azt is javasoljuk, hogy bizonyos értékek elérését a teszteszközökben a jóváhagyási kritériummá kell tenni. Szerződésben rögzítettnek kell lennie, hogy az részbetét csak akkor számlázható ki négy héttel a frissítés után, ha mind a fontos adatok rendelkezésre állnak, és az ügynökség a topértékeket megerősíti (például a Core Web Vitals és a Schema Markup által validált termékrészletek a Keresési Konzolon). Ennek a munkafolyamatnak a segítségével – ahogyan ebben a bejegyzésben is le van írva – a láthatósági veszteséged egy erős tartalmi, szerkezeti és technikai változtatások utáni frissítés után korlátozva marad, és megteremted az alapot ahhoz, hogy a Google hamarosan magasabban rangsorolja a webhelyedet vagy online áruházadat. Ha érdekes volt számodra a cikk, nézd meg bátran más tartalmunkat is: 1101,908,1066,1086