Webhely migráció: A leggyakoribb hibák! - figyelmeztet Semalt



Szia! A mai cikkben Semalt mesélni fog a weboldal migráció során elkövetett leggyakoribb hibákról. A webhelyek migrációjának 90% -ával legalább az egyik hiba gyakran megjelenik, amelyről ma mesélek. Sajnos az is előfordul, hogy a legkisebb hiba is a forgalom elvesztésével és a láthatóság csökkenésével járhat.

Tehát, ha fontolóra veszi a webhely áthelyezését, áttelepítését vagy a domain megváltoztatását, javasoljuk, hogy olvassa el a teljes cikket.

Ha elérte ezt a pontot, akkor valószínűleg tudja, mi a migráció. Webhely migráció esetén több típusra oszthatjuk.

Migrációs típusok

CMS-CMS

Az e-kereskedelem közül a migráció legnépszerűbb típusa az egyik CMS-ről a másikra való áttérés. Tegyük fel, hogy üzlete kezdetben kis készlet mellett növekszik, kevés termék és igényei kisebbek voltak. Azonban az idő múlásával az áruház növekedésével az igényei növekedni kezdtek, ezért elkezdett gondolkodni a CMS megváltoztatásán, amely lehetővé teszi, hogy olyan dolgokat hajtson végre, amelyekre az adott CMS-ben szeretne lenni.

És itt ténylegesen fontolgatja a CMS-ről egy másik CMS-re való váltást. Ebben az esetben az áttérés számos előnnyel jár. Képes több kérdést kezelni, integrálódhat a rendszerekkel, pl. a nagykereskedők számára, amelyek növelik vállalkozását, és a CMS egyszerűen megkönnyíti az Ön számára.

Domain-Domain

A migráció másik típusa az egyik domainről a másikra. Tehát üzletünk például X név alatt működött, de egy idő után azt tapasztaltuk, hogy ideje váltani, és a márkánknak más nevet kell adnia. Ezért új domaint vásárolunk, és át akarjuk váltani az üzletet egy másikra.

Néha az is előfordul, hogy ha például van egy olyan domainünk, amely valahogy szenvedett (pl. Szűrőt alkalmaztak rá), és tudjuk, hogy itt semmit nem lehet elérni, akkor fontolóra vesszük a tartomány megváltoztatását is. Ezután a domain migrációjával foglalkozunk egy másik tartományra.

Váltson oldalt

Akkor is foglalkozunk a migrációval, amikor frissíteni akarjuk üzletünk megjelenését - megváltoztatjuk a sablonját, egyszerűen megváltoztatjuk az oldalt, mármint azt a vizuális részt, amelyet a felhasználók látnak. Gyakran az URL elérési útjának megváltoztatásával jár, ezért itt maga az áttelepítés és annak helyes megvalósítása is nagyon fontos lesz. Mivel azt akarjuk hagyni, ami jól működött számunkra, és hozzáadjuk ezeket a funkciókat, hogy a jövőben nagyobb legyen a weboldal forgalma.

Emiatt emlékeznünk kell bizonyos szabályokra, amelyek megakadályozzák, hogy elveszítsük a már megszerzetteket. Valószínűleg elsősorban az áttérést társítjuk az átirányításokkal. Tehát, ha bármelyik migrációt elvégzi, valószínűleg valaki azt mondja, hogy "ne feledje, végezzen átirányítást". És ez igaz, természetesen az átirányítások fontosak, de sok más elem is befolyásolja, hogy az áttérés sikeres lesz-e vagy sem.

Hidd el, ha nem készülsz fel megfelelően az átállásra, akkor hibázol a folyamat során, az eredmények valóban irányítóak lehetnek. Az áttelepítésre való felkészüléshez megfelelően meg kell terveznie, majd végre kell hajtania, és meg kell vizsgálnia, hogy a webhely hogyan reagál, sokkal könnyebb lesz, mint elkapni a rossz migráció után történteket.

