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?
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 have to create a new asp.net mvc page that integrates content provided by a cms on the server side static. my mvc page provides a masterpage with the navigation and certain links should point to pages of the cms (which is installed on the same server). it should be something like a "server side iframe".
my idea is to create a controller which loads the page of the cms using a webrequest, extracts the body part of the page and passes the extracted data to the view. the view simply outputs the passed html. i also plan to add some logic to pass post requests to the cms (for news letter subscriptions, contact forms, ...)
now my question is: is it possible to implement this solution? or is there a better way to do this on the server side?
Could you use Application Request Routing to just hand off requests to your CMS, or do you need to include the externally provided content within an existing masterpage?
If you need to use the masterpage I would stick to the solution you suggest, although I might investigate the most robust and efficient option for querying the content from the CMS and perhaps if caching would be a good option.
It is undoubtedly possible, but keeping track of users, authentication, cookies etc. seems like a really tedious job. Also, embedding css classes, hard-coded styling etc. from the CMS in your MVC site could give you a severe headache.
If the CMS isn't home-brewed it probably has an API. In that case I would much prefer to use the API to get at the data I needed and then render that data using pure MVC. This will give you a much cleaner and more stable integration with the CMS.
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.
I am playing with learning ASP.NET MVC as a non-web developer. I am trying to find the best idiom to use for an app that has a concept of selecting a 'project' to work on the first page that affects all other pages.
There seems to be three choices:
Just put the information into the session state. Works fine, but isn't very MVC-ish
Embed the state into all URLs ... so instead of /Products/Details/1 the URLs are all /(project_id)/Products/Details/1
Setting a separate cookie for this information
Since nearly all the URLs in the application would require the current project this seems overkill, and makes constructing the URLs used in any of the views that much more work. It would also require that I validate the permissions on each call since the user could easily modify it.
Any suggestions on the best approach -- is using the session such a bad idea?!
Option 2 out of yours is my choice.
So instead of /Products/1/Details
I would make it Project/1/Products/1/Details
Its just more in line with REST. Its virtually irrelevant to MVC, but if you want your Routes and URLs to read like resources in REST, you'll want the url to collapse at the slashes and carry the state. Other ways are to mark a project id in cookie, but that kills linking, so that as someone leaves and comes back they get put back there.
Session also makes it hard to test if you bind yourself directly to that concept.
Personally, I would just use the session. There's nothing non-MVCish about the session really - think of it as just being part of your model.
Using a cookie is really no different than using the session. Embedding it in the URLs is not a bad option though, especially for "linkability" if that's a concern for your project. But it has the side effect of cluttering up URLs and requiring you to pass that ID around constantly from page to page.
I have a website where my present "geeky" urls look like:
http://www.bestatdubaiholidays.co.uk/pages/Quote/Details.aspx?GUID=01a25b0c-e0ac-40ba-abd1-298f3abd9612
I want to change these to Search Engine Friendly ones - something like:
http://www.bestatdubaiholidays.co.uk/the-palm-atlantis.aspx
or
http://www.bestatdubaiholidays.co.uk/the-palm-atlantis
I have hundreds of incoming links (from ad campaigns and other sites) to my geeky urls that I want to retain.
So if someone types a geeky url, I want the address bar to show the equivalent search engine friendly url.
Can anyone help? Referring to other articles won't help. Believe me, I've read every one of them. Any example urls will be helpful.
Use something like this http://blog.eworldui.net/post/2008/04/ASPNET-MVC---Legacy-Url-Routing.aspx
You don't have to use MVC, the routing classes are standalone now
I suggest using a Front controller. This means that you use the rewrite engine of whatever httpd server you're using to redirect ALL requests to a single file (index.php or index.aspx or whathaveyou) and then you use code in that file to dispatch to the appropriate page. You can do a redirect from the geeky URLs to the friendly URLs, and if it's a friendly url then you load the appropriate page.
This would be way easier than writing huge rewrite rules for each type of page you might have. And this way all of the work is done in the same language your site is already running, so you don't have to learn and maintain a new file that is in its own language just for the redirection.