Search Engine Friendly Without Using Cookies

[lokksta]

Hi,

 

I've been looking through some guides and contribs and it seems that for best results with search engines, cookies need to be used to store sessions rather than mysql.

 

So is there a way to still make you site SEF without using cookies?

 

Thanks.

[boxtel]

Hi,

 

I've been looking through some guides and contribs and it seems that for best results with search engines, cookies need to be used to store sessions rather than mysql.

 

So is there a way to still make you site SEF without using cookies?

 

Thanks.

<{POST_SNAPBACK}>

 

osc always uses cookies. the session id is stored in that cookie, nothing else.

 

however, if the client does not accept cookies, there is no alternative but to add the session id to the url in order to retain it.

 

if you set force cookie enabled, then this will not be done but it also means that the customers who do not accept cookies cannot shop, cannot retain their language settings, currency settings, and all the other session-dependant stuff.

 

spiders do not get session id's at all if you enable prevent spider sessions and keep your spiders.txt file up to date. with force cookie use, spiders will hit your cookie usage page a lot as they do not accept cookies by default.

[lokksta]

Thanks for your reply Amanda. So what would you suggest the best thing would be?

 

Cheers.

[boxtel]

Thanks for your reply Amanda. So what would you suggest the best thing would be?

 

Cheers.

<{POST_SNAPBACK}>

 

never force cookies

always prevent spider sessions

 

maybe implement :

 

http://www.oscommerce.com/community/contri...ch,seo+friendly

[mjm]

Chemo writes quality code, I have been using cName/pName since he released it. Urban Clothing FoS

[lokksta]

Thanks both, I will certainly give that contrib a try :thumbsup:

[FalseDawn]

never force cookies

always prevent spider sessions

 

IMO this is very bad advice, and I'd recommend forcing cookie use for the following reasons:

 

The "prevent spider sessions" is not foolproof for a start - any spider that is not matched by your spiders.txt file will merrily create sessions, resulting in links containing the session ID.

 

OK - some of these spiders may well be obscure, but what happens if 2 people happen to find one of these links, and both click on it to get to your site?

If the session is still active on your server, then what happens if one of them decides to purchase - possibility of financial info not being secure. Very bad.

 

The first time you click on a link, the session ID appears in the URL.

What about if Joe sends his friend Bill this URL, or posts it on a public board?

 

What about if he then goes and enters sensitive information and someone clicks on this link whilst he is doing it? Again, he might think he is secure, but he won't be!

 

Passing sessions via the URL is an inherently insecure method of operating.

 

If you _don't_ force cookie use, then someone with cookies disabled will see the session IDs in the URL. This is a potential security risk for your customer, and as far as I can see, you are doing them a huge favour by not allowing this to happen by forcing cookies.

 

At the end of the day, your options are basically security vs convenience

 

1) Force cookies, and sleep well knowing that your users are pretty well protected from other people being able to view their data, with the caveat that you might turn away the few who disable cookies.

 

2) Don't force cookies, knowing that even those who disable cookies can shop at your store (albeit with their session ID in the URL).

Don't sleep well, wondering what those strange urls are that are appearing in search engines you didn't allow for, or when you're going to get a call from someone saying their shopping cart (or worse, their financial information) has been merged with someone else's

[FalseDawn]

spiders do not get session id's at all if you enable prevent spider sessions and keep your spiders.txt file up to date. with force cookie use, spiders will hit your cookie usage page a lot as they do not accept cookies by default.

 

This is also blatantly incorrect.

 

The only time a regular user will see this page is when they try to add something to the cart, login or checkout.

 

These are actions you should be preventing spiders from doing anyway, using your robots.txt file.

[lokksta]

Thanks for the reply FalseDawn, I will bear that info in mind.

 

I hadn't really thought about two people using the same session id via a search engine (if the search engine created a session), resulting in insecurity.

 

So thanks for pointing that out :thumbsup:

[Guest]

never force cookies

always prevent spider sessions

<{POST_SNAPBACK}>

Amanda is correct...

 

1) NEVER force cookies

2) Always prevent spider sessions

 

The myth that you need a spider or SID killer goes back to the old MS1 days when it was indeed an issue. However, MS2 has good code that if used properly will work without fail. If it does not work correctly then you need to update the spiders.txt file or take other measures.

 

A side note about the stock code for preventing spider sessions: it appears as though the new MSN bot is a bit sneaky. There have been a lot of stores that are setup correctly but still getting the osCsid's indexed. This should be eliminated as soon as the spiders.txt file is updated.

 

As was said above, the best combination is to prevent spider sessions along with a proper robots.txt file. If you don't have a robots.txt file in your document root use something like the following code:

User-agent: *
Disallow: /admin/
Disallow: /account.php
Disallow: /advanced_search.php
Disallow: /checkout_shipping.php
Disallow: /create_account.php
Disallow: /cookie_usage.php
Disallow: /login.php
Disallow: /password_forgotten.php
Disallow: /popup_image.php
Disallow: /shopping_cart.php

