SEO: optimalizálás htaccess segítségével

A SEO, azaz keresőoptimalizálás egy becsületes szakma, aminek alapjait egyszerű programozóként is érdemes elsajátítani. Profi valószínűleg nem leszel, mert az teljes embert kíván, viszont olyan SEO alapokat tudsz adni az oldaladnak, amivel az ügyfeled már meg lehet elégedve.

A htaccess ráadásul egy egyszerű szöveges fájl, amit egyszerűen lehet szerkeszteni, és könnyű az adott oldalhoz igazítani.

Egy SEO szakember agya

Ha megértjük hogyan működik egy SEO szakember agya, egyszerűbb lesz elvégezni a munkáját.

Egy seo szakember agya
Ha SEO szakember olvassa ne sértődjön meg, ez csak poén.

A fenti ábra egy karikatúra, amivel arra szeretném felhívni a figylmed, hogy milyen NE legyél. Az első és legfontosabb dolog ami segít első helyre kerülni a keresőoptimalizálásban, az a minőségi tartalom aminek valami egyedi mondanivalója van, és a gyors oldalbetöltés.

.htaccess és a keresőoptimalizálás

Az alapokról annyit, hogy létre kell hoznunk egy .htacces fájlt abban a mappában, ahol a fő index.php fájlunk van (amelyik kezeli a beérkező kéréseket). Ez egy sima szöveges fájl, amit a szerver még azelőtt feldolgoz, hogy bármihez hozzányúlna a fájljaink közül.

IE turbó

Van, hogy az Internet Explorer “modern” verziói IE7 verzióban jelenítik meg a tartalmat, ezt kiküszöbölhetjük azzal, hogy kényszerítjük a legfrissebb motor használatára. Plusz, ha telepítve van a ChromeFrame (egy csomó jó cuccot engedélyez), abban jeleníti meg az oldalt. Ehhez mindössze a következő sorokat kell bemásolni a .htaccess fájlba:

Gzip tömörítés

A következő néhány sor engedélyezi és alkalmazza a gzip tömörítést, így kevesebb adatot kell átpumpálnunk a klienshez -> gyorsabb betöltődés -> jobb felhasználói élmény -> öröm, bódottá!

Az első rész talán a legérdekesebb, ahol meg van mókolva a header (mókolva = piszkálva). Valaki egyszer a statisztikákat bújva rájött, hogy a felhasználóknak 15%-a nem tömörítve kapja meg az adatokat, holott a küldő és fogadó fél részéről is adottak a lehetőségek. Hamar rájött, hogy néhány proxy és biztonsági program buzerálja meg azokat a fejléceket, amelyek a tömörítésre vonatkozó adatokat tartalmazzák, emiatt nem működik a varázslat. Az első pár soros nyers kód pontosan ezt hivatott megoldani, de ne akard tudni a mocskos részleteket, csak másold be.

A maradék egyszerűen megoldja a tömörítést. Megspórolsz egy csomó sávszélességet, az oldal gyorsabban töltődik be, a felhasználó boldog, a Google boldog.

Cache, Expires header

A böngésző minden egyes oldal betöltésekor lekéri az összes adatot a szerverről akkor is, ha mondjuk egy fejlécben szereplő logó képről, vagy az összes oldalon jelen lévő css fájlról van szó. Kivéve, ha szólunk előre a böngészőnek, hogy ez a fájl bizony sűrün elő fog fordulni, ráadásul igen ritkán változik a tartalma, szóval mi lenne ha tárolná és nem kéregetné folyton.

A következő sorok a különböző fájl típusokhoz rendelnek lejárati időt. Ha ez letelik, a felhasználó böngészője ismét lekéri a tartalmat a szerverről, addig viszont megspórol egy csomó felesleges adatforgalmat. Ez főleg most, a mobilnet fénykorában fontos.

Ezek elég ravasz módon ki vannak találva, azonba ha valamilyen okból kifolyólag hetente lecseréled a fontokat, bátran írd át a megfelelő sort.

Ezen kívül van még egy módja az új verziók letöltésének kikényszerítésére, amit rendszeresen használni is szoktunk css fájlok esetében például. Ha módosítod a css/pelda.css fájlt, a html kódban hivatkozz rá a következőképpen: css/pelda.css?20160923

Nem muszáj az aktuális dátumot beírni, lehet verziószám vagy bármilyen egyedi dolog a kérdőjel után, de ez alapján a kliens böngészője felismeri, hogy a névegyezéstől függetlenül új fájlról van szó.

ETag

