7 replies to this topic

[maleman]

hi folks,
I'm a newbie here.

I'm making a new site. I only made a few other sites and used straight html and CSS for formatting.

With the new site, I want to serve two different pages. One page will serve browsers that support "getElemntById". The other page will go to old browsers that don't support "getElementById".

I want to avoid any type of penalty and abide by the rules.

I'd like to use my pages for old browsers as the default and serve the getElementById pages to the browsers that support it (or maybe vice versa).

Is it possible to use a redirect to serve the correct page to a certain browser. If so, where can I get info on how to go about it.

I welcome your input and any suggestions you can give me.

Thanks for your interest,
maleman

Edited by maleman, 09 October 2004 - 10:24 PM.

[chrishirst]

welcome to the forum maleman

It won't matter to the spiders because you will be using a javascript to detect to level or version of the JVM (I assume) a SE crawler won't trigger the detection script, so will only "see" the page that is served as the default.

if you need the script a browser sniffer is here.

[maleman]

thanks chris,

I'll detect if a browser supports getElementById and serve my rich format page. If the browser doesn't support getElementById, I'll serve the default page.

I have to use two versions of each page, you'll see as I explain.

The script is something like this:

<script>
<!--
if ((document.layers) || (document.all)) //detects NN4 & IE4
serve up the default page
else
if (getElementById)
serve up my rich format page;
//-->
</script>

*There's a couple others I'll have to detect also.

The code under the "if" is more complex in my script. I'm detecting screen size and loading one of three separate style sheets for three separate screen sizes.

"if(getElementById)" will return TRUE if the browser supports it. If it doesn't support it, then the script will serve the default page.


My problem is that I'm using tables and want to support old browsers beginning with NN4 and IE4. I'm formatting with CSS. NN4 doesn't recognize CSS "width" for tables. If you use " width: 22px;" NN4 doesn't recognize it and your tables are screwed up if you try to use CSS to set the width.

I'm not supporting anything older than NN4 or IE4. Those people are going to have to upgrade and I'll inform them of this. Right now, I'm getting 10 or 12 hits a week from NN4, so I have to support it or risk losing out because of a broken display.

My default pages will support the old browsers so I have to use straight html <td width="22"> to size my tables.

I can't reformat the width using CSS if I have already set the width with width="22". At least, I don't know of a way.

So, I need a duplicate of all my default pages with the widths and everything else formatted with CSS. I'd store the new set in a subdirectory and redirect to that subdirectory for the newer browsers.

What I don't know is how to redirect the browser to the pages with rich text format in the subdirectory. Once the visitor is in the subdirectory, that's where he'll stay until he leaves because there will be no links out to the top level. The entire site wiil be duplicated in the subdirectory.

I'm not sure if this is considered as cloaking. Is this cloaking? I won't do anything that's against anybody's TOS so whatever route I take has to 100% legitimate.

Is there such a thing as legitimate cloaking? I've heard that other sites use cloaking to serve different browsers.

I won't have to redirect for the default pages which will be on the root of the site's top-level directory.

The current plan is to store the pages for old browsers on the root and store pages for the newer browsers in a subdirectory and redirect to the new browser directory as needed.

This will also cover if the visitor has his JavaScript turned off. He will automatically get the default old browser pages which will pisplay on his screen with no problem.

Moreover, the pages in the default directory can be written with little or no script because I've already screened for browsers and every browser I send to that directory will support my formatting.

I know how to do a 301 redirect. I'm using one now on a page that I changed the filename.

Spiders follow 301 redirects so that can't be used or can it?

Do you smell what I'm cookin?

If you can help me, I'd really be grateful

Thanks and I'm sorry this turned into an Epistle,
maleman

Edited by maleman, 09 October 2004 - 10:43 PM.

[chrishirst]

What you are doing is perfectly legitimate. My view on what is spam is the intent not the method. Here you are using the method to deliver the same content (formatted differently) to different user-agents based on the capabilities of that user-agent. what you are doing is content delivery not cloaking. The real cloakers like to blur that distinction to legitimise their (deceptive) methods.
If you were delivering different content and detecting UA names or IPs that would become a whole different issue.