This should be used in combination with the prevent spider session setting and an updated spiders.txt file.

 

Bobby

[FalseDawn]

Chemo,

I respectfully disagree with your comments about cookies.

 

I have given my arguments for forcing cookies.

What are your arguments against forcing them? The argument that it will alienate the few users who disable cookies doesn't cut it.

[Guest]

Chemo,

I respectfully disagree with your comments about cookies.

 

I have given my arguments for forcing cookies.

What are your arguments against forcing them? The argument that it will alienate the few users who disable cookies doesn't cut it.

<{POST_SNAPBACK}>

I base my opinion on the fact that over 90% of my site visitors are using Internet Explorer. Your mileage may vary but check your server logs and it should give you a rough breakdown of browser statistics.

 

Why does it matter? Because the default installation for Internet Explorer disables cookies. In order for a customer to enable cookies they must manually change the settings or add the site to the list of trusted domains.

 

Now, let's do some estimating. Let's say that 90% of the customers that come to a store have wallets open and ready to buy something. Further let's assume the average customer has the ability to connect to the internet but knows nothing or very little about accepting cookies and how to change the setting. Of those 90% of Internet Explorer using customers more than half will either not know how to change the settings or will simply move on to the next site out of inconvenience.

 

Your views may differ from my own and that is perfectly acceptable. However, I would rather give my site every opportunity to convert a browsing customer into a paying customer and will not purposely implement a system that detracts from that concept.

 

Sure...there will be some that want to purchase your wares regardless of inconvenience but with the competitive nature of the internet why chance it when your nearest competitor is only a click away?

 

Your argument for passing session ID's doesn't hold water. There is a setting directly below the "Prevent Spider Sessions" that is "Recreate Session". This option is DESIGNED TO HANDLE SHARING OF SESSION ID'S. If a osCid is passed by mistake or lack of knowledge than when a second person enters through that same SID it will destroy the session and assign a new one. Hence, your entire argument is based on a drawback for ANY session based system but is one that the osCommerce application can handle with ease.

 

So, my question to you is why chance losing 50% of the potential paying customers when the MINOR threat of passing session ID's can so easily be handled with a flip of the switch?

 

Bobby

 

Bobby

[boxtel]

I base my opinion on the fact that over 90% of my site visitors are using Internet Explorer.  Your mileage may vary but check your server logs and it should give you a rough breakdown of browser statistics.

 

Why does it matter?  Because the default installation for Internet Explorer disables cookies.  In order for a customer to enable cookies they must manually change the settings or add the site to the list of trusted domains.

 

Now, let's do some estimating.  Let's say that 90% of the customers that come to a store have wallets open and ready to buy something.  Further let's assume the average customer has the ability to connect to the internet but knows nothing or very little about accepting cookies and how to change the setting.  Of those 90% of Internet Explorer using customers more than half will either not know how to change the settings or will simply move on to the next site out of inconvenience.

 

Your views may differ from my own and that is perfectly acceptable.  However, I would rather give my site every opportunity to convert a browsing customer into a paying customer and will not purposely implement a system that detracts from that concept.

 

Sure...there will be some that want to purchase your wares regardless of inconvenience but with the competitive nature of the internet why chance it when your nearest competitor is only a click away?

 

Your argument for passing session ID's doesn't hold water.  There is a setting directly below the "Prevent Spider Sessions" that is "Recreate Session".  This option is DESIGNED TO HANDLE SHARING OF SESSION ID'S.  If a osCid is passed by mistake or lack of knowledge than when a second person enters through that same SID it will destroy the session and assign a new one.  Hence, your entire argument is based on a drawback for ANY session based system but is one that the osCommerce application can handle with ease.

 

So, my question to you is why chance losing 50% of the potential paying customers when the MINOR threat of passing session ID's can so easily be handled with a flip of the switch?

 

Bobby

 

Bobby

<{POST_SNAPBACK}>

 

 

For me, having a multi lingual site, the inconvenience is also that if I force cookies , customers who do not accept them will have to re-set their preferred language and currency and (in my case) font size and screen size every time they load a page unless they stick with the default settings. This because these session specific settings are stored in session variables which do not exist under those conditions.

 

So it it not just that they cannot buy, they cannot reasonably browse my site without sessions.

[FalseDawn]

Chemo,

Thanks for the reply.

I will investigate the option you mention of forcing a session to be recreated and exactly how this is implemented.

Is it based on IP address? If so, this is also fallible, as people behind proxies will appear to have the save IP, and it would cause havoc for AOL users.

 

Further let's assume the average customer has the ability to connect to the internet but knows nothing or very little about accepting cookies and how to change the setting

 

Probably true, but with clear enough instructions on how to change settings, I can't see this being an issue.

 

Because the default installation for Internet Explorer disables cookies

