Prerendering with Meteor
Set up SEO-friendly prerendering for your Meteor application in Galaxy
What is prerendering?
Search engines and social media platforms work best when they can immediately see your page's content. But if your Meteor app renders everything in JavaScript, they might just see a blank page or a loading screen. That's where prerendering comes in.
Prerendering generates static HTML snapshots of your pages before search engines crawl them. Think of it as taking a screenshot of your fully-rendered app and serving that to bots. Your real users still get the full interactive experience, but search engines get exactly what they need for SEO.
Why you need it
Without prerendering, search engines struggle to index dynamic content. This hurts your search rankings, and social media platforms can't show rich previews when people share your links. Prerendering fixes both problems.
Getting started
Galaxy includes a built-in prerendering service, available on the Essential plan and higher, at no additional cost. If you're on the Free plan, you'll need to upgrade to use this feature.
Prerendering requires at least an Essential plan. Free plan apps can't use Galaxy's prerendering service.
If you have the right plan, adding prerendering takes just one command.
Open your Meteor app directory and add the SEO package.
meteor add mdg:seoIf you're already using the spiderable package, remove it. These two packages don't play well together.
meteor remove spiderableDeploy your app to Galaxy. The prerendering service activates automatically.
meteor deploy your-app-nameThat's it! Your app is now prerendering pages for search engines. No configuration needed.
Testing if prerendering works
Want to verify that prerendering is actually happening? You need to simulate how search engines see your site, not just how your browser does.
The old ?_escaped_fragment_= parameter approach is outdated. Google discontinued the AJAX Crawling Scheme back in 2015, and modern search engines don't use it anymore. Skip that method.
The right way is to test with curl commands that mimic actual search engine User-Agent strings. This tells your prerenderer to serve the static HTML version instead of raw JavaScript.
curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -L "https://www.yourapp.com" > googlebot_response.htmlcurl -s -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" -L "https://www.yourapp.com" > bingbot_response.htmlcurl -s -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" -L "https://www.yourapp.com" > facebook_response.htmlcurl -s -A "LinkedInBot/1.0 (compatible; Mozilla/5.0; Jakarta Commons-HttpClient/3.1 +http://www.linkedin.com)" -L "https://www.yourapp.com" > linkedinbot_response.htmlThen check the file to confirm it contains your fully rendered page content.
If you see your actual page content (text, headings, etc.) in the response file, prerendering is working great. If you only see a header and a reference to a script file, something's not right and you'll need to troubleshoot.
Troubleshooting
Cache freshness and limitations
Galaxy's prerendering service has one important limitation: pages are cached for up to 4 days. If your content changes frequently, that might not work for you.
Need to refresh cached pages more often, or need full control over prerendering? Set up your own prerender.io service. You'll have manual cache clearing and custom expiration policies.