A blog történetének első vendégposztja következik. Varga Bence tisztelt meg kérésemre egy írással keresőre optimalizált HTML – CSS kódolás témájában. Volt korábban egy ilyen jellegű kérés, amikor a blog olvasóit arról kérdeztem, hogy miről szeretnének olvasni.
Bence zömében webes alkalmazásokat fejleszt és a szabványok elkötelezett híve.
Nézzük ő hogyan látja ezt a kérdést és mit tanácsol keresőbarát kód írásához.
A keresőoptimalizálás számomra inkább vallásnak tűnik, mintsem tudománynak. Mindannyian értelmezni próbáljuk láthatatlan szent könyvünk, a Google algoritmus parancsolatait. Minannyian saját értelmezésünkben hiszünk, ehhez ragaszkodunk. Ebben a cikben megpróbálok összegyűjteni néhány szabályt, amire én figyelek, amikor egy oldal HTML+CSS szerkezetén dolgozom. A tanácsokat igyekszem egyenként megindokolni, hátha hitelveim termékeny talajba hullanak a tisztelt olvasó lelkében.
Első látásra meglelpő lehet, hogy ezek a tanácsok mennyire egybeesnek a webes akadálymentesség megoldásaival. A logikai kapcsolat viszont könnyen felfedezhető: megpróbálunk az oldal legalsó szintjét, a HTML-t minél több indormációval ellátni, ami a grafikus megjelenítés nélkül is értelmezhető.
Helyes szemantika
A kereső robotok sem grafikusan olvassák az oldalunkat. Nincs információjuk arról, mi fog majd egymás mellé / alá kerülni a kész oldalon, mi lesz nagy piros és mi csak kis fekete betűkkel. Azt azonban látják, mi van egymáshoz közel, mi alkot egy egységet a HTML forrásban. Grafikus megjelenítés nélkül is felismerhetők egy bekezdés határai, amelyet P tagbe zártunk. Látható, hogy fontosnak tartjuk a szöveget amit a STRONG tag fog körül, vagy hogy hova fektetjük a hangsúlyt az EM tag segítségével.
A leghangsúlyosabb kiemelés, amivel élhetünk nem más, mint a cím: H1, H2, H3 … Igyekezzünk tagolni a szöveget, belső címeket használni 4-5 bekezdésenként (persze ahogy a szöveg is engedi).
Ezek használatával, ha a kereső nem is érti a szavak jelentését, egy struktúrát kap, amiből könnyebben és nagyobb megbízhatósággal kibányászhatja, hogy miről is beszélünk az oldalon. Ez a biztonság egyrészt előnyös a keresőnek, mert nem vakon halászik egy szólevesben, hanem tippeket kap, mely kulcsszavak lesznek jellemzőek a szövegre, másrészt mi is jobban beirányozhatjuk az oldalt az illető kulcsszóra, ha nem engedjük, hogy az indexelés során “elkeveredjen” a lap érdektelen kulcsszavak felé.
A valódi tartalom pozíciója a fájlon belül
Egyik oldalon a keresett kulcsszó előfordul a második bekezdésben, a másik oldalon a tizedikben. Melyik dokumentum lesz az érdekesebb a számodra? Valószínűbb, hogy az első. (Persze a kereső nem tudja, mi jár a fejedben, amikor egykét kulcsszót beírsz a mezőbe, de belátható, hogy az esetek nagy százalékában nem a témára specializálódott írásról beszélhetünk, ha csak a szöveg felénél fordul elő először egy kifejezés).
Mit tehet érted a CSS? A szöveget nem írja meg helyetted, viszont segít megfelelően pozícionálni azt az oldalon. Képzeljünk egy klasszikus 3 oszlopos oldalfelépítést. Először lássuk táblázat alapú layouttal:
<table>
<tr colspan="3">
<td>
{fejléc kép}
{fő navigáció}
</td>
</tr>
<tr>
<td>
{navigáció}
{legújabb cikkek}
{szavazás}
{reklám}
</td>
<td>
{valódi tartalom}
{kapcsolódó írások}
</td>
<td>
{legújabb képek}
{naptár}
{reklám}
</td>
</tr>
</table>
Most ugyenzt az oldalt CSS alapokon:
<div id="wrap">
<div id="main">
<div id="content">
{valódi tartalom}
{kapcsolódó írások}
</div>
<div id="nav">
{navigáció}
{legújabb cikkek}
{szavazás}
{reklám}
</div>
</div>
<div id="sub">
{legújabb képek}
{naptár}
{reklám}
</div>
<div id="head">
{fejléc kép}
{fő navigáció}
</div>
</div>
A különbséghez nem szükséges sok kommentár. Amíg az első, táblázatos megoldás szigorúan fentről lefelé, balról jobbra haladva írja le a tartalmat, addig a CSS lehetsőséget ad az elemek némileg szabadabb pozícionálására. Az eredmény: az első esetben a szöveg elejét (ahol igazán figyel a kereső) érdektelen statikus elemek töltik ki (fejléc, navigáció, kiajánló). A CSS alapú layoutnál fontosság sorrendjében helyezhetjük el a tartalmat a fájlon belül. (Akár a bal és jobb oszlop helyét is megcserélhetjük, ha úgy látjuk jónak).
A cikknek nem célja a CSS oktatása, de azok számára, akik még mindig nem hisznek álljon itt a második példát teljessé tevő stíluslap:
#wrap {
width: 900px;
margin: 0 auto;
padding: 150px 0 0 0;
}
#main {
width: 700px;
float: left;
}
#content {
width: 500px;
float: right;
}
#nav {
width: 200px;
float: left;
}
#sub {
width: 200px;
float: left;
}
#head {
position: absolute;
top: 0;
height: 150px;
}
Grafikus elemek text alternatívái
Köztudott, hogy a keresők a szövegben keresnek. Egy meglévő oldal optimalizálásánál az első dolog általában a szöveges navigáció biztosítása az oldalon. A flash ugyan a legrosszabb választás, aminél kép-alapú link egy fokkal jobb, de messze nem ideális:
<a href="termekek.html"><img src="termekek.gif"></a>
Mi magunk elsőre láthatjuk, hogy a “Termékek” menüpont kódja áll itt előttünk, de ha egy keresőt üzemeltetnénk mennyire adnánk hitelt egy olyan könnyen manipulálható dolognak, mint a fájlnév? Persze butaság lenne átesnünk a ló túlsó oldalára, és azt mondani, semennyire. A fájlnév is egy tényező a rangsorolásnál, de önmagában vajmi keveset jelent. Főleg egy ilyen linkhez képest:
<a class="menu" href="termekek.html"><span>Termékek</span></a>
Persze a stíluslap fogja a fenti linket grafikussá tenni:
a.menu {
display: block;
width: 200px;
height: 40px;
background: url('termekek.gif');
}
a.menu span {
display: none;
}
Ez szintén egy bevett eljárás akadálymentesítésre. Divat például grafikus címeket használni. Ezek H1 és H2 elemek, amik előre elkészített képet tartalmaznak (általában az olvasók gépén nem szereplő, egyéni karakterekkel, grafikus effektekkel). Ezeknek az elemeknek így egyszerűen megoldhatjuk a szöveges alternatíváját.
Persze felvetődik itt a hidden text kérdése. A google irányelvei szerint nem szerepelhet rejtett szöveg a weblapon. Néhányan a következő trükköt használják:
a.menu span {
position: absolute;
top: -1000px;
left: -1000px;
}
Itt nem konkrét elrejtésről van szó, hanem kiküldik a szöveget valami képernyőn kívüli pozícióba. Néhányan a z-indexszel variálnak. Ami biztos: a Google nem fog kitiltani automatikusan azért, mert display: none szerepel az egyik CSS fájlodban. Ha meg rosszhiszeműen használod, és ott van ezer kulcsszó, eltüntetve, bármilyen trükkösen is teszed ezt (-1000 vagy z-index) ha valaki bejelent a csalásért úgy is ban lesz a vége. Kapcsolódó: Matt Cutts néhány kommentje a témában 2005-ből.
Dizájn elemek csak backgroundban
A dizájnhoz használt képeket (fejléc, keretek, sarkok) amúgy sem a google képkeresőjébe szánjuk. Ezekre mindig a background CSS paramétert használjuk. Ha IMG-ként csak a valódi, tartalomhoz kapcsolódó képek szerepelnek a forrásban, mindenképpen több “figyelmet” kapnak a keresőktől. Nem akarok találatokba bocsátkozni a kép rangját illetően, de egy biztos: a második IMG egy oldalon könnyebben fog bekerülni az indexbe, mint a harminckettedik.
Képek megfelelő elhelyezése
Bevett megoldás, hogy a dokumentumban képek lekicsinyített változatát (thumbnail) használjuk. általában valamilyen módon linekjük a képek nagyobb változatát is. A legkézenfekvőbb megoldás, azonban nem jár túl esztétikus eredménnyel:
<a href="nagykepek/farkas.jpg"><img src="kiskepek/farkas.jpg" alt="..." title="..."></a>
A fenti kód betölti a kiskepek/farkas.jpg képet. Rákattintva pedig teljes méretű változata, a nagykepek/farkas.jpg jön be, kitöltve a böngészablakot. Ennél egyértelműen cizelláltabb megoldást szeretnénk. Gondolhatunk a TARGET=”_blank” módszerre, ami már nem a HTML dokumentum helyén, hanem új ablakban hozza be a képet. Ha ez a megoldás megfelel nekünk, akkor itt meg is állhatunk. Egy oktató anyaghoz tökéletes. Céges környezetben azonban valami látványosabbal, kényelmesebbel, kezelhetőbbel szeretnénk villogni. És itt kezdődnek a problémák.
Megnyithatjuk például fejléc nélküli, méretre szabott ablakban javascript segítségével:
<a href="javascript:kepPopup('nagykepek/farkas.jpg');"> ...
Itt viszont a crawler (spider, akármi) nem fogja követni a linket. Mi sejthetjük, hogy a paraméter egy fájlnevet takar, amit a böngészőbe beírva letölthetünk, a kereső viszont nem fogja lefuttatni a JavaScript kódot. Számára egyszerűen egy olyan protokoll, amit nem tud követni. Készíthetünk egy dinamikus megoldást, amikor egy minimális fejléc (vagy keret) jelenik meg a kép körül (például index.hu):
<a href="kepmutat.php?file=nagykepek/farkas.jpg"> ...
Ezt a linket már követni tudja a keresőrobot. Hátránya viszont, hogy a kép egy dokumentummal (egy linkkel) távolabbra került az alap oldaltól, így a kép körüli kulcsszavaktól is! És a Google képkeresőjében is ez az oldal fog bejönni, amin ugyan rajta lesz a lapunk fejléce, de sokkal jobban szeretnénk, hogyha az alap dokumentumon landolnának a látogatónk a keresőkből.
Ebből a szempontból a legjobb megoldás valahogy így működik:
<a href="nagykepek/farkas.jpg" onclick="javascript:kepPopup('nagykepek/farkas.jpg'); return false;"> ...
A HREF-et követve a kereső egyből megkapja a képet. A valódi látogatók pedig kattintás után részesülhetnek akármilyen flancos effektben, amit kitaláltunk nekik. (A return false pedig letiltja a böngésző alap-működését, tehát a kép nem fog betöltődni a dokumentum helyére). Szépíthetünk a megoldáson diszkrét JS alkalmazásával. Szerencsére a népszerű kép-effektek is (LigntBox, LightWindow) ez utóbbi módszert preferálják. Használatuk leveszi a vállunkról a szkriptírás terhét is.
A sokéltŰ TITLE tulajdonság
A képek gyorstippjeinek helyes megadása is a TITLE-lel történik. Sajnos az IE működése ahhoz a berögződéshez vezetett, hogy az ALT szöveget – helytelenül – gyorstipp megejtésére használják ma is. (Pl: “Kattints ide a kép kinagyításához”). Az ALT tagben egszerűen írjuk le a képen látható dolgokat, mint például – Matt Cutts macska-példájának szellemében – “macska a konyhában”. És ne feltétlenül a kulcsszó célzás eszközévé tegyük (“nátrium gazdag tápszer kisállatoknak”). A TITLE attribútum itt is bőséges helyet kínál a kép magyarázatára. – És ne becsüljük alá azokat a látogatókat, akiket a “macska” képünkre kapunk, hiszen ők is potenciális kuncsaftok a tápszerre. (Az a bizonyos long tail effektus…)
A TITLE gyakorlatilag az összes elemhez megadható. Gyakran előfordul, hogy egy mondatban néhány szó linkként funkcionál. Ilyenkor hasznos plusz információt adni arról, hova is vezet a link, vagy mi a kapcsolata a szöveggel. Ha kitöltjük a TITLE-t nem csak az olvasók dolgát könnyítjük meg, de jó helyet biztosít egy rövid kulcsszógazdag szövegnek, ami még a linkhez is kapcsolódik.
Rövid, navigációs linkek kiegészítője is lehet. Egy Letöltés feliratú link mellé például nem árthat egy “Ingyenes próbaverzió letöltése” kiegészítő szöveg.
Ha szakkifejezéseket használunk, első előfordulásukkor jelezzük őket a DFN (definition) taggel, és fejtsük ki jelentésüket a TITLE attribútumban. Ezek a szövegek általában egér-ráhúzásra, gyorstippként jelennek meg. Rövidítéseknél ugyanígy, megadhatjuk a “hosszú változatot”, csak ekkor az ABBR taget használjuk a szó körül.
ID, NAME: na ne vicceljünk
Két újabb tuajdonság, ami a tagek 90%ához biggyeszthető. Ne engedjünk a csábításnak. Az, hogy elemeknek fölöslegesen NAME-et adunk meg, kulcsszavakkal teletűzdelve elég kétségbeesett megoldás. Egyrészt alapból helytelen felhasználás, másrészt túl könnyen manipulálható. (Emlékszünk még a KEYWORDS META tagre?) Ilyesmivel ne égessük magunkat.
Nyelv jelölése
A Google általában jól becsüli meg a dokumentumok nyelvét. De miért ne biztosítsuk be magunkat (különösen ha nemzetközi domainen van az oldalunk)? Én a kezdő HTML tagben mindig megadom őket (a második csak XHTML esetén érdekes):
<html lang="hu" xml:lang="hu">
Szöveg/kód arány és szabványosság
A rangsoroló algoritmus egyetlen célja, hogy minőségi, releváns találatokat adjon a témában. Van összefüggés a HTML aránya és a tartalom minősége között? Valamennyi biztosan. Egy olyan médiumnál, ahol nem sajnálták a pénzt és időt igényes, minőségi kód létrehozására, ott valószínűleg a tartalom terén is hasonló igényesség lesz jellemző. Ez a korreláció azonban nem túl erős.
Ha a kód validitása felől közelítünk, akkor még ebbe a szalmaszálba sem kapaszkodhatunk. A szabványos kód egyáltalán nem dívik mostanában. (Igaz, cnn.com és nytimes.com)? Itt biztosan nem fogunk korrelációt felfedezni, hiszen már egy hiányzó ALT attribútum is elég a validitás elveszéséhez. Rosszabb lesz ettől a tartalom? Biztosan nem.
Mindezek alapján egy olyan forgatókönyvet tudok elképzelni, hogy van néhány súlyosabb HTML hiba, ami már a forrás alapján is negatívan hat a dokumentumra. Vagy például a linkekkel kapcsolatos. Ezek talán gyakorolhatnak negatív hatást. Ha jó tanácsot szeretnék adni: írjunk tiszta, szabványos kódot, de ne a jobb hely reményében, hanem hogy saját életünket könnyítsük meg vele.
Zárszó
Egy-egy tipp megítélésekor mindig képzeld bele magad a kereső helyébe. Te mi alapján rangsorolnál? Mi adhat tippet arról, hogy az egyik oldal egy picit jobban a témába vág, mint egy konkurense? A Google-nél a dokumentum felépítése mindig is másodlagos lesz, az algoritmus lelkét a rád mutató linkek elemzése jelenti. Azonban egy jó minőségű, világosan besorolható tartalom, relevanciájával könnyen megelőzhet egy sűrűnbben linkelt weblapot is.