New proposal for a set of links on the front page Lassi Kortela (28 Dec 2020 14:31 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (28 Dec 2020 16:25 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (28 Dec 2020 17:01 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (28 Dec 2020 18:06 UTC)
Re: New proposal for a set of links on the front page Jakub T. Jankiewicz (28 Dec 2020 19:19 UTC)
Re: New proposal for a set of links on the front page Marc Feeley (28 Dec 2020 22:05 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (28 Dec 2020 22:49 UTC)
Re: New proposal for a set of links on the front page Jakub T. Jankiewicz (29 Dec 2020 08:42 UTC)
Details on privacy and tracking Lassi Kortela (29 Dec 2020 11:41 UTC)
Re: Details on privacy and tracking Lassi Kortela (29 Dec 2020 11:43 UTC)
Re: Details on privacy and tracking Jakub T. Jankiewicz (29 Dec 2020 12:49 UTC)
Re: Details on privacy and tracking Lassi Kortela (29 Dec 2020 13:06 UTC)
Re: Details on privacy and tracking Jakub T. Jankiewicz (29 Dec 2020 16:15 UTC)
Re: Details on privacy and tracking Lassi Kortela (29 Dec 2020 16:40 UTC)
Gambit and other JavaScript Schemes Lassi Kortela (29 Dec 2020 12:11 UTC)
Re: Gambit and other JavaScript Schemes Lassi Kortela (29 Dec 2020 12:17 UTC)
Re: Gambit and other JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 12:55 UTC)
Re: Gambit and other JavaScript Schemes Lassi Kortela (29 Dec 2020 13:14 UTC)
Re: New proposal for a set of links on the front page Marc Feeley (29 Dec 2020 14:38 UTC)
Aspects of JavaScript Schemes Lassi Kortela (29 Dec 2020 14:55 UTC)
Re: Aspects of JavaScript Schemes Marc Feeley (29 Dec 2020 15:11 UTC)
Re: Aspects of JavaScript Schemes Lassi Kortela (29 Dec 2020 15:27 UTC)
Re: Aspects of JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 16:54 UTC)
Re: Aspects of JavaScript Schemes Marc Feeley (29 Dec 2020 21:35 UTC)
Re: Aspects of JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 22:33 UTC)
Re: Aspects of JavaScript Schemes Jakub T. Jankiewicz (29 Dec 2020 16:36 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (29 Dec 2020 15:04 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (29 Dec 2020 16:19 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (29 Dec 2020 16:30 UTC)
Re: New proposal for a set of links on the front page Arthur A. Gleckler (29 Dec 2020 16:38 UTC)
Re: New proposal for a set of links on the front page Lassi Kortela (29 Dec 2020 16:46 UTC)
lips.scheme.org implementation subdomain Lassi Kortela (28 Dec 2020 22:28 UTC)
Re: lips.scheme.org implementation subdomain Jakub T. Jankiewicz (29 Dec 2020 08:04 UTC)
Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 12:35 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 12:43 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 13:20 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 13:45 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 17:13 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 17:43 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 18:34 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 18:46 UTC)
Re: Hosting and SEO for Scheme implementations Arthur A. Gleckler (29 Dec 2020 16:28 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 16:35 UTC)
Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz (29 Dec 2020 17:21 UTC)
Re: Hosting and SEO for Scheme implementations Lassi Kortela (29 Dec 2020 18:15 UTC)
Re: New proposal for a set of links on the front page Jakub T. Jankiewicz (29 Dec 2020 20:05 UTC)
Scheme tutorials Lassi Kortela (29 Dec 2020 20:16 UTC)
Re: Scheme tutorials Jakub T. Jankiewicz (29 Dec 2020 21:44 UTC)

Re: Hosting and SEO for Scheme implementations Jakub T. Jankiewicz 29 Dec 2020 13:20 UTC


On Tue, 29 Dec 2020 14:34:52 +0200
Lassi Kortela <xxxxxx@lassi.io> wrote:

> > If I would need to setup server then it's useless to me, I wanted
> > something that would not require to pay for anything, so the service will
> > not be lost after my death. I wanted something that will still exists
> > after I'm dead.
>
> We should think about offering hosting to Scheme implementations. Most
> implementations' sites are reasonably low-traffic and lightweight, so a
> cheap server with nginx could probably handle many sites.
>
> We currently have only one server (one of the cheapest reputable
> commercial VPS). It currently only hosts "community" sites (i.e. sites
> that volunteers are making to cover all of Scheme, not just one
> implementation).
>
> Arthur, do you think we could we add implementation sites to that server
> or is there a point to separating implementation sites to their own servers?
>
> I think the charter of Scheme.org doesn't need to say how the servers
> are handled, but in practice, it would be good to think of a clear policy.
>
> Would implementers trust having their sites on the same server as
> community sites?

It would be awesome if lips could be hosted on your sever, but nice thing
about GitHub pages is that I've got Jekyll build on each commit for free. In
order to connect git repo on GitHub with your server I would probably need
something more then just static hosting. I can check if I can use GitHub
actions to just upload static files to different server and build the files
using GitHub actions. I would need SSH access probably, but simple ftp would
also probably be fine. But I'm not 100% sure if simple hosting would work with
GitHub actions, since I recently watched video about GitHub actions and the
guy used VPS with root access to set this up.

One note: I have tracking on lips.js.org right now, it use my private instance
of Piwik (Matomo) but I don't use the data in any way, I just visit from time
to time dashboard and see how many visitors I've got, that + Google Webmaster
tools help be improve the SEO of the site.

With my Piwk I can enable every possible privacy option, so it make sure that
it don't store any sensitive data.

Maybe I will switch to something lighter since Piwik is very heavy and
sometimes overload my cheap shared hosting with too many php processes.

>
> > I think that simple redirect is fine then, the problem with domain is that
> > the only useful if it stick to the address. Right now those two
> > implementation are kind of use useless (the domain names). If you just
> > want to have same link to that implementation then setup l.scheme.org
> > with url shortener would provide the same benefot.
>
> The point of having a subdomain for everything is on the one hand to
> make Scheme.org more consistent for users and admins, and on the other
> hand to entice implementations to have a presence under Scheme.org, even
> if it's just a name (subdomain with redirect).
>
> Making a subdomain is a small hassle to implementers, and having a
> simple link to an external site would be easier. My personal opinion is
> that we should think of Scheme.org like a long-term investment, that
> cannot succeed if we don't get people at least a little bit invested in
> it as a community. There should be at least a little give-and-take, and
> adding a subdomain is pretty minimal as far as investments go. This
> opinion may be somewhat unpopular, especially since it makes more work
> in the short term, but it seems to me like it would make sense
> long-term. What do you think?
>
> > The only benefit I see for domain is SEO and that it looks nice. But just
> > redirect is kind of pointless.
> >
> > But if you decide that this is how all implementations will work then I'm
> > fine with just redirect. But you need to know that it's good only for
> > scheme.org to organize the structure it probably will of no use for the
> > implementer, because he will not get even a link to his site so it will
> > not benefit SEO at all.
>
> Thanks. This is very good advice. So search engines consider only the
> target address of the redirect, not the source address.

I'm not exactly sure how this works with redirect that you have, that is more
on DNS side. But with normal 301 redirect it's recommended to use it because
when you change the domain and old one is indexed in Google, new one will get
the same ranking, you just move the ranking from old to new domain. Even when
there are links pointing to old domain. Also giving new domain that is not
indexed redirect to old domain that is indexed is kind of pointless in SEO
perspective. The new domain that is redirect, will probably never got indexed
by Google.

My domain js.org is pretty new, I only have few links and I can change
everything, also I'm in process of creating new website, so it would be great
if new website have new domain. and domain will have name of the language
which is keyword that people search using so it would be great.

One problem with js.org is that I will need to manually change all the links
that I've added, to have any links to new site because js.org don't offerer
redirect so I will need to setup a site that would have a link to new website.

--
Jakub T. Jankiewicz, Web Developer
https://jcubic.pl/me