Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search Engine Optimization for Skosmos 3.0 #1533

Open
MikkoAleksanteri opened this issue Sep 28, 2023 · 5 comments
Open

Search Engine Optimization for Skosmos 3.0 #1533

MikkoAleksanteri opened this issue Sep 28, 2023 · 5 comments
Assignees
Milestone

Comments

@MikkoAleksanteri
Copy link
Contributor

MikkoAleksanteri commented Sep 28, 2023

Skosmos pages have generally pretty good visibilty on search engines. However, according to Finto.fi use statistics, the number of visit directly from search engine searches has decreased quite a bit in the past few years.

Now that the front end of Skosmos in getting a major overhaul with version 3.0, it might be a good idea to try to optimize the visibility of Skosmos pages to search engines.

The current (Skosmos 2.X) SEO methods include:

  • Skosmos presents a consistent URL space for each vocabulary (and all combinations of supported UI and content languages), where the vocabulary home page and individual concept pages have their own URLs and most of the page contents are rendered on the server side. This means that the vocabulary is presented as an easily crawlable space of interlinked HTML pages.
  • There is a little bit of metadata in the <head> section of each Skosmos generated page, e.g. generator: <meta name="generator" content="Skosmos 2.16" />
  • Skosmos installations such as Finto.fi typically include a simple robots.txt file which restricts access to some URL paths, although this is not a part of the Skosmos codebase but must be added locally.

Let’s use this issue to spec out the concrete measures needed for Skosmos 3.0 SEO.

For related issues see at least #583

@joelit joelit added this to the 3.0 milestone Oct 24, 2023
@miguelvaara
Copy link
Contributor

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

The title tag is a crucial element for SEO.

It tells search engines (and users) what the page is about. Include primary keyword or key phrase.

More info: https://seo.ai/blog/why-are-title-tag-and-h1-essential-for-seo

Meta Description

A good meta description can "lure" users to click on the link in search results. It should be concise, informative and appealing.

<head>
    <meta name="description" content="Concise, informative, and appealing description">
</head>

More about search terms in the meta description: https://yoast.com/meta-descriptions/

Sitemaps

A sitemap = XML file that lists all the URLs on the website

  • Make a list of all the pages on the website that are relevant to include in the sitemap
  • Use online sitemap generator tools
  • Example:
<url>
   <loc>https://www.example.com/page1</loc>
   <lastmod>2023-10-25</lastmod>
   <changefreq>weekly</changefreq>
   <priority>0.8</priority>
</url>
  • Manually upload the sitemap to the root directory of the website
  • Submit the sitemap to search engines

Read: https://www.semrush.com/blog/sitemap-examples/

In our case, a sitemap may not be a very effective approach due to the nature of our service. The relationships between pages are not structured based on the meaning of the content. If we choose to implement this, it is better to create a small, focused sitemap that includes only the most relevant parts.

robots.txt

It's also important to know how to limit search engine visibility

  • robots.txt is a text file that gives instructions to search engine crawlers about which pages or files they should not index.

Read: https://www.conductor.com/academy/robotstxt/

Heading Tags :

Search engines pay attention to headings to figure out the structure and content of a page.

  • Use relevant keywords in headings.
  • <h1> <h2> etc..

Tips: https://blog.hubspot.com/marketing/header-tags (In our case, headers are mostly determined by the terminology work conventions, so this is not the best way for us to improve SEO aspect)

Content:

