Hacker News Reader

Comment by IkmoIkmo | Hacker News Reader

> At my previous job, site was rendering on server. It was old, and we wanted to redesign it. I wanted to keep rendering on the server. CTO and VP wanted to build Angular site because everyone is moving to Angular and its easy to find Angular developers. Company's 30+% of new visitors comes through SEO.

I think I missed the point of your second paragraph, I'd be interested to know what you meant to say. (currently working with Angular on a small hybrid app and thought about experimenting with it on the web but SEO concerns were the first thing that came to mind, so it feels like a relevant piece to me!)

View on HN

I think he's pointing out the extreme ridiculousness of doing things just because they're what everyone is up to- if you're doing ng-includes and using ngRoute client-side for the public bits of your app, you're going to want to consider either a phantomjs-based snapshot service or refactoring to render the HTML on the server (you can still work Angular in w/ this latter approach, it's just trickier). Most of the Sails apps I've done have been server-rendered pages for the public sections with >=1 SPAs for the logged-in experience. In my experience, this is the most practical approach and lets you get some of the best of both worlds.

The implication is that without server-side rendering, SEO would drop. This isn't actually true for Google (edit: sometimes!), since it executes JavaScript, in part to prevent SEO gaming of its platform. But it would likely harm other web crawlers unless care was taken to incrementally add Angular to the existing HTML pre-rendered, or to execute the Angular.js server-side for bots and a nice page load speedup.

@lstamour Careful! We tested this theory last Fall with sailsjs.org and it turned out to be patently false-- we went from the second result when you google "Node.js framework" to not even being present. When I turned our headless browser snapshot stuff on again about a month later (we use brombone), it worked itself out. Needless to say, sucks :/ But everyone should be aware of the reality.

Sorry, that's true. I should have been a bit less forceful on that one. I know personally that there's a lot which goes into Google's rankings -- for instance: mobile optimization, SSL, and (where JS can slow things down the most) page speed. Google wants the web to be fast, and if two websites have identical rankings, it will rank the faster one higher. Waiting on JavaScript delays the "time to visible content" by a significant amount.

From my experience, the state of javascript for what's ostensibly the best web crawler in the world is still "it might work".

I know google is experimenting but I have never seen any JS rendered page in the google search result.

My mobile hacker news client http://hn.premii.com/ ranks top on Google but not because of the content. Content is not indexed by Google.

If your site is going to rely on search engines like google, and bing, you should think twice before committing to angular or client only app.

- JS only site won't rank higher on search engines.

- Facebook share/Open graph won't work

Or any site that relies on getting HTML from you to index wont work.

Reply on news.ycombinator.com