Google may stop following their own AJAX guidelines, that means that the current way to achieve crawlability with a meteor app won’t work any longer. http://searchengineland.com/google-may-discontinue-ajax-crawlable-guidelines-216119
I think it’s time to re-priorize the “Server Side Rendering” Feature on trello. When (and IF) this google update happens, Meteor apps will have huge problems if you depend on regular traffic from search engines (like I do). This would be an instant showstopper.
Hmm. We need may need to remove spiderable, but we could index our apps anyway.
That’s because Google can render our apps.
I did an experiment on this few months ago.
Check this: https://meteorhacks.com/meteor-seo-google-fetch-and-render.html
I have read your article and I just wouldn’t count on google currently. The ideal solution would be the same thing what twitter does, or how derby.js handle it: On the first request, just render the complete HTML on the server and deliver it, and while the user views the website, establish the wecksocked connection and so on.
That way, a meteor app is crawlable without hassle, and the user experience just feels way faster. Currently your fast-render package is just essential for public facing stuff @arunoda … but this wouldn’t be neccessary any longer with SSR. Also, the current phantomJS hack isn’t that speedy when you view the response times for crawlers.
All these problems could be solved by proper SSR. It would reduce much hassle and ideally does it’s stuff in the background so it’s a no brainer with zero configuration needed.
Yes. I agree.
May be React could help us on this.
@anonyfox I read the article as well and what I understood from it is that it is actually very good news.
As far as I understand, Google is commissioning out ajax crawling because it just does not need it any more, instead it will be running the full javascript to render the page as a broser would, and than it will index that.
The article supports this by linking back to https://www.seroundtable.com/googlebot-crawl-final-page-19088.html
Gary Illyes from Google commented during a panel at SMX West that since Google was able to render your full page starting back in May 2014, it may discontinue the AJAX crawlability recommendations offered in the Google Developer center.
I do agree that server side rendering would be nice for faster loading apps (hello fast render) but I think it is now actually time that we change how we perceive SSR and what it is good for. I guess SEO is no longer a SSR concern.
Okay, let’s assume that google is able to fully render a meteor website soon. Are other search engines equally advanced? Yandex, Bing/Yahoo, …?
Usually my experience is, that developers and managers just ask me as the first question if google is able to index this “dynamic SPA pages” easily. When I have to say “maybe” in the future, this is a definite showstopper for many.
I’d like to be sure that it will work, no matter what.
And the problem extends even further, social sharing and the like. These social networks have crawlers on their own and request the shared page with much simpler crawlers than google has. And this stuff must work, or meteor is just unusable for some (many?) usecases.
Sure, it would be nice if the crawlers all over the world would be able to just render our javascript pages perfectly, but in the meantime?
Well, I do agree with you on all accounts.
But again, most of us have been on the meteor train before it was 1.0 and are by association forward thinking people, caring less (than others do) about some aspects of a stack that we previously used to take for granted.
I remember just a few months back when people argued meteor not to be production ready, it was lack of an account system before that, in a few weeks/months (as the article suggest) meteor apps will have become perfectly indexable by google.
Well, I strongly believe facebook will have that covered soon as well.
As for yandex, bing etc, well as much as I am pro competition, I don’t really care after google gets to show my pages on search results for some 90+ % of people doing searches on the internet.
In the meantime, we can use prerender.io which is very simple to intgrate with meteor.
But let me add that, I’ve been actively coding apps/sites to show a go-upgrade-your-browser overlay (yes an undismissable annoying mandatory monsterous overlay) to IE<9 for through 2013-4 and now I’ve taken it further to restrict browsers < IE10. So this is my preference. We need to make hard and firm choices to be able to move forward. And this time I’m betting on Meteor and bots’ ability to index them.
As much as I share your mindset, I can see only advantages for SSR on the first request.
Just what pops in my mind right now, probably way more.
I think our final goal would be something like what Ember is trying to do with Ember Fast boot. Very much like what derby.js has in place where the initial page is HTML while we wait for JavaScript to take over.
exactly this. this would the perfect behavior.
As I said, I do agree with your comments on all those accounts. My thinking is, seo will probably cease to be our main SSR concern in not so distant future. (Ignoring the effect of loading time perhaps.)
But yes, SSR is a definite plus without argument.
For sake of discussion, do you trust meteor for an app that’s supposed to create 100k pages per day!
I mean, that’s really impressive, and I sure would like to know what kind of an infrastructure your planning to deploy on and what specific measures you took for perfomance reasons.
We can all talk about this until we are blue in the face… But nothing is stopping someone from taking up this mantle and building something. Prove out some concepts, make something useful.
Iron-router wasn’t build by MDG, but it is in almost every single app.
Yeah, I would look at prerender.io if you really care about this stuff. They cache things on their end and someone made a package for Meteor to make it work easily.