Fejlesztői verzió

Noindex Nofollow

Ha a weboldal új változatán dolgozunk, akkor általában a fejlesztői verzióval foglalkozunk. Tehát egy olyan oldalról van szó, amelyet nem szabad elérni a felhasználók és a keresőmotorok számára sem, és a Noindex Nofollow paraméterekkel kell megjelölni. Ennek a módszernek köszönhetően nem engedélyezzük weboldalunk indexelését, és szabadon dolgozhatunk rajta.

Ez különösen fontos, ha például a tartalmat a régi oldalról helyezzük át az újra, mert a Google, ha eljut a fejlesztési oldalunkra, indexelni kezdi. Tehát a keresőmotorok indexe tartalmazni fogja mind az új, mind a régi oldal tartalmát - akkor a duplikációval kell megküzdenünk.

Mivel a fejlesztői verziót a keresőmotorok robotjai blokkolják az indexeléshez, karcos papírként kezelhetjük. Biztonságosan megtervezhetünk néhány megoldást, néhány elemet nyugodtan megvalósíthatunk, és ez nem lesz negatív hatással a weboldal láthatóságára. Például nagyon gyakran megtervezhetjük a menü felépítését és megváltoztathatjuk az URL-eket. A normál világban ez nem lehetséges, mert ha a bejáró megtalálja az adott URL-t és indexeli, akkor ha megváltoztatjuk ezt a címet, és nem hozzuk létre az átirányításokat, akkor a 404 hiba jelenik meg.

SEO együttműködés

A fejlesztői verzió esetében az is fontos, hogy ha például egy SEO cég, amellyel együttműködik, hozzáférjen hozzá, akkor az is szabadon dolgozhat rajta, átadhatja és segítheti az áttérésben. Ha nincs ott, és élő organizmuson dolgozunk, akkor ez sokkal nehezebb feladat.

Migráció

Az összes tartalom áthelyezése

Fejlesztői verzióval nem feledkezhetünk meg a többi elemről sem, amelyek szintén fontosak lesznek egy sikeres migráció esetén. Ha üzletünk már optimalizált volt, tartalma volt az általunk optimalizált kategóriákban és termékekben, amelyeket ismerünk a forgalom generálásához, akkor itt emlékeznünk kell az összes tartalom egyik oldalról a másikra való átvitelére.

Tehát áthelyezzük a címet, a Meta leírást, a leírásokat a régi oldalon lévő formázással együtt. Ha voltak alternatív leírások a webhelyen, akkor arra is ügyeljünk, hogy az új oldalon szerepeljen. Ugyanez vonatkozik a címsorokra is - vagyis ha optimalizáltuk a weboldalunk címsorait, akkor ugyanazoknak a fejléceknek kell lenniük az oldal új verziójában is. Ezek az elemek az új weboldalunk átkapcsolása után máris rangsorolni fogják.

Átirányítások

Címtérkép

Természetesen érdemes előre felkészülni arra, hogy létrehozzák a régi címek átirányítását az újakhoz, hogy az oldal bekapcsolása egyszerűen átirányuljon, és a Google gyorsan észrevegye, hogy ezek az átirányítások léteznek, ha belépnek a weboldalra.

Átirányítja az összes aloldalt

Az átirányításoknál az alapvető hiba az, hogy csak a kezdőlapot irányítjuk át. Tehát ha például megváltoztatjuk a domaint és egyikről a másikra váltunk, akkor csak a kezdőlapot irányítjuk át. A kategóriák, termékek, blogcikkek nem érdekelnek minket - ez nagyon nagy hiba.