The main body content of the page is important! Include target keywords and phrases and write informative content (from the viewers point of view).

  • In our case, we could focus on using "right" words in the metadata of the vocabularies (shown on the vocabulary's homepage)

Read: https://www.weebly.com/seo/content

Images:

  • images provide additional information/context for search engines.

Not relevant in our case. More: https://contentmarketinginstitute.com/articles/optimize-images-seo/

Internal Links:

Linking to relevant internal pages within the website helps search engines understand the relationships between different pages.

  • In our case, the links and relationships between pages are determined "differently" due to the nature of the vocabularies. There is not much we can do about this.

Read more: https://yoast.com/internal-linking-for-seo-why-and-how/

URL Structure:

Having clean, descriptive URLs makes it easier for search engines to understand the content of the page.

  • This is one important factor in SEO optimization, but our URLs do not contain any semantics, except for the short names of the vocabularies, so there is not much we can do about it.

More: https://www.searchenginejournal.com/technical-seo/url-structure/

@osma
Copy link
Member

osma commented Apr 18, 2024

Here is a current proposal on how to improve some aspects of SEO, in particular the title and description metadata in <head> that affects the display of search results in search engines. Heading structure in Skosmos 3 is already quite good thanks to the accessibility improvements.

We need several new config.ttl settings that control the title and description metadata. A multilingual value in this context means that there may be several literal values with different RDF language tags, one per UI language.

Global settings

  • skosmos:serviceName - a short service name such as "Finto"; already exists
  • skosmos:serviceNameLong - longer version of the above; multilingual value
  • skosmos:serviceDescription - value for the description metadata on the landing page; multilingual value
  • skosmos:feedbackDescription - value for the description metadata on the feedback page; multilingual value
  • skosmos:aboutDescription - value for the description metadata on the about page; multilingual value

Vocabulary-specific settings

  • dc:title - vocabulary name, long version, multilingual value; already exists
  • skosmos:shortName - vocabulary name, short version, multilingual value; already exists
  • dc:description - value for the description metadata on the vocabulary home page; multilingual value

Constructing title and description metadata for different page types

Landing page

  • title: value of skosmos:serviceNameLong setting in current UI language (e.g. "Finnish Ontology and Vocabulary Service Finto")
  • description: value of skosmos:serviceDescription setting in current UI language (e.g. "Interoperable vocabulary and ontology services for dataset indexing"); if this is not set, there will be no description metadata on the page

About page

  • title: "About - {skosmos:shortName}" e.g. "About - Finto" ("About" needs to be translated to current UI language)
  • description: value of skosmos:aboutDescription setting in current UI language (e.g. "More information on ontology and vocabulary service Finto"); if this is not set, there will be no description metadata on the page

Feedback page

  • title: "Feedback - {skosmos:shortName" e.g. "Feedback - Finto" ("Feedback" needs to be translated to current UI language)
  • description: value of skosmos:feedbackDescription setting in current UI language (e.g. "Send vocabulary feedback to Finnish ontology and vocabulary service Finto"); if this is not set, there will be no description metadata on the page

Vocabulary home page

  • title: "{dc:title} - {skosmos:serviceName}" e.g. "YSO - General Finnish ontology - Finto"
  • description: value of dc:description from config.ttl for the current vocabulary in the current UI language; if this is not set, there will be no description metadata on the page

Concept page

  • title: "{prefLabel} - {skosmos:shortName} - {skosmos:serviceName}" e.g. "labyrinths - YSO - Finto"
  • description: "Concept xxxx in vocabulary yyyy" where xxxx = prefLabel and yyyy = dc:title, e.g. "Concept labyrinths in vocabulary YSO - General Finnish ontology"; the pattern needs to be translated for the current UI language

Search result page (within a single vocabulary)

  • title: "'{search_term}' - {skosmos:shortName} - {skosmos:serviceName}" e.g. "'cat' - YSO - Finto"
  • description: not needed?

Search result page (global search)

  • title: "'{search_term}' - {skosmos:serviceName}" e.g. "'cat' - Finto"
  • description: not needed?

Error page

  • title: "Error - {skosmos:serviceName}" e.g. "Error - Finto" ("Error" needs to be translated to current UI language)
  • description: the specific error message that is also displayed on the page, e.g. "404 Error: The page /xxx/ cannot be found."

@joelit
Copy link
Contributor

joelit commented Apr 18, 2024

It's a good call to not inflect the names so they don't have to be hard coded.

Two things come to mind:

  1. There is no support for different error status codes other than 404 and 500, and I do't think the error situations are handled in a controlled manner. Should have an issue about supporting error messages better to get a better view of what situations the error page is shown in, and what the error messages might be (e.g. bad request 400, not found 404, request timeout 408, internal server error 500).

  2. Could there also be a clarification for the preferred format for the the links to the concept pages within a vocabulary? Now the links are internally in the form of /$vocab/$lang/page/$localName or in the form of /$vocab/$lang/page/?url=$url while the canonical form for the concept would be $url. Can we communicate the first two versions are alternatives to the third? It could potentially be a big improvement for crawlers.

@osma
Copy link
Member

osma commented Apr 18, 2024

  1. There is no support for different error status codes other than 404 and 500, and I do't think the error situations are handled in a controlled manner. Should have an issue about supporting error messages better to get a better view of what situations the error page is shown in, and what the error messages might be (e.g. bad request 400, not found 404, request timeout 408, internal server error 500).

I think this is a bit out of scope for SEO, so a new issue would be a better place to discuss this.

  1. Could there also be a clarification for the preferred format for the the links to the concept pages within a vocabulary? Now the links are internally in the form of /$vocab/$lang/page/$localName or in the form of /$vocab/$lang/page/?url=$url while the canonical form for the concept would be $url. Can we communicate the first two versions are alternatives to the third? It could potentially be a big improvement for crawlers.

There was a discussion about the use of link rel=canonical and link rel=alternate in #583 that might help with this. Though I disagree a bit with the statement that these are alternatives; the concept URI is an abstract entity while the Skosmos URLs provide concrete HTML representations of that entity - not the same thing, and typically a 303 See Other response is used to link from the former to the latter to make that distinction.

But anyway, linking between the different URIs/URLs should be investigated further because it could be important for SEO.

@osma
Copy link
Member

osma commented Apr 25, 2024

Implementation of this in Skosmos 3:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In progress
Development

No branches or pull requests

4 participants