WPSSO Core Pro and the WPSSO JSON Pro add-on provide complete Schema markup (aka Google’s Product Rich Card) for WooCommerce products, including all variations and extensive product information (size, weight, sale prices / dates, color, condition, etc.) – far beyond the basic Schema markup provided by the WooCommerce plugin itself.
WPSSO Core Pro can also read several custom WooCommerce product attributes, if / when you create them in your WooCommerce store:
Additional information on managing custom product attributes is available in the WooCommerce integration notes for WPSSO Core.
There are several ways to add aggregate ratings — as I’ll explain below — but first, before we dive into the “How”, let’s talk about what an “aggregate rating” actually is. ;-) The Schema.org website defines the Schema aggregateRating property value as:
The overall rating, based on a collection of reviews or ratings, of the item.
Two things to keep in mind about this:
- An aggregate rating value is calculated from several customer ratings / reviews for the current webpage content (an e-commerce product review, for example).
- Google prefers — and often double-checks — that Schema markup reflects the current content of the webpage. So, if you want to manually set aggregate rating and/or review values in your Schema markup, make sure that these customer ratings and/or reviews also appear in your webpage content (ie. the ratings and reviews are visible).
Google reads a variety of structured data from webpages, including e-commerce Product details, Recipes, Reviews, etc. — along with three standard Schema types from a website’s homepage: WebSite, Organization, and Person.
In this post we’ll focus on the Organization markup — using Google’s preferred LD+JSON structured data format — which Yoast SEO, WPSSO Core, and most SEO plugins add to a WordPress site’s homepage.
Google uses the Organization markup to enrich its Knowledge Graph information for the website’s Organization (aka Business, Corporation, etc.).
See Google My Business, Your business information in the knowledge panel, and Improve your local ranking on Google for more information on Google’s Knowledge Graph and local business markup.
See Google’s About Search Features and Structured Data General Guidelines for more information about the current Schema types recognized by Google.
WPSSO Core (and its add-ons) can be used by themselves, or in combination with Yoast SEO and other popular SEO plugins — WPSSO Core will warn of any conflicting plugin settings and the Pro version of WPSSO Core includes integration modules to read post / term meta from all the popular SEO plugins. The following examples were created using the Free versions of Yoast SEO, WPSSO Core, and its Free add-ons.
It’s been a very productive two weeks of coding for both the WPSSO Core plugin, and it’s WPSSO Schema JSON-LD Markup add-on.
On April 26th – just two weeks ago – WPSSO Core v4.0.0 was released, which included support for the new Gutenberg editor. Since then, WPSSO Core v4.1.0, v4.2.0, and v4.3.0 were also released (the last one just today), along with WPSSO JSON v1.25.0 and v1.26.0.
In case you missed all the update notices and posts about those versions, the following is a quick summary of the big changes and improvements in both WPSSO Core and its JSON-LD add-on. And at the end of this post, you can also find a summary of our release schedule philosophy, and why we chose to release four big improvements, in four different versions, in just two weeks. ;-)
The release of WordPress 5 and the new Gutenberg editor are just around the corner, and Gutenberg developers still have not tackled a serious design issue with the current Gutenberg notification system — notices in Gutenberg are being displayed over the content area, forcing users to dismiss notifications to gain access to their content — and in some cases, where several non-dismissible notices are displayed, users may not have access to the content area at all.
The notification system in the current version of WordPress is nothing fancy — and can feel a bit intrusive when several notices are displayed at once — but it’s a lot more flexible and functional than the proposed Gutenberg notification system. :-) As an example, here are some typical SSO (Social and Search Optimization) notifications when editing a test post in the current version of WordPress, in the Gutenberg editor, and with the upcoming release of WPSSO Core v4.2.0 that moves SSO notices into the admin toolbar.
The new Gutenberg editor for WordPress v5 may not be ready yet — and I can certainly attest to that, lol — but it’s coming soon, and WPSSO Core is ready for Gutenberg!
This latest version of WPSSO Core (scheduled for release this week) includes several key changes aimed specifically at integrating WPSSO Core with the new Gutenberg editor. The Document SSO (Social and Search Optimization) metabox is now refreshed when the Gutenberg post is saved, and any SSO notices are displayed using the new Gutenberg notification system. The notices themselves have also been improved by including more information about the dismiss button — either simply hiding the notice (Gutenberg default), temporarily dismissing it for 1 hour, 3 months, etc, or dismissing it permanently.
Have you tried the Gutenberg editor yet?
WordPress v5 is coming soon, and if you haven’t tried the new Gutenberg editor in a staging environment (contact your hosting provider for details), then you could be in for a major surprise! Many plugins will not be compatible with Gutenberg, and for those few and rare plugin authors that are still actively maintaining their plugins, updates to support the Gutenberg editor may take some time. Save yourself the headache – install the Gutenberg editor in a staging environment now, and make sure all your plugins are compatible. ;-)
WPSSO Core v4.0.0 beta is available now.
If you’re a WPSSO Core Pro user — and have a staging environment — you can select the “Beta and Up” version filter for WPSSO Core in the SSO > Update Manager settings page, to install and test the latest beta version. You can also re-select the “Stable / Production” version filter at any time to re-install the last stable / production version.
There’s an exciting new cache feature coming in WPSSO Core v3.56.0 — a new “Auto-Refresh Cache After Clear All” option will be available under the SSO > Advanced Settings > Cache Settings tab (Pro version).
One of the interesting things about WPSSO is that most cached objects, like meta tags and Schema JSON-LD markup, are created and stored as arrays, independent of the webpage. This makes it possible to loop through all post, term, and user IDs, and re-create those arrays easily — again, completely independently of the webpage (or WordPress action hooks), so no HTTP connection is required — which makes for a very fast and efficient way of creating (or re-creating) cache objects! ;-)
The new “Auto-Refresh Cache After Clear All” option is enabled by default. When you click the “Clear All Cache” button (from any settings page), the WPSSO cache will be cleared and a background task will be started to re-create all the missing WPSSO cache objects. The same class method is also called when the plugin is activated, to optimize the speed of all front-end webpages and back-end editing pages. :)
WPSSO Core v3.52.0 includes a new “Robots” option for search engines / SEO in the post edit Publish metabox (see the changelog here). Uncheck the “meta name robots” option under the SSO > Advanced > Head Tags List > SEO / Other tab to hide / exclude the “Robots” option from the Publish metabox (enabled by default if no SEO plugin is detected).
This new WPSSO Core version includes a new “Person” role for users – this role is added to all new users by default. You can uncheck the “Add Person Role for New Users” option under the SSO > Advanced > Integration tab to disable this automatic feature (enabled by default). The “Person” role will be used by WPSSO JSON for selects requiring a “Person” role for its Schema markup.
WPSSO Core v3.53.0 also includes fix for the image upscale feature – an incorrectly named variable prevented the proper calculation of the image upscale size.
Once in a while a WPSSO Core user will ask me how to disable notices from WPSSO for small images — they reason that images uploaded to their Media library are sized correctly beforehand, and they cannot re-upload larger images without significantly altering their content layout (including huge images, instead of smaller ones, in their post content). For example, if a user requires a 300x200px image for their content, they upload a 300x200px image to the Media library. What they don’t realize is that WordPress isn’t meant to be used this way and they’re breaking an essential WordPress feature by doing this — not to mention that WPSSO will probably reject the image for being too small for Facebook Open Graph meta tags and Google Schema markup requirements. :-)
WordPress and several 3rd party plugins provide different image sizes based on the resolution of the viewing device (aka responsive images). For example, a 300x200px image in your content will look blurry on high resolution screens (almost all current mobile phones, tablets, and laptops) because the browser must “upscale” the image to 450x300px or 600x400px in order to fill a 300x200px space on these high resolution screens. WordPress includes additional image markup in the webpage to provide alternative sizes (300x200px, 450x300px, and 600x400px for example), which allows the browser to choose the appropriate image based on the screen resolution. If you upload a 300x200px image to the Media library, WordPress will not be able to offer these additional image sizes, and WPSSO will not be able to use this image for most social sites and search engines (which have minimum image size requirements).
So, what should you do if you want a 300x200px image in your content?
That’s what WordPress image sizes are for. ;-)
A number of WPSSO Core customers using JetPack have reported that shortlinks no longer work for Custom Post Types (CPTs). According to JetPack, this is a feature, and PHP code specifically for this JetPack feature must be added to your functions.php file — or an additional property added to the Custom Post Type definition. Unless you have made these PHP code changes, JetPack will break the WordPress
wp_get_shortlink() function for all Custom Post Types.
Because of this new JetPack feature, older versions of WPSSO Core (before version 3.48.7) may show a warning on Custom Post Type editing pages that the post shortlink is empty — which also prevents WPSSO Core from checking the current post webpage for duplicate meta tags. Additionally, the WordPress “Get Shortlink” button on post editing pages and the
link rel="shortlink" HTML tag in webpage headers will be missing.
WPSSO Core version 3.48.7 now checks for empty values returned by the
wp_get_shortlink() function and provides a correct shortlink URL. This not only addresses the new Jetpack feature, but also fixes incorrectly coded themes that disable the
link rel="shortlink" HTML tag by returning an empty shortlink value (a violation of the WordPress theme guidelines).