SEO tanfolyam – második lecke

Ez a lecke egy rövid sugallatból áll, ami a következő. Kedves olvasó, ne legyél annyira hülye, mint én és használj canonical tagot, ha már egyszer Website Optimizeres tesztelésre adtad a fejed (teljesen jogosan). Az ember sokféleképpen képes magát érzékeny területen rúgni….

SEO tanfolyam – első lecke

<elso lecke>

hogyan add vissza a látogatók 90%-át

8 órám volt kideríteni, hova lett egy weboldal látogatottsága, illetve mivel lehet visszahozni azt a sírból.

2 órába tellett rájönnöm és a megoldás is egyszerű volt: kérjük meg a designert, hogy ne vegye ki a tracking kódot a forrásból legközelebb.

</elso lecke>

Új scriptet telepítettem. Átirányítanám a régit, de hogyan?

Pár hete szembesültem azzal a problémával, hogy egy adott könyvtárba telepített scriptnek mennie kellett és helyébe csak egy sima index oldal került. 404-et nem akartam adni és errordocumentként sem akartam kiszolgálni az új index fájlt, így aztán maradt a rewrite. Ez a történet jó pár óráig feltartott, de két lépésben azért csak sikerült az alábbi kódokkal.


RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) /mappa/ [L,R=301]

Amennyiben a kért mappa, vagy fájl nem létezik a szerveren, akkor érvénybe lép a szabály.

Ezzel eléggé boldog is voltam jó sokáig, azonban később sikerült felfedeznem olyan indexelt oldalt is, ahol a query string galibát okozott, hiszen a domain.hu/mappa/pelda.php?id=5 URL-ből a rewrite domain.hu/mappa/?id=5 URL-t kreált.

Szerencsére ezt a gondot azért sokkal gyorsabban orvosolni tudtam.


RewriteCond %{query_string} .
RewriteRule (.*) http://www.domain.hu/mappa/$1? [R=301,L]

Így végül minden korábbi URL szép. 301-gyel adta vissza az új oldalt.

Remélem spóroltam ezzel a poszttal némi fejfájást.

Css és javascript optimalizálás YSlow módra

Pár hónappal ezelőtt kezdtem beleásni magam a weboldalak technikai jellegű optimalizálásába. Amelynek legfőbb indikátora az volt, hogy kevés dolgot utálok jobban a lassan töltődő oldalnál. A folyamat során egyik legfontosabb mérföldkő a YSlowval történő találkozás volt. Ez a firebugba beépülő extension nagyban megkönnyítette a továbbhaladást a felsorolt direktívák segítségével, azonban konkrét technikai megoldások hiányában kénytelen-kelletlen egy szuperhosszú, de annál tanulságosabb folyamat vette kezdetét…

YSlow ajánlások a css, valamint js fájlokra vetítve

Css js fájlok kifele!

Aki nem tegnap kezdett bele, bizonyára sejti, hogy ez a szakasz a külső fájlként futtatott js-ek valamint stíluslapok éltetésének lett dedikálva. A dolognak legnagyobb előnye az, hogy az inline scriptekkel és stílusokkal ellentétben a külső fájlokat a böngésző cacheli és így minden request azok méretével rövidül, mind a fájlok mérete, mint a response time figyelembevételével.
Nem olyan régen tanultam azt a szabályt, hogy a javascriptek bekérésének ideális helye pont a </body> felletti sor, ezzel gyorsítva a dokumentum minél előbbi megjelenítését.
<megjegyzés>Van olyan js, amely csak a <head> részbe pakolva működik</megjegyzés>

Minek annyi request?

Leginkább a Joomla scriptet használó oldalakon szoktam elszörnyülködni, hogy az oldal webmestere feltol 5-6 plugint, komponenst a felhasználói élmény érdekében, amelyek egyenként megkérnek minimum egy stílus lapot és gyakran jönnek a js csokrok is, amely komoly másodperces töltést igényelnek. Már szinte nem is weblap manapság, ahol legalább egy lightbox nem fut a képek dögösítésére. Magam részéről a lightbox.css tartalmát rendre belepakolom a normál css legvégére ezzel minimalizálva a requesteket. Hasonlóképpen gyakran összevonhatóak a javascriptek funkciói, de a logikai sorrendet minden esetben érdemes megtartani ha működőképes dolgokra vágyunk.

Expires header vs cache control

A YSlow ajánlása szerint a nem dinamikusan változó fájlok távoli jövőben lejáró headerjével a visszatérő látogatóknak kedvezhetünk.
A js és css valamint egy két további mime type lejáratának meghosszabbítására használjuk az alábbi .htaccess kódot:

