PDA

Pogčedajte punu verziju : Optimalni URL zarad SEO (PHP implementacija)


Pedja
04. 06. 2007., 18:16
Razmisljam kako da unapredim jedan svoj mali skript sa optimalnim URL za SEO pa rekoh ne bi bilo lose da se konsultujem sa ljudima koji su se time vec bavili. Temu sam pokrenuo ovde zato sto me interesuje prvenstveno PHP zavisno resenje. Ako moderatori misle da je ipak bolje da se tema nadje u SEO forumu, slobodno prebacite.

Prvi deo problema je odluka kako uopste treba da izgleda optimizovani URL da bi bio najoptimalniji. Za pristup svakom dokumentu uvek imamo dve vrste parametara: fiksni i opcioni.

Fiksni su oni parametri koji su neophodni da bi opcija radila, recimo sam identifikator opcije. Njih nije tesko resiti tako sto se prosto ti parameri navedu u URL-u, na primer: http://nekidomen.com/news/ gde je news parametar koji odredjuje koja opcija se izvrsava i prikazuje. fiksnih parametara moze da bude i vise kao naprimer http://nekidomen.com/album/category1/ gde je album oznaka opcije foto albuma na category1 je oznaka kategorije u okviru albuma koju treba priakzati. S obzirom da su oba parametra neophodna da bi se mogao prikazati dokument, moze se usvojiti pravilo fiksne pozicije svakog od parametara.

Opcioni parametrisu oni koji mogu, ali ne moraju postojati u URL-u. Dobar primer bi recimo bio parametar kojim se odredjuje jezik na kome treba da se prikaze sadrzaj. Ako parametar postoji, dokument se prikazuje u navedenom jeziku, a ako ne postoji, uzima se podrazumevani jezik. Slicno je i sa parametrom koji bi definisao vrstu dokumenta koji se prikazuje, koji moze da odredi da li se prikazuje HTML, print varijanta ili recimo WAP. Samim tim sto opcioni parametar moze, ali ne mora biti naveden, ne moze se usvojiti pravilo o njegovoj fiksnoj poziciji u URL-u.

E sad kako resiti te opcione parametre?

Prenego sto perdjem na taj deo price, jedna napomena. Na pocetku sam naglasio da sam s opredelio na resenje koje ce raditi na PHP-u. Razlog je sto zelim da PHP radi mehanizam parisranja URL-a a ne url_rewrite.

Kao url_rewritepravilo bih koristio

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Ovo je pojednostavljena varijanta dovoljna za ovaj primer. Ukratko ovo pravilo ce svaki URL prevesti u sledeci oblik:

index.php?q=navedena_putanja

Ili na primeru:

http://nekidomen.com/news/
ce postati
http://nekidomen.com/index.php?q=news

a
http://nekidomen.com/
ce postati
http://nekidomen.com/index.php?q=album/category1/

