Bad order of Postgres links in Google search results and how to fix it

From: Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
To: PostgreSQL www <pgsql-www(at)postgresql(dot)org>
Subject: Bad order of Postgres links in Google search results and how to fix it
Date: 2018-06-22 21:09:32
Message-ID: CANNMO++kxJmaaB7X6hq_8SqcEruySZrF=UkcPm-EG1JCKVascw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

Hi,

It is very annoying that it most cases, Google search engine result page
(SERP) orders links to Postgres documentation so that older versions go
first and sometimes the most up-to-date version is not even listed on the
1st page.

For instance, if I try to google "postgresql string functions"
<https://www.google.com/search?q=postgresql+string+functions> (in Chrome's
incognito mode to have less bias; try it yourself but keep in mind that
results may vary depending on your region, settings and search history) it
currently shows me links in the following order:

1. https://www.postgresql.org/docs/9.1/static/functions-string.html
2. https://www.postgresql.org/docs/9.6/static/functions-string.html
3. https://www.postgresql.org/docs/9.5/static/functions-string.html
4. https://www.postgresql.org/docs/8.1/static/functions-string.html
5. http://www.postgresqltutorial.com/postgresql-string-functions/

etc, and current (Postgres 10) documentation doesn't even present on the
1st page of SERP. (Well, it does, but only PostgresPro's Russian version
https://postgrespro.ru/docs/postgrespro/10/functions-string.html – and it's
not because I speak Russian – I by purpose didn't give Google any signs to
suspect that; I suspect it's because PostgresPro's page has better SEO
weight than corresponding official English page).

This is the very confusing situation – I hate clicking "latest" each time I
use Google to get some Postgres info, and, what is much, much worse, less
Postgres-experienced people even don't suspect that they work with very
outdated data (fresh example:
https://twitter.com/will_in_wi/status/1009813068346519552 – notice Postgres
version IN URL, it's 8.2, from 2007).

Here is a quick look at SEPRs of the query "XXX string functions" for other
open source database systems:

A. "mysql string functions"
<https://www.google.com/search?q=mysql+string+functions>

1. https://dev.mysql.com/doc/en/string-functions.html
2. https://dev.mysql.com/doc/refman/5.6/en/string-functions.html
3. https://dev.mysql.com/doc/refman/5.5/en/string-functions.html
4. https://www.w3schools.com/sql/sql_ref_mysql.asp
5. https://www.w3schools.com/sql/func_mysql_substring.asp

B. "mariadb string functions"
<https://www.google.com/search?q=mariadb+string+functions>

1. https://mariadb.com/kb/en/library/string-functions/
2. https://mariadb.com/kb/en/library/built-in-functions/
3. https://mariadb.com/kb/en/library/locate/
4. https://mariadb.com/kb/en/library/like/
5. https://www.techonthenet.com/mariadb/functions/position.php

C. "mongodb string functions"
<https://www.google.com/search?q=mongodb+string+functions>

1. https://docs.mongodb.com/manual/reference/method/db.collection.find/
2. https://docs.mongodb.com/manual/text-search/
3. https://docs.mongodb.com/manual/reference/operator/query/
4. https://docs.mongodb.com/manual/tutorial/query-documents/
5.
https://code.tutsplus.com/tutorials/full-text-search-in-mongodb--cms-24835

In all 3 cases, we observe that the 1st position is being held by a
version-free link, which is still relevant and shows information for the
current, most recent production-ready version (e.g., for MySQL it's 8.0 and
the links for previous versions – 5.6 and 5.5 – go, with version hard-coded
to the URL).

This is very convenient and the most user-friendly situation and I think
all Postgres user would benefit from it and the daily amount of confusion
in this world would be much less if we somehow influence on Google SEPR to
make it place results for the most recent and production-ready version to
the very top.

But how?

Postgres documentation has hardcoded links and the special link with
"current" word in URL (current main documentation page:
https://www.postgresql.org/docs/current/static/index.html). But why it
isn't being used by Google and as the main one? The reason is that
PostgreSQL website doesn't consider it as the main one. Any time I go to
https://postgresql.org/docs/ or https://www.postgresql.org/docs/ and try to
achieve any documentation page I don't get "current" word in URL – I need
to choose version myself, so I definitely get version in the URL.

This leads to the situation when people refer to documentation pages with
hardcoded version in URL, when they write articles, tweet or discuss
anything in social networks (what is very imporatnt for Google and ranking
of pages nowadays) or chats or forums.

What I propose:

===
1) On the main page (www.postgresql.org) refer to the current documentation
(URL = https://www.postgresql.org/docs/current/static/index.html) to allow
me to get there with just 1 click. This step will give great weight for
this page and spread good weight among deeper pages with "static" keyword
in URL. It will also – as well as the next steps in my proposal – encourage
people to use "current" URLs in their discussions/articles/posts everywhere.

2) Anywhere where the list of documentation versions is given, to the
"CURRENT" version to the top, emphasizing that this is the "main" one at
the moment, using the entry URL with "current" keyword and using exact
version only for displaying purposes, not in any URLs. Example:
https://www.postgresql.org/docs/manuals/ – the URL leading to the version
10 documentation should have "current", not "10"

3) On the page https://www.postgresql.org/docs/ allow users to get to the
"current" documentation as quickly as possible, without additional thinking
and clicking. Now I see the word "current", click it expecting to see the
documentation already but see the list of versions again because it leads
me to the mage https://www.postgresql.org/docs/manuals/. I would rephrase
it so the word "current" would have URL
https://www.postgresql.org/docs/current/static/index.html). In general, I
would redesign this page to make it more UX-friendly.

