
Hogy fulladt káoszba a weboldal költöztetés? – Rosenstein marketing esettanulmány
Ebben a cikkben
Az online elérhető tartalmak 91%-ára nem érkezik forgalom Googleből. Gyakorlatilag így van ezzel a híres budapesti vendéglő, a Rosenstein is. Egy erős márka és egy közepes honlap általában elég ahhoz, hogy a vendégek kiszolgálva érezzék magukat. Ebben az esetben viszont olyan hibákat követtek el a weboldalnál, amik láttán mi is vakartuk a fejünket. Erről készítettem egy marketing esettanulmányt, aminek a lényege: hogyan NE csinálj weboldal költöztetést!
A marketing esettanulmány háttere
A közelmúltban barátoktól kértem tippeket, hogy milyen éttermeket érdemes kipróbálni Budapesten. Rengeteg ötletet kaptam persze és rájuk is kerestem kapásból, hogy végiglátogassam a weboldalukat és az étlapukat. Készítettem belőlük egy táblázatot, hogy melyiket szeretném kipróbálni ebben az évben és milyen alkalomkor.
Az ajánlások között felmerült a Keleti pályaudvar mellett lévő Rosenstein Vendéglő is. Amikor rákerestem, jött az első meglepetés.
A találatok között a vendéglő főoldala megjelenik Googleben, de már a meta leírásből is kiderül, hogy itt valami probléma van. Ráadásul egyetlen más oldalt sem látok ami hozzájuk tartozna.
Ekkor elkezdtem kicsit kutakodni és olyan hibákat találtam, hogy egy marketing esettanulmányt készítése mellett döntöttem: hogyan NE csinálj weboldal költöztetést.
Ebben a cikkben a weboldal költöztetés hibákból fakadó problémákra fókuszálok. Ha szeretnél egy teljes elemzést is végignézni, olvasd el Gábor IKEA webshop SEO auditját.
Technikai SEO háttér
Rosenstein robots.txt
Az oldal indexálásával kapcsolatos az egyik hibát nagyon könnyű volt megtalálni. Még azelőtt, hogy a weboldalt megnyitottam volna, rögtön a robots.txt vizsgálatával kezdtem.
Ha valaki nem szeretné, hogy az oldala megjelenjen Googleben, csak el kell helyeznie a Disallow: /
szöveget az oldala robots.txt-jébe. Itt pontosan ez történt.
Főleg weboldal fejlesztése közben bevett szokás, hogy elrejtik a keresők elől az oldalt, hogy a félkész verziót még ne lássák mások. Néha viszont a végleges migrációnál elfelejtik ezt módosítani, így élesben sem kap majd forgalmat az új weboldal a keresőkből.
Hisz direkt megmondjuk neki, hogy „ne gyere az oldalamra, köszi!”
Érdekesség, hogy a tiltás ellenére is megjelenik a főoldal Googleben. Olyan esetekben szokta a kereső felülírni a robots.txt beállításait, ha feltételezi, hogy itt komoly emberi hiba csúszott az oldal kódjába. Főleg branded search esetében. De itt is látható, hogy csak a főoldalt jeleníti meg, semmilyen más oldalt nem.
Ekkor még nem is sejtettem, hogy a probléma gyökere ennél sokkal mélyebben rejtőzik.
A robots.txt módosításával (a „/” törlésével) általában a probléma megoldódik. Ebből viszont még nem született volna marketing esettanulmány, úgyhogy nézzük is tovább a Rosenstein weboldalát.
Iframe weboldal
A robots.txt ellenőrzése után meglátogattam a valós weboldalt. Az első hiba ami nagyon szembeötlő, maga a tartalom. A 9 menüpontból 1 magyar, 8 angol. A főoldal alján pedig ugyanúgy mixelve van az angol és a magyar nyelv. Így nem szabad megúszni az oldal nyelvi változatainak elkészítését.
Emellett a fekete sáv az oldal tetején látható, hogy fixált, ha legörget valaki az oldal aljára. De az oldal menüje nem található meg ott. Ezt elsőre nem igazán tudtam hova tenni. De a cikkben erre is fény fog derülni.
Ahogy kutakodtam a weboldalon, két dolog tűnt fel azonnal:
- az URL nem változik, akármelyik menüpontra is kattintok
- minden egyes link egy külső, Wix domainre mutat
Azonnal fogtam is a rosenstein.hu URL-t és átfuttattam Screaming Frogon.
Pro tipp: alapbeállításként a Screaming Frog nem ellenőrzi azokat az oldalakat, amik robots.txt-ben el vannak rejtve. Ezt át lehet állítani a Configuration / Robots.txt / Settings menüben az „Ignore robots.txt” bekattintásával.
Ezután a Screaming Frog egyetlen oldalt talált, a főoldalt. Ekkor lettem biztos abban, hogy valójában a Rosenstein weboldalán lévő tartalmak nem is ott vannak, hanem a Wix oldalon.
Megnézve az oldal kódját, mindössze ennyit látni:
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Rosenstein</title>
</head>
<body style="overflow:hidden; margin:0;">
<div style="background-color:black; z-index:10; position:fixed; top:0px; right:0px; width:100%; height:42px;"></div>
<div style="background-color:black; z-index:10; position:fixed; bottom:0px; width:100%; height:50px;"></div>
<iframe src="http://szkorossy.wix.com/rosenstein" background="transparent" frameborder="0" height="100%" width="100%"></iframe>
</body>
</html>
Ez egy iframe, ami rejteget még szépségeket. Tehát valójában két oldallal van dolgunk:
- van a rosenstein.hu, ami egy iframe kóddal behúzza egy Wix oldal tartalmát
- és van egy Wix oldal, ahol a tényleges tartalom található
Ez a megoldás így természetesen „nem ideális”, hiszen
- az oldal maga lassabb mintha a rosenstein.hu oldalon lennének a tartalmak,
- az oldal, ami a cél lenne, nem tud megjelenni Googleben
- hiába minden linképítési tevékenység, annak az értéke így nem fog realizálódni
Eközben a Wix oldal indexálva van Googleben, az viszont nem tud a vendéglővel kapcsolatos kifejezéskre rankelni, mert nincs linkje.
Jó hír viszont, hogy a wix oldal URL-jei megfelelően változnak, ha az oldalak között váltunk.
De elemzzünk tovább. Mi történik akkor, ha valaki mint én, étterem étlapjára kíváncsi?
Van egy harmadik, WordPress honlap is a háttérben
Keressünk rá arra a Googleben, hogy „Rosenstein étlap”. Ekkor ezt találjuk:
Az URL elárulja, hogy ez egy WordPress honlap.
- http://rosenstein.hu/wp-content/uploads/2013/menu.pdf
Viszont korábban egy Wix oldalt és egy iframe-et találtam csak. Tehát valahol a háttérben kell lennie egy harmadik, WordPress weboldalnak is valójában. MICSODA? Itt vagy valaki egy rossz viccet űz velünk, vagy valami komoly gond lehet a háttérben.
Ekkor egy site search (site:rosenstein.hu) segítségével kigyűjtöttem az összes elérhető oldalt. Első próbálkozásra csak a főoldalt jelenítette meg, de a keresés megismétlésével úgy, hogy a kihagyott elemeket belefoglalja a kereső, már láttam 11 oldalt. Ez angolul a „repeat the search with the omitted results included” opció.
Ezek az oldalak mind a rosenstein.hu oldalhoz tartoznak (tehát nem a Wix oldalhoz), és nem iframe-mel töltődnek be. Ezek valós oldalak, amik egy harmadik, 2012-ben készült WordPress alapú honlapon élnek. Például a szilvapálinka aloldal:
- http://rosenstein.hu/szilvapalinka/
Találtam tehát 3 oldalt, amikkel kapcsolatban ezeket tudtam meg:
- van egy Wix alapú oldal, ami teljesen jól működik (ahol az új oldalt fejlesztették)
- ez viszont hibásan van egy iframe-mel behúzva a rosenstein.hu domainre
- és a háttérben még él a régi WordPress alapú weboldal
- ráadásul az oldal el van rejtve a Google elől a Disallow-val robots.txt-ben
Ekkor döntöttem úgy, hogy rendet teszek a saját fejemben, hogy vajon mi is történhetett a háttérben. Mert van 3 weboldal, ami közül azt nem indexálja a Google amelyiket egyébként kéne. És van két oldal, aminek nem kéne ott lennie, de mégis ott vannak…
Az oldal története
A Web Archive szolgáltatásával vissza lehet nézni több millió weboldal korábbi verzióját. Itt is ezt vettem elő, és reméltem, hogy lesz információja a Rosenstein domainről is, hisz egy régóta élő, több száz linkkel rendelkező domainről van szó. A tippem helyes volt, találtam róla információt.
Webarchívum
Korábban szó volt a Wayback Machine használatáról redirect auditokhoz. Itt is ugyanezt az eszközt használtam arra, hogy visszanézzem, mikor és melyik weboldal élt és melyiket használták.
Ebből kiderült, hogy számos weboldalt használt az étterem évek során. És szépen végigkövethető a weboldaluk fejlődése, evolúciója.
2005-ben ez az oldalt használták:
2012-től egy ehhez hasonló, de modern WordPress honlap volt használatban:
2017 körül pedig ezt az oldalt lecserélték az elsőként megtalált iframe alapú oldalra és az azt kiszoltáló Wix oldalra.
Káosz weboldal költöztetés: 3 weboldal 1 helyett
Ebből viszont még mindig nem áll össze, hogy miért érhető el párhuzamosan az új és a régi oldal is. Ezért megnéztem, hogy a tárhelyen mi is található. Ehhez Maces terminálon keresztül pingeltem a rosenstein.hu-t.
- ping rosenstein.hu
Windowson a parancssor ugyanúgy használható erre:
- ping rosenstein.hu
Így kiderül a tárhely IP címe: 193.23.139.22
Mivel egy domain csak egy tárhelyhez rendelhető hozzá, így kiderül, hogy a tárhelyen elérhető mind a Rosenstein régi, WordPress honlapja, mind az új iframe oldala.
Mikor az új weboldalt készítették, a tárhely megmaradt, viszont az azon található WordPress oldalt nem törölték le azelőtt, hogy az új oldalt kezdték volna el használni.
Kezd tisztulni a kép, de még mindig vannak homályos pontok.
A jó, a rossz és a csúf
Az iframe oldal csak a főoldalból áll, nincsenek aloldalak. Ez a korábbi Screaming Frog vizsgálatnál kiderült. Egy jó weboldal esetében ezután akármilyen slugot írnánk be az url végére, egy 404-es oldalnak kellene betöltődnie. De itt nem ennyire egyszerű a helyzet.
Ha nem a főoldalt, hanem egy aloldalt szeretnénk betölteni, akkor két lehetőség van:
- létezik az aloldal, ebben az esetben be is tölti azt – pl: http://rosenstein.hu/rolunk/ (ezt WordPress oldal szolgálja ki)
- nem létezik az az aloldal, ilyenkor pedig 404-es oldal töltődik be a WordPress oldalon – pl: http://rosenstein.hu/seo
Mivel a WordPress oldalon élnek aloldalak, ezeket el is lehet érni és ki is lehet deríteni, hogy hány van belőlük. A robots.txt tiltása miatt Googleben ezeket viszont nem lehet megtalálni. Sitemap pedig nincs megadva, ezért a teljes oldallistát kicsit nehezebb kinyerni.
Ilyenkor viszont egy trükköt és a Screaming Frogot használva mégis meg lehet mindent tudni.
1) Mivel nem tudunk a főoldalról indulni (hiszen az egy iframe oldal), egy WordPress aloldalról kell indítanunk a spidert. Ehhez a http://rosenstein.hu/rolunk/ oldalt használtam.
2) A korábban mutatott módszerrel, vagyis Configuration / Robots.txt / Settings menüben az „Ignore robots.txt” bekattintásával le kell tiltani a robots.txt figyelembe vételét.
Ezzel azonban még csak a Rólunk aloldal elemeit kaptam vissza.
3) A Configuration / Spider / Basic menüben be kell kattintani a „Follow Internal „nofollow””-t, ezáltal a belső nofollow linkeket is követi a spider.
Így megkaptam a teljes listát, amiből pedig kiderült, hogy a főoldalon kívül 660 különböző elem érhető el.
Amiből 204 elem a HTML.
Http és https
Ideális esetben azt kellene tapasztalnunk, hogy a http oldal átirányít a https változatra, ott pedig megfelelő SSL certificate-tel rendelkezik az oldal, így valóban létrejön a biztonságos kapcsolat és a várt tartalmat tudjuk letölteni. Ezzel szemben a következő valósul meg:
A http oldal az elvárttal szemben nem irányít át a https verzióra.
Https certificate
A certificate meglétét egyszerűen ellenőrizni lehet: a címsorban az url előtt lévő Secure gombra kattintva kiválaszthatjuk a Certificate részleteit.
Az oldal viszont rendelkezik https certificate-tel, ami 2018. augusztus 19-ig érvényes. Az is látható, hogy Let’s Encrypt-et használtak a hitelesítéshez.
Tehát van működő https változata az oldalnak! Mégis, itt is van plusz egy hiba, amire nem számítottam.
Hiba a https tartalomban
Ha a https változatát tölti be valaki az oldalnak, ez a képernyő fogadja:
Egy-egy fekete sáv az oldal tetején és alján. Valójában viszont a Wix oldal tartalmának kellene betöltődnie.
Két kérdés merül fel ekkor:
- Miért nem töltődik be a Wix oldal tartalma?
- Mi az a két fekete sáv ott?
A Wix oldal betöltésének a hibáját az iframe kódjában kell keresni.
<iframe src="http://szkorossy.wix.com/rosenstein" background="transparent" frameborder="0" height="100%" width="100%"></iframe>
Ha iframe-en keresztül töltünk be egy https oldalt, akkor csak a https tartalmak fognak megjelenni. Az iframe forráskódja azonban ezzel szemben http-n fut.
A dolog szépsége, hogy a Wix oldal eközben https.
Tehát ahhoz, hogy ezt a tartalmi hibát megoldjuk, egyetlen „s” karaktert kellene elhelyezni a kódban a http végére és máris betöltődne az oldal tartalma.
Ezt meg is mutatom, hogy lehet ellenőrizni inspecttel Google Chromeban. Simán csak beleírom az s karaktert a kódba és be is tölt az oldal. (Kattints a bal alsó play ikonra, hogy megnézd a videót.)
A tartalom elrejtésének művészete
Nem hagyott nyugodni az a kérdés, hogy miért töltődik be az iframe-en túl két fekete sáv a weboldalon. Pedig az oldal kódjában egyértelműen látható az iframe előtt közvetlenül. Ez a kód, amiről szó van:
<div style="background-color:black; z-index:10; position:fixed; top:0px; right:0px; width:100%; height:42px;"></div>
<div style="background-color:black; z-index:10; position:fixed; bottom:0px; width:100%; height:50px;"></div>
Ekkor megnéztem a Rosenstein oldalt kiszolgáló Wix oldalt is. Ami így néz ki:
A fekete sáv itt nem él, hiszen az csak az iframe-es oldal kódjában található. És igen,
A fekete sáv arra szolgál, hogy a Wix hirdetéseket eltakarja a Rosenstein végleges oldalán.
Ezzel a lépéssel a Wix aktuális árazása alapján havi 6,25 €-t spórolnak havonta. 310 forintos euróárfolyammal számolva ez évi 23 250 forint.
Javítási lehetőségek
Mi a megoldás a rengeteg problémára?
Rendkívül sok technikai probléma merült fel az oldal vizsgálata során. Ezeket még átlátni se könnyű:
- két különböző weboldal (egy iframe és egy WordPress honlap) él ugyanazon a domainen és ugyanazon a szerveren
- az új oldaluk iframe alapú
- https és https, illetve www és www nélküli átirányítások hiánya
- duplikált tartalmak
- robots.txt-ben az oldal rejtve van a keresőrobotok elől
Ezen kívül rengeteg kihagyott lehetőség van a háttérben
- a Rosenstein oldalának tartalmai relevánsak a keresők számára, de mivel nem megtalálhatóak, vendégeket veszítenek még azelőtt, hogy találkoztak volna velük
- viszonylag könnyen, új tartalmak készítésével a Rosenstein weboldalára releváns forgalmat lehetne terelni, ami az online reputációját önmagában növelné, majd fizető vásárlókká konvertálhatók
- ezek közül érdemes kiemelni az angol és magyar kevert tartalmak tisztázását
- a backlink erő egyáltalán nem hasznosul, amit a Rosenstein domain kap
- az oldalon jelenleg nincs analitita bekötve, tehát azt sem tudják, hogy a honlap hogy teljesít, amit érdemes pótolni
- nincs Open Graph kép és leírás megadva az oldalnál, így közösségi médiában megosztás esetén is várhatóan kisebb az elköteleződés
Ráadásul fájó pont, hogy továbbra sem találtam meg az aktuális étlapot.
A következőkben a problémák azonosítása után javaslatokat adok a fő problémák megoldására. Mindezt úgy, hogy a meglévő Wix alapú weboldal használatával tervezek. Tehát nem új weboldal készítésével.
Tárhely és domain-, átirányítási- és duplikált tartalom problémák megszüntetése
A legszebb szerintem az egész Rosenstein weboldal technikai marketing elemzésben, hogy:
A legtöbb probléma nagyjából 10-15 perc alatt orvosolható, ráadásul a Rosenstein weboldal költségei is alig nőnek.
Ehhez pedig a következőket kell csinálni:
- elő kell fizetni a Wix prémium szolgáltatásaira
- át kell irányítani a domaint a Wix tárhelyére névszerver segítségével
- törölni kell a tárhelyen lévő WordPress tartalmat és lemondani a tárhelyszolgáltatást
Wix prémium szolgáltatás előfizetés
A prémium szolgáltatásra azért van szükség, mert így használható a Wix tárhelye, így nem kell a továbbiakban fenntartani a saját tárhelyet.
Ezzel a megoldással rengeteget nyerne a Rosenstein, hiszen:
- innentől nem lenne szükség az iframe oldalra egyáltalán,
- a tartalmat így is kiszolgáló Wix oldal lenne elérhető a domainen a továbbiakban
- ez az oldal alkalmas lehet arra, hogy megjelenjen a keresőkben, ezáltal SEO forgalmat generáljon
- megszűnnek a hirdetések az oldalon az előfizetés miatt
- a jelenlegi saját tárhelyen lévő oldalak törölhetőek, így a WordPress oldal általi tartalom-kiszolgálás is megszűnik
- a http és https verziók átirányítási problémái és tartalom duplikációk megszűnnek, mivel a Wix hátterű oldal ezt kezeli
- a www és www nélküli verziók átirányítási problémái és felesleges tartalom duplikációk megszűnnek, mivel a Wix oldal ezt is kezeli
- a saját tárhely innentől kezdve lemondható, ami a költségek csökkentését eredményezi
- gyorsabb lesz a weboldal betöltődési sebessége
- megszűnnek a jelenlegi főoldal duplikációk, mint a rosenstein.hu, és a rosenstein.hu/index.html
Mindennek a költsége pedig nagyjából évi 23 250 forint. Plusz egy kis idő, amit rá kell szánni a módosításokra.
Domain átirányítása névszerverekkel
A WhoIs rekordból kiderül, hogy a domaint 2004 szeptemberében regisztrálták és a Viacom Informatikai Kft. a domain regisztrátor. A névszervert is ők biztosítják.
Névszerver: ez mondja meg a domain lekérdezésekor a látogató böngészőjének, hogy milyen IP cím tartozik a domainhez. Ezen az IP címen található a tárhely. A tárhelyen pedig a weboldal érhető el.
Mivel nem Wix regisztrálású domainről van szó, két módja* van a domain átirányításának:
- névszerver beállítás
- pointing
*Néhány TLD esetében lehetőség van a domain átmozgatására Wixhez, de a .hu nincs köztük.
A pointing nem ajánlott átirányítási megoldás, ezért a névszerver beállítást érdemes használni. A névszerver beállításon keresztüli domain átirányításról a Wix nyújt pontos leírást.
A logikai ív mögötte viszont annyi, hogy a Viacom e-Tiger névszervereit át kell állítani a Wix által megadottra. A tárhellyel külön nem kell foglalkozni, azt automatikusan biztosítják.
Tárhely törlése és szolgáltatás lemondása
Amint az átirányítás megtörtént, a meglévő tárhelyre már nincs szükség, így ha nincs rajta másik weboldal, amit használ a Rosenstein, érdemes innen törölni a meglévő tartalmakat, majd lemondani a szolgáltatást.
Ezzel legalább évi 12.573 forint megtakarítást eredményez majd. Tehát összesen nagyjából
23 250 – 12 573 = 10 677 forint extra költséget jelent évente.
A szolgáltatást a Viacom ügyfélszolgálatán lehet lemondani a szolgáltatáscsomag módosítása oldal alapján.
Indexálás tiltásának megszüntetése
Ha a jelenlegi https://szkorossy.wixsite.com/rosenstein oldal átirányításra kerül a https://rosenstein.hu/ domainre, nem lesz tartalom duplikáció, így a Rosenstein oldal indexálása is célszerűvé válik.
A Google organikus forgalom szerzésének alapvetően 3 feltétele van:
- crawlolhatóság
- indexálhatóság
- jó helyezések
Erről szól ez az angol nyelvű Matt Cutts videó:
1) Ebben az esetben tudjuk, hogy a Wix oldal crawlolható, hiszen már így is indexálva vannak Googleben:
- site:https://szkorossy.wixsite.com/rosenstein
2) Az indexálhatóság jelenleg robots.txt-ben van letiltva, ami a WordPress sitehoz tartozik. Viszont az átirányítással az a robots.txt megszűnik és egy új kerül a helyére. Ebben azonban figyelni kell rá, hogy ne legyen elrejtve az oldal a Google indexeiből.
Továbbá érdemes Wixen generálni egy sitemapet, amit a robots.txt-ben fel kell tüntetni ezután, hogy a botoknak iránymutatást adjon.
Többnyelvű tartalmak szétválasztása
Jelenleg az oldal kétnyelvű. Magyar és angol. Ez viszont nem nyelvi változatokkal van elválasztva, hanem ugyanazon az oldalon kétnyelvű leírásokkal. Ez természetesen nem felhasználóbarát. És ezt a Google is tudja.
Amennyiben végiggondolták és valóban szükség van többnyelvű oldalra, érdemes valós nyelvi változatokat készíteni és azt az oldal kódjában is lekezelni.
Nemzetközi SEO segítségével a botok felé hreflangekkel jelezhető, hogy több különböző URL-en található oldal valójában egy csoportba tartozik. A hreflangek implementálásához a Google irányelveit kell követni.
Backlink erő kihasználása
A Rosenstein oldalára mutató linkek száma önmagában impresszív az online aktivitáshoz viszonyítva: 1079 backlink, 243 domainről.
Ez akkor is így van, ha ennek egy része linkfarmokról és különböző cégtudakozókból származik Ahrefs alapján.
A linkerő jelenlegi formájában egyáltalán nem hasznosul, azonban a domain átirányítása után már fog. Legalábbis azok, amelyek most is létező oldalra mutatnak.
A linkerő csak abban az esetben hasznosul, ha az egy létező oldalra mutat. Ha az oldal azóta megszűnt és 404-es hibaüzenetet kap a felhasználó, aki a linken keresztül érkezik, annak a SEO értéke sem közvetítődik.
Ezért a maximális linkerő kihasználásához egy kis plusz munkára van szükség: fel kell fedezni azokat a linkeket, amelyek 404-es oldalra mutatnak.
1) Valamilyen backlink adatbázisból (Ahrefs, SEMrush, Majestic) le kell gyűjteni a backlinkeket. Ehhez fizetős verzióra van szükség, de például az Ahrefsből – amelyik a legnagyobb adatbázissal rendelkezik – van 7 napos trial időszak.
SEMrush képzés
Ismerd meg Te is az egyik legnépszerűbb SEO eszközt!
A SEMrush tanfolyamban összeszedtük azokat a funkciókat, amit mi is a legtöbbet használunk a napi munkánk során. Megismerhetsz benne a kulcsszókutatáshoz, versenytárselemzéshez, vagy akár linképítéshez hasznos folyamatokat. Ezekhez pedig részletes leírást és magyar nyelvű oktató videókat is készítettünk.