So? There are _so_ many sites requiring cookies for full functionality that I'd wager the first thing a lot of people do is to reset the setting to "medium" or "medium high" as soon as they hit one. For a start, Yahoo mail and Hotmail will not work without cookies. Try disabling them, then trying to sign in.

How many people have yahoo or Hotmail accounts??

 

 

 

So, my question to you is why chance losing 50% of the potential paying customers when the MINOR threat of passing session ID's can so easily be handled with a flip of the switch?

 

50%? I doubt it very much.

Any potential security threat should not be considered minor, and as far as I can see, there's no "flip of a switch" that is foolproof here.

 

 

 

Anyway, I'm not being argumentitive, I guess we'll just have to agree to disagree on this issue. :-)

[Guest]

It's your store...make your own decision. After all it's YOU that will have to live with the fallout and not me.

 

Bobby

[FalseDawn]

I have already made my decision - this isn't about me, it's about trying to put forward both sides of an argument so other store owners can make an informed decision, too...

[Guest]

The fact is that forcing cookies is inconvenient to the customer to varying degrees. If that customer has no experience configuring their browser it will be a sale killer. However, if they are web savvy then it will matter less.

 

The decision has to be made by the store owner taking into account their customer base. If they are in a technical field (such as software or computers) then their customers will most likely feel comfortable adjusting their browser settings to accomodate a purchase. However, if their base is somewhat more technically challenged then that potential sale will go to the competitor's website which is more easy to use in their eyes.

 

Either way I don't agree that forcing cookies is acceptable. Your opinion differs. The store owner's mileage may vary.

 

Bobby

[lokksta]

Thanks FalseDawn and Chemo for your input.

 

Chemo, do you see having the session id in the url as a prob with search engines, or would you suggest using a decent spiders.txt file?

 

I would rather not force cookies on my customers, just through personal choice, but I am worried if a search engine starts it's own session and uses the url with it's session in it.

 

Thanks.

[Guest]

Thanks FalseDawn and Chemo for your input.

 

Chemo, do you see having the session id in the url as a prob with search engines, or would you suggest using a decent spiders.txt file?

 

I would rather not force cookies on my customers, just through personal choice, but I am worried if a search engine starts it's own session and uses the url with it's session in it.

 

Thanks.

<{POST_SNAPBACK}>

Any time a session ID is passed around it has serious implications. When that session ID is being passed by a search engine the implications have a much greater impact.

 

The stock osC that suppresses session ID's for spiders is mature and functions well. However, it is NOT foolproof as it relies on the spiders.txt file to identify them. You can minimize the possibility of a spider picking up a session ID by keeping that file updated.

 

It should be noted that the "major" spiders have an entry in the updated spiders.txt file. A big THANK YOU is in order for the members that are maintaining that contribution.

 

What exactly is the definition of a "major" search engine spider? That depends on your store and will vary among the community. For myself the majors are ones like Google, yahoo, MSN, Yahoo, AOL, Ask, etc. There are too many spiders in the world to document all of them but an updated spiders.txt file will catch 99.9% of them and suppress the session ID.

 

So what happens if a session ID is accidentally indexed (maybe got it before updating the spiders.txt file)? Easy...enable the "Recreate Sessions" option in the admin control panel:

 

Admin Control Panel -> Configuration -> Sessions -> Recreate Session -> TRUE

 

Bobby

[lokksta]

Thanks Bobby, that certainly cleared things up for me :thumbsup:

 

I do have a couple of questions though:

 

1) Would you suggest to set "Recreate Session" to true anyway, just incase?

 

and

 

2) What is the best way/place to update the spiders.txt file?

 

Thanks for your time :D

[Guest]

I always leave the Recreate Sessions setting true no matter if it is a new store or existing. It's peace of mind...

 

To update the spiders.txt file download the contribution and upload it to your server. You will OVERWRITE the old one (which is several years old and is out of date). It's that easy!

 

Bobby

[lokksta]

I always leave the Recreate Sessions setting true no matter if it is a new store or existing.  It's peace of mind...

 

To update the spiders.txt file download the contribution and upload it to your server.  You will OVERWRITE the old one (which is several years old and is out of date).  It's that easy!

 

Bobby

<{POST_SNAPBACK}>

 

OK I'll give that a go, thanks again :thumbsup:

[Guest]

No problem...now you have to answer the same question when someone asks on at least 3 occassions in return. :)

 

Bobby

[lokksta]

No problem...now you have to answer the same question when someone asks on at least 3 occassions in return. :)

 

Bobby

<{POST_SNAPBACK}>

 

OK, sounds fine to me, or I could just send them the url of this thread ;)

 

I've also just noticed that im browsing my store as a guest and there's no session id in the url, then if I login I get the session id in the url. This all seems normal, but when I logout I still get the session id in the url. Is this normal or have I messed something up?

 

Sorry if that is a dumb question :)

[Guest]

Your store is functioning correctly. A customer should ALWAYS get a session ID in the URL when moving from NONSSL -> SSL or vice versa.

 

Bobby