Ez egy jó dolognak indult anno, de mára teljesen elavult. Feladata, hogy minden lekért fájlhoz generál egy kódot a tartalma alapján. A kliens például lekér egy css fájlt, ami mellé megkapja a hozzá tartozó ETag-et is: 10c24bc-4ab-457e1c1f. Legközelebb mielőtt lekérné, megkérdezi a szervert, hogy változott-e az ETag, és amennyiben nem, a már letöltött változatot használja. Az ETag csak akkor változik, ha módosítunk a fájlon.

Az egyetlen probléma ezzel az, hogy hiába használom a pandeveloper.hu és pandaegyetem.hu oldalon is a jQuery ugyanazon verzióját, mindkét alkalommal lekérésre kerülne a fájl, mivel az ETag-ek szerverenként különböznek. Az expire header ezt a problémát áthidalja.

Ezzel a pár sorral le is tiltjuk az ETag használatát, csökkentve a folyamatok számát.

www. előtag

A rewrite engine teszi lehetővé, hogy a szerverhez érkező url kéréseket manipuláljuk, és például a pandeveloper.hu/wordpress cím beírására ugyanaz a tartalom jöjjön be, mint a pandeveloper.hu/?id=69. Így tudunk felhasználóbarát url címeket készíteni, illetve átirányításokat, és aldomaineket kezelni.

Az a nagy helyzet, hogy a kereső motorok duplikált tartalomnak tekintik ha egy oldalt www előtaggal, és a nélkül is el lehet érni. Ezért büntetés jár, és az oldal hátrébb kerül a rangsorban. Kötelezzük el magunk valamelyik mellett (szerintem a www nélküli szebb) és használjuk azt.

Íme a www nélküli módszer, ami a www.pandeveloper.hu beírásakor átalakítja azt pandeveloper.hu formára:

Aztán ennek az ellenkezője (ügyeljünk rá, hogy csak az egyiket illesszük be a kódunkba!):

Url végi / jel

Kevesen tudják, hogy ugyanilyen büntetés jár ha egy oldalt per jeles és perjel nélküli url címen is el lehet érni. Elérés alatt itt azt értem, hogy ha beírjuk a böngésző címsorába az urlt, akkor enter leütése után is az marad bent, és nem lesz átirányítva.

A kijavított változatra példa a https://pandaegyetem.hu/befektetes-alapjai-egyszeruen/ és https://pandaegyetem.hu/befektetes-alapjai-egyszeruen. Ezekre a linkre kattintva, ugyanaz az oldal jön be, a böngésző címsorában is ugyanaz a cím szerepel, pedig a másodikat / jel nélkül próbáltuk elérni.

Ha használjuk a .htacces átírást, akkor a keresők motorja nem lát majd duplikált tartalmat.

Először a / jel használata, amit nagyobb előszeretettel használnak:

Illetva a / jelek levétele (itt is csak az egyiket szabad használni!):

Error 404

Miért fontos az Error 404 és 500 hibák saját oldallal való lekezelése? Ez a SEO-nak egy olyan része, amelyik megpróbálja a felhasználókat az oldalon tartani.

panda 404
A Pandák 404 oldala

Ha kapsz egy sima 404 oldalt csak mert elgépeltél egy karaktert, akkor lehet, hogy fogod magad és inkább máshová mész. Azonban ha a 404-es oldalad ki van egészítve pár speciális dologgal, például egy “Erre gondoltál?” és link egy lehetséges tartalomhoz az oldalon belül, akkor valószínűleg a felhasználó azt meg fogja nézni. Persze fontos, hogy lehetőleg releváns linket mutass neki.

Ezen kívül javítja a felhasználói élményt, ha valami vicces kidolgozott hibaoldal fogadja őket. Én például ilyen hibaoldaltkészítettem, nekem ennyi elég, de vannak ennél szebbek és jobbak.

Általában php-n belül dobálunk kivételeket, és azok hozzák be ezeket az oldalakat. Ha ehhez nem értesz, akkor is élhetsz a speciális hibaoldalakkal, mindössze meg kell adnod a helyüket:

További források

Egy oldal minél kevesebb DOM elemből épül fel, minél tisztább, annál jobban szeretik a keresők. Érdemes elolvasni a Google útmutatóját, vannak benne hasznos dolgok.

A fenti kódokat http://html5boilerplate.com/ erről az oldalról szereztem. Paul Irish nagy arc, sokat lehet tőle tanulni, nézzétek a videóit, tanulmányozzátok a munkáját.

Nekünk, programozóknak kell rendbe tennünk az internetet. Sokan csak tele szemetelik, de takarítani senkinek nincs kedve. A legegyszerűbb, ha kiemelkedünk tiszta kódunkkal és a szabványokat szem előtt tartó programozással.

Szerintem hamarosan eljön az az idő, mikor az internet szétbomlik egy rendezett és egy rendezetlen részre, és akkor szeretném, ha az oldalaim nem a gettóban lennének.

Jó optimalizálgatást!