2) Az exportált adatbázisban azokat az URL-eket kell végignézni, amelyekre a hivatkozások mutatnak. Ezek közül ki kell szűrni azokat, amely oldalok ma már nem léteznek (vagy most még a WordPress honlapra irányít), pl:
- http://rosenstein.hu/en/
- http://rosenstein.hu/category/blog/
- http://rosenstein.hu/galeria-2/
Ezen túl arra van szükség, hogy ezeket a linkeket kitől kapta az oldal.
3) Ha van kontakt azokhoz, akik a hivatkozásokat adták, akkor érdemes megkérni őket, hogy frissítsék őket https-re, illetve a most megfelelő oldalra.
4) Ha nincs kapcsolat a hivatkozást adóhoz, akkor is hasznosítható a linkérték egy része. Újra létre kell hozni a korábbi oldalt, amire hivatkoztak, majd azt 301-es átirányítással átirányítani a főoldalra, vagy egy releváns oldalra. Esetleg egy olyan oldalra, aminek linkre van szüksége ahhoz, hogy jobb helyezést érjen el Googleben.
Ezen túl érdemes végignézni a linkeket abból a szempontból is, hogy melyek lehetnek károsak. És azokat disavowolni. Erről az IKEA esettanulmányban írt Papp Gábor részletesebben.
Analitika bekötése
Hogy az eredményeket valóban mérni is lehessen, legalább Google Analytics és Google Search Consolet indokolt lenne bekötni. A Google Analytics kódot a Wix útmutatója mentén lehet bekötni, a GSC pedig verifikálható a GA asszinkron kóddal.
Open Graph adatok megadása
Ugyan az OG adatok nem tartoznak szorosan a keresőoptimalizáláshoz, mégis érdemes erre az apróságra figyelni, hiszen a közösségi médiából származó forgalom konverzióját jelentősen befolyásolja.
Mivel a Rosenstein esetében a Facebook Debugger nem talál megfelelő adatot, így nem tud megfelelő OG címet megjeleníteni, míg OG képet, és OG leírást egyáltalán nem talál.
Tehát az OG képet és leírást érdemes definiálni és beállítani minden aloldalon. Így ha valaki megoszt egy tartalmat, linket a Rosenstein weboldaláról, akkor Facebookon jó leírás, jó kép és szöveg fog megjelenni.
Az OG adatokról korábban a Facebook Debugger használatáról szóló cikkben írtam részletesebben.
Az új étlap
Ha a költöztetést jól csináljuk meg, akkor a Rosenstein + étlap kifejezésre keresve lehetőségünk lesz a valódi, és nem a 2013-as étlapot is megtalálni. Az aktuális étlapot a főoldal legalján belinkelve találhatjuk most. Ezt érdemes lenne a fenti menüpontok közé is elhelyezni.
Tanulságok
A rossz weboldal károsabb tud lenni annál mintha nem is lenne egyáltalán. Felhasználói (vendéglőbe járó) oldalról szerintem ez igaz a Rosenstein weboldalára is. Létezik, a „kötelezőt lehozták”, de közel haszontalan jelenlegi állapotában. Ami pedig az étterem hírnevéhez méltatlan.
Egy weboldal fejlesztésénél érdemes inkább előre kikérni egy jó SEO szakértő tanácsait, aki 1-2 óra alatt olyan dolgokra tud rávilágítani, amelyek kiküszöbölésével később komoly presztízsveszteség kerülhető el.
A teljes háttértörténetről persze nem sokat tudok így kívülről. A weboldalt érintő problémáktól elvonatkoztatva, az oldal készítőjének kimondottan szép grafikai munkái érhetőek el. Hogy a költöztetés hol csúszott el, azt nyilván házon belül jobban tudják.
A lényeg az, hogy a hibák nagy része viszonylag könnyen, gyorsan és szinte költségmentesen javítható. Ezért érdemes is lenne időt szánni rá. Egy kétszemélyes vacsoráért cserébe, például én is szívesen megcsinálom őket. 🙂
Tetszett a cikk? Szeretnél még több ilyet olvasni?
Akkor iratkozz fel és küldünk egy emailt, ha hasonló cikket írunk!
Hozzászólások
Moderáld magad – vagy mi fogunk. :)
Na jó, nem fogunk, szóval csak ésszel!