Minden aloldalnak megvan a saját láthatósága, amelyet egy ideje építünk. Optimalizált, kívülről összekapcsolt ... Tehát, ha egy új cím jelenik meg a webhely struktúrájában, akkor az csak friss, és amíg nem erősítjük meg ezt a címet, miután átirányítottuk a régiről az újra, olyan, mintha felépítenénk mind a semmiből. Természetesen az áthelyezett címelemek vagy az új oldalon megvalósított tartalom itt segít nekünk, de a régi aloldal hatalmát nem adjuk át.

A 301 átirányításnak köszönhetően nem veszítjük el azt, amin már dolgoztunk, ezért nagyon fontos a címek 1: 1 arányú átvitele. Tehát ha rendelkezünk kategória címmel, akkor minden kategóriát át kell irányítanunk a megfelelőjére. Ugyanez vonatkozik a termékekre is. Természetesen, ha sok ilyen termék van, és nem akarjuk nagyon lelassítani a szervert, akkor természetesen kiválaszthatja a termékek egy részét, vagy csak a szabályokat alkalmazhatja.

Természetesen megkönnyíthetjük magunk számára, ha lehetőségünk van olyan oldalak létrehozására, amelyek ugyanúgy néznek ki, amikor egy oldalt tervezünk. Tehát, ha nem változtatjuk meg az URL-ek szerkezetét a régi és az új áruházban, akkor természetesen nem kell létrehoznunk ezeket az átirányításokat. Ha azonban megváltoztatunk például egy CMS-t, gyakran egyszerűen lehetetlen, és ezeket az átirányításokat végre kell hajtani.

301, nem 302

Miután létrehoztuk az összes átirányítást, emlékeznünk kell arra, hogy ezeknek az átirányításoknak állandó átirányításoknak kell lenniük, vagyis 301 átirányításnak. A szintén gyakran végrehajtott 302 átirányítás ideiglenes átirányítás - nem fogja átadni azoknak az aloldalaknak a hatalmát, amelyekről korábban meséltem.

Analitika

Ha új oldalt kapcsolunk be, akkor azt is meg kell győződnünk arról, hogy webhelyünk rendelkezik a Google Analytics és a Google Search Console kódokkal. Ennek köszönhetően megfigyelhetjük, mi történik a weboldalunkon és hogyan viselkedik.

Új indexelés

Ha befejeztük az egyes szakaszokat, és készen állunk arra, hogy az oldalt megnézhesse a Google, természetesen beküldhetjük az oldalt az új indexeléshez a Search Console-ban. Új térképet is feltölthetünk a Search Console-ba, hogy könnyebben azonosíthassa az új oldal tartalmát - ez kicsit gyorsabban megtörténik.

Arra is emlékeznünk kell, hogy az első időszakban a Google indexeli az új oldalt, de a régit is az indexben tartja, ezért időt kell hagynunk arra, hogy a régi oldalt eltávolítsuk az indexből, és egy újat helyére kell tenni. Az első három-hat hónapban figyelni fogjuk, hogy mi fog történni.

Természetesen a láthatóságot megmutató eszközökben láthatjuk pl. csökkenés egy bizonyos idő alatt, de akkor ez az oldal elkezd ugrálni. Ha nem ez a helyzet, akkor ellenőriznie kell, hogy mi ment rosszul. Úgy tűnhet, hogy a fejlesztő 301 átirányítást vezetett be, és ezek az átirányítások 302 átirányításnak bizonyultak. Tehát ezeket a dolgokat csak a migráció után kell felvenni.

Ezek voltak a leggyakoribb hibák az oldal migrálásakor. Ha tudjuk, hogy migrációnkat rosszul hajtották végre, ez azt jelenti, hogy oldalunk kudarcra van ítélve? Nem teljesen. Természetesen bevezetheti a helyreállítási tervet, csak ami fontos, az idő. Ha a webhely-migrációt nem hajtották végre megfelelően, az első hónapokban még mindig lehetőségünk van helyrehozni az elvesztett forgalmat. Később - ha a Google eltávolítja a régi címeket a keresőkből - ez sokkal nehezebb lehet.

mass gmail