Should AJAX use hashtag /#!/ or not?
Asked Answered
G

3

10

I've made a webpage that has the URL-form http://www.example.com/module/content It's a very dynamic webpage, actually it is a web app.

To make it as responsive as possible, I want to use AJAX instead of normal page requests. This is also enabling me to use JavaScript to add a layer to provide offline capabilities.

My question is only: How should I make the URLs? Should they be http://www.example.com/module/content or http://www.example.com/#!/module/content?

Following is only my thoughts in both directions. You don't need to read it if you already have a clear thought about this.

I want to use the first version because I want to support the new HTML5 standard. It is easy to use, and the URLs look pretty. But more importantly is that it allows me to do this:

If the user requests a page, it will get a full HTML page back.

If the user then clicks a link, it will insert only the contents into the container div via AJAX.

This will enable users without JavaScript to use my website, since it does not REQUIRE the use to have JavaScript, it will simply use the plain old "click a link-request-get full html page back"-approach.

While this is great, the problem is of course Internet Explorer. Only the last version of IE supports History API, and to get this working in older versions, one needs to use a hashtag. (50 % of my users will be using IE, so I need to support it...) So then I have to use /#!/ to get it working.

If one uses both these URL-versions, the problem arises that if a IE user posts this link to a website, Google will send the server a _unescaped_string (or similar..) And it will index the page with the IE-version with the hashtag. And some pages will be without the hashtag.

And as we remember, a non-hashtag is better on many different things. So, can this search engine problem be circumvented? Is it possible to tell the GoogleBot that if it's reaching for the hashtag-version of the website, it should be redirected to the non-hashtag-version of the webpage? This way, one could get all the benefits of a non-hashtag URL and still support IE6-IE9.

What do you think is the best approach? Maybe you have tried it in practice yourself? Thanks for your answer!

Gerson answered 2/11, 2012 at 22:3 Comment(3)
Even if you are a Student of Hogwarts, you're still no match for me :P. Google will never index hashtagged URLs, simply because it cannot, hashtag is for the client-side only, and Google index doesn't support JavaScript.Jacobean
@MadaraUchiha Yes, it will index pages with hashbangs, simply because it converts it to a GET-request! ;)Gerson
And then it will add the hashbanged one to the index, so that the search results will return the hashbang-version directing the users directly into the AJAX version of the webpage.Gerson
S
9

If you want Google to index your Ajax content then you should use the #!key=value like this. That is what Google prefers for Ajax navigation.

If you really prefer the pretty HTML5 url without #! then, yes, you can support both without indexing problems! Just add:

<link rel="canonical" href="preferredurl" />

to the <head> section of each page (for the initial load), so to help Google know which version of the url you would prefer them index. Read more about canonical urls here.

Sender answered 3/11, 2012 at 1:12 Comment(3)
Thanks for your reply! After a lot of reading I found that the Googlebot works with 301 Moved header, but as I understood it, they couldn't guarantee that it worked.. And this is a more HTML-approach. But I think this approach is better to use if you have multiple similar pages, not two identical ones. What do you think is the best and most reliable way of doing it? After all, whichever way I do it, I have to do the same server logic. (Either send a 301 header when escaped_fragment isset(), or send a canonical head link.Gerson
Do you have any experience as to if it is best to use both versions or only the hashbang one? I want this website to be as modern and "new standards supporting". So I want to have clean URLs for non-IE browsers if it isn't going to introduce too much hassle and problems.Gerson
That's the key. If it's much hassle and introduces lots of problems, I don't want it.Gerson
H
2

In that case the solution is very easy. You use the first URL scheme, and you don't use AJAX enhancements for older IE browsers.

If your precious users don't want to upgrade, it's their problem, but they can't complain about not having these kewl effects and dynamics.

You can throw a "Your browser is severely outdated!" notice for legacy browsers as well.

Higbee answered 2/11, 2012 at 23:8 Comment(5)
As I said, I need to support them because they are quite a few, and they cannot update their browsers because they are required to use them in at work...Gerson
@StudentofHogwarts: That's a different problem. Back in my old workplace, I nearly beat up our so-called "network administrator" before he finally agreed to upgrade to chrome. We used IE6 until then, across the 200-computer network we had. Thing is, as long as no one complains, no one cares. Be the one to make noise.Jacobean
Well, you've got a point. But that wasn't my problem.. The reason why I can't be the one to make noise is that most users will come from small companies. So they are not individuals, but it's not one big one either. So I can't tell 13 different companies to change and suppose all of them do.Gerson
@StudentofHogwarts: Sure you do! These companies are your clients, correct? State that a new browser is a requirement for your web-app, much like they shouldn't use Windows 95, they shouldn't be using an old IE browser. Small companies are easier to persuade because they are smaller, and have less computers (making the upgrade process less of a hussle). In any case, I'll read it through once more to try and come up with something. But you should really consider this approach! You won't only be helping yourself, but all of these poor people forced to use IE against their will!Jacobean
Okay, if you/I can't come up with a good enough solution, I'll have to try what you said.Gerson
H
1

I would not use /#!/ in the url. First make sure the page works normally, with full page requests (that should be easy). Once that works, you can check for the window.history object and if that is present add AJAX. The AJAX calls can go to the same url and the main difference is the server side handling. The check is simple, if the HTTP_X_REQUESTED_WITH is set then the request is an AJAX request and if it is not set then you're dealing with a standard request.

You don't need to worry about duplicate content, because GoogleBot does not set the HTTP_X_REQUESTED_WITH request header.

Hairston answered 3/11, 2012 at 14:7 Comment(3)
Thanks for your answer! That is indeed the way I do it now. (I only set it up with ?ajax=1..) But what about the 50 % who use Internet Explorer < 9?Gerson
If you use ?ajax=1 you're adding redundant information, because the headers should already tell you whether or not the request is a ajax request. And the good thing about progressive enhancement is that the site still works, even when a browser lacks some feature. It may be slower, but it does work.Hairston
Yes, I'm going to use HTTP_X_REQUESTED_WITH instead. Thanks for your reply! :)Gerson

© 2022 - 2024 — McMap. All rights reserved.