On 301s. Crawlers don't actually follow the redirection in the way that browsers do. What will happen is the 301 response header is received and returned back to the data storage, this should the initiate the process of changing the stored URI to the URI returned in the Location header so the next visit will be to the new URI.

And you can't actually "do" a 301 with javascript as it is a client-side script and HTTP response codes are server-side.

[Ron Carnell]

I wouldn't think you'd want a server-side redirect, 301 or otherwise.

On the contrary, instead of encouraging 'bots to find their way into your advanced browser folder, you'd probably want to use robots.txt to exclude them. And you'd need to strongly discourage your visitors from creating links into that folder, too. Otherwise, if someone with an older browser found a link into the advanced folder, either through a search engine or on another site, they would end up exactly where you don't want them, presumably with no way out.

Since HR is as much a marketing forum as it is a tech one, I think it's important to consider the potential ramifications of essentially fencing off a large portion of your site. I think you're setting yourself up with some hoops that are going to take a bit of jumping to successfully navigate. You're probably going to need to do just as much browser detection in your advanced browser folder as you do in the default folder, so you can give people a way back out where needed. And, you likely still need to exclude one or the other from the search engines if you want to avoid a duplicate content filter.

Marketing aside, however, the answer is to use a JavaScript redirect, which obviously the spiders won't follow. location.replace(newurl); should do the trick, I think.

[Randy]

To add a thought into the mix...

Do you have SSI, PHP, ASP or the like available to you?

If so I would approach it a bit differently than doing a JS redirect. You would probably still want to do the individual folders/pages simple because there are so many things that would need to change in the code that it would be difficult to do it all dynamically. However I think it might make more sense to simply have a bit of Javascript to do your browser testing and then using a server side include the page code that is needed for that browser.

That would get rid of any potential duplicate content issues Ron mentioned above, and remove the issue of visitors linking to a page that you wanted the spiders to stay away from. Technically speaking, everyone would be seeing the same page/file name, regardless what their browser supported. They would simply be served a different formatting depending upon their browser capabilities.

You could also get the browser User-Agent strings and assign whether they support getElementID from that sort of list I suppose. However this is potentially fraught with difficulties since browser versions change often, meaning you would have to update your browser list often.

Plus if JS was available in a certain browser but the user had it Disabled, you would need to detect that up front. You might want to take a look at something like PHPSniff to get an idea of the kinds of things that can be done with server side browser sniffing.

Did that make any sense?

Sadly, I don't believe you can use any server side scripting to detect getElementID specifically. Not without reloading a page anyway. You can use it to detect user-agent information, however even that wouldn't tell you if JS was enabled or not. So maybe a combination of JS and PHP (ASP, etc) to do the job.

The only problems I foresee are:

• JS and PHP/ASP don't always play well together since the server side stuff takes place before the page is displayed and Javascript routines run on the client side after the page has loaded. This makes passing variables back and forth difficult at best.
• You would need to come up with some reasonable method to detect if Javascript was disabled, regardless of the browser type.

Okay, that's enough thinking out loud for a Sunday morning. My brain hurts now!

[maleman]

Thanks guys for all the insight.

I thought about SSI. That's probably the best route. I have ASP available but prefer to stay away from that.

I'm trying to come up with something barebones simple that work's. I've always taken the "simple" approach. It's worked best for me as far as dealing with search engines. Spiders like a meal served quick and fast. They don't care if you're a techno genius. They're just looking to get in and out with their info. The easier you make it for them, the better off you'll be.

Like Einstein said, "Keep it simple but don't oversimplify".

With my simplistic attitude, I guess I've gotten behind in my programming. I do C++ and VB but since I've gotten into this website-search engine thing, I hardly program anymore. I picked up JavaScript in a snap through C. I got into ASP through VB.

I try to keep any programming to a minimum or even nonexistant if possible.

The easiest way out for me here would be to just make one page for everybody. That way I can keep the barebones approach.

If search engines weren't a factor, I'd be using ASP.

I'll see what I can come up with based on your suggestions.

Thanks and I appreciate you input very much.

[Jill]

If search engines weren't a factor, I'd be using ASP.

What do the search engines have to do with you not using ASP?