SSG, fallbacks and SEO considerations

[rus-yurchenko]

Hi there, I struggle with the following question...

Whether fallback pages will be a blocker for crawlers on their "first visit" since they generate a static HTML with no potential SEO content or they will somehow pass the crawl and can produce correct data for the SEO? It potentially related to OG preview generation and indexing.

What happens from the SEO point when we haven't rendered SSG page yet? How do the not-pre-renreded pages behave for SEO?

[rafaelalmeidatk]

Google's crawlers will run JS in the client so the fallbacks won't negatively affect your SEO performance, for others crawlers you can read Joe's response here: #11552 (reply in thread)

[arunoda]

@Timer is possible to mark this question as Unanswered.
Because, this is an incorrect answer.

Even though Google can read JS (it's a question, it does that for every page), in the case of fallback, it cannot render the page correctly.

In the case of fallback, we are making an HTTP request to get the payload and render the page on the client-side.
I don't think that inside a Google crawler. I didn't check lately, but it didn't work a few years ago.

I also think, selectively blocking fallback is a bad thing.
Let us choose whether we need a blocking fallback or not for a given page.

Is this feature on the roadmap, any PRs?
If not, I can help.

[timneutkens]

In the case of fallback, we are making an HTTP request to get the payload and render the page on the client-side.
I don't think that inside a Google crawler. I didn't check lately, but it didn't work a few years ago.

This works fine, their crawler got significantly more advanced the last year. It also runs the JS indexing significantly faster (few seconds after the http crawl instead of 2 weeks).

Let us choose whether we need a blocking fallback or not for a given page.

We're planning to add a fallback: 'block' option that would have the blocking behavior. Though it's a trade-off as you lose reliably sending a fast response to users around the world

[arunoda]

@timneutkens cool.

We're planning to add a fallback: 'block' option that would have the blocking behavior. Though it's a trade-off as you lose reliably sending a fast response to users around the world

But this only needed for the first request, right?
After the first render, we can use existing SWR behavior.

[timneutkens]

But this only needed for the first request, right?

Correct

[arunoda]

Thanks @timneutkens

[revskill10]

I have a demo for your purpose here
I use a SSR version as fallback. The drawback is that, because we're using now, we have no way to write to the cache at runtime when user first visit a non-static page.
But if you're trying to deploy to your own server, it's possible to do that.

So, when user first visit a non-static page, you will write the page into cache (public path is /static to be served from nginx).

My now.json is like this

{
  "builds": [
    {
      "src": "node/serverless.js",
      "use": "@now/node",
      "config": {
        "includeFiles": [
          "node/*.json",
          "node/*.js"
        ]
      }
    }, {
      "src": "web/**/*",
      "use": "@now/static"
    }
  ],
  "routes": [
    { "src": "/", "dest": "web/www/index.html" },
    { "src": "/about/wartortle'", "dest": "web/www/about/wartortle.html", "continue": false },
    { "src": "^/static/(.+)", "dest": "web/$1" },
    { "src": "^/(.*)", "dest": "node/serverless.js"}
  ]
}

Notice the /about/wartortle route, it's a static page !
Hope this will answer your question about this issue.
I hope in future now will allow us to control the writable storage system from static build to achive the above result.