Improvements for title tag, keywords and implementation of Open Graph tags +canonical

[internetinnovations]

This issue aims to be a placeholder & idea generator for improving Contao's overall SEO configurability.
We are looking forward to your feedback!

Title tag improvements

Contao's current behavior for title tags, makes it impossible to "remove" a site-specific title tag. This means: Right now a one-pager or home page always starts with "site title" or "page name", followed by - "site title (root)". This solution is unfeasible.
There are several possible solutions (all of them can be combined):
a) Checkbox "no root title for this page" below page title configuration
b) Automatically check, if page title is identical with "root title" -> if true, only show root title w/o "-"
c) Optional system setting: Don't use page name as title, when page title is empty

Keyword optimizations ("Suchbegriffe")

Right now the Keywords are maintained for each article. This might be practical in case Contao is used like a blog. In cases where Contao is used for a website, which is being published in the APAC area (where keywords are being heavily used from search engines), it is more easy to handle keywords for each page.
Solution:
Add an additional Keyword input field in the meta tags section for each page and combine them automatically with the article keywords
site structure -> edit -> meta data -> keywords

Open Graph implementation

Right now it is not possible to manage and maintain og-tags off the go in Contao.
E.g. Open Graph image tags are used by most of the social media services and can have a huge impact on the first impression.
A possible solution could look like this:
Each page will get additional input fields for manual og tag configuration (site structure -> edit -> meta data)

• Tags that should be configurable for each page
  -- og:image (select picture from file manager)
  -- og:title
  -- og:description
  -- og:url
  -- og:type
• Automatically generate these tags
  -- og:image (only if empty. Use og:image from root site. og:image for root site should be mandatory.)
  -- og:title (only if empty. Should use same logic as for page title.)
  -- og:description (only if empty. Should use page description.)
  -- og:locale

Canonical

It should be possible to define, if the content of a page is original or a copy. Google rewards pages with self-canonical tags.

• Automatically Optional generate self-canonical for each page
• Add an input field for canonical in the meta data section for each page. If field is filled, this url should replace the self-canonical

Note

We would combine the features mentioned above with our refactored version of i18nl10n extension for Contao 4.4

[frontendschlampe]

Title tag improvements

In layout settings you can make any setting you want. You can change the default behavior by your own.

Keyword optimizations ("Suchbegriffe")

I don't understand, why we need two positions to handle keywords. I think one position is enough.

Open Graph implementation

You can use hofff/contao-opengraph. When we would add OpenGraph tags to the core, we also have to add other things, like Twitter Cards, too.

Canonical

You can use christianbarkowsky/rel-canonical to provide canonical tag.

[internetinnovations]

Title tag improvements

In layout settings you can make any setting you want. You can change the default behavior by your own.

Of course it is possible to manually change the default behavoir, but the current behavior isn't user friendly, nor very useful. Is there any argument against improving this by default?

Keyword optimizations ("Suchbegriffe")

I don't understand, why we need two positions to handle keywords. I think one position is enough.

Okay, than this position should be on site structure level.

Open Graph implementation

You can use hofff/contao-opengraph. When we would add OpenGraph tags to the core, we also have to add other things, like Twitter Cards, too.

We disagree on this. Twitter Cards is the optimization for one specific Social Media provider. OpenGraph is used by all services (e.g. WhatsApp). Every web project should use og tags, no matter whether the project's goal. Your extension is great, but please re-think if it could be extended and integrated into the core.
Contao wants to be simple and user friendly. It is clear why the core team doesn't want to implement everything into the core, but especially this feature is basic for high quality content management.

Canonical

You can use christianbarkowsky/rel-canonical to provide canonical tag.

Same as above. A lot of content managers don't even know, what a canoncial is. Why shouldn't Contao provide such tags automatically off the go?

Contao always said: "We follow open web standards". OG and Canonical tags are open web standards.

[asaage]

Keyword optimizations ("Suchbegriffe")

I don't understand, why we need two positions to handle keywords. I think one position is enough.

Okay, than this position should be on site structure level.

Definitely not.

• Editors might not have access to the sitestructure
• in case you have multiple articles on the page and/or some of them are displayed as teasers each of them might bring their own keywords though they are sharing the same page.

[ausi]

Contao always said: "We follow open web standards". OG and Canonical tags are open web standards.

OpenGraph is not an open web standard IMO.

Canonical tags are standard AFAIK, but how should Contao know which URL it should put into the canonical tag?

[frontendschlampe]

Canonical tags are standard AFAIK, but how should Contao know which URL it should put into the canonical tag?

I think, it should be like the extension christianbarkowsky/rel-canonical make it.

[internetinnovations]

Keyword optimizations ("Suchbegriffe")

