I’m having a debate with myself lately. I’m a big fan of Meteor and a strong believer in the platform for the future. The project I’m about to embark requires heavy-duty SEO. It’s a public site with a hundreds of thousands of listings and “pages”. It would be critical for me to have Google to index all of that content correctly.
Given the nature of Meteor, and its inherited problems SEO I’m worried if selecting Meteor would be a right decision.
What do you guys think?
I think it should be fine, you’re not the first person to do SEO for Meteor.
Google is indexing pages now with a browser that can follow links, don’t think you need to use spiderable anymore.
There’s also server-side rendering for Blaze (https://github.com/meteorhacks/meteor-ssr), though not strictly necessary for SEO.
Thanks.
Leaving SEO aside. Let’s say you were to work on a job aggregator site with a large traffic potential. How large of an infrastructure I would need to handle say, 1000 concurrent DDP connections?
That question is impossible to answer without knowing how much data each user is subscribed to, how often it changes, and how different it is for different users.
I know, I know… Sorry about that. This is more of a philosophical question.
Say you asked to build indeed.com, with more reactivity and interactivity 
If most of your content is static, I would recommend something else such as Rails with a Memcache thrown in front of it.
Meteor shines where data is moving constantly, and you want that interactivity in your UI. SEO it’s still a crap shoot at the moment.
Just use meteor methods for static data, you get the same scalability of normal node.js app and you get fiber on the server. Please for gods sake dont go back to rails or django, you will regret it down the road. And If you really want to go non-meteor route then express or phoenix is much better.
Honestly from what you describe, to me it doesn’t sound like Meteor is the right tool for the job, since your pages are public and (I assume) don’t change a lot.
Instead I would probably recommend two separate apps, a back-end CMS-type app to manage the content (which could itself be using Meteor), and then some kind of static site generator like Middleman to take in an API and output static HTML pages for the public-facing part of the site.
From what I can gather, you’re not going to want any single page app for those requirements. It’s possible if having a SPA experience is critical, otherwise having a SSR (server-side rendered) page with “JS Sprinkles” for AJAX/validations will most likely be a perfect fit.
What languages are your most comfortable with? Do you have any realtime needs?
A CMS system serving static pages as @sacha suggested would work if you need to have a UI to add/edit pages. This could still use Meteor and something like Nginx could serve out the static pages.
@SkinnyGeek1010 what about something like a Ebay/penny auction ? SPA like behaviour is needed, realtime is needed too. But seo is important as well in this kinda apps, no ?
I think every case depends but auction sites don’t have critical SEO because the pages are short lived. Also those typically don’t have a lot of different pages, maybe a dozen or less.
Also thousands of ‘pages’ to me sounds like different templates. For example this forum app doesn’t have millions of ‘pages’, maybe a few dozen or less. Perhaps I misunderstood the requirements there though.
I wanted to share a solution to the SEO and slow first page load problems most client-side websites have. Meteor 1.3 can be an excellent SEO optimized, fast loading web-app. You can acheive:
See this Stack Overflow question and answer: http://stackoverflow.com/questions/38339780/score-100-on-google-pagespeed-insights-using-meteor-ie-a-web-app-landing-page/
An example page: http://bc-real-estate-math.com/