I've embedded Google Calendar into HTML page. It has a big number of calendars in it, so, to make it nice I'd like all the calendars to be turned off by default.
It seems that jQuery can't help here, due to same origin policy.
Is there a simple straight-forward "just-make-it-work" solution?
EDIT: in the question mentioned above there was a word about using local proxy for this task. What is it and how to do it?
I think that your best solution is to pull in the calendar feeds and present the calendar yourself.
Same-origin policy will always bite you. jQuery is just JavaScript. It isn't magic, and if it cannot access something, neither will any other client-side scripts you write.
Proxying something as complex as the Google Calendar isn't a good idea. Even if you get it working, they may change it in the future.
It's trivial to pull in their XML. You can find the URL right on the same panel that you got the HTML for the shared calendar. Then, you can load all of those server-side and present them on your page however you would like.
Related
I am just wondering if Google or other search engines execute JavaScript on your web page. For example, if you set the title tag using JavaScript, does the Google search engine see that?
There have been some experiments performed for SEO purposes which indicate that at least the big players (Google, for example) can and do follow some simple JavaScript. They avoid sneaky redirects and such, but some basic content manipulation does seem to get through. (I don't have a link handy for Google themselves confirming or denying this, it's just various posts I've come across when dealing with this before.)
However, this is generally considered unreliable. If SEO is being done for any important purpose, don't rely on the spiders indexing much dynamic content.
There's actually a very good (in my opinion, anyway) answer here to a very similar question. What I like about that answer is how it breaks down the steps for generating good, indexable, and best of all maintainable web pages with concerns properly separated. Adhering as much as possible to this process generally results in good SEO, good accessibility, and good design skills in general.
Yes, Google executes Javascript. How much is a moving target.
Google executed some Javascript as early as 2011: http://searchengineland.com/google-can-now-execute-ajax-javascript-for-indexing-99518
This article from 2012 documents some experiments on what Javascript Google did and did not run at the time: http://moz.com/ugc/can-google-really-access-content-in-javascript-really
In May 2014, Google said publicly that they execute Javascript: http://googlewebmastercentral.blogspot.com/2014/05/understanding-web-pages-better.html Although that post says that Google has been getting better, there are no publicly available details on what Javascript Google does and does not execute -- but presumably they are at least as good at it as they were in 2012.
I'm pretty sure they dont. However, you can see for yourself: google have a tool which will show you your page as it sees it as http://www.google.com/webmasters/
if the text is in the onpage javascript, google will see the text. but it will not be seen as the text of the title element.
but hey, this is quite easy to test. just do it. wait two days. if you then google your site with site:.... look whats in the headline. if it's in there then the answer is yes: google sees it, if not: no google doesn't. it's easily testable.
(p.s.: my money is on: no)
We need to remember that JavaScript is client-side language, and always start executing from client-side. If all of titles or contents are via javascript then it'll be output from client-side, and I doubt it'll show up on Google search (meanwhile if outputted on .html, then yes).
If I am correct as of latest, meta tags are "fuel for search-engine", and it have ties to SEO, where it is common robots to be scripted to crawl on your site.
It's often said that iframes are bad for SEO (this worries the client) and should be avoided in most cases (from the research I've done). I would like to avoid them but I can't find an adequate alternative, to summarize, I have a website portfolio that needs to be displayed on the home url (example.com) and showcases the use of responsive design. A JavaScript solution is offered here at, also a demo is linked via github:
Source: https://github.com/OriginalEXE/Switcheroo
This is great, seems to do exactly what i need. I've checked the developers material for a mention of SEO, but found nothing. Now I've read some conflicting material on how Google treats iframes, for instance what if I kept the iframe content on a sub-domain such as (portfolio.example.com - showing a basic html homepage of a clients site) is Google known to treat sub-domains differently? (Again I've tried to find info about this). The content in the iframe doesn't need to be crawled, only the parent url. (example.com)
I've read that some people might use PHP to display the content like this (display a 3rd party site, framed and the ability to resize between mobile/tablet/desktop) however a previous developer was already building a WordPress plugin which was causing all kinds of security holes. I'd prefer to keep any solution on the front end/JavaScript.
Finally I've read about the use of robots.txt, would this stop Google trying to crawl the iframe content, can't find any clear answers. I'm happy to elaborate more on this, and apologies if my question isn't clear, I've been sitting on this problem for some time and I've been unable to find any direction.
Indeed google crawls iframe.
As long as the pages [invoked in the iframe] are designed in SEO friendly manner, then you do not need to worry about google not crawling to it.
Alternatively, if you have created a subdomain, you may submit the link to Google Webmaster so that it is crawled.
As of today, Yahoo and Bing have problems crawling iframe content.
Please read the following resources to confirm the hypothesis...
Post 1
and this
Post 2
Hope it helps!!!
Just a quick question for you all...
I've got a jsFiddle here and just wondering if we load content this way from an external api on load of the page will Google be able to see this information?
Here's the code of the fiddle...
<p>Property name <span id="property_name"></span></p>
function propInfo(propertyName) {
document.getElementById("property_name").innerHTML = propertyName;
}
Accessing this api is out of my hands - I'm told the only way to do it currently is via Javascript.
We obviously want our pages to be appearing correctly in Google so any help with this would be great!
You need to have a look at these guidelines to make sure that Google can access whatever content you load via AJAX - https://developers.google.com/webmasters/ajax-crawling/
As long as you're compliant with those, you shouldn't have a problem.
The only people who can definitively answer this for you are Google.
Matt Cutts did confirm that Google's crawler does run some content-generating JavaScript and index the result, but I don't think the details of the limits of that have ever been publicly disclosed.
Soon I'll be needing to build a widget that some of our clients can embed in their own websites.
To future proof my widget the embed code would be something like this:
<script type="text/javascript" src="path/to/remote/file.js"></script>
<div id="my_widget"></div>
What are the strengths and weaknesses of iframes vs JSONP?
Are there any common SEO based issues with iframes?
First of all, iframes and jsonp are not mutually exclusive: one is a rendering mean, the other is a communication mean.
Your choice is rather between in-document inclusion (that is creating the widget within the host DOM) or in-iframe inclusion (that is having a new, separate DOM for the widget).
The advantage of an iframe is sandboxing: no collision between your widget and the host's javascript and css. That means you can safely:
use/define any javascript library you want
use simple html code together with simple css rules (which is a clear bonus for maintenance)
As for the drawbacks:
an iframe is heavy-weight and may seriously slow down host page rendering
the iframe will also consume much more memory and resources, which may be a problem if the host page is targetted at mobiles
So, if it is reasonable to assume people using your widget will be willing to "adapt" their pages for it, go the in-document way. If not, use an iframe but understand the limits.
As for SEO issues, as long as you dynamically create the widget (whether it's in-document or with an iframe), search engines won't see it. I dunno if that's what you want, but that's what you'll get ;)
Heres some slides from a presentation on cross domain scripting by Alex Sexton
http://www.slideshare.net/SlexAxton/breaking-the-cross-domain-barrier
Unfortunately its just the slides so is missing the accompanying explanations but could be helpful
If you're making API calls and only fetching data, JSONP will result in better performance. If you're rendering things, then you must use iframes. If you want to prevent the host site from access to your widget data, iframes are the way to go. But if your data is public, then JSONP will result in a simpler implementation (since iframes will mean you need to deal with resizing). On the flip side, iframes provide for good CSS sandboxing, so you won't collide with the host page's CSS.
I chose to go with JSONP. You can see the details of how I implemented it here:
if I allow partner sites to republish my RSS feed, will that boost my SEO ranking?
Some people gave their opinions on SEO. I'm still not sure, however, if it helps SEO. I just got an idea to test it though, and I'm going to carry it out right now! I'm going to make a page with just the JavaScript that renders the widget (feed in this case). Then, I'll use Google's Webmaster Tools to see if Google picks up any of the keywords in the feed content. I'll post the answer to the link above after I get the results.
Wish us the best!
Matt
I don't mean for the title to be derogatory, but this is a rather frustrating problem, and I'm looking for a good workaround, given a language barrier involved.
I have a site set up for a plugin I wrote, and, rather than use the site's resources to write their own code, I've had people simply rip the code from the samples on the site. Normally, this wouldn't be any issue at all, but they are also taking my Google Analytics instantiation, so my Analytics data is getting very skewed by incorporating visitation data from their websites.
I've been able to contact the English-speaking site owners with little issue. The problem lies in the Japanese language sites that are yanking the code. I have no idea how to ask them to take down the analytics portion.
Long-term, I'm providing a package that streamlines the learning-to-use process, but in the meantime, what can I do about this language barrier? Is there a way around this problem that I haven't thought of?
You could modify the javascript on your pages to only load Analytics if the domain matches your own.
Two ideas:
Don't show your actual GA code on your site. Replace it with some filler code that makes it obvious it's meant to be replaced. Since I'm not sure what your plugin is about I'm not sure how practical this is, but I think there must be a way.
Use Google Translate to give foreign users the option to see your page translated into their own language. Google even offers a tool to add a "Choose your language" drop-down to any page. (And of course make sure the most important parts of your site are in plain, easily-translated English.)
Good luck!
Also, building on Greg's solution, if the domain doesn't match your own, you could alert a message telling the implementer to remove the code, a la what Crockford did with his JSON parser.
I would contact them in English (using plain language), and at the bottom I would add a version of the same text run through Google Translate - with an apology that it was generated by Google Translate and may not be accurate.