grrr, PR ne raste
10 naročnikov
10 naročnikov
Ok, sej vem da stvar ni tako enostavna kot izgleda, amapk če na stran linkam iz ene PR3 in ene PR4 strani, zakaj za hudiča to ni dovolj, da bi na linkani strani dobil vsaj PR1, ne pa da umiram brez PRa?
P.
43 odgovorov
pač edina stran, kjer se linki prodajajo (pač izmed mojih) ma PR0, ostale, ki so samo podporne za reklamo drugih strani, na katerih nisem nič posebej delal, pa mata 2 in 3...
popizdiš.... :D
Alex, metoda stara ze kar nekaj let, je pa dobro, da ljudje vedo, da ni vsak PR pravi... To smo opozarjali ze Bakterijo, pa ni verjel... Na (njegovo) sreco je bil tako ali tako prepozen :)
Je pa na sreco zadevo povsem enostavno preverit, pogledas googlov cache strani in ce ni pravi, je tudi PR fake :)
Vini, nevem če je to zanesljivo, saj po spremembi TBPR spremeniš na osnovno pa ma google pravi cache TBPR pa je še vedno isto visok.
frisby, ja, imas prav... problem se je pojavil zadnje case, ko Google tako neredno updata TBPR... na nekaterih forumih sem ze zasledil pobude za peticije, da naj Google ukine prikazovanje TBPR, ce ga misli tako neredno updatati, ker je ravno zaradi tega zadeva tako ranljiva in nagnjena k zlorabam...
Čeprav jaz te pobude za "peticijo" nisem zasledil, bi bilo bolj smiselno, da pač redirectane strani ne dobijo PR, sploh nevem kakšna je korist. Če imam jaz site1.com in ima nek PR, sedaj pa preselim na site2.com, bi bilo bolj smiselno da bi site2.com pridobil/izgubil ne pa site1.com.
Ker ima večjo verodostojnost, če nekdo, ki je zanesljiv (site1.com), redirecta na neko stran (in potem dobi PR od redirectane oz. se doda vrednost trenutnem PR strani) kot nekdo, ki ni, pa dobi od strani, na katero redirecta (npr. visok kr en PR). Ne vidim smisla.
frisby, to vsekakor... ampak ta ista/podobna zgodba se vlece se od 302 hijackov, pa se kar niso uredili teh zadev tako, da bi bilo kul...
ce pa malo razmislis, se pa dejansko google drzi http standardov... recimo:
301 Moved Permanently
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
kar dejansko tudi naredi... domena, ki redirecta na drugo domeno, je referenca na to drugo... zato cache pokaze tisto koncno... in zato je tudi PR domene enak ciljni domeni, ker je izvorna domena pac le referenca na drugo... povsem isto kot pri spremenljivkah in referencah...
302 Found
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
V primeru 302 hijackov je tudi Google pocel tocno to...
Je pa res hudo butasto vse skupaj...
Ja razumem, čeprav je res nesmiselno kot rezultat v tem primeru.
Se mi pa zdi, da g zaradi prodaje linkov vse bolj zanemarja TBPR in dvomim da bi ideja o pogostejšem updatanju prišla do realizacije.