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?