Mdg:seo not Working

saeeed · December 17, 2020, 5:46pm

I went through everything correctly, but the package does not work properly .

The steps I went through are as follows:

The steps I went through are as follows meteor add mdg:seo
And I downloaded this package prerender
And this is the content of the server.js :

I ran this package on port 3033

And this is my meteor settings

The problem is that nothing works properly, meaning the content is not rendered

Content should now be at the address below, but it is not

view-source:http://localhost:3000/?_escaped_fragment_=

And when I try the following curl, it does not work and does not return the correct content:

curl -A Googlebot http://localhost:3000

As you can see, the content of the div App is empty

But when I try the following curl, it works properly and returns the correct content :

curl http://localhost:3033/render?url=http://localhost:3000/

saeeed · December 17, 2020, 6:04pm

Also, none of the JavaScript tags are removed!

captainn · December 17, 2020, 6:04pm

I have never tried to do that, but it looks like a great idea!

saeeed · December 17, 2020, 6:07pm

@captainn is is a good idea, at least it repels the negative impact of meteor on Google.
But you will never replace the rendering server because the rendering server, in addition to affecting Google, also improves the user experience, due to the increased loading speed.

captainn · December 17, 2020, 6:10pm

SSR is not all upside. It dramatically increases the stress on your app server. A microservices division of labor (so to speak) can make sense.

Anyway, there isn’t a lot of source code to look at in mdg:seo. Try making token in your settings file any truthy value, and see if that fixes you up.

github.com

meteor/galaxy-seo-package/blob/8b1a6d638cc2c5077b529fcd0c3aa467f44ad3f1/server/prerender.js#L15


var settings = Meteor.settings.PrerenderIO;
token = process.env.PRERENDERIO_TOKEN || (settings && settings.token);
protocol = process.env.PRERENDERIO_PROTOCOL || (settings && settings.protocol);
// service url (support `prerenderServiceUrl` (for historical reasons) and `serviceUrl`)
serviceUrl = settings && (settings.prerenderServiceUrl || settings.serviceUrl);
serviceUrl = process.env.PRERENDERIO_SERVICE_URL || serviceUrl;
if (token) {
  if (serviceUrl) prerenderio.set('prerenderServiceUrl', serviceUrl);
  prerenderio.set('prerenderToken', token);
  if (protocol) prerenderio.set('protocol', protocol);
  prerenderio.set('afterRender', function afterRender(error) {
    if (error) {
      console.log('prerenderio error', error); // eslint-disable-line no-console
    }
  });

saeeed · December 17, 2020, 6:14pm

@captainn
@filipenevola I think this package has a logical flaw, because the prerender server can have no tokens.
And can be without authentication.
On the other hand, in addition to having tokens, it can also have a username. Which is not included in the package

captainn · December 17, 2020, 6:15pm

It’s so small - if you need different behavior, fork the package and put it in your local packages directory, and make it do what you need.

saeeed · December 17, 2020, 6:20pm

Do you think it is possible that we do not have a separate server for the prerender and even a separate port above?
Instead, embed it in the meteor itself

captainn · December 17, 2020, 6:22pm

Maybe, but it’ll put more stress on your server.

captainn · December 17, 2020, 6:23pm

Another possibility is to debug what’s going on in fast-render, and try to fix that, since it’s our only blocking item with SSR.

saeeed · December 17, 2020, 6:34pm

@captainn It is my wish that there is no problem in the meteor rendering server and that we can benefit from it.
And as you said, the only obstacle left is the previously reported fast rendering package problem.
@abecks But the problem is that the manufacturer of Fast Render does not have the necessary cooperation and apparently has abandoned the package support.
@filipenevola On the other hand, there is no serious will on the part of meteor officials to solve the ssr problem in meteor.

And always when we ask them this question, they refer us to side packages.
And the result is that now the whole ssr meteor is useless because fast rendering does not work properly