Optimalni URL zarad SEO (PHP implementacija)
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? |
Citat:
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. |
Samo ću opisati svoje stavove o URL-ovima. Poštujem par pravila:
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). |
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. |
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 |
koliko mislite da se gubi i da li se uopste gubi ako je url
http://www.domen.com/?page=diplomas-and-degrees |
Citat:
Jedino ako Google bas preporucuje da se jezici odvoje poddomenom? |
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. |
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 |
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: Kôd:
RewriteRule ^([a-z]+)/([^/]+)/([a-z]+)/([^/]+) /?$1=$2&$3=$4 [L] |
Citat:
Citat:
Citat:
[quote] - 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. Citat:
|
@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 |
Citat:
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 |
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 |
jos jedno pitanje
kako resavate nasa slova u "lepim" url-ovima da li pustate unicode kodove ili zamenjujete ch sa c itd. |
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 |
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. |
a ovo 5 je ID artikla? pretpostavljam..
p.s. jel smem da "ukradem" tvoje resenje :P |
Citat:
http://www.example.com/Sports/Footba...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 |
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 ? |
Mislim da jeste, jer onda imas kljucne reci na odgovarajucem jeziku u samoj adresi dokumenta.
|
Zasto onda maltene niko to ne radi :), ili ja znam malo CMS-ova sa maximalnom mutlijezickom podrskom.
|
Citat:
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...Golf_for_sale/ parametri su lokacija (subdomen), proizvodjac, model |
Citat:
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. |
Citat:
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. |
Vreme je GMT +2. Trenutno vreme je 13:17. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.