<ifModule mod_headers.so>
<FilesMatch "\.(ico|flv|jpg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
</FilesMatch>
</ifModule>

Amennyiben a mod_header nem betöltött Apache modul a szerveren, akkor természetesen nem fog működni a dolog, de kicsit lejjebb majd ezt a dolgot is orvosoljuk.

Gzipre fel!

Az 1.3-as Apache szerveren a mod_gzip, a 2.X verziók esetében már a mod_deflate modulok teszik lehetővé az akár 60-70%-os tömörítési rátát, amelyet a mai modern böngészők minden gond nélkül kezelnek.

Mod_gzip .htaccess kódja

<IfModule mod_gzip.c>
mod_gzip_on Yes
AddEncoding gzip .gz
mod_gzip_item_include file \.css$
mod_gzip_item_include file \.js$
</IfModule>

Mod_deflate .htaccess kódja

<IfModule mod_deflate.c>
<FilesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

Természetesen megeshet az is, hogy habár Apache szerveren van a lapunk, mégse elérhető egyik modul sem. Ilyenkor sem szabad szomorkodni, hiszen van még egy esély, amely kicsivel több módosítást igényel, de szerintem 3 perc alatt elkészül vele mindenki.
Első lépésként a js illetve a css fájlokat nevezd át php fájlkiterjesztésűvé majd css esetén a fájl legelejére helyezd ezt a kódot

<?php
if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip'))
{ob_start("ob_gzhandler");
header("Content-type: text/css; charset: UTF-8");
header('Expires: Thu, 15 Apr 2010 20:00:00');}
else ob_start();
?>

javascript esetén ezt

<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start();
header("content-type: application/x-javascript");
header('Expires: Thu, 15 Apr 2010 20:00:00');
?>

Egyetlen dolog maradt ezután hátra, mégpedig a link illetve a script tagban a kérés módosítása az új fájlkiterjesztésnek megfelelően.

Minify

Nem másról van szó, mint a szerveren lévő fájlok méretének minimalizálásáról. Számos js illetve css online optimalizáló eszköz fellelhető az Interneten, de személy szerint én a YUI Compressor mellett teszem le a voksom, amely alkalmas mindkét fájltípus tömörítésére. Az eszköz használatát következő posztomban fogom bemutatni.

Sokat kérek?

Kedves cégadatbázis üzemeltetők!

Árulják már el nekem, hogy mi abban annyira jó, hogy egy cég hivatalos honlapját már nem lehet megtalálni a sok szeméttől?
Ha már mindenképpen roppant relevánsnak érzik az oldalukat a Magyarországon működő vállalkozások neveire legalább egy nyomorult linket tennének ki az oldalra, mert akkor talán lenne valami értelme is az őrült erőlködésnek.

Pillanatnyi csalódottságomat ezen a szuper hasznos oldalak váltották ki, de a lista sokkal hosszabb:

  • eucegadatbazis.hu
  • cegbongeszo.hu
  • weblaptudakozo.hu
  • cegmatrix.hu
  • eucegadatbazis.hu

Akkor legyen némi dícséret is. Köszönöm, hogy legalább a telefonszámot megjelenítik néhol. Majd felhívom a céget, hogy megkérdezzem a honlapuk címét.

Aging delay, avagy hova ez a nagy sietség

Már régóta érlelődik bennem ez a poszt és remélem eléggé vonzónak találjátok majd a téma megvitatására.

Miről szól az aging delay?

Nem másról, mint az új oldalakat sújtó szörnyű Google filterről.

Megnyilvánulási formája?

Az újonnan regisztrált domainek előrejutásának akadályozása a találati listán a népszerű szavakra értelmezve.

Logika mögötte?

A régóta létező tartalom megbízható.

Hossza?

Gyakorlatban közel 9-12 hónap.

Hogyan enyhíthetem?

  • Amennyiben Google Webmaster Tools felhasználó vagy, az előéleted a Google kartotékrendszerben pedig patyolattiszta az oldalad tulajdonviszonyát minél előbb igazold.
  • A linkmarketing során fókuszálj a long tail szavakra, mivel alacsonyabb találat alacsonyabb fokú hátráltatást jelent. Természetesnek tűnő linkeket építs. Deep linkek valamint URL használata a link szövegeként nagyon természetesnek hat. Amennyiben a természetes linképítést nem nagyon veszi be a gyomrod, próbáld meg minél több szöveggel pozicionálni a tartalmad a linkek segítségével.
  • Ha indulni akarsz egy online projekttel, a start előtt minél előbb tudasd a Google-lel annak létezését.

