I am building a blog for myself. Because it is relevant, here is the link: http://www.codetunnel.com. As you can see the page loads via AJAX so that I can do some stylish loading effects, among other things. It's actually a web-terminal that accepts commands and arguments and processes them via ajax; my URL structure executes these commands based on the URL passed in so that different pages can have unique URLs even though they are loaded via ajax. I've done past projects like this but have never cared much about optimizing the site for search engines, until this one.
Would a blog post being loaded via AJAX hurt its ability to be found by web crawlers? I'm assuming it would but I want your opinions before I decide how to move forward.
Thank you!
It depends. If you use unobtrusive javascript and progressive enhancement meaning that in your page you have links:
#Html.ActionLink("foo bar", "foo")
which would be AJAXified in some external js file, web crawlers will follow those links as all normal links and if the server returns content this content will be indexed just as all other content of your site. But if the url is built with javascript, then, no, it won't be indexed as crawlers normally do not execute javascript. I would also recommend you providing a sitemap as well.
I would say yes it would as from what I know the search engine wont see the loaded content, just the content from the initial page load.
Unless you use some kind of progressive enhancement (see this presentation), the main problem is that search engines will load and index only initial stuff.
As per my experience in search engine optimization yes, it will hurt rankings of the website. But now Google has proposed a proposal through which you can use Ajax to load the pages and at the same time it won't hurt your SEO efforts.
Related
I'm actually making a rails app for a music band. And they recently asked for a music streamer to play music throughout the whole application.
As they're on bandcamp, I thought that I might as well do that via the iframes they provide, before building a javascript streaming feature in some time.
But, here's the issue : when you put an iframe in your application.html.erb, it's reloading itself everytime the user is loading a new page. Exactly as if the code wasn't in the layout, but on every pages instead.
So far I've tried some stuff, like putting the iframe in a partial and calling it via : render 'layouts/shared/music_widget', but the issue stay the same.
As I've found nothing on the web so far, I'm guessing I've missed something ( maybe I lack some knowledge in rails' basic magic )... so, I'd be glad if someone here could help me with this one.
Thanks !
That’s because when you reload, a completely new page is generated and downloaded by your browser. The whole HTML is replaced with every HTTP request. To achieve what you want, you’d have to look into asynchronous solutions and SPA’s (Single-page Applications), basically having only one page and replacing the content of it using AJAX.
I suggest using batman.js, a great library which makes it relatively easy to switch to AJAX page loading using Rails. A big advantage is that it was built with Rails in mind, and as such it couldn’t be more simple to integrate it with your current application. However it does require you to learn CoffeeScript.
Alternatives include AngularJS, Ember.js, Backbone.js, each of them having gems helping with Rails integration.
I am sure there are many more, but I listed the most popular choices. You could also create your own JavaScript to handle that. The easiest solution in such a case would be to have the big <div> containing everything but the iframe; bind to the click event of a elements with a special attribute set (for example data-ajax="true"), make an AJAX request to the URL specified in href, and replace the content of the big <div> with the response.
In any case, you’ll need to read more about Single-page Applications.
I am working on a similar project which requires the use of iframe to play music thoughout the website. For that I used two layouts, one is the application.html.erb and another one is called player.html.erb
Now Application .html.erb is the one which contains header, footer and the iframe. And the other layout does not contain any of these and is the one which is used to for the actions to be opened in the url.
I am loading a form onto a page via ajax in my Rails 3.2 app. These views are being picked up by Google and the urls just render blank pages. Should I somehow prevent access to these pages when attempting to view from outside my app (http referrer or something like that) or just use the robots.txt file?
Therefore my question is: What is the best thing to do when you have a view which is only ever loaded in via ajax. This is a programming question, as I am happy to code in whatever best practices to my controller files etc. However, it is also from the perspective of SEO and the performance of my app.
I don't want Google to index these pages - however - I don't know if preventing access directly is the best option (such as in this question: How deny access direct URL to my partial views? <- wrong environment, or this one https://stackoverflow.com/questions/11522307/prevent-direct-access-to-certain-urls-only-rails-app-can-load-them <- related but unanswered.)
Of course, I could define these pages in my robots.txt and stop them being indexed, however, maybe there is a better solution.
If you don't want Google to index any of your apps pages for what ever reason Ajax or not I suggest simply using a robots.txt file to Google not to index them.
I'm not aware of a way to block specific partials, Only whole pages.
This would be considered an SEO best practice.
Is there any reason you felt this may not have been the solution? UX? Google TOS?
We are looking to integrate the display of some of our models, as well as a payment process, with some of our client's websites. It seems that everybody is going the Iframe route, but this also looks to be rather outdated when compared to XSS techniques.
How would one go about using XSS in rails 3 to enable multi page browsing functionality of elements of our site in another's site? As I understand it, we need to get a correct JSON protocol going, custom rendering in the client's website of the JSON, as well as maintaining state between page changes in the payment process and shopping cart.
Iframes certainly seem easier, but I am open to discussion around this, and an explanation of using XSS.
You need JSONP to do Cross domain scripting. This is a good article explaining it: http://emphaticsolutions.com/2011/01/21/functional-widgets-with-rails-javascript-jsonp.html
Here's a discussion on iframe vs jsonp: JSONP vs IFrame?
Also learn more about JSONP: https://www.google.com/search?q=writing%20widgets%20with%20jsonp
Isotope lets you write templates in javascript. These templates can then be rendered by either the client (using plain-old javascript) or on the server (using Johnson).
The benefit is DRYer code. When updating the DOM on an ajax or web socket update, you can don't have to write a new partial...just point it to the one you already wrote.
Has anyone used this?
Interesting, I would have to try it, however , and I know not a lot of people do it, but I actually use HAML to template .js files. Although there is still that problem the author mentions , of each request being templated on the server and sending back html, unless you are sending loads of kb, or you have really, really high load site I don't think it's such a big deal.
Also ideally you shouldn't be even sending html data back and force, just JSON objects, which are rendered on the page by your ajax request. The only legitimate use I can see for this is if you have heavily ajax website, such as where you load a page once, and the you just keeping doing ajax requests for all interaction and javascript to manipulate view.
So it would help if you would clarify the final goal. Is this for some internal app where you control user environment ( you know for sure which browsers they will use, and that they will have fast enough computers to manipulate all this javascript?) Or is it going to be an app targeted towards 3rd world, where people don't have yet resources available to use all that fancy javascript.
All that said, it's an interesting concept, and I will try it our myself, to see how well it works.
This uses Johnson, which last I checked did not work on Ruby 1.9. So that might hint at some of the immaturity of this particular solution. Eventually the community will come up with something that works really well.
One approach I have used is to make 2 completely separate templates, but try to make them as similar as possible so that it is easy to port changes from one to the other.
This seems like a bad idea. In an Ajax application, I believe that the server should be responsible for rendering all display text. This makes i18n easier, and concentrates everything in one place. The JavaScript should simply receive data from the server, with all display text already rendered, and put it in the appropriate DOM object.
In other words, I believe that in an Ajax application, the need for a JS template engine is itself a design smell.
The situation is different in exclusively client-side JS applications, of course.
I'm working on my first Ruby on Rails aplication and it's quite big (at least for me ;) - database has about 25 tables). I'm still learning Ruby and Rails and I never wrote anything in Javascript nor Ajax.
Should I add Ajax to my application from the beginning? Or maybe it will be better to add it latter?
Or in the other words: is it (relatively) easy to add ajax to existing web application?
Jeremy Keith has written a great article on this topic, which he refers to as Hijax
In short:
Plan for Ajax from the start.
Implement Ajax at the end.
Depends on how important Ajax is for the application. Since you are probably going to use Ajax for progressive usability enhancements only, I would say it is best to start with a traditional non-Ajax software, and add Ajax features only when you have the first features working. You can do this feature by feature, or write the whole software first, and then start ajaxing it.
Adding Ajax may be easier if you familiarize yourself with unobtrusive JavaScript techniques. Use jQuery instead of Prototype.js, or LowPro in addition to Prototype.js. For the latter, see e.g. Jarkko Laine's PDF book Unobtrusive Prototype.js.
If you are planning to do AJAX, I would do it from the beginning. It will help you structure your controller actions and views, especially with respect to generating some data in partial views, correctly from the very beginning. Knowing that some actions need to be able to render just parts of the page will change your design. This isn't to say that you can't go back and retrofit the design, but I think it's easier to get the design right if you design with this in mind up-front. You should also consider how to make it work without AJAX (or javascript at all), too so that your design is as fail-safe as possible. That doesn't mean that all functionality has to be available, but that important functionality works in the absence of javascript. For example, action links that use AJAX should have a default url that will invoke the correct action via a GET request if the javascript isn't enabled. Forms that post via AJAX should also work if posted normally. Dynamic behavior (like an image gallery) should have a usable, alternative view that works, etc.