It's taking the original workaround idea and moving it further along. I
think it's a good idea. But we need to find out the impact of a page's
outgoing links being reduced and pointing to the same "#" url. Will it
decrease the PageRank? There are pseudo calculations out there that tell
you approximately how your PageRank will be affected by the number of
incoming and outgoing links.Gili Igor Vaynberg wrote: > i had an idea last night that might make this less painful. > > what if we have a "spider" toggle on request cycle? we toggle it on if > we know its the spider performing the request. with the spider mode on > urlFor calls for non-bookmarkable pages will return "#" and bookmarkable > urls will not be rewritten. this will basically only make bookmarkable > urls visible to the spider and since it doesnt need a session to crawl > bookmarkable urls its ok if jsessionid is not appended. > > feedback? > > -Igor > > > On 4/12/06, *Johan Compagner* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > defering the creation of the session and the whole google crawler thing > are 2 seperate issues for me. > > Because a bookmarkable url could be a non stateless page anyway > because of a form or link on it. > And then you do have the session. And urls with jsessionid will be > generated after that for every > page, bookmarkable mountable or whatever, that is hit after that. > > > johan > > > > On 4/12/06, *Michael Day* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > On Apr 11, 2006, at 6:40 PM, Nathan Hamblen wrote: > > > It looks like Wicket is doing all the right things. I don't > think it > > should try too hard to avoid generating a session for bookmarkable > > links > > cause the googlebot could always find those same links after it > has > > created a session elsewhere, muddying things just as much. > > Not really - the correct action would be to use a robots.txt to > prevent the spider from going to pages which require a session > in the > first place. > > > Instead, search conscious sites (and what big site isn't?) > should just > > disable url rewriting in a WebRequest subclass. Users without > cookies, > > and Google, will still be able to browse the non-interactive > parts of > > the site through bookmarkable urls. You'd have to hack essential > > (search) forms, but that's no harder than doing the same form in a > > caveman framework. Then you'd customize the session expired > page to > > explain that cookies are required for interactivity. > > Okay, but I don't think you should require cookies just because you > want to be search-engine friendly. URL rewriting is a great and > useful feature. I don't see why we should give it up if we don't > have to. > > The question is really whether it is *possible* for wicket to defer > creating a session. If it is possible, then let's defer it. If > not, > then we have no choice but to use workarounds like this. But let's > be realistic - these *are* workarounds. > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking > scripting language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642> > _______________________________________________ > Wicket-user mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/wicket-user > > >
signature.asc
Description: OpenPGP digital signature
