Completely disable for specific custom post types?

If the webpage is public, it should have some meta tags and Schema markup to identify the content for social and search crawlers. Why would you want a public webpage to NOT have any meta tags and Schema markup?

js.

There’s meta tag information being added to WooCommerce orders, I see this information being sent back to our fulfillment warehouse in our rest api responses. A customer’s order doesn’t need optimizing.

We have a resource library on another site. The files/resources are password protected. There are no search engines crawling this content. There is no need for optimizing it.

I haven’t checked but private groups under bbpress/buddypress installs don’t need optimizing either.

There simply are instances where the extra html bloat isn’t needed on a web page.

Here’s a portion of the rest api response we’re outputting to requests from our fulfillment center.

                {
                    "id": 475019,
                    "key": "_wpsso_head_info_schema_type",
                    "value": "webpage"
                },
                {
                    "id": 475020,
                    "key": "_wpsso_head_info_og_type",
                    "value": "website"
                },
                {
                    "id": 475021,
                    "key": "_wpsso_head_info_og_img_thumb",
                    "value": {
                        "en_US": "<!-- getting thumbnail size for image ID 346 = success --><div class="wp-thumb-bg-img" style="background-image:url(https://example.com/wp-content/uploads/2021/08/EXAMPLE-LOGO-1200-X630-150x150.jpg);"></div><!-- .wp-thumb-bg-img -->"
                    }
                },
                {
                    "id": 475022,
                    "key": "_wpsso_head_info_og_desc",
                    "value": {
                        "en_US": "No Description."
                    }
                }

This has nothing to do with order management. Also, I have come across json parsing issues in relation to language being specified. Possible null character within string. For now I just strip it out since it doesn’t matter in relation to the order.

There are at least 6 or 7 sites using the premium versions of your plugins, all actively licensed. I came here because I didn’t feel like tracking down the person with account information to login for premium support.

To be honest, I am not a fan of the wpsso plugins. It all seems a bit bloated to me. Of the 500 schema markups we probably use 6 or 7 of them. We don’t care about targeting Whatsapp or such things. It is getting to be to much, in my opinion.

The lack of meta tags and Schema markup does not prevent social and search crawlers from accessing a webpage, and when they do, if there are no meta tags or Schema markup, then they have to guess at the type of content, use random images in the webpage, and more-or-less random text for titles, descriptions, etc. All public webpages benefit from meta tags and Schema markup, in part to control the information picked-up by social and search crawlers, and to identify its content. The webpage might be marked as “noindex” in meta tags, a checkout page might have “Checkout page” as its description in meta tags and Schema markup (instead of random text from the webpage), etc. If a webpage is public, it’s best not to have crawlers guessing at its content. ??

If the webpage is private, then WPSSO should not add any meta tags or Schema markup, as crawlers will not be landing on the webpage so they are not required.

If you’re convinced that some public webpages benefit from NOT having any meta tags or Schema markup, you can always hook the ‘wpsso_add_head_html’ filter and return false. I would strongly advise against that though.

As for “bloat”, visitors and crawlers do not notice a 3ms difference. ?? See here for more info on various performance metrics: https://surniaulula.com/2021/apps/wordpress/plugins/wordpress-seo-plugin-performance-report-for-q4-2021/

js.

Here’s a portion of the rest api response we’re outputting to requests from our fulfillment center.

It looks like you’re dumping ALL post metadata in the REST API. This is not related to meta tags or Schema markup in the webpage. Those fields are for the WordPress columns on the admin side – nothing to do with the front-end.

FYI – Standard naming for post/term/user metadata is to prefix an underscore for “private” metadata, so as a general rule, metadata keys with underscores are plugin/theme specific and not for general use.

Schema JSON-LD on the front-end should not contain any null values, although they may be present internally, but generally we try to avoid assigning null values to Schema properties internally. If you have an example of a Schema property with a null value, I’m happy to have a look at the code that may be responsible and making sure that null value is not saved.

Anyone can create an account on the Premium support site – all you need is an Authentication ID to open a ticket, which can be found on the SSO > Premium Licenses settings page.

WhatsApp, like Facebook, uses Open Graph meta tags. Open Graph meta tags and Schema markup are the two most popular structured data markup standards for crawlers – without those two standards, any crawler accessing a webpage would not know what the content is, so you loose control over it’s use by those crawlers. A generic logo image, title, and description is always best in those cases, and a “noindex” doesn’t hurt if you don’t want the webpage to be listed anywhere. ??

As I said though, if you want to disable meta tags and Schema markup on the front-end, the ‘wpsso_add_head_html’ filter should do the trick. ??

js.

BTW, if you want to disable those informational columns on the back-end, check-out the SSO > Advanced Settings > Interface tab. ??

js.

@dave-lozier Were you able to configure the plugin as you wish using the SSO > Advanced Settings > Interface options and ‘wpsso_add_head_html’ filter?

The ‘wpsso_add_head_html’ filter, like most WPSSO methods, filters and actions, receives the $mod variable, which makes checking things like the post type easier and faster.

Here’s a good reference page for the $mod variable: https://wpsso.com/docs/plugins/wpsso/notes/developer/the-mod-variable/

You can also find the complete list of WPSSO filters here: https://wpsso.com/docs/plugins/wpsso/notes/developer/filters/all/

js.