I've been developing the client-side for my web-app in JavaScript.

The JavaScript can communicate with my server over REST (HTTP)[JSON, XML, CSV] or RPC (XML, JSON).

I'm writing writing this decoupled client in order to use the same code for both my main website and my PhoneGap mobile apps.

However recently I've been worrying that writing the website with almost no static content would prevent search-engines (like Google) from indexing my web-page.

I was taught about this restriction about 4 years ago, which is why I'm asking here, to see if this restriction is still in-place.

Does heavy JavaScript use adversely impact Googleability?

  • 4
    What's with the 99999999 links?
    – DeadMG
    Jun 4, 2012 at 4:11
  • 1
    I thought this might be good for the community wiki, (if it gets good replies); so I thought it would make sense to have well-defined question content.
    – A T
    Jun 4, 2012 at 4:12
  • 4
    @AT That's not how Community Wiki works... You posted on Programmers, the crowd here is expected to understand what a search engine is, no need to link to the Wikipedia article. Your question isn't really well defined, you aren't telling us anything about the actual project and how it works, other than some vague buzzwords.
    – yannis
    Jun 4, 2012 at 7:10
  • It's a general question. The vague buzzwords have been disambiguated through references. I also included my use-case for having a decoupled client, i.e.; same codebase for mobile apps and website. My question is very well defined and applicable to a wide audience.
    – A T
    Jun 4, 2012 at 7:27
  • 3
    @AT The problem with the buzzwords is not that they are vague themselves, but you are not telling us absolutely anything on how exactly you implement the various technologies. Linking to a reference sites for extremely common buzzwords is completely pointless, we know what the technologies are and how they are used, what we don't know is how you use them in your project. Also the one bit of information you actually give us, "decoupled client", is quite idiomatic and means absolutely nothing by itself.
    – yannis
    Jun 4, 2012 at 15:37

6 Answers 6


Google (and I suspect Bing as well) have gotten much better at reading and indexing text found in JavaScript elements during the past 3-5 years or so. They do this for two reasons. First, to provide better indexing of content for users and, second, to detect and thwart various spamming techniques.

The problem is that you may not get indexed as well as you would like for the keywords you want or for long tail combos that may be valuable. Let's say that your topic was on dog training supplies. You might be able to rank for dog training supplies if your incoming links were good and other on-page elements fit the search engines' statistical profiles. However, since you have content for "German Shepard training supplies" or "Great Dane training supplies" buried inside a lot of replaceable text, you might not rank as easily for these terms. There are some ways to manage this but the best strategy will depend on specifics for your site.

Another thing to consider is that splitting off content into standard and mobile sections can cause ranking problems as well. Make sure that you use the canonical tag to indicate that your standard page is the one that should be considered the primary source. This avoids duplicate content filtering and possible penalties associated with the recent Google Panda update.

  • Do you have references?
    – Pacerier
    May 12, 2014 at 12:49

As a general rule, search engines do not crawl content generated by JavaScript or Ajax. The most notable exception being Google's crawlable Ajax. But that only applies to Google and even then that's a bad idea.

To make your site more search engine friendly you will need to make content available via static links. Without these you essentially have a one page website which is very difficult to rank well. But it can if you obtain enough incoming links which is possible if your game is very good.

Finally here is a good link from Google


If most of your actual page content is in a database, and the only way the user actually sees it is if a JavaScript queries the DB via Ajax and inserts the result into the DOM, then there is basically no way for search engines to see it. This hasn't changed; if anything, it has got worse as Web sites are made less and less static.


Do an ajax get request on a typical web page rather than some API address and output the results as a string. That's what the spiders have to work with. Google is supposedly a little bit smarter and there are supposedly some workarounds but if you have static content for the indexing, why would you try to serve and build it via Ajax?

And yes, I've seen Android tutorials that suggest otherwise. You'd think Google engineers would be a little more google conscious but maybe that's the problem when all you have to do is tap somebody on the shoulder to have your junk show up on the first page of keyword terms you're targeting. In order to index your page, there has to be something to index. The more straightforward that process is for algorithms written by a bunch of Stanford Java guys... well, let's just say, duh.

It might be able to follow some JS-stuff if you do it right, or so I've heard but I've paid very little attention to this because really, you're solving the wrong problem 99 times out of 100 at that point. Serve static HTML from the server. Anything you want users to build or reference in ways that shouldn't "stick" to a given URL, is reasonably handled by Ajax and DOM work.

Why add more complexity to the issue when you can do it in a way that never stopped making sense in the first place? Faster rendering in JS? That's just ignoring the real problem which is that a given browser's HTML/CSS parsers need an upgrade.


Google, or any other search engine for that matter, will not execute/evaluate the JavaScript on your page.

So if you rely on JavaScript for retrieving the data to present to the user, then that data will not be seen/indexed by search engines.

  • 1
    They do evaluate it these days. See forbes.com/sites/velocity/2010/06/25/… This is from 2010 and their ability to execute, statistically evaluate and other analyze Javascript has only continued to be improved and refined.
    – jfrankcarr
    Jun 4, 2012 at 11:48
  • Ok, it has gotten more advanced. But how far does it go? If the page retrieves data asynchronously through AJAX and then inserts the retrieved data in the DOM, will Google be able to see that data as part of the original URL?
    – Pete
    Jun 4, 2012 at 12:05
  • It's been hard to tell exactly how far they go since this part of their algorithm has been seeing a lot of updates. It does look at DOM element insertion but much of the initial focus was to deal with web spam techniques (ad insertion overlays, keyword stuffing/redirecting, etc). More recent updates seem to be doing more content analysis but exactly how much is unclear still.
    – jfrankcarr
    Jun 4, 2012 at 14:32
  • this is not 100% true nowadays. Actually, at least google do some experimenting with indexing ajax content.
    – shabunc
    Jun 4, 2012 at 14:39

The best idea is building your website and the checking Google cache. See what google shows on it's text only cache. This is the most simpliest answer as well as most useful answer you should care about if you understand.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.