LibreOffice help online pages, and SEO

[mikesaunders]

Hello everyone,

One thing I noticed today: I put "LibreOffice export PDF" into Google
and the first result was this page:

https://help.libreoffice.org/Common/Export_as_PDF

However, it's the older design, with a red warning. The new design is
way better (and thanks to everyone who worked on it!):

https://help.libreoffice.org/6.3/en-GB/text/shared/01/ref_pdf_export.html

I'm wondering if there's anything we can do to get the new design higher
on Google. Has anyone looked into SEO / redirects or anything like that?
Otherwise, I can investigate at some point...

[wget]

Hi Mike,

I'm wondering if there's anything we can do to get the new design higher
on Google. Has anyone looked into SEO / redirects or anything like that?
Otherwise, I can investigate at some point...

With the current help system, this would be hard to do in my guess.

The meta info are missing and the current process when releasing
documentation is not generating these needed pieces of info. + OpenGraph
and Twitter Cards are missing as well.

The URL rewriting could be improved as well. i.e. from a SEO point of view:
https://help.libreoffice.org/latest/en-US/text/shared/05/new_help.html?&DbPAR=WRITER&System=UNIX
is hard to guess from a robot and the latter prefers something like this:
https://docs.libreoffice.org/en-US/common/newhelp
It's sad to say this but the new doc system from MSFT
(docs.microsoft.com) could be a great inspiration here wrt. URL naming
e.g. [1]

The old help system based on MediaWiki is more SEO friendly because
Google (and other search engines) knows how to index MediaWiki-based
websites.

The best bet like discussed a bit with Olivier a few weeks ago on the
LibreOfficeFR Telegram account would be to use another help system,
relying on well established system rather than creating our very own. In
2019, all the organizations I'm participating in are using ReadTheDocs
for a reason

But this needs to be analyzed from a programmatic point of view. From my
understanding BoD is quite reluctant (and it's understandable!) because
any other system than what we currently have is not well integrated into
LibreOffice; i.e. the system linking the GUI to the help system needs to
be made hard solid first before proposing another solution.

As TDF is a meritocratic system, this could be a nice subject for a
hackathon (the FOSDEM hackfest?)

Regards,

[1]
https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-how-it-works

[ilmari]

William Gathoye (LibreOffice) kirjoitti 5.12.2019 klo 18.53:

I'm wondering if there's anything we can do to get the new design higher
on Google. Has anyone looked into SEO / redirects or anything like that?
Otherwise, I can investigate at some point...

With the current help system, this would be hard to do in my guess.

The meta info are missing and the current process when releasing
documentation is not generating these needed pieces of info. + OpenGraph
and Twitter Cards are missing as well.

The URL rewriting could be improved as well. i.e. from a SEO point of view:
https://help.libreoffice.org/latest/en-US/text/shared/05/new_help.html?&DbPAR=WRITER&System=UNIX
is hard to guess from a robot and the latter prefers something like this:
https://docs.libreoffice.org/en-US/common/newhelp
It's sad to say this but the new doc system from MSFT
(docs.microsoft.com) could be a great inspiration here wrt. URL naming
e.g. [1]

I think this is a non-issue, if we autogenerate a sitemap and point Google to it. I have no idea, if this is the case currently.

The best bet like discussed a bit with Olivier a few weeks ago on the
LibreOfficeFR Telegram account would be to use another help system,
relying on well established system rather than creating our very own. In
2019, all the organizations I'm participating in are using ReadTheDocs
for a reason

Read the Docs is a presentation system for reStructuredText documents. This implies two separate questions:
1) which markup language should we migrate to from XHP?
2) how should we present the documents?

I don't see a need for change regarding point 2 no matter the markup source. The HTML target can remain the same.

I bet the organisations you refer to are using Read the Docs for technical documentation as is the common case (programmers, sysadmins etc.). I don't remember off-hand it being used for end user facing documentation.

The Read the Docs theme would be great for our API docs and I once experimented in converting our Doxygen docs to rST. I don't think it is a good fit for our Help content.

Ilmari