tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anthonyvie...@gmail.com
Subject Re: JSESSIONID and impact on google
Date Tue, 09 Feb 2010 19:22:40 GMT
If you want to be seo friendly then change the application so that
session is not in the url.

Google sees each unique url as one page. With each visit to a jsession
site it will see the same content on multiple pages and the score will
go down for those seo terms.

Simple answer: Use cookies for sessions.

Keep urls clean and descriptive using - between words.

On 2/9/10, Pid <pid@pidster.com> wrote:
> On 09/02/2010 16:32, Marian Simpetru wrote:
>> jsessionid in URLs returned around 79 million search results.
>
> Yep. I know they're there.
>
>> google search on jsessionid SEO will give you lots of examples.
>>
>> On a question asked to google, they reply by explaining the algorithm
>> (multiple URL with same content -> lower ranking, JSESSIONID=zzz ->
>> multiple URLS)
>>
>> I can see there is a penalty in google webmaster tools. Can't say on
>> other websites...
>
> This I also know.
>
> But as I said, it would be surprising *to me* to find that Google
> weren't trying to filter this type of noise out of their URL indexes.
>
> Having thought about it a little more, I would like to add that we
> implement XML Sitemaps on our site and this may be having an effect on
> matters.
>
>   http://sitemaps.org/protocol.php
>
>
> When I look in my logs I can see sequential(ish) requests for URLs from
> all of the bots hitting our site and they do not have session id
> parameters appended.
>
> Of 68600 URLs appearing in the Google index of the site I have in mind,
> only 46 match a search for jsessionid and some of those appear because
> the HTML contains a URL to another site with the parameter present.
>
> The total number of URLs referenced in the XML sitemaps is somewhat
> below the total indexed on this domain and the difference is markedly
> larger than 46.
>
> I, perhaps hastily, have concluded that search engines are somehow
> storing pages without the session id parameter present in the URL.
>
>
> p
>
>
>> Marian
>>
>> On Tue, 2010-02-09 at 16:07 +0000, Pid wrote:
>>> On 09/02/2010 15:46, Christopher Schultz wrote:
>>> >  -----BEGIN PGP SIGNED MESSAGE-----
>>> >  Hash: SHA1
>>> >
>>> >  Marian,
>>> >
>>> >  On 2/9/2010 9:31 AM, Marian Simpetru wrote:
>>> >>  Google act as a non cookie browser and hence he is served with non
>>> >>  unique URLs (because of session ID is appended to URL).
>>> >
>>> >  I heard at one point that Google's crawler *did* support cookies. I
>>> >  never verified that, but it sounds like they currently do not support
>>> > them.
>>> >
>>> >>  Question is: Is there a way to configure tomcat to only use cookies
>>> >> (not
>>> >>  append jsessionid to URL for cookie0less browsers).
>>> >
>>> >  It's not a Tomcat configuration, but you can always write a filter
>>> > like
>>> >  this:
>>> >
>>> >  public class NoURLRewriteFilter
>>> >      implements Filter
>>> >  {
>>> >     public void doFilter(...) {
>>> >       chain.doFilter(request, new HttpServletResponseWrapper(response)
>>> > {
>>> >         public String encodeURL(String url) { return url };
>>> >         public String encodeUrl(String url) { return url };
>>> >         public String encodeRedirectURL(String url) { return url };
>>> >         public String encodeRedirectUrl(String url) { return url };
>>> >       });
>>> >     }
>>> >  }
>>> >
>>> >  Now, this will likely cause an explosion in the number of sessions
>>> >  generated by Google's crawler. You might want to couple this with a
>>> >  separate filter (or just create a GoogleCrawlerFilter that does all
>>> >  this) that identifies Google's (and others) user agent and intercepts
>>> >  calls to getSession() and either refuses to create a session (probably
>>> >  not a good idea) or returns a fake session that gets discarded after
>>> >  every request. Another option would be to set the session timeout to
>>> >  something like 10 seconds so the session dies relatively quickly
>>> > instead
>>> >  of sticking around for a long time, wasting memory.
>>> >
>>> >>  Maybe a better idea would be that someone from Apache Tomcat should
>>> >> push
>>> >>  to google with some standards tomcat implement in this respect so
>>> >> that
>>> >>  google change the algorithm and not punish with low ranking websites
>>> >>  powered by tomcat.
>>> >
>>> >  This is not a"Tomcat problem": it's a problem with any site that
>>> >  requires sessions to maintain state on the server.
>>> >
>>> >  I agree with Chuck: fix your webapp to tolerate Google's crawler, or
>>> >  suffer the consequences.
>>> >
>>> >  Something else you can do is use a robots.txt file to prevent the
>>> >  crawler from hitting certain URLs. That might help.
>>>
>>> I'm not doing anything special, I don't think.
>>> Google bots hit our site, the session count goes up a bit.
>>> Google does not include jsessionid in the URLs it indexes.
>>>
>>> It may be that the site has been around for long enough that the Google
>>> algorithms know that we have a session id should be removed from a URL.
>>>
>>> It would be surprising to me if Google (et al) was not trying to remove
>>> PHPSESSIONID and JSESSIONID data from URLs.
>>>
>>>
>>> p
>>>
>>>
>>> >  - -chris
>>> >  -----BEGIN PGP SIGNATURE-----
>>> >  Version: GnuPG v1.4.10 (MingW32)
>>> >  Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/
>>> >
>>> >  iEYEARECAAYFAktxg08ACgkQ9CaO5/Lv0PBxDACgweTaZAglz476s7TvYo63//2a
>>> >  IgcAoIp0u2ZxOes8fFPuUAoP2FrHk/VN
>>> >  =FjsP
>>> >  -----END PGP SIGNATURE-----
>>> >
>>> >  ---------------------------------------------------------------------
>>> >  To unsubscribe, e-mail:users-unsubscribe@tomcat.apache.org
>>> > <mailto:users-unsubscribe@tomcat.apache.org>
>>> >  For additional commands, e-mail:users-help@tomcat.apache.org
>>> > <mailto:users-help@tomcat.apache.org>
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:users-unsubscribe@tomcat.apache.org
>>> <mailto:users-unsubscribe@tomcat.apache.org>
>>> For additional commands, e-mail:users-help@tomcat.apache.org
>>> <mailto:users-help@tomcat.apache.org>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

-- 
Sent from my mobile device

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message