> 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