What do you use for your frontend? React?
Do you have a constant number of pages or something that keep increasing (e.g. posts, new products)
No matter the front-end you will have to look into SSR or tight integration with prerender.io or ostr.io.
If React, maybe this will come in handy: https://github.com/Meteor-Community-Packages/react-router-ssr
After that it is about setting the necessary meta tags for Google and others.
After lots of research, I finally went for prerender.io in combination with mdg:seo. Unless you have lots of different pages, it’s free and just works.
3 Likes
I chose prerender/prerender which I host myself (I do full stack devops). Whenever it is time, I start the service, request it in small batches with the urls of each changed and new page. The result goes into redis, from which the search engines are served via nginx.
I had to do this because the day I looked into how to do SSR with Meteor + react-router it turned out that I’m mentally handicapped.
Most pages in our app are product pages (kinda), many of which just come and go quite frequently, meaning that site.xml is also constantly changing; maintaining it properly was a bit challenging.
Prerendering comes with unforeseen challenges too. JSS is a killer feature, not in a good sense this time. Plus we use packery for a dynamic grid which programmatically calculates the layout for any given viewport. Search engines’ simulated viewport can however vary (Googlebot’s, most prominently), and that totally breaks the grid’s layout. This forced us to do lots of if (prerender) { do this } else { do that } kind of programming, which is absolutely no fun.
If you do prerendering, the front end matters for the way you do 404 or redirects, the way you inject dynamic meta tags (essential for SEO) also the way you handle analytics either Google or a different kind.
I opted to do the same and … have the exact same ‘problems’. Still I definitely prefer prerendering to SSR. I am curious though how SSR performs with large numbers of queries as the number of pages grows. This is not only about SEO but also the social shares and web scrapping. I feel it is more optimal to provide the page prerendered from Redis rather than generate it on the fly. I keep my prerendering server in Digital Ocean behind a firewall. Before the firewall, the amount of sniffing and useless traffic and malware looking for wordpress file structures was incredible. Now I only allow my Meteor IP. This is also something that makes me curious about SSR, how it handles this useless and permanent hand banging into the Meteor server ports.
1 Like
I start prerender on localhost:3000 in the same VM where the process runs that sends the requests to the prerender service, hence I at least don’t have the non-stop external banging.
Another problem I encountered with prerendering was its apparent incompatibility with JSON-LD of which I make use for SEO purposes. The problem with it is that it appears as <script> in the html, which the prerender service gets rid of from the final result. I renamed it to <jsonld>, which gets left intact by prerender. Before it goes to redis a full text replacement changes it back to <script>. It’s kind of silly though 
We do SSR and serve thousands of pages. Our SSR output is being cached and being used both for HTML and AMP output. We do AMP because of the SEO benefits. We serve the cache through redis
Majority of our public-facing pages are served through SSR
3 Likes
@rjdavid – Assuming that someone gets it right with prerendering (+redis as cache), including having just the right amount of inline css in every page: would that solution be still inferior to yours?
I assume yes. The usability benefit is one of our main reasons that we do SSR. Our pages immediately loads the SSR html version then JS is loaded in the background. Once loaded, React hydrates everything in place.
On the perspective of the user, the page loads really fast because what he sees first is the light html version. And he can start browsing while the JS and React is loading/hydrating in the background
Here is a sample page
Let’s separate the two concerns:
- UX
- SEO
As for the user experience, and please correct me if I’m wrong, the benefit of SSR is restricted to the very first page load. That admittedly is very important, I’m not saying that it isn’t.
What about the SEO aspect? Aren’t the two solutions, SSR vs. prerendering just about the same from that perspective?
1 Like
Check the new core web vitals released by Google. It requires that fast initial benefit from the user because Google use the Chrome data (that permission to allow anonymous data to be shared when you first use Chrome) as part of measuring the score of the core web vitals. And the core web vitals will be a major SEO ranking factor for Google.
So, no, I do not think they are separate concerns (of course if your target is Google)
2 Likes
Oops: I wasn’t aware that Google measures via Chrome too. Thank you for the hint! It makes it instrumental to get into SSR.
On that note, I have followed the discussions of you and others with regards to the magic with CSS inlining and deferring, and I felt that it was very-very complicated and full of – for the lack of a better word: hacks, way outside of what is normally done in any common e-commerce application, and definitely outside of my comfort zone. Do you think there is a way to “tame” and normalize those solutions and thus make them accessible to… say, everyone?
I was also surprised upon learning that Chrome User Experience Report is being used in PageSpeed. That made us serious about SSR last July.
SSR was not easy (with the way we wanted it to behave). And yes, we are maintaining a fork of 2 core meteor packages to be able to do what we wanted. All the steps that we did were indicated in the first link I posted above including the link to our PWA + AMP implementation at the end of that thread. Not easy but doable. And eversince we completed everything last July, we go back to coding features and just dealing with small bugs appearing from time to time (normally AMP related).
While I highly appreciate your posts about what you pulled off, and all the details are really useful, I think it is safe to say that fallible humans with limited resources won’t be able to replicate your solution anytime soon.
I call this situation alarming. Applications developed with Meteor won’t stand a chance SEO-wise in face of the new core web vitals, except in a few exceptional cases of those who, like you guys, with great effort and determination build a custom solution around what in fact should be provided in Meteor core.
Sorry for the delays. The replies were going to SPAM.
Thank you for the replies. I am getting organic in a niche so the SEO tags are important but will look at Prerender.io since it is free. My data changes pretty regularly so have been looking at the Google and how to handle it as well and seems like that is the way to go with the non JS page.
My apps use a lot of headless browsers and I actually didn’t realize how simple it was to fork off a crawler to return a static HTML page so can just do this myself I believe if I need something more dynamic.
I call this situation alarming. Applications developed with Meteor won’t stand a chance SEO-wise in face of the new core web vitals, except in a few exceptional cases of those who, like you guys, with great effort and determination build a custom solution around what in fact should be provided in Meteor core.
I think most SEO engines supports client-side rendering. It works slowly, but it works.
Am I wrong?
The problem is with “slow”. FCP, or First Contentful Paint, as Google calls it, is the new gold, as long as it is less than 2 sec. If you’re app can do that, Google deity is smiling at you, otherwise not so much. If your FCP is greater than 4 sec, the app is on its best way into Google’s purgatory, which is really not a bad thing as long as the app in question is not intended to be found by human beings at all.
Only SSR can give you quick FCPs. This is not quite true: Google could be fooled until recently with prerendered snapshots which can be served within a fraction of a second. Alas, Google now uses Chrome to collect FCP measurements from internet users.
Loading speed is important, and not only for applications but also for any site. And if you don’t invest in this time, then you can hardly get to the top.
Therefore, need to check everything and conduct internal website optimization. Check all tags and meta tags, as well as all connected styles and libraries, should be involved. If they are not needed, then you must fix it, since this will also slow down the work. This is the first thing I started with on my site. I’m currently working on keyword grouping using this tool https://seranking.com/keyword-grouper.html This saves a lot of time and convenient to use. It’ll take much longer to do it manually.
We used prerender.io in a project written in Blaze. We were also changing the meta data according to the page with the ostrio:flow-router-meta package. It even had url language support. ex: /tr/urunler, /en/products etc.