neos / neos-seo

A package to bundle SEO-related functionality for Neos.
GNU General Public License v3.0
13 stars 36 forks source link

TASK: Add google-site-verification meta tag #165

Closed Benjamin-K closed 2 years ago

Benjamin-K commented 2 years ago

When using the google search console to have a better overview about search results of your site, till now you had to add the required meta tag (or verification file or header) yourself for each project.

This pull request adds a property to the seo tags so you can easily add your google-site-verification meta tag. Output will be

<meta name="google-site-verification" content="yourGoogleSiteVerificationProperty" />
Benjamin-K commented 2 years ago

What's the problem with having it as a node property? I think this is much easier to maintain than the settings. Plus: Having it in the settings requires us to handle multi-site setups more carefully, which will not be the case with a node property.

Sebobo commented 2 years ago

It only needs to be applied to the homepage right? Then we could have it as a separate mixin and devs can set it as super type to their homepage NodeType. And in Fusion we can add the condition that its only rendered if node == site.

Wdyt?

kdambekalns commented 2 years ago

What's the problem with having it as a node property?

It can easily lead to confusion if added on more nodes than just the site node. What will Google think? What will users expect?

kdambekalns commented 2 years ago

It only needs to be applied to the homepage right? Then we could have it as a separate mixin and devs can set it as super type to their homepage NodeType.

That would be a nice addition!

I'd still love to be able to set it via settings. That way it can be populated from an env variable in different server environments.

And in Fusion we can add the condition that its only rendered if node == site.

Awesome.

Benjamin-K commented 2 years ago

Good catches. So i will create a new mixin for that and update the docs. The fusion does not have to be changed (except for the node == site condition).

What would you expect when setting the property via settings? We should handle multi-site setups when having the property via settings, too.

How about:

Neos:
  Seo:
    googleSiteVerification:
      'siteNodeIdentifier': 'googleSiteVerificationProperty'
Benjamin-K commented 2 years ago

Another solution for the node property could be:

'Neos.Seo:SeoMetaTagsMixin':
  properties:
    metaGoogleSiteVerification:
      ui:
        inspector:
          hidden: 'ClientEval: node.depth > 2'

This will show the property only on the site node as all other documentNodes have a higher depth.

For Google it should be enough to have the meta tag on the home page, so this change will help here, too.

What do you think?

Sebobo commented 2 years ago

I personally don't want properties on nodes that I don't need. So I definitely prefer the mixin to control the feature individually.

kdambekalns commented 2 years ago

What would you expect when setting the property via settings?

It should be used as default value, I could then disable/hide the property and have it "settings-only". Or leave the property in place and it would override the setting.

We should handle multi-site setups when having the property via settings, too.

Definitely, possibly for other settings as well. I like the way it's done here:

https://github.com/neos/neos-googleanalytics/blob/164bdc771862c44aa343138a155963c3aee5b83f/Configuration/Settings.yaml#L52-L62

Benjamin-K commented 2 years ago

Ok, i updated my commit to have settings as fallback and a mixin that could be added to the nodeType of the site node. Also i updated the documentation. I did not yet implement the multi site setup via settings, but that should be ok for now i think.

Benjamin-K commented 2 years ago

Definitely, possibly for other settings as well. I like the way it's done here:

https://github.com/neos/neos-googleanalytics/blob/164bdc771862c44aa343138a155963c3aee5b83f/Configuration/Settings.yaml#L52-L62

I like that way, too. But that should be a separate PR i think. And the change should not be breaking if possible.