Include some basic SEO options to core

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

2 Likes

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

Title
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 youdomain.com/index.php?id=1. When people don’t use such an extension, they doesn’t care about SEO at all :wink:

OG-tags
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.

href-lang
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:

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.

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 typo3.com 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 typo3.com 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.

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.

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.

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.

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.

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

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

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

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.

I get the point that it is a content thing, but let’s take for example the blog of typo3.com 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.

1 Like

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.

2 Likes

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.

The main heading is shown in the page tree in the TYPO3 backend. Yes you can also show the nav title there. But the browser title should be optimized for search engines. Therefore include keywords and describe the content with a limited number of characters. The page title is for identifying the page, the browser title for SEO.

The page title will further be used as fallback. So allways a browser title is shown.

1 Like

That’s indeed an interesting approach.

SEO title => a title that differs from page title and navigation title and is used for the tag

Definitely yes! I usually use the pagetitle inside the page <h1> but almost always you have to set a different <title> (I know there is already a “navigation title” field, but that’s used for menus).
Also, every SEO-related extension add this field, and this is because it is needed (IMHO).

I also agree about the other fields; if we have to keep it “basic” I’d say to limit it to

  • title tag
  • robot instructions
  • canonical url (maybe)
  • href-lang
1 Like

Agree we need some of this in the core, so good call.

Regarding the canonical; this should be, and can be, automated. Mount points and show contents of this page can be automated. A big challenge lies in language fallbacks, since there are many options to consider.

OG tags and Twitter cards; will that affect SEO, or just influence the performance of your links on social media? Social Media is not equal to SEO, so if there is no effect in SEO, I would put them in separate extension.

I personally would put this in a separate core extension. There are many installations who do not need this, like intranets. The website developer should be in charge to define if this functionality should be used.

@richardhaeser; you do have a customer where the page title is in the page :wink:

Indeed. A lot of the canonical can be automated, but… You should have the possibility to override the canonical by setting an own. This is needed to set for example canonicals to external urls.

SEO is also about linking to your website. Social media is one of the most important ways of links to a website at the moment. A quote from the guys of Yoast: “You need links pointing to your website and for that to happen, people need to talk about you and your website. That is the essence of social media, so our plugin helps you optimize for that as well!”

For every installation it is good to have SEO enhancements. It is not only about external search engines, but also for internal search engines. So it might be a separate core extension, but I think it should be enabled by default.

And I know indeed a couple of sites using the page title in the page :wink:

3 Likes

This topic was automatically closed after 28 days. New replies are no longer allowed.