DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)
-   PHP (http://www.devprotalk.com/forumdisplay.php?f=9)
-   -   Optimalni URL zarad SEO (PHP implementacija) (http://www.devprotalk.com/showthread.php?t=3005)

Pedja 04. 06. 2007. 18:16

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?

MorenoArdohain 04. 06. 2007. 18:28

Citat:

Originalno napisao Pedja (Napišite 36297)
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

Citat:

Originalno napisao ivanhoe (Napišite 36318)
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:
Kôd:

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)


Vreme je GMT +2. Trenutno vreme je 01:29.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.