Az aldomain valóban megoldást jelent

Tapasztalatom szerint a hátráltatás enyhébb, de elkerülhetetlen.

Hol olvashatok többet a témáról?

Miért számítok a kommentedre?

A személyes tapasztalatok megosztása mindenképpen fontos, hiszen a Google nagyon hasonlít a nőkre. Minden férfi másként ismeri őket.

Captcha Ashtor féle köntösben

Azt gonodolom, a webfejlesztéssel foglalkozó hölgyeknek és uraknak mindig a látogató érdekét kell a középpontba állítani. Ezen felbuzdulva írtam -már nem is tudom mikor- a fájdalommentes captcha vezérfonalát fejtegető erőlködésemet. Jöttek is szép számmal a hozzászólások, de a legkomolyabb javaslat fölött valamiért átsiklottam.

Ha nincsen kedved kattingatni, hát úgy is jó. Íme az idézet.

Ha egy kicsit belegondoltok, egyáltalán nincs is szükség a CAPTCHA-ra.

Miről szól a játék? Arről, hogy a botok ne tudjanak automatikusan bejegyzéseket küldeni. Ha ezt megoldod, akkor nem kell a júzereket kínlasztani.

Pedig erre a megoldás annyira egyszerű!

És a megoldás valóban nagyon egyszerű:

(FORM action=”suck_bot.php” id=”submitform”)
(INPUT ….
(/FORM)

(SCRIPT)
var cel1=”act”
var cel2=”ion”
var ext=”php”
id=”submit”+”form”
document.getElementById(id).action=cel1+cel2+”.”+ext
(/SCRIPT)

A megfelelő nyitó és záró tagokat kéretik normálisokkal helyettesíteni.

Erről a külső javascriptes botszivatásról volt szerencsém a későbbiekben egy NAGYON senior fejlesztővel beszélgetnem, és ő is elismerte, hogy ez aztán az ötlet.

Ashtornak mindeképpen járna innen egy afféle credit link, de a neten sajnos nem akadtam bele a weboldalába, pedig kétségkívül nagy tapsot érdemel, mert ezidáig ragyogóan működő védelmet adott a kezünkbe.

Feltaláltam a spanyol viaszt? No azt azért nem..

..de mindenesetre most nagyon nagy a vigyor a fejem. Történ ugyanis, hogy hetek óta egy portált bütykölgetek, hogy még annál is tökéletesebb legyen, mint amire én azt mondom, hogy ez durván jó.

Az oldal adatbázisból jeleníti példámban a content-ként identifikált div tartalmát. A tartalom mennyiségétől függően változik a div#content height értéke, és bizonyos lapokon mindezek értelmében a footer felugrott és meglehetősen gagyiként hatva rombolta az idegrendszeremet.

Chuck Norris rajongóhoz méltó elszántsággal vetettem bele magam a javascript vadászatba, amelynek eredménye az alábbi kód lett


var totalheight = document.body.offsetHeight;
var kell=window.innerHeight;
var mas=229;
var jo=kell-mas +'px';
if (totalheight<=kell){ document.getElementById('content').style.height=jo;}

Némi magyarázat a javascript kódolásban nem nyakig belemerült olvasóknak:
A scriptben két dolgot kell megadni, elsőként a div#content-től független elemek magasságát, amit a kódban a mas változó definiál. A másik dolog, ami testrseszabást igényel az a getElementById funkcóban szereplő div identifikáció. Miután ez bekerült a kódba, azokon a tartalmakon, ahol a horizontális scroll nem jelenik meg, a tartalmat 100%-ig nyújtja a div#content magassági értékének manipulálásával a látható tartományban.

További kellemes nyarat mindenkinek!

Frissítés
Tupacko észrevételének fényében a böngészőfüggetlen kód a következő:


var totalheight = document.body.offsetHeight;
var B=navigator.appVersion;
if(B=="Netscape"||B=="Opera"){
var kell=window.innerHeight;}
else{
var kell=document.documentElement.clientHeight;
}
var mas=229;
var jo=kell-mas +'px';
if (totalheight<=kell){ document.getElementById('content').style.height=jo;}

Tesztelve: IE6, IE7, IE8, Opera 9.51, Safari 3.1.2, illetve FF3
Bocs ha valami kimaradt, ezek elérhetőek a pc-ről.
Ismét kellemeset!