hi, my 2 cents >Javascript apps can be fully crawlable yes, and i think it's cool that you try to provide a solution as a service for this. but as with every

hi, my 2 cents >Javascript apps can be fully crawlable yes, and i think it's cool that you try to provide a solution as a service for this. but as with every technology, there are some tradeoffs a) serving google a different response bases on the user-agent is the definition of cloaking (it's not misleading or malicious cloaking, it's cloaking non the less) b) you hardcode a dependency to a third party server - you have no control over - into your app (and from the sample code on the page, there is no fallback available if this server is down) c) there are latency/web-performance issue i.e.: for a first time request by a search engine the roundtrip would look like so: [googlebot GET for page -> googlebot detected -> app GET to prerender.io -> prerender.io GET to page -> app delivers page -> prerender.io returns page to app -> app returns page to googlebot] this will always be slower than [googlebot GET for page -> app returns page to googlebot] so basically the prerender.io approach creates some issues. said that. we don't have - yet - another "no tread-off" solution the "make ajax crawlable" approach basically allows - non malicious, non misleading - cloaking https://developers.google.com/webmasters/ajax-crawling/docs/specification https://developers.google.com/webmasters/ajax-crawling/docs/... (sorry google, but ?_escaped_fragment_= was really one of your must stupidest specs ever, even worse then "nofollow") so if you target "?_escaped_fragment_=" in the GET request, and not the user-agent cloaking a.k.a. sending different responses is ok but: it creates a double googlebot crawl issue i.e.: [googlebot GET http://www.exmaple.com/test http://www.exmaple.com/test -> googlebot parses HTML and finds <meta name="fragment" content="!"> in the HTML -> googlebot pushes http://www.exmaple.com/test?_escaped_fragment_= http://www.exmaple.com/test?_escaped_fragment_= into its "stuff to crawl-queue" (a.k.a. discovery-queue) -> googlebot crawls http://www.exmaple.com/test?_escaped_fragemten_= http://www.exmaple.com/test?_escaped_fragemten_= -> gets server side get request (or if you would use a prerender.io service the whole roundtrip to the prerender.io site would start) ] this is a no go if you have a big site with hundred of thousands to millions of pages. and there is another much, much bigger issue: * showing JS clients * and "other only-partially-JS clients" (google parses some JS) different responses just does not work in the long turn. why? if there is no direct feedback, then there is no direct feedback! non-responsive mobile site currently offer overall poor user experience, why? because all the guys working on the site sit in front of their fat office desktops. no feedback equals crap in the long run. and it's worse for "for robots only" views, because people just don't have to live with the crap they server spits out, as they always just see the fancy JS versions. since the hashbang ajax crawl-able spec came out it consulted some clients on this question, everyone who choose the _escaped_fragment_ road anyway did regret it later on. even if the the first iteration works, 1000 roll out later, it doesn't - if there is no direct feedback, then there is no direct feedback. conclusion: if you have a bit site and want to do big-scale (lots of pages) SEO you are stuck with landingpages and delivering HTML + content via the server + progressive enhancement for functionality, until the day google get's its act together. and for first-view webperformance i recommend the progressive enhancement approach anyway, too.