The current version of its main, central part:

This section contains current <https://www.postgresql.org/docs/manuals/>
and archived <https://www.postgresql.org/docs/manuals/archive/> manuals for
PostgreSQL users. You can read the release notes
<https://www.postgresql.org/docs/current/static/release.html>, and view a
listing of books <https://www.postgresql.org/docs/books/> written about
PostgreSQL.

I propose:

For each major PostgreSQL version, a separate version of manual exists:

- most recent production-ready version
<https://www.postgresql.org/docs/current/static/index.html> (10),
- the list of currently supported versions
<https://www.postgresql.org/docs/manuals/> (9.3 – 11 beta),
- archived <https://www.postgresql.org/docs/manuals/archive/> manuals
(6.3 – 9.2).

Also, you can:

- read the release notes
<https://www.postgresql.org/docs/current/static/release.html>,
- view a listing of books <https://www.postgresql.org/docs/books/> written
about PostgreSQL,
- work with PostgreSQL wiki. <https://wiki.postgresql.org/wiki/Main_Page>

4) Inside manuals, I would reverse the order of versions mentioned and
would make "current" upper case. Now it is:

This page in other versions: 9.3
<https://www.postgresql.org/docs/9.3/static/index.html> / 9.4
<https://www.postgresql.org/docs/9.4/static/index.html> / 9.5
<https://www.postgresql.org/docs/9.5/static/index.html> / *9.6* / current
<https://www.postgresql.org/docs/current/static/index.html> (10
<https://www.postgresql.org/docs/10/static/index.html>)

I propose:

This page in other versions: CURRENT
<https://www.postgresql.org/docs/current/static/index.html> (10
<https://www.postgresql.org/docs/10/static/index.html>) / *9.6* / 9.5
<https://www.postgresql.org/docs/9.5/static/index.html> / 9.4
<https://www.postgresql.org/docs/9.4/static/index.html> / 9.3
<https://www.postgresql.org/docs/9.3/static/index.html>

===

Once these steps are done, one cannot expect immediate results from Google.
Some time (months or, for some cases, even years) needs to be passed before
SEPRs for most popular queries will be properly reorganized.

I can try and make the corresponding patches myself once the consensus is
achieved here.

Nikolay

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Bruce Momjian 2018-06-23 03:01:53 Re: SCRAM with channel binding downgrade attack
Previous Message Raymond O'Donnell 2018-06-22 11:28:05 Re: typo "licence"