Обсуждение: Get rid of /static/ in doc urls?
Hi, For reasons I can't quite understand the /static/ in the docs URL bugs me, now that we don't have /interactive/ anymore. Could we just shorten that out of the URL? The redirects shouldn't be problematic... I think as long as we issue the right redirects, search engines shouldn't be troubled by this, but my knowledge about this kind of stuff is severely outdated. Greetings, Andres Freund
On 10/19/18 6:26 PM, Andres Freund wrote: > Hi, > > For reasons I can't quite understand the /static/ in the docs URL bugs > me, now that we don't have /interactive/ anymore. Could we just shorten > that out of the URL? The redirects shouldn't be problematic... > Yeah, that makes a lot of sense. > I think as long as we issue the right redirects, search engines > shouldn't be troubled by this, but my knowledge about this kind of stuff > is severely outdated. > We would need permanent redirects, but those are not hard to set up, especially in Django (or at the webserver level if we wanted to be super efficient). AFAIK this should be fairly trivial (and a good idea to do) so I'd +1 the change. I think, again, it's a matter if we want to apply it at the Django or webserver level. Jonathan
Вложения
Greetings, * Jonathan S. Katz (jkatz@postgresql.org) wrote: > On 10/19/18 6:26 PM, Andres Freund wrote: > > For reasons I can't quite understand the /static/ in the docs URL bugs > > me, now that we don't have /interactive/ anymore. Could we just shorten > > that out of the URL? The redirects shouldn't be problematic... > > Yeah, that makes a lot of sense. I tend to agree. > > I think as long as we issue the right redirects, search engines > > shouldn't be troubled by this, but my knowledge about this kind of stuff > > is severely outdated. > > We would need permanent redirects, but those are not hard to set up, > especially in Django (or at the webserver level if we wanted to be super > efficient). Sure, could be done either way. > AFAIK this should be fairly trivial (and a good idea to do) so I'd +1 > the change. I think, again, it's a matter if we want to apply it at the > Django or webserver level. The one thing I wonder about is- didn't someone say at one point that shorter urls are preferred by search engines, and if we made the 'current' doc link shorter than the per-version doc links that it'd be much more likely to show up higher in search results (which we would generally prefer)..? Presuming that is the case, maybe we get rid of /static/ but add something in for the per-version urls to make them longer than 'current'? Or, if that's all wrong, that's fine too. :) Thanks! Stephen
Вложения
> On Oct 19, 2018, at 8:32 PM, Stephen Frost <sfrost@snowman.net> wrote: > > Greetings, > > * Jonathan S. Katz (jkatz@postgresql.org) wrote: >>> On 10/19/18 6:26 PM, Andres Freund wrote: >>> For reasons I can't quite understand the /static/ in the docs URL bugs >>> me, now that we don't have /interactive/ anymore. Could we just shorten >>> that out of the URL? The redirects shouldn't be problematic... >> >> Yeah, that makes a lot of sense. > > I tend to agree. > >>> I think as long as we issue the right redirects, search engines >>> shouldn't be troubled by this, but my knowledge about this kind of stuff >>> is severely outdated. >> >> We would need permanent redirects, but those are not hard to set up, >> especially in Django (or at the webserver level if we wanted to be super >> efficient). > > Sure, could be done either way. > >> AFAIK this should be fairly trivial (and a good idea to do) so I'd +1 >> the change. I think, again, it's a matter if we want to apply it at the >> Django or webserver level. > > The one thing I wonder about is- didn't someone say at one point that > shorter urls are preferred by search engines, and if we made the > 'current' doc link shorter than the per-version doc links that it'd be > much more likely to show up higher in search results (which we would > generally prefer)..? > > Presuming that is the case, maybe we get rid of /static/ but add > something in for the per-version urls to make them longer than > 'current'? > > Or, if that's all wrong, that's fine too. :) In some odd-list discussions, we’ve discussed reaching out to some other OSS communities to see how they handle multiple versions of documentation wrt search engines. I’d rather we follow through on that part first instead of continually guessing what will make sense. FWIW (and ignoring my own advice) a lot of SEO is done on URLs with the “slug” names, so I don’t think too much weight is placed in length until it’s over a “large” amount. Additionally, the content earlier in the URL is more important anyway, so just having less should be more. Jonathan > > Thanks! > > Stephen
> On 20 Oct 2018, at 02:32, Stephen Frost <sfrost@snowman.net> wrote: > The one thing I wonder about is- didn't someone say at one point that > shorter urls are preferred by search engines, and if we made the > 'current' doc link shorter than the per-version doc links that it'd be > much more likely to show up higher in search results (which we would > generally prefer)..? I’ve never seen URL length matter, and especially not in the short lengths we have with/without static. The SEO wizards we had at $work were only interested in URLs that conveyed meaning, which ours do quite well (especially if we lose /static). My bigger concern is the duplicate content we have with /docs/current/ and /docs/11/, and in general for doc pages not changed in a release. We clearly saw SEO punishment in similar situations, with Google more or less picking one at random to index and rating the other much lower. The common solution is setting canonical URLs but that doesn’t apply to us. cheers ./daniel
Hi, On 2018-10-20 15:03:40 -0400, Jonathan S. Katz wrote: > > > On Oct 19, 2018, at 8:32 PM, Stephen Frost <sfrost@snowman.net> wrote: > > > > Greetings, > > > > * Jonathan S. Katz (jkatz@postgresql.org) wrote: > >>> On 10/19/18 6:26 PM, Andres Freund wrote: > >>> For reasons I can't quite understand the /static/ in the docs URL bugs > >>> me, now that we don't have /interactive/ anymore. Could we just shorten > >>> that out of the URL? The redirects shouldn't be problematic... > >> > >> Yeah, that makes a lot of sense. > > > > I tend to agree. > > > >>> I think as long as we issue the right redirects, search engines > >>> shouldn't be troubled by this, but my knowledge about this kind of stuff > >>> is severely outdated. > >> > >> We would need permanent redirects, but those are not hard to set up, > >> especially in Django (or at the webserver level if we wanted to be super > >> efficient). > > > > Sure, could be done either way. > > > >> AFAIK this should be fairly trivial (and a good idea to do) so I'd +1 > >> the change. I think, again, it's a matter if we want to apply it at the > >> Django or webserver level. > > > > The one thing I wonder about is- didn't someone say at one point that > > shorter urls are preferred by search engines, and if we made the > > 'current' doc link shorter than the per-version doc links that it'd be > > much more likely to show up higher in search results (which we would > > generally prefer)..? > > > > Presuming that is the case, maybe we get rid of /static/ but add > > something in for the per-version urls to make them longer than > > 'current'? > > > > Or, if that's all wrong, that's fine too. :) > > In some odd-list discussions, we’ve discussed reaching out to some other OSS communities > to see how they handle multiple versions of documentation wrt search engines. I’d rather > we follow through on that part first instead of > continually guessing what will make sense. > > FWIW (and ignoring my own advice) a lot of SEO is done on URLs with the “slug” names, so I > don’t think too much weight is placed in length until it’s over a “large” amount. Additionally, > the content earlier in the URL is more important anyway, so just having less should be more. Isn't the "multiple versions vs search engines" discussion relatively independent from removing /static/? Greetings, Andres Freund
On 10/22/18 7:00 PM, Andres Freund wrote: > Hi, > > On 2018-10-20 15:03:40 -0400, Jonathan S. Katz wrote: >> >>> On Oct 19, 2018, at 8:32 PM, Stephen Frost <sfrost@snowman.net> wrote: >>> The one thing I wonder about is- didn't someone say at one point that >>> shorter urls are preferred by search engines, and if we made the >>> 'current' doc link shorter than the per-version doc links that it'd be >>> much more likely to show up higher in search results (which we would >>> generally prefer)..? >>> >>> Presuming that is the case, maybe we get rid of /static/ but add >>> something in for the per-version urls to make them longer than >>> 'current'? >>> >>> Or, if that's all wrong, that's fine too. :) >> >> In some odd-list discussions, we’ve discussed reaching out to some other OSS communities >> to see how they handle multiple versions of documentation wrt search engines. I’d rather >> we follow through on that part first instead of >> continually guessing what will make sense. >> >> FWIW (and ignoring my own advice) a lot of SEO is done on URLs with the “slug” names, so I >> don’t think too much weight is placed in length until it’s over a “large” amount. Additionally, >> the content earlier in the URL is more important anyway, so just having less should be more. > > Isn't the "multiple versions vs search engines" discussion relatively > independent from removing /static/? > Not from an SEO standpoint, which is what Stephen had brought up above. It's all interrelated. However, I think we can move on the removing `/static/` more quickly, we just need to pick a method. I could at least put together a pgweb patch to show what it would look like from that approach. Jonathan
Вложения
On 10/19/18 6:30 PM, Jonathan S. Katz wrote: > On 10/19/18 6:26 PM, Andres Freund wrote: >> Hi, >> >> For reasons I can't quite understand the /static/ in the docs URL bugs >> me, now that we don't have /interactive/ anymore. Could we just shorten >> that out of the URL? The redirects shouldn't be problematic... >> > > Yeah, that makes a lot of sense. > >> I think as long as we issue the right redirects, search engines >> shouldn't be troubled by this, but my knowledge about this kind of stuff >> is severely outdated. >> > > We would need permanent redirects, but those are not hard to set up, > especially in Django (or at the webserver level if we wanted to be super > efficient). > > AFAIK this should be fairly trivial (and a good idea to do) so I'd +1 > the change. I think, again, it's a matter if we want to apply it at the > Django or webserver level. Attached are a series of patches that accomplishes safely removing `/static/` in the doc URLs. The first patch does exactly that: whenever someone tries to browse to a docs URL, e.g. "/docs/current/static/index.html" it will permanently redirect the user to "/docs/current/index.html" The second patch updates all the references on the site to use the new format. The pith of it is in the presskits; I did opt to update those as the less references we have to the old URL scheme, the better. Contrary to some earlier comments about handling this in varnish, etc. after reviewing some of the logic surrounding the docs, it is better we handle this on the Django level. Please let me know what you think. Thanks, Jonathan
Вложения
On Sun, Nov 4, 2018 at 5:38 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 10/19/18 6:30 PM, Jonathan S. Katz wrote:
> On 10/19/18 6:26 PM, Andres Freund wrote:
>> Hi,
>>
>> For reasons I can't quite understand the /static/ in the docs URL bugs
>> me, now that we don't have /interactive/ anymore. Could we just shorten
>> that out of the URL? The redirects shouldn't be problematic...
>>
>
> Yeah, that makes a lot of sense.
>
>> I think as long as we issue the right redirects, search engines
>> shouldn't be troubled by this, but my knowledge about this kind of stuff
>> is severely outdated.
>>
>
> We would need permanent redirects, but those are not hard to set up,
> especially in Django (or at the webserver level if we wanted to be super
> efficient).
>
> AFAIK this should be fairly trivial (and a good idea to do) so I'd +1
> the change. I think, again, it's a matter if we want to apply it at the
> Django or webserver level.
Attached are a series of patches that accomplishes safely removing
`/static/` in the doc URLs.
The first patch does exactly that: whenever someone tries to browse to a
docs URL, e.g. "/docs/current/static/index.html" it will permanently
redirect the user to "/docs/current/index.html"
One of the redirects is set as permanent and the other one non-permanent. Granted it's just a change of a previous redirect, but is there any reason to have different kinds of redirect e.g. for root page vs other pages?
The second patch updates all the references on the site to use the new
format. The pith of it is in the presskits; I did opt to update those as
the less references we have to the old URL scheme, the better.
I notice there are still some references to /interactive/ in old presskits. I suggest fixing that at the same time.
Contrary to some earlier comments about handling this in varnish, etc.
after reviewing some of the logic surrounding the docs, it is better we
handle this on the Django level.
We may want to put a shortcut in at the varnish level as well, but I definitely think it needs to be handled at the django level as well - at least. We can decide later if just the django level is enough.
On 11/5/18 7:43 AM, Magnus Hagander wrote:
>
>
> On Sun, Nov 4, 2018 at 5:38 PM Jonathan S. Katz <jkatz@postgresql.org
> <mailto:jkatz@postgresql.org>> wrote:
>
> On 10/19/18 6:30 PM, Jonathan S. Katz wrote:
> > On 10/19/18 6:26 PM, Andres Freund wrote:
> >> Hi,
> >>
> >> For reasons I can't quite understand the /static/ in the docs URL
> bugs
> >> me, now that we don't have /interactive/ anymore. Could we just
> shorten
> >> that out of the URL? The redirects shouldn't be problematic...
> >>
> >
> > Yeah, that makes a lot of sense.
> >
> >> I think as long as we issue the right redirects, search engines
> >> shouldn't be troubled by this, but my knowledge about this kind
> of stuff
> >> is severely outdated.
> >>
> >
> > We would need permanent redirects, but those are not hard to set up,
> > especially in Django (or at the webserver level if we wanted to be
> super
> > efficient).
> >
> > AFAIK this should be fairly trivial (and a good idea to do) so I'd +1
> > the change. I think, again, it's a matter if we want to apply it
> at the
> > Django or webserver level.
>
> Attached are a series of patches that accomplishes safely removing
> `/static/` in the doc URLs.
>
> The first patch does exactly that: whenever someone tries to browse to a
> docs URL, e.g. "/docs/current/static/index.html" it will permanently
> redirect the user to "/docs/current/index.html"
>
>
> One of the redirects is set as permanent and the other one
> non-permanent. Granted it's just a change of a previous redirect, but is
> there any reason to have different kinds of redirect e.g. for root page
> vs other pages?
I think given the nature of the change, it could be a permanent
redirect. I've adjusted this in the code and reattached.
One could also argue that the temp redirect triggered by this line:
if ver >= 10 and version.find('.') > -1:
# Version 10 and up, but specified as 10.0 / 11.0 etc, so redirect
back without the
# decimal.
return HttpResponseRedirect("/docs/{0}/{1}.html".format(int(ver),
filename))
could be made a permanent redirect too, given the change of the number
scheme. Thoughts?
>
> The second patch updates all the references on the site to use the new
> format. The pith of it is in the presskits; I did opt to update those as
> the less references we have to the old URL scheme, the better.
>
>
> I notice there are still some references to /interactive/ in old
> presskits. I suggest fixing that at the same time.
Yeah...wow. And some where there up until 9.6 too. I also caught a few
more statics in the process. Attached.
> Contrary to some earlier comments about handling this in varnish, etc.
> after reviewing some of the logic surrounding the docs, it is better we
> handle this on the Django level.
>
>
> We may want to put a shortcut in at the varnish level as well, but I
> definitely think it needs to be handled at the django level as well - at
> least. We can decide later if just the django level is enough.
>
+1.
Jonathan
Вложения
On Mon, Nov 5, 2018 at 3:13 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 11/5/18 7:43 AM, Magnus Hagander wrote:
>
>
> On Sun, Nov 4, 2018 at 5:38 PM Jonathan S. Katz <jkatz@postgresql.org
> <mailto:jkatz@postgresql.org>> wrote:
>
> On 10/19/18 6:30 PM, Jonathan S. Katz wrote:
> > On 10/19/18 6:26 PM, Andres Freund wrote:
> >> Hi,
> >>
> >> For reasons I can't quite understand the /static/ in the docs URL
> bugs
> >> me, now that we don't have /interactive/ anymore. Could we just
> shorten
> >> that out of the URL? The redirects shouldn't be problematic...
> >>
> >
> > Yeah, that makes a lot of sense.
> >
> >> I think as long as we issue the right redirects, search engines
> >> shouldn't be troubled by this, but my knowledge about this kind
> of stuff
> >> is severely outdated.
> >>
> >
> > We would need permanent redirects, but those are not hard to set up,
> > especially in Django (or at the webserver level if we wanted to be
> super
> > efficient).
> >
> > AFAIK this should be fairly trivial (and a good idea to do) so I'd +1
> > the change. I think, again, it's a matter if we want to apply it
> at the
> > Django or webserver level.
>
> Attached are a series of patches that accomplishes safely removing
> `/static/` in the doc URLs.
>
> The first patch does exactly that: whenever someone tries to browse to a
> docs URL, e.g. "/docs/current/static/index.html" it will permanently
> redirect the user to "/docs/current/index.html"
>
>
> One of the redirects is set as permanent and the other one
> non-permanent. Granted it's just a change of a previous redirect, but is
> there any reason to have different kinds of redirect e.g. for root page
> vs other pages?
I think given the nature of the change, it could be a permanent
redirect. I've adjusted this in the code and reattached.
One could also argue that the temp redirect triggered by this line:
if ver >= 10 and version.find('.') > -1:
# Version 10 and up, but specified as 10.0 / 11.0 etc, so redirect
back without the
# decimal.
return HttpResponseRedirect("/docs/{0}/{1}.html".format(int(ver),
filename))
could be made a permanent redirect too, given the change of the number
scheme. Thoughts?
Yes, I think it should be. Also makes it consistent.
With that change as well, lgtm.
> The second patch updates all the references on the site to use the new
> format. The pith of it is in the presskits; I did opt to update those as
> the less references we have to the old URL scheme, the better.
>
>
> I notice there are still some references to /interactive/ in old
> presskits. I suggest fixing that at the same time.
Yeah...wow. And some where there up until 9.6 too. I also caught a few
more statics in the process. Attached.
:)
Haven't reviewed in detail, but I'm sure this part is OK.
On 11/5/18 9:31 AM, Magnus Hagander wrote: > > Yes, I think it should be. Also makes it consistent. > > With that change as well, lgtm. Per that change and some brief off-list discussion, this has been pushed. Andres: thanks again for proposing Welcome to the new era of doc urls. Jonathan
Вложения
On 2018-11-05 10:37:37 -0500, Jonathan S. Katz wrote: > On 11/5/18 9:31 AM, Magnus Hagander wrote: > > > > Yes, I think it should be. Also makes it consistent. > > > > With that change as well, lgtm. > > Per that change and some brief off-list discussion, this has been pushed. > > Andres: thanks again for proposing > > Welcome to the new era of doc urls. Thanks a lot! Greetings, Andres Freund