Na ovaj nacin ce PHP u $?GET['q\] dobiti sadrzaj bitnog dela URL-a i moci ce sam da ga parsira.

Razlog zbog koga sam se odlucio na ovaj pristup je taj sto je time iskljucena potreba za naknadnim podesavanjima u .htaccess ako se pojave neki specijalni slucajevi u obliku URL-a a i dobija se nesto vise slobode u oblikovanju URL-a.

Recimo, zaodredjenu vrstu dokumenata broj parametara moze biti fiksan, ali za razlicite vrste dokumenata moze biti razlicit. Petljati se sa tim u .htaccess znacilo bi da se mod_rewrite podesava prema specificnoj strukturi nekog sajta, a to ne smatram dobrim pristupom, koji dodatno komplikuje i prica o opcionim parametrima nakoju cu se sada vratiti.

Ako opcione paramere u URL-u ostavimo kao query, na primer...

http://nekidomen.com/album/category1/?lang=en&doc=print

... onda ce oni biti prosledjeni skriptu kao i svaki drugi get parametri. Problem je sto je pitanje kako bi se to odrazilo na SEO.

Druga mogucnost bi bila da se parameri takodje prosledjuju kao prividne putanje u URL-u, kao recimo...

http://nekidomen.com/album/category1/lang=en/doc=print

... jer bi sada PHP mogao da ih prepozna kao paramere lang i doc i procita njihove zadate vrednosti.

Ili mozda postoji neki treci, bolji, nacin?


Ovde imam jos jednu nedoumicu, vezanu za parametar kojim se odredjuje jezik prikaza. On je po priordi opcioni, ali se uvodjenjem jednog pravila koje se odnosi samo na njega, moze tretirati i kao fiksni. PRavilo bi glasilo da ako je navdena oznaka jezika ona je uvek navedena kao prvi folder iza root adrese sajta. Na primer:

1. http://nekidomen.com/en/album/category1/
2. http://nekidomen.com/sr/album/category1/
3. http://nekidomen.com/album/category1/

Ovo je moguce izvesti ako se preptostvi da ce postojatiunapred definisana lista mogucih oznaka jezika, te ce skript moci lako da prepozna da li je jezik naveden (primeri 1 i 2) ili nije (primer 3).

Koliko se ovakav pristup u definiciji URL-a odrazava na SEO? Umetanje oznake jezika ispred oznaka opcija, prakticno dodaje jedan nivo vise u putanji do dokumenta.

I na kraju ostaje jos jedno pitanje: kako resiti problem opcionih parametara u smislu da, ako je parametar izostavljen (ili je redosled parametara izmenjen) dobija se isti sadrzaj dokumenta iako je URL drugaciji?

MorenoArdohain
04. 06. 2007., 18:28
I na kraju ostaje jos jedno pitanje: kako resiti problem opcionih parametara u smislu da, ako je parametar izostavljen (ili je redosled parametara izmenjen) dobija se isti sadrzaj dokumenta iako je URL drugaciji?

Razbij parametre iz URL-a u array:
za http://nekidomen.com/sr/album/category1/
to su: sr, album i category1, pa ih uporedi sa listom definisanih jezika.

Edit: sorry, mislio sam da pitas za jezik, ali generalno, princip bi bio isti ako znas kakvi ce biti parametri u URL-u.

Ilija Studen
04. 06. 2007., 18:37
Samo ću opisati svoje stavove o URL-ovima. Poštujem par pravila:


URL je lokator. On označava LOKACIJU resursa (stranica, diskusija, attachment ili bilo koji resurs pružen od strane aplikacije)
Parametri koji menjaju oblik u kom je resurs uslužen idu u query string


Na primer, u activeCollab 1.0 adresa određene diskusije u sistemu je:

http://example.com/projects/1/discussions/12

Pošto su postovi na diskusiju prelomljeni na stranice ima i paginacija. Podatak na kojoj si stranici ne menja lokaciju resursa, samo bolje definiše šta treba da bude prikazano:

http://example.com/projects/1/discussions/12?page=12

Što se jezika tiče, ako je jezik switch koji menja samo jezik u interfejsu guraj ga u query string. Ako pak menja ceo resurs (kompletna je stranica na drugom jeziku) onda je deo lokacije.

Kako ovo utiče na SEO stvarno ne znam (da budem iskren, ni ne zanima me previše).

Pedja
04. 06. 2007., 18:39
MorenoArdohain, ne bih bas svaki parametar poredio sa listom jezika. Prvo, to je neprakticno, a drugo, lako moze da se desi da neki drugi parametar moze da ima vrednost koja je slicna oznakama jezika.

U svakom slucaju, znam da realizujem bilo koji od ovih nacina, vec me interesuje sta je optimalnije iz ugla optimizacije za pretrazivace.



Ilija, moje i tvoje razmisljanje je u sustini identicno, samo sam ja drugacije nazvao stvari. Ono sto ja nazivam staticnim parametrima, u tvojoj definiciji odredjuje lokaciju, a ono sto ja nazivam opcionim parametrima, kod tebe su parameri koji menjaju oblik dokumenta. Ja sam ove definicije usvojio kao opstije.

No, ti si naveo jos jednu formu URL-a ( http://example.com/projects/1/discussions/12?page=12 ) koju takodje treba uzeti u obzir.

Ja je nisam navodio zato sto se u njoj gubi osnova zbog koje se radi SEO - uvodjenje kljucnih reci u URL. U ovoj notaciji koju si naveo samo si zamenio query navodjejem parametara u putanji, ali u URL ne figurira stvarni naziv recimo projekta ili diskusije, sto bi za SEO bilo znacajno, jer bi se tako u URL ugradile kljucne reci. Ovaj nacin navodjenja parametara se bavi samo problemom ogranicenog broja query parametara koje pretrazivac uzima u obzir ali ne i problemom korsicenja kljucnih reci.

Da se razumeom nisam ni ja SEO frik, ali gledam da ispostujem neka osnovna pravila i moje iskustvo govori da to itekako daje rezultate. Ubacivanje kljucnih reci u URL dokumenta je jedno od vaznijih, ako ne i najvaznije pravilo za uspesan SEO.

ivanhoe
04. 06. 2007., 20:19
sto se SEO tice, evo par predloga koji su mi prvi pali na pamet, a pouzdano znam da rade:

- razdvoj jezike po subdomenima: umesto nesto.com/sr, koristi sr.nesto.com, Osnovi jezik mozes da furas na glavnom domenu jednostavnosti radi, ili da dodas redirect (vidi sledecu tacku)

- izbegni potencijalni duplicirani sadrzaj koji moze da nastane ako imas podrazumevane parametre (odnosno opcione kako ih ti zoves). Ako postoji opcioni parametar, to prakticno znaci da ces imati 2 url-a do iste strane, i zato obavezno uradi 301 redirect jednog urla na drugi. Lakse je da url bez podrazumevane vrednosti redirektujes, jer onda mozes da parsiras urlove na uniforman nacin, znas da ce svi imati taj parametar

- Ako postoji opcioni parametar koji npr. menja nacin sortiranja nekih podataka, ali u sustini se prikazuju isti podaci, onda obavezno zabrani googlu da indexira te ostale strane (a to opet znaci da mozes da saljes GET parametar za tu opciju, jer te bas briga za pretty urls na toj strani)

- gledaj da url bude sto manje dubine, uz upotrebu odgovarajucih kljucnih reci/ fraza

MrSteel
04. 06. 2007., 21:47
koliko mislite da se gubi i da li se uopste gubi ako je url

http://www.domen.com/?page=diplomas-and-degrees

Peca
04. 06. 2007., 22:10
sto se SEO tice, evo par predloga koji su mi prvi pali na pamet, a pouzdano znam da rade:

- razdvoj jezike po subdomenima: umesto nesto.com/sr, koristi sr.nesto.com, Osnovi jezik mozes da furas na glavnom domenu jednostavnosti radi, ili da dodas redirect (vidi sledecu tacku)
Tako rasipa PR...
Jedino ako Google bas preporucuje da se jezici odvoje poddomenom?

bluesman
04. 06. 2007., 22:12
Nista ne dobijas na PR ako imas papazjaniju sa jezicima na sajtu.

Tacno je da se subodmenima "rasipa" PR, ali je vece zlo drzati vise jezika na istom domenu.

MrSteel
04. 06. 2007., 22:25
i jos jedno pitanje kako bi napisao rewrite za
recimo da zelim

http://www.domen.com/p/diplomas-and-degrees/lang/en

pa da mi on to pretvori u

http://www.domen.com/?p=diplomas-and-degress&lang=en

mozda je pitanje malo naivno ali nisam koristio rewrite do sada

ivanhoe
05. 06. 2007., 09:30
ovo sto blues kaze, jeste rasipanje PR, ali od mnogo ljudi sam cuo (mislim da je i Dinke to ovde pominjao) da im je uvodjenje dodatnog jezika na istom domenu oborilo PR. Ne znam dovoljno da mogu da argumentujem kako i zasto, ali je fakat da se to desava..

@MrSteel:

RewriteRule ^([a-z]+)/([^/]+)/([a-z]+)/([^/]+) /?$1=$2&$3=$4 [L]


u sustini se RewriteRule sastoji iz 2 dela: prvi je RegExp kojim parsiras url, drugi je ono sto zelis da dobijes (brojevi sa $ ispred su matchovane vrednosti, tj. ono sto se naslo unutar zagrada u regexpu).[L] je flag koji kaze mod_rewrite da si zavrsio sa obradom, da ne gleda sledeci RewriteRule (posto je moguce nanizati ih vise u red ako zelis)

Pedja
05. 06. 2007., 09:49
- razdvoj jezike po subdomenima: umesto nesto.com/sr, koristi sr.nesto.com, Osnovi jezik mozes da furas na glavnom domenu jednostavnosti radi, ili da dodas redirect (vidi sledecu tacku)


O tome sam razmisljao ali je ispalo iz kombinacije zato sto zahteva specificna podesavanja na hostu.


- izbegni potencijalni duplicirani sadrzaj koji moze da nastane ako imas podrazumevane parametre (odnosno opcione kako ih ti zoves). Ako postoji opcioni parametar, to prakticno znaci da ces imati 2 url-a do iste strane, i zato obavezno uradi 301 redirect jednog urla na drugi. Lakse je da url bez podrazumevane vrednosti redirektujes, jer onda mozes da parsiras urlove na uniforman nacin, znas da ce svi imati taj parametar


To se samo namece kao prva ideja, ali mi se nesto ne dopada da, kada se pristupi nekom dokumentu, on prvo uradi redirekciju. Ne zaboravi da hocu da svu kontrolu URL-a radi PHP, a ne web server, tako da bih u stvari terao citac da ponovo ucitava dokument. Sad to nije neki veliki overhed ali opet, ima ga :(


- Ako postoji opcioni parametar koji npr. menja nacin sortiranja nekih podataka, ali u sustini se prikazuju isti podaci, onda obavezno zabrani googlu da indexira te ostale strane


Zasto to zabraniti?


- gledaj da url bude sto manje dubine, uz upotrebu odgovarajucih kljucnih reci/ fraza
[quote]

To se podrazumeva, a mislim da se i postize ovim fiksiranjem parametara jer tako nema potrebe da se navodi i naziv i vrednsot parametra vec samo vrednost.

[quote=bluesman]
Tacno je da se subodmenima "rasipa" PR, ali je vece zlo drzati vise jezika na istom domenu.


No ovo nemam sta da kazem. Gogole sve vise opravdava moje misljenje da upravo on postaje sve znacajniji negativan cinilac na web-u. Kako god da organizujes sajt, Gogole ce imati razlog da to vidi kao zlu nameru.

MrSteel
05. 06. 2007., 09:59
@ivanhoe:
hvala puno,
regexp mi je razumljiv, zagrade su mi pojasnile stvar sa $
nisam se do sada udubljivao sad mi je sve jasnije
jos jednom hvala

Ilija Studen
05. 06. 2007., 10:38
Ilija, moje i tvoje razmisljanje je u sustini identicno, samo sam ja drugacije nazvao stvari. Ono sto ja nazivam staticnim parametrima, u tvojoj definiciji odredjuje lokaciju, a ono sto ja nazivam opcionim parametrima, kod tebe su parameri koji menjaju oblik dokumenta. Ja sam ove definicije usvojio kao opstije.

No, ti si naveo jos jednu formu URL-a ( http://example.com/projects/1/discussions/12?page=12 ) koju takodje treba uzeti u obzir.

Ja je nisam navodio zato sto se u njoj gubi osnova zbog koje se radi SEO - uvodjenje kljucnih reci u URL. U ovoj notaciji koju si naveo samo si zamenio query navodjejem parametara u putanji, ali u URL ne figurira stvarni naziv recimo projekta ili diskusije, sto bi za SEO bilo znacajno, jer bi se tako u URL ugradile kljucne reci. Ovaj nacin navodjenja parametara se bavi samo problemom ogranicenog broja query parametara koje pretrazivac uzima u obzir ali ne i problemom korsicenja kljucnih reci.

Naveo sam URL samo kao primer šta mislim pod "lokacijom resursa", a šta pod parametrom koji samo menja način prikaza resursa. Navedeni primer je iz aplikacije koja je uvek iza login screena (u novom activeCollabu su svi URL-ovi takvi).

Javni content orijentisan sajt bih napravio da radi kao:

http://example.com/news/some-news-title

Često stavim i ID u URL kako bi mi bilo lakše da izvlačim podatke (ne znam koliko je to loše s tim da sam 100% siguran da je prvi URL bolji od drugog zbog dodatnog nivoa):

http://example.com/news/some-news-title-12 ili http://example.com/news/12/some-news-title

boccio
05. 06. 2007., 12:19
Mi smo problem sa paginacijom i jezikom u URL-u za novi Vivvo resili na sledeci nacin:

http://www.example.com/Sports/Football/index.5.en.html

Nema preteranog rasipanja PR-a po pod-kategorijama (a o pod-domenima tek nema reci), a tu je sve. Krajnja ekstenzija se menja u zavisnosti od zeljenog formata outputa, tipa:
http://www.example.com/Sports/Football/index.5.en.pdf
http://www.example.com/Sports/Football/index.5.en.rss
http://www.example.com/Sports/Football/index.5.en.atom
http://www.example.com/Sports/Football/index.5.en.wap
http://www.example.com/Sports/Football/index.5.en.txt

Ista shema se koristi i za sav ostali output nevezan za kategorije/stranice, tipa:
http://www.example.com/author/Pera.en.html
http://www.example.com/tag/kupus.en.html
http://www.example.com/tag/sarma.7.sr.html

MrSteel
05. 06. 2007., 13:59
jos jedno pitanje

kako resavate nasa slova u "lepim" url-ovima
da li pustate unicode kodove ili zamenjujete ch sa c itd.

Aleksandar.Ilic
05. 06. 2007., 18:24
Da li moze objasnjenje zasto je ovo http://www.example.com/Sports/Football/index.5.en.html
bolje od ovog:
http://www.example.com/en/Sports/Football/5/index.html

boccio
05. 06. 2007., 19:42
Nista spec, samo jedan podfolder manje sto bi trebalo da bude lepse resenje sa stanovista rasipanja PR-a.

Osim toga nemas muku oko toga da zabranjujes da postoji kategorija "5" ili "324" da ne bi doslo do kolizije.

Aleksandar.Ilic
05. 06. 2007., 22:40
a ovo 5 je ID artikla? pretpostavljam..

p.s. jel smem da "ukradem" tvoje resenje :P

boccio
06. 06. 2007., 01:14
a ovo 5 je ID artikla? pretpostavljam..

ne, 5 je paginacija... ID articla je u ovom slucaju "index", a moze biti npr.
http://www.example.com/Sports/Football/liverpool-looses-game.5.en.html, sto vodi na petu stranicu articla (ili ako je kategorija, petu stranicu kategorije), na engleskom jeziku, u HTML output-u. DA ne bude zabune, princip je:
www.example.com/<kategorija>/<podkategorija>/<SEF-URL>.<stranica>.<jezik>.<format-outputa>

Mozes da uzmes, slobodno... u suprotnom ne bih ni objavio ovde zar ne :D

Aleksandar.Ilic
01. 09. 2007., 01:52
Jedno pitanje, da ne otvaram novu temu.
Da li je pametno da SEF ime za stranice prevodim u zavisnosti od jezika.
npr:
http://www.example.com/Knjige/Hari-Poter.5.sr.html
http://www.example.com/Books/Harry-Potter.5.en.html
?

Pedja
01. 09. 2007., 02:58
Mislim da jeste, jer onda imas kljucne reci na odgovarajucem jeziku u samoj adresi dokumenta.

Aleksandar.Ilic
01. 09. 2007., 19:50
Zasto onda maltene niko to ne radi :), ili ja znam malo CMS-ova sa maximalnom mutlijezickom podrskom.

pkrstic
06. 09. 2007., 05:56
Jedno pitanje, da ne otvaram novu temu.
Da li je pametno da SEF ime za stranice prevodim u zavisnosti od jezika.
npr:
http://www.example.com/Knjige/Hari-Poter.5.sr.html
http://www.example.com/Books/Harry-Potter.5.en.html
?
pa sa ovim ti onda ne treba jezik...

da se nadovezem na pricu, ako vec pravite linkove koji imaju strukturu podfoldera, zasto ne organizujete to kao jednu stranicu

http://www.example.com/knjige.hari-poter.5/

samo sto bi moralo da se obrati panja na karaktere koji se pojavljuju u linku, ovim bi se izbeglo raspinje PR.

Poslednji projekat koji sam radio je car-4-me.com, i tam je intezivno koristen parametar u subdomenu, posoto se radi o pretrazivacu, dobro se pokazalo na google jer kad neko trazi vozilo desava se da izbaci punu stranu samo sa tog sajta sa razlicitim poddomenima, gde je lokacija (mesto) u podomenu.

Evo primera linka http://chicago__il.car-4-me.com/used_volkswagen.Golf_for_sale/
parametri su lokacija (subdomen), proizvodjac, model

Pedja
06. 09. 2007., 10:01
Zasto onda maltene niko to ne radi :), ili ja znam malo CMS-ova sa maximalnom mutlijezickom podrskom.

Zato sto je komplkikovano da se izvede. Em moras da vodis racuna o kodiranju znakova, em moras daiscistis one znakove koji ne prialze u URL-u, em moras da obezbedjis jednoznacnost generisanih linkova, da resis problem moguce promene sadrzaj akoji korsitis za generisanje linka (naslova na primer)...

Medjutim, kada u sam URL uvedes ID dokumenta kao sto je to ovde predlozeno, onda stvari postaju jednostavnije. Naime tebi je iz URL-a potreban samo taj ID da znas o kom se dokumentu radi, ID je jedinstven, nepromenljiv a sve ostalo u URL-u ne sluzi nicemu osim bas kao kljucne reci. Onda mozes bez problema da koristis i razlicite jezike u url-u.

Ovih dana cemo pustiti online sajt koji radimo i u kome je sve to implementirano pa mozete da probate kako to radi u praksi.

jablan
06. 09. 2007., 11:06
Zasto onda maltene niko to ne radi :), ili ja znam malo CMS-ova sa maximalnom mutlijezickom podrskom.
Zato što je potražnja za ovom funkcionalnošću premala. To jest, uvek je pri dnu TODO lista.

Takođe, obično zahteva promene na strukturi baze pa se ljudi teško odlučuju da je uvedu jednom kad već imaju razrađeni jednojezički CMS.