Search engine visibility

[mcrider]

Simpla looks amazing, but from what I gather, content is injected into the page via JS so it would not be visible to web crawlers. Do you guys have a solution for this? Would you have to do the usual hash fragment trick?

[bedeoverend]

@mcrider so given the popularity of SPA and JS heavy sites, web crawlers will render DOM and run JS on a page, allowing dynamic content to be loaded and indexed. This article goes into a lot of detail on it, but tl;dr it's a good test showing Google supports dynamic content.

Does that address your concerns? Obviously SEO is a big concern for people and we want to make sure we get it right :)

[mcrider]

That hasn't been my experience with SPA apps, at least how i've built them. My first test case was with an angular app about a year ago and their SEO was really bad when I launched it; I integrated seo4ajax and their search rankings went way way up -- this is why services like seo4ajax exist. But i'm not an expert on this, so maybe what Simpla does would be more google-friendly.

It'd be really cool to see Simpla integrated into a build/deploy phase so whats on your API could be output into static HTML.

[Patrick-DE]

I don' t like to argue with anyone but google does render my site as followed (rendered via search console): https://i.imgur.com/Ar7jtFY.png So it looks like it's not rendering properly.

[bedeoverend]

@mcrider we've had some thoughts around integrating a build step - our concern is that it could possibly enforce people to have a particular backend setup, however if it was an optional community tool, that could be more appropriate. Will keep you posted though!

@Patrick-DE thanks for flagging that - I'll do some digging into what's going on and get back to you on why it's not rendering.

[madeleineostoja]

I'd hazard a guess that this is a timing issue, which is why it's intermittently bugging out. As @bedeoverend and @mcrider touched on, there are two things we need to do to properly solve this:

1) Eager-load content into Simpla elements on paint, before anything else (right now editing logic/UI is loaded even if just viewing). This should fix this issue in most cases and give a good perf boost.

2) Support pre-rendering with an NPM module that uses the logic of simpla-block to inject static content from Simpla's API into elements on the backend. We would leave this framework/buildstep agnostic and leave it to the dev to mix it in on their own, or just run on the CLI.

[idris]

Would love to see an API to get content server-side. Doesn't even need to be a node_module, just expose a public API.

I'd be happy to build an npm package for it if you open up the API.

[madeleineostoja]

@idris a server-side SDK, and opening up the RESTful interface generally, is definitely on the cards - we just need to clean up our endpoints and finalise a few design decisions before making everything public.

Will let you know as soon as the API is public, would love your help in putting together an npm module for it.

[bedeoverend]

We've done more testing on this and it seems simpla-text is the main issue here i.e. it's not Simpla itself. Looks like simpla-text's long boot time is causing blocking issues and the crawler fails.

We're working on refactoring simpla-text (see this issue) and the change of editing engine and splitting editing from viewing logic should significantly reduce that boot time, which will help crawlers index the site.

We've also got a bunch of refactors underway including our new SDK and new implementations of simpla-block which will help resolve this too.

[madeleineostoja]

Simpla 2 has just been released (along with simpla-text v1 and simpla-img v1), which drastically improves perf and should fix this issue in almost all cases.

Closing this issue, and have opened another to track progress of SSR at #66