I don't understand, why we need two positions to handle keywords. I think one position is enough.

Okay, than this position should be on site structure level.

Definitely not.

• Editors might not have access to the sitestructure
• in case you have multiple articles on the page and/or some of them are displayed as teasers each of them might bring their own keywords though they are sharing the same page.

Good arguments, agreed!
I think we will then have to stick to our self-developed solution for i18nl10n and use two positions to handle keywords. Otherwise it wouldn't be possible to manage keywords for multiple languages w/o duplicating each article for each language. Maybe we'll find another solution for this issue...

[internetinnovations]

OpenGraph is not an open web standard IMO.

It is licensed under the OWFa (which is also preferred by Mozilla) and used by nearly every popular web service which allows URL sharing. Why isn't it?

[ausi]

OpenGraph is not an open web standard IMO.

It is licensed under the OWFa (which is also preferred by Mozilla) and used by nearly every popular web service which allows URL sharing. Why isn't it?

The OWFa grants you that you can implement the specification without having to fear patents. This is unrelated to whether something is a web standard or not.

But even if it was a web standard, I don’t think we should implement all meta tags that some URL sharing service wants to see. This use case should be handled by an extension, so that everyone can choose which meta tags they want to support.

Canonical tags are standard AFAIK, but how should Contao know which URL it should put into the canonical tag?

I think, it should be like the extension christianbarkowsky/rel-canonical make it.

There you have to select for every single page which page should be used as the canonical one. And it still produces duplicate content URLs (with and without https, different domains, etc...).

How canonical URLs should be set, strongly depends on the project IMO. Automatically generating self-canonical references doesn’t make sense and can be harmful.

[internetinnovations]

But even if it was a web standard, I don’t think we should implement all meta tags that some URL sharing service wants to see. This use case should be handled by an extension, so that everyone can choose which meta tags they want to support.

Each of the top 500 websites uses og:title and og:image tags. Every popular social media platform uses and recommends to use them.
I totally agree, that not every meta tag should be implemented in the core. But to be honest: I don't see any big difference between having the option of managing a tag meta name="description" and a meta property="og:description", resp. meta property="og:image". Even contao.org uses the meta property="og:image".
From your point of view the meta name="description" also could/should be handled by an extension.
Don't you think both tags are crucial for modern websites and crucial features should be in the core?

[ausi]

Each of the top 500 websites uses og:title and og:image tags.

This is just not true.

Every popular social media platform uses and recommends to use them.

Google recommends Schema.org microdata not Open Graph.

I don't see any big difference between having the option of managing a tag meta name="description" and a meta property="og:description"

The social media platform would just fallback to the meta name="description" so there is no need for og:description.

resp. meta property="og:image". Even contao.org uses the meta property="og:image".

This is the only one that could make sense to add to the core I think. It should then be used for schema.org and Open Graph. But it’s not that easy, where would you set the image size that should be used for this image? Every reader module would have to be extended to set the “page image”.

[fritzmg]

For og:image see the codefog/contao-social_images for reference. It automatically collects images from text and image content elements, as well as from news and event entries. You can also define a "social image" per page in the site structure.

The original image will be used - however, it would probably make sense to have an image size setting (per website root).

[internetinnovations]

Google recommends Schema.org microdata not Open Graph.

Sorry, you are right. Google was using Open Graph and had it in their G+ documentation. This is not the case anymore. It has been replaced by Schema.org microdata and is now in place for nearly all google services. Thanks for the update on this.

resp. meta property="og:image". Even contao.org uses the meta property="og:image".

This is the only one that could make sense to add to the core I think.

This is the most important property. I also think, that it should also be used for schema.org and Open Graph. @fritzmg approch seems to be legit.

[ausi]

For og:image see the codefog/contao-social_images for reference. It automatically collects images from text and image content elements, as well as from news and event entries.

I don’t think automatically collecting the images of the page makes sense because the social media platforms already do that themselves.

You can also define a "social image" per page in the site structure.

I think that’s the right way to do it. Reader modules should set the image as well similar to how the page title is handled.

it would probably make sense to have an image size setting (per website root).

The layout settings may be a better place for this setting.

[fritzmg]

I don’t think automatically collecting the images of the page makes sense because the social media platforms already do that themselves.

Agreed, may be @qzminski added this, because you used to be able to select which image you want to use in your share post (a long time ago...), if multiple images were found by Facebook (either via og:image or otherwise). But nowadays it does not make sense anymore.

[internetinnovations]

So we agree on the OP idea of placement in the BO?

Each page will get additional input fields for manual og tag configuration (site structure -> edit -> meta data)

And in addition the defined og:image from root level of site structure, will be used as fallback for sub pages, if no individual og:image is set?

[leofeyer]

As discussed in Mumble on October 5th, we could add a "page image" in the site structure, which is then used as og:image. The page image should be overwritten by news and event images (== teaser image) similar to this:

https://github.com/contao/news-bundle/blob/add868722ffdb4e6a879761fbce248d97001f195/src/Resources/contao/modules/ModuleNewsReader.php#L123-L126

[fritzmg]

Hm, I dislike the semantics. In most cases I had to use

• terminal42/contao-pageimage
• codefog/contao-social_images

in the same Contao Installation - where the page image would be used for a large header image for example and the social image for the share image. They always had to be different. But I guess in future Contao Installation it would be "Page Image" and "Header Image" then ;) (where the latter comes from an extension).

[qzminski]

As discussed in Mumble on October 5th, we could add a "page image" in the site structure, which is then used as og:image. The page image should be overwritten by news and event images (== teaser image) similar to this:

You can have multiple og:image tags in the document so maybe it would be better to put the news and event images on top of the page image, instead of just overwriting it.

[internetinnovations]

I'd like to get back to the title optimizations topic.
From a SEO perspective there are four popular usages of the title tag:
Page Title - Root Title (Standard Contao Behaviour, Google, Wikipedia)
Page Title (Facebook, T-Online)
Root Title (Onepagers)

@frontendschlampe argument, that it can be changed in the layout settings, is not very user friendly.
A website can use many layouts and in such case every layout needs to be adjusted manually to have that behavior. Is there any reason, why the standard behavior for empty titles shouldn't be changed?

Maybe a checkbox "Do not automatically use page name as page title" already helps?

In addition there could be a selection "composition of page title" for each root page to select out of the functionalities above.

Any more opinions?

[bekanntmacher]

meta kewords can be removed. it has been officially known since 2009 that these are ignored: https://www.youtube.com/watch?time_continue=5&v=jK7IPbnmvVU

[internetinnovations]

@bekanntmacher that applies for Google but not other search engines like Baidu.
Baidu still heavily relies on meta keywords. We've seen this on yuneec.cn with great impact.

[bekanntmacher]

yuneec.cn does not use keywords

[internetinnovations]

@bekanntmacher
This is because we're using the i18nl10n in this project, which does not support keywords on a country-based level. This is currently being refactored by us for Contao 4.4
Thus it's still important to keep this feature in place for the new i18nl10n extension and projects with localizations for China (baidu) or Russia (yandex).

[bekanntmacher]

ok. I didn't know baidu optimization was going to be supported by contao.

[fritzmg]

ok. I didn't know baidu optimization was going to be supported by contao.

Well, the keywords meta tag is part of the HTML specification.

[bekanntmacher]

but nobody needs it except china (and probably not for long)

[fritzmg]

The Contao search indexer also makes use of it.

[bekanntmacher]

ok, I see. I ask myself why but that's another question...

[fenepedia]

I'd like to get back to the title optimizations topic.
Maybe a checkbox "Do not automatically use page name as page title" already helps?

It would be great if there is a checkbox. "Override complete title with my custom title"
So I could use it on specific pages, like home.

At the moment I use the following workaround:

fe_page_default.html5

// Anpassung Titel für Home

global $objPage;

if ($objPage->alias == 'index') {
	$this->title = $this->pageTitle;
}
include $this->getTemplate('fe_page');

[bekanntmacher]

@fenepedia
in which case you want to overwrite the title?

[fritzmg]

I agree with @fenepedia . In almost all our websites we override the default fe_page template like that.

@bekanntmacher see the code. We want the index page to have a different <title> tag than the others. Sure, you can do that with a different page layout. However since Contao does not support child page layouts it's rather cumbersome to maintain a different page layout for the index page, just so that its <title> is different. Thus it's more convenient to override the fe_page template.

We usually use something like this:

global $objPage;
$this->title = $objPage->alias == 'index' ? '{{page::rootPageTitle}}' : $this->title;
$this->extend('fe_page');

[bekanntmacher]

Yes, I understand that but in which case or why do you want to overwrite the title?

[fritzmg]

See the code ;). In my example the start page of the website would show

Root page title

instead of

Start page title - Root page title

In @fenepedia 's example it would show

Start page title 

instead of

Start page title - Root page title

[bekanntmacher]

Ja, ich kann den Code lesen... du beantwortest meine Frage nicht: in welcher Anwendung brauchst du das?

[xchs]

Weil man vielleicht für die wohl wichtigste Seite einer Website "NewCo" in den SERPs haben möchte und nicht "Start page - NewCo". Jetzt klar?

[bekanntmacher]

Das ist aber ein Spezialwunsch welcher wie oben beschrieben gelöst werden kann. Ich glaube nicht, dass dies viele brauchen. Ich wüsste jetzt auch keine Anwendung wo es wirklich Sinn macht nur den Brand als Title zu zeigen.

[xchs]

Ich glaube nicht, dass dies viele brauchen.

Das weiß ich nicht, ich für meinen Teil mache das jedenfalls auch so.

Ich wüsste jetzt auch keine Anwendung wo es wirklich Sinn macht nur den Brand als Title zu zeigen.

Ein prominentes Beispiel wäre z. B. Apple. Wenn Du in der Google-Suche nach site:apple.com suchst, dann erhältst Du für die Startseite in den SERPs "Apple" und nicht "Irgendwas - Apple" – also auch nur den Brandnamen. Für alle anderen Seiten liefern die Ergebnislisten wie gewohnt einen Titel nach dem Schema "Irgendwas - Apple".

Es soll mitunter auch schon vorgekommen sein, dass bei entsprechend langem Seitentitel in der Startseite der eigentliche Unternehmensname (bzw. Name der Website) irgendwo ganz hinten in den Ellipsen verschwunden ist und somit in den SERPs gar nicht mehr sichtbar war.

[internetinnovations]

It is best practice to place root title only on start pages. This was the main intention of the OP.

[asaage]

Would be nice if someone has a similar elegant snippet that does not rely on alias=='index'
for it to work on multi-language-sites on the same domain.
for example i have index for the startingpage in the german page-root but home in the english page-root.

[bekanntmacher]

Was mit site: angezeigt wird, ist nicht relevant, denn was in den SERP's angezeigt wird das weicht häufig von site:-Ergebnis ab. Vor allem dann, wenn der Title nicht relevant zum Inhalt ist oder wenn der Brand weggelassen wird. Dann hängt ihn Google am Schluss automatisch an. Auch wenn er vorne ist, stellt ihn Google meist nach hinten.

Also: den root-title kannst du immer ans Ende stellen, auch bei der Startseite. Für das Ranking ist das völlig egal.

[fritzmg]

Ja, ich kann den Code lesen... du beantwortest meine Frage nicht: in welcher Anwendung brauchst du das?

Ich wüsste jetzt auch keine Anwendung wo es wirklich Sinn macht nur den Brand als Title zu zeigen.

Usually the website root title will be the comany's name for example. The default title in the page layout is {{page::pageTitle}} - {{page::rootPageTitle}} which will lead to <title> tags such as:

Some nice page - The awesome company
Another cool page - The awesome company
…

However, this behavior is problematic for the start page. Most of our customers do not want

Start page - The awesome company

They want to introduce their company on the start page and thus choose The awesome company as the page title for the start page. Which would then lead to

The awesome company - The awesome company

Which is superfluous of course. Instead it should just be

The awesome company

See https://www.apple.com/ <title>Apple</title>
vs. https://www.apple.com/ipad/ <title>iPad - Apple</title>

See https://www.google.at/ <titlte>Google</title>
vs. https://www.google.at/intl/en_at/about/ <title>Our latest | Google</title>

See http://www.spacex.com/ <title>SpaceX</title>
vs. http://www.spacex.com/ <title>Company | SpaceX</title>

etc.

[internetinnovations]

@fritzmg Thanks for making it clearer with your examples.

[bekanntmacher]

Ich kann euch nur abraten, das zu tun, was ihr oben wollt. Dazu kann ich abschliessend einfach noch folgendes empfehlen:

1. Apple ist kein gutes Beispiel: der Brand hat ein ganz anderes Gewicht als die Brands die du und ich mit Contao-Seiten bedienen.

2. Schreibt mehr als nur den Brand in die Root Page.

3. Schaut nicht zu stark was im HTML-Code anderer Seiten steht, sondern schaut was in den SERP's passiert/angezeigt wird. Beides kann sich voneinander unterscheiden.

[fritzmg]

Apple ist kein gutes Beispiel: der Brand hat ein ganz anderes Gewicht als die Brands die du und ich mit Contao-Seiten bedienen.

That's not up to you to decide 😉 . But you are right, it does not make sense for every brand. May be the fe_page template hack will have to suffice.

[backbone87]

i think the topics in this ticket are important, but imho the ticket is too big. maybe it would be useful, if we create new tickets for each separate topic:

• drop/opt-out of meta keywords
• OG/Schema.org/Social-Tags for Contao core
• title handling

also these issue should be created in contao/core-bundle

[Redrocirt]

An addition to the OpenGraph topic: There is an extension available for Contao 4, adding optional fields in the page options (also Twitter cards optional/separate): https://github.com/numero2/contao-opengraph3 - maybe this is useful in some cases... There you can also select different images for OG and Twitter.