Include some basic SEO options to core

(Richard Haeser) #1

Include some basic SEO options to core

Every websites benefits from a good SEO and therefor I think it is good to have some extra options in the core. At the moment there are several extensions adding properties to pages to make it possible to set some meta tags for Search Engine Optimization. By adding this to core, we help TYPO3 to provide more SEO options out of the box. Normally I’m not a big fan of adding a lot of functions like this to core, but because SEO is such an important part of your website I think in this case it is good to do it.

Fields to add

  • SEO title => a title that differs from page title and navigation title and is used for the <title> tag
  • Canonical URL => a field to set the canonical URL of the page. When filled, it will add the <link rel="canonical"> tag with the href attribute filled with the given URL. If the field is empty, it will return the URL of the current page.
  • robot instructions => a field to make it possible to set the <meta name="robots"> tag. Possible options: noindex,nofollow, noindex,follow, index,nofollow, index,follow. The default value should be index,follow.
  • OG-tags => Add option to set separate title, description and image when shared on Facebook (and other OG-tag based social networks)
  • Twitter cards-tag => Add option to set separate title, description and image when page is shared on Twitter
  • href-lang => Not a field in backend, but automatically set <link rel="alternate"> tag when other languages are available for this page

Possible Migrations

Because this are new fields for core, I think a migration isn’t needed. However I think we should recommend SEO-extension-developers to migrate to these fields in stead of using own fields.


  • No extensions needed for these basic SEO options
  • TYPO3 will be more SEO-friendly out of the box


  • When you have installed a SEO extension providing these tags, it would be possible that tags are rendered twice. If everyone uses the new Metatags API (, it is possible to check if a specific metatag is already set.

Remarks and notes

When we have any SEO questions, we can check with the guys of Yoast. We can write the code as part of the Yoast project and move it from extension to core.


Topic Initiator: @richardhaeser
Topic Mentor: @dermattes1

(Markus Klein) #2

Sorry I miss the point. What do you use the page-title then for?

What exactly does the user enter there? A manual URL? I would disagree then.

Issuing a canonical for the current page only makes sense if realurl is activated and you want to make sure that access via non-realurls to the page through search engines is properly telling them that you want them on the realurl.

This may cause severe conflicts with single-view pages of extensions.
On top of that you need to ensure that this works correctly for USER_INT plugins, hence where the page itself is cached, but the plugin isn’t and the non-cached plugin is changing those meta tags during rendering.

Basically I agree, but having this wrong (for whatever reason) can cause severe troubles SEO-wise.

Other than those points, I’m all in getting SEO better OOB.

(Bernd Wilke) #3

SEO title: we already have a lot of ‘title’ fields (or similars like alias and subtitle) and so a lot of seo extensions introduce a new pagetitle field I do not see a lot of usage (but fallbacks to default fields)

Canonical URL / href-lang: so I think they are very important for SEO, I think they should be provided automatically and not by hand. Here it is IMHO important to have an extension for URL tuning like realurl.

OG-tags / Twitter cards-tags: do you really want separate fields for facebook, twitter, google? aside from the additional work for editors I consider it confusing if a page has different teasers

in general: aside of the importance of SEO-options be aware that we have a lot of non-static pages ((paginated) list-/detail view) where these values must be adapted to the individual content. A good API with viewhelpers is necessary.

(Mathias Schreiber) #4

pages.title = W124
pages.seo_title = Experience the new Mercedes Benz E-Class

Regarding the realurl and canonical topic:
We have speaking URLs on the roadmap for v9, so this should work out.
I have no idea how to automatically set the canonical for a specific page, so I’m totally up for input on this one.

Regarding the OG:Tags etc.:
The review Richard mentioned has been built to address exactly that.

Regarding link rel alternate:
I’m not deep enough into this topic, but would you consider this insolvable?

Yes, having dedicated Twitter cards does have an impact on your social performance.
I suggest that you read up on the topic in general, because you got a few things wrong in your perception.
The proposal refers to OpenGraph and Twitter Cards. Nobody talks about Google+ or alike (since these come from OpenGraph). Twitter cards on the other hand offer a lot more meta data like the account name associated with the page (think author of blog post).

As with Markus I also suggest to read through what the review Richard mentioned actually does before posting things already addressed in the proposal so we can keep the thread clean.

@richardhaeser you can add me as a topic mentor here.


(Martin Wiederkehr) #5

The page title is shown on the page itself, SEO title (title tag) is more specific and should describe the content on a page in a very short way. see for more
info[quote=“richardhaeser, post:1, topic:289”]
OG-tags => Add option to set separate title, description and image when shared on Facebook (and other OG-tag based social networks)
Twitter cards-tag => Add option to set separate title, description and image when page is shared on Twitter

Should be set automatically with an option for manual overwriting. This is getting quite complex on bigger pages with but would definitely make sense if it’s working properly.

I would only offer OG-tags by default and offer the possibility for additional fields by API. There are a lot more implementations than only Twitter, but imho this goes above basic SEO.

I would really like to see more SEO features in the core. I think Mattes mentioned something in that direction for v9, but I could be wrong.

(Bernd Wilke) #6

It is not about individual tags for facebook, twitter, google, … . My aspect was: how often do you have a different title for facebook, twitter, google, …?
Of course you need individual fields if you have the usage, and you might need further fields if you consider another index with individual filds important to your site.
Do we want a general (=simple) solution to have some SEO basics or do we want a complete solution for any kind of search machine?

(Mathias Schreiber) #7

If you’re doing Social Media right, every single time :slight_smile:

(Richard Haeser) #8

I see some great responses and I will try to react on all mentioned replies:

As @dermattes1 already explained it is possible that you want to set your SEO title different as the title that is displayed on your page. It has after all an other purpose. Is the title shown on the page more a: “this content is about”, the SEO title is more a teaser to attract people to go to your page. Of course there should be a fallback to the normal page title. This is why almost all SEO-extension do this.

Canonical URL
@liayn you are right that referring to the own page only is necessary when you have nice urls, but after all I think a lot of sites do use things like realurl or similar. Besides that: we also think the nice url’s should be in core and thats why we will support the core development in this with everything that is possible for us. But if for whatever reason the nice urls wont make it to core, a lot of people will still use realurl or similar. When you don’t use it, there is also no problem and won’t affect your SEO if the canonical is just When people don’t use such an extension, they doesn’t care about SEO at all :wink:

Yes this can cause issues in extensions, but thats why I mentioned the new Metatag API. And I think it is good we contact some of the extension developers of widely used extensions, to use the new API in CMS9 compatible extensions.

We already checked on that and for our use-cases this is not a problem. Thats why I think it is good to really check the first version on this new feature in different setups.

By the way, this is just a start. We can also think about things like sitemaps and so on, but for now, lets keep it “simple”. :wink:

(Albrecht Köhnlein) #9

I don’t think setting canonical URLs manually is a good idea. How should that work with extension detail pages like news? All news have the same page, so you could only set one canonical URL for all your news.

In my opinion, canonical URLs are necessary when you use mountpoints to tell the search engines, where the original page is located. But I have no idea, how this could be done manually - maybe, it’s even better to detect mountpoints automatically and set canonical tag to the original page.

(Richard Haeser) #10

For most of the URL’s it can be done automatically and thats also what I said. When you don’t fill the canonical ourself, it can be determined. But… There are cases that you want for example cross-domain canonicals or manually set the canonical.

Example 1: I copy a blog of and “embed” it on my website. Of course with a nice mention of the source, but still: the same content is on my page as well as on the website. Google will see it as duplicate content as long as I don’t set a canonical url to the source url.

Example 2: When you use the reference function for a lot of content elements on the same page (for example when you have an A-B test) in that case you also want to set the canonical url to the source page.

Yes this is advanced canonical usage, but with a CMS like TYPO3 this should definitely be possible to do. With our customers we really need these kind of features.

(Marc H) #11

Hey. We do the same by our SEO extension. Therefore I support Richards point. Some things are basics. Some extra thoughts:

Extend records and pages
It is also necessary not only to extend pages. We need this features for every extension that works with detail views. In cs_seo we offer a possibility to extend records with an SEO IRRE element. Maybe not the best way, but it works for us. Maybe an API like the system categories have already is an idea. href-lang is here also needed.

noindex, nofollow
Split this into two fields (checkboxes). So you can hide the nofollow box easily for an editor without SEO knowledge.

remove keywords field
This meta tag is ignored by search engines since a long time ago.

I am looking forward to the new meta tag API.

We currently add this fields:

  seo_title varchar(255) DEFAULT '' NOT NULL,
  seo_title_only tinyint(1) unsigned DEFAULT '0' NOT NULL,
  seo_focus_keyword varchar(255) DEFAULT '' NOT NULL,
  canonical varchar(255) DEFAULT '' NOT NULL,
  no_index tinyint(1) unsigned DEFAULT '0' NOT NULL,
  no_follow tinyint(1) unsigned DEFAULT '0' NOT NULL,
  og_title varchar(255) DEFAULT '' NOT NULL,
  og_description text,
  og_image int(11) unsigned NOT NULL default '0',
  tw_title varchar(255) DEFAULT '' NOT NULL,
  tw_description text,
  tw_image int(11) unsigned NOT NULL default '0',
  tw_creator varchar(255) DEFAULT '' NOT NULL

Maybe we can find some matches with other SEO extensions and integrate some fields in the core. Otherwise we can speak with other extension developers about naming conventions.

(Richard Haeser) #12

Hi @mhirdes. Great you also took the time to give your vision on this topic!

About the extend of records: do you provide a general way of doing it, because I think it should be possible for extension builders to just set the right tags. So title and meta tags should be writeable for an extension. The implementation in the records itself, is more functionality for an extension I think. Or in the extension with the detail view, or otherwise in a SEO extension like we both create.

The noindex, nofollow thing I can get, altough I don’t have a usecase to seperate those two fields in my projects. Someone that is capable of excluding the current page from indexing, should be capable to set the nofollow as well I think.

I’m with you regarding the keywords field. The only problem is that this field is used in several other cases I think besides SEO. So removing this field will be a breaking-change.

(Marc H) #13

Hey @richardhaeser . Thanks for the fast response.

Extend records is done by pageTSconfig. cs_seo Manual. There you can also define fallback fields like title and description. To have something like this in the extension builder would be great. The base should be an API for SEO settings. But not only SEO settings, URL settings as well. Usually they also should be avialable for every detail view. A further argument to have speaking URLs in the core.

I think of an editor training. Our costumers often get confused the first time when they see the page settings. So we want to keep it for them as simply as possible. IMO the noindex is easy to explain and more necessary than the nofollow option.

I aggree with you regarding to the keywords field.

(Markus Klein) #14

Ah, here we go. There’s the major difference. We mostly do not show the page title on the page (except maybe bread crumbs) but let the user define the h1 via normal CE headers.

(Markus Klein) #15

Let the games begin. dd_googlesitemaps in the core pls, where all extensions can plugin nicely.

(Richard Haeser) #16

We didn’t had that usecase as well with our customer, but I got a lot of requests regarding this on the Yoast plugin.

(Richard Haeser) #17

Let start with some “simple” SEO fields :wink: Sitemaps is in my opinion a phase 2 feature.

(Markus Klein) #18

Issuing the page title on the page itself (I suppose as h1) will eventually fail hard for details view of extensions.
Extensions are able to adjust the page title in general (which is taken into account for the title tag), but if the page title is output somewhere with TS this will not work, as the title is probably already rendered before the detail view plugin is even triggered.
That’s why IMHO we do not need more title fields for a page. The page title is the one that is printed into the title tag and is well controlable by extensions at the present state. The nav-title can be used by any sort of custom rendering (menu, sitemaps, whatever) to have a different title of the page. We do not need a dedicated title for pure content usage, since that belongs to content, hence we have content elements for that.
I someone still needs to have a dedicated place for such a title, I suggest using the a BE layout with a column named “page title”, which only allows (ext:content_defender) a dedicated CE that only has a title/header field.

(Richard Haeser) #19

I get the point that it is a content thing, but let’s take for example the blog of as an example. As far as I know they just prints the title field as the main heading (h1) on the detail page of a blogpost. These blog posts are just “normal” pages with a different doktype so no records. Let’s say, in some cases they want another SEO title as the heading. In that case, they do have to create a content element on every blog post even if the main heading is the same as the SEO title. So when people wants this to be separated (and I know a lot of them) they always have to create a content element. If we want to make TYPO3 easier to use, it saves an editor about 3 or 4 clicks to do the same when they have a field for this in the page properties. And when people just wants it occasionally, it will save even more time.

Don’t forget a SEO title is not always used so it is for special occasions. Some will never use it, some will always use it (and everything in between). Again: I’m against unnecessary fields and didn’t had the usecase myself, but after soms chats with people I’m quite convinced that when you start offering SEO enhancements out of the box, you get a lot of request regarding a separate title for SEO and that it actually makes sense. After working on the Yoast plugin I realised that the way I / we use TYPO3 is not the same as a lot of other people.

Maybe some other people can give their opinion on this particular point? Maybe @mhirdes also have some good reasons why he also separated the main heading from the SEO title.

(Markus Klein) #20

I’m also not vetoing against such fields and editor convenience is for sure the most important thing in this regard, since otherwise they do not take the time at all to fill all those fields.