Task #86545

Make canonical and hreflang optional

Added by Ben Robinson over 1 year ago. Updated 6 months ago.

Status:
Closed
Priority:
Should have
Category:
SEO
Target version:
-
Start date:
2018-10-02
Due date:
% Done:

100%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

It would be useful to have a TypoScript option which deactivates the generation of the canonical and/or hreflang tag.

F.e. 404 pages and and other pages with "no_index" possibly should not have a canonical or hreflang tag. I could image something like ...

[page|no_noindex = 1]
    page{
        canonical = 0
        hreflang = 0
    }
[global]

This would also make it possible to generate both tags manually or via extension without having duplicates or contradictory tags.


Related issues

Related to TYPO3 Core - Bug #86577: hreflang and canonical ignores extension parameters Closed 2018-10-05
Related to TYPO3 Core - Feature #88242: Make canonical optional Closed 2019-04-28
Duplicates TYPO3 Core - Bug #86569: Respect no_index while creating canonical and hreflang tags Closed 2018-10-04

Associated revisions

Revision 3823f0af (diff)
Added by Richard Haeser about 1 year ago

[TASK] Only render hreflang tag when multiple languages are available

Make sure the hreflang tags are only rendered when there is more than 1
language enabled for the current page.

Resolves: #86545
Releases: master
Change-Id: Ib2bbccbc25544a4d162e7cb6da0ffc50a31df2ba
Reviewed-on: https://review.typo3.org/58837
Tested-by: TYPO3com <>
Reviewed-by: Riny van Tiggelen <>
Tested-by: Riny van Tiggelen <>
Reviewed-by: Jörg Bösche <>
Reviewed-by: Josef Glatz <>
Tested-by: Josef Glatz <>
Reviewed-by: Jigal van Hemert <>
Tested-by: Jigal van Hemert <>

History

#1 Updated by Richard Haeser over 1 year ago

  • Status changed from New to Needs Feedback
  • Assignee set to Richard Haeser

Good point for 404 pages etc, but what other use-case can you think of? Because I don't like the idea that people will disable the core-features and do their own implementations. If some more flexibility is needed, we have to define for what use-cases. The 404 is a valid use-case but I rather create a "smart" solution that won't add those tags on a page that will result an "error-code" and are set in the Site configuration.

#2 Updated by Christian Knauf over 1 year ago

It should also be possible to deactivate or regenerate the canonical tag if you have eg. in a detail view of an extension, since it changes the URL there.

#3 Updated by Ben Robinson over 1 year ago

Christian, yes that would be important.

Another use-case are pages with robots="noindex". Two different SEOs told me that it is important never to implement canonical or hreflang on noindex pages (f.e. thank-you pages of forms), because this "misleading signals" could confuse the search engines. I can't say in how far that applies, but the choice to deactivate the tags should be available, to fulfill the individual desires.
Therefor it could be good enough, if both tags would be skipped on noindex pages. 404 pages do not need a separate rule, because they can just be set to noindex.

But I would prefer to leave the choice up to the integrator, which tags are written to the code. It is even possible to deactivate the title and body tag (noPageTitle and disableBodyTag), and we should not force anyone to have those tags.

#4 Updated by Richard Haeser over 1 year ago

  • Tracker changed from Bug to Task

In issue #86569 I will make sure that no canonical and hreflang tags will be generated if the current page is in "noindex" mode. I think this solves this problem as well?

#5 Updated by Richard Haeser over 1 year ago

  • Duplicates Bug #86569: Respect no_index while creating canonical and hreflang tags added

#6 Updated by Ben Robinson over 1 year ago

Thanks, that's great!

I think it does not solve the whole problem – the tags would still be wrong on URLs created by extension (like detail view of news), which Christian mentioned above.

#7 Updated by Christian Knauf over 1 year ago

but there is still the problem with the canonocal tags on z.b. Detail pages of extensions. therefore, there should be a way to generate the canonocal Tag itself or better the additional parameters must respect when using a routeEnhancers.

#8 Updated by Ben Robinson over 1 year ago

Yes, if it's mandatory, the canonical needs to respect those parameters.

The hreflang tag is likely to be even more challenging with extensions: for example in detail view, it should check whether the extension record exists in the other languages and then generate it accordingly, otherwised skip the hreflang for this language.

For monolingual pages, the hreflang is unnecessary and can always be skipped.

#9 Updated by Richard Haeser over 1 year ago

For respecting the parameters for extension, issue #86577 is there. I will have a look at that tomorrow.

I will close this issue if you're ok with that.

#10 Updated by Richard Haeser over 1 year ago

  • Related to Bug #86577: hreflang and canonical ignores extension parameters added

#11 Updated by Ben Robinson over 1 year ago

Yes, that's fine. Thank you!

#12 Updated by Richard Haeser over 1 year ago

  • Status changed from Needs Feedback to Closed

#13 Updated by Ben Robinson about 1 year ago

I just talked to a SEO regarding this. He reminded me that the hreflang only makes sense for multilingual pages. It should be possible to deactivate it for monolingual websites or it should automatically be deactivated, if there is only one website language. The same may apply (depending on the SEO) for multilingual environments if there is no translation for a particular subpage. Should we reopen this issue?

#14 Updated by Christian Knauf about 1 year ago

Make sense for me ..

#15 Updated by Ben Robinson about 1 year ago

I can't reopen it. Richard, could you please?

#16 Updated by Richard Haeser about 1 year ago

  • Status changed from Closed to In Progress

Well I think it is better to automatically remove the hreflang when only 1 language is available. i'm in favor of reasonable choices instead of options. If you have a multi-language-site with a one-on-one language and the language in enabled in frontend, it doesnt make sense to disable the rendering of the hreflang.

So I will reopen and will create a patch for this.

#17 Updated by Ben Robinson about 1 year ago

Thanks for reopening this.

Well I think it is better to automatically remove the canonical when only 1 language is available.

I think the canonical is fine – the hreflang should be removed on monolingual sites.

i'm in favor of reasonable choices instead of options.

Sounds good!

#18 Updated by Richard Haeser about 1 year ago

Ben Robinson wrote:

Thanks for reopening this.

Well I think it is better to automatically remove the canonical when only 1 language is available.

I think the canonical is fine – the hreflang should be removed on monolingual sites.

Sorry I ment the hreflang (changed original message)

#19 Updated by Gerrit Code Review about 1 year ago

  • Status changed from In Progress to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58837

#20 Updated by Richard Haeser about 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#21 Updated by Ben Robinson about 1 year ago

Hi Richard, thanks for the patch, this is great!

Today I received a request from an SEO to outsource hreflang to an external sitemap as described on https://support.google.com/webmasters/answer/189077?hl=en (section "Sitemap"). The reason for this is that the project has lots of languages and only little content. It would degrade the ratio of the short content and the rest of the code if the hreflang would be integrated in every page.

Luckily, the project is still under 8 LTS, but I just wanted to tell you, that there might still be need to disable the hreflangs in some cases.

#22 Updated by Christoph Hendreich 9 months ago

#23 Updated by Benni Mack 6 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF