sessions without hurting ranking

what do i need to do to avoid hurting my serach engine rankings

[Tartan75]

I am about to impliment a shopping cart. Its critical that this doesnt hurt search engine rankings for the site.

The shopping cart uses sessions - appart from that there is no other change to the site as a whole - just a handful of extra pages. My concern is that while i impliment sessions, there will be an accidental side effect that will hurt rankings for the whole site. I am aware of the problems with URL encoded sessions, hence am using cookies based sessions. However i beleive that there is a default setting 'use url encoded sessions if cookies not avaliable'. If i understand correctly I can overcome this problem by using the following imediately before session_start();

ini_set(session.use_only_cookies,1);

Is there anything else i should watch out for?

[daisho]

If you are writing the cart yourself you should only start a session when the "ADD ITEM" button is clicked or something like that.

Also to see if you should start a session you could manually check to see if "PHPSESSID" was passed as a cookie or GET/POST var. If so then they _MUST_ have clicked the "ADD ITEM" button and theirfor be a user and theirfore it's safe to do a session_start()

Now this hold true only if the "ADD ITEM" button or anything else that should trigger a session to initially start is hidden behind a <FORM> or a URL protected by "robots.txt" that way you know that GoogleBot (and others) will never crawl to those pages and theirfore never signal a session start.

This way you can still support customers without cookies.

[Tartan75]

daisho
Thanks for your advice - im sorry looking at my original post again, i should have made clear that i would like site wide sessions for one or two other things too.

I assume i am correct in thinking it is possible to get sessions running without hitting search engine ranking?

[daisho]

Yes it is. Their are just some pitfalls. Also you will hurt the Cachability of your page. This has nothing to do with search engines but rather proxy caches around the internet. These can releave stress on your server and make your pages appear a lot more peppy. There are ofcourse downfalls with them. One being that a heavily cached pages log file will not be the true reflection of visitors since many visitors may have viewed a cached page.

If you want sessions site wide then turning off URL rewriting (so only cookie sessions will work) will ensure that Googlebot and others will not get caught in a spider trap. You should realize thought that a session on every page can add a fair amount of overhead. Ofcourse the amount depends on many many factors.

[kkrumlia]

If there was a change in the other pages which is not the case here as it's pointed out wouldn't one be able to
start session
do a certain test
if test is true (that is another session has started via a form )
We do whatever
else { remove and delete the sessions }
Just a thought if it's of any help

[daisho]

I am not sure what will happen in that case. That's why I would

1. Check for session ID
2. If session ID exsits then session_start()
3. If not then don't or decide if your being crawled or whatever you need to do.

That I would find to be the safest way.

Your suggested method may also work find I have just never tested it.

daisho

[kkrumlia]

Your way is the better way to achieve that , but the way i proposed works fine too. I have a question we know that if cookies are disabled the sessid will be displayed in the URL and thus anybody who gets to that can get to an open account sort of. So is there a browser id or any kind of other id to store in database parallel to sessid so in case this usage happens it's caught and blocked ?

[daisho]

I'm not sure what you are asking. Why would you want to stop a user without cookies to register?

What do you want to store in the database. Can you give me some type of example of your train of thought.

daisho

[kkrumlia]

MY question was if the cookies in the browser are disabled so when a session starts the the url will reflect something like this
www.somesite.com/ppp/index.php?PHPSESSID=c2be4a22719fdf9c816799983357534f

Now if any other person obtains this sessid he gets to the same info the original person is viewing.

So is there a way to stop this buy saving something unique other than sessid. So if sessid gets compromised that id won't.

[edited by: jatar_k at 5:03 am (utc) on April 30, 2003]

[daisho]

You could store the remote host in the session at time of creation. That way if the client IP address changes then you know something is up.

You will also have to deal with proxy servers look into the header "X_FORWARDED_FOR" header to find the true client IP address in the user connects through a proxy server.

That's something that would be very hard to fake.

Again to make your site much more indexable and/or cacheable I'd still do something like:

<?
if( isset($_REQUEST['PHPSESSID']) ) {
session_start();
$session_is_active=TRUE;
} else {
$session_is_active=FALSE;
}
?>

That way you are extra safe and will not create a spider trap. Then on some explicite pages you can just do a "session_start()" but preferably somewhere where you've blocked spiders from going.

Then for the rest of your code you have a "$session_is_active" veriable so you know if you can use the session or not.

Another solutions could be going to get a good browscap.ini file and using the get_browser() call to see if the referer is a crawler or not. If it is then don't start a session. If not then do. That way you can have sessions everywhere for browsers but you will not create a session and theirfore not create a spider trap if it is a crawler.

daisho