hi, I’m trying to save html files in public folder. Everything works fine on localhost, but I when I try to deploy it on galaxy files doesn’t appear as expected (I mean appaddress.meteor.com/myfiles).
I have found in galaxy logs some files are in ‘/app/bundle/programs/’ directory, so I tried to redirect my files there, but it doesn’t work. I couldn’t find any information regarding file tree. Does anybode have any idea how could I find path to /public?
As with most container based solutions, you should not upload files to the container’s file system.
Whenever the container is replaced (restarts, new versions etc), the file system is destroyed along with the deployed code.
Consider using a cloud service like S3 for file uploads.
I want to create html snapshots based on page content which is changing periodically. So, as I understand- new versions doesn’t bother me. I just want to access them without using any template or js magic.
I was trying to save files by process.env['METEOR_SHELL_DIR'] + '/../../../public/'
If you don’t need to save tons of images you could always use a free cloudinary account… Much easier than trying to fight a containerized environment.
1 Like
I’m not saving images, I want to save html snapshots. Meteor is fully based on javascript, so I must create static html files to make it visible for bots (even googlebot can’t see meteor subpages, seo purposes). I know that most of bots can understand only pure html files. I want to control when snapshots are created and be able to add snapshots addresses to sitemap.xml file- this is why I want to save them in /public- no need for using templates and routing.
Couldn’t this be accomplished much easier using something like SSR?
1 Like
I’m trying to measure the impact of creating snapshots frequency on crawling. With static html files I can easily gather logs and see which pages are visited by bots and when did it happen. I don’t think it could be possible with SSR, but feel free to correct me if I’m wrong.
I’m not sure how you are gathering the stats on the static files but being that you can control the code for SSR, the sky is the limit and you can do pretty much whatever you can think up.
Meteor web apps are fundamentally ill-suited for SEO requirements (as opposed to some real requirement, like a piece of user experience).
You should emit static, publicly accessible landing pages for whatever search queries you want to rank for, and redirect the user to the actual application once they’ve visited the page. Host them in a static CDN, like CloudFront or S3.
Can you please elaborate on why exactly Meteor is “ill-suited for SEO”?
1 Like
It’s tough to get the best scoring out of Google for any Javascript-heavy application really.
You can always do a thing where you hijack the middleware to send whatever you want. Sure. You can do that with any node framework. Indeed, you can send baked HTML files to a client that requests something at a particular URL really easily with any web server.
I think @agiiik is going to have a bad time trying to work around turning a single page realtime web app into a static site Google likes. You’re really just building two separate websites.
I’d advocate embracing the fact that the static, indexable site is really its own thing. It’s a thing that’s pretty much only relevant to machines, and only relevant because Google cares. Obviously the end user just wants the best possible website. They don’t care about making something indexable. So to meet all the goals well, consider solving the SEO problem explicitly, not as a hack.
SSR doesn’t solve this?