What’s New in WPSSO Core v15

The common way to create Schema markup for WooCommerce product variations in the past has been to create multiple Schema offers for a product – one offer per variation. Unfortunately, the Google merchant crawler has always been very unreliable when reading offers, sometimes being able to read product offers, and sometimes not. Even now, after Google added merchant validation to their Rich Results Test tool, it does not guarantee that the Google merchant crawler will be able to read Schema markup as predicted by Google’s test tool.

Some structured data plugins have attempted to work around the limitations of Google merchant’s crawler by offering different Schema markup when query arguments for variation attributes are present in the URL. WooCommerce creates a single webpage for a product (like WordPress does for a single Post or Page), and javascript is used to adjust the information displayed based on URL query arguments for variation attributes – but there still is only one singular HTML webpage for a product. Some structured data plugins break this single product webpage by adjusting the Schema markup to include only the variation offer when URL query arguments are present. This has some serious drawbacks as the WooCommerce product webpage can no longer be cached, the canonical URL value is now invalid (ie. points to the main product page, which has different markup), and search engines traditionally ignore query arguments, which means they are seeing different markup for the same URLs. Breaking the WooCommerce product webpage might help fix Google merchant’s limitations, but it does so at the expense of search engine ranking.

So, how do we preserve the single webpage for a WooCommerce product with variations?

Continue reading


Better Schema Markup for WooCommerce

WPSSO + WooCommerce logos.

WooCommerce is a popular e-commerce plugin, with a solid and well designed code base, but WooCommerce is not an SEO plugin – its Schema markup for search engines is minimal and it does not provide any social meta tags for Facebook, Pinterest, Twitter, etc. This guide provides a quick and easy solution to fix your WooCommerce product Schema markup and meta tags.

Warnings for WooCommerce Markup

The Google Rich Results Test Tool, Schema Markup Validator, or the Google Search Console may report one or more of the following errors for the Schema markup provided by the WooCommerce plugin:

Continue reading


Shipping Delivery Time for Google Rich Results

WPSSO + WooCommerce logos.

In September 2020, Google announced support for shipping details in Schema Product Offers and how shipping details would be presented in search results. Adding the new shippingDetails property to your Schema Product markup is especially important if you offer free or low-cost shipping, as this will make your products more appealing in search results.

In October, Surnia Ulula announced support for shipping details in the WPSSO Core Premium plugin, to provide both the Google recommended Schema OfferShippingDetails shippingDestination and shippingRate properties for WooCommerce products. Although these two properties are enough to satisfy Google’s recommended shipping details markup, the Google validator now warns that an additional deliveryTime property is recommended.

The deliveryTime property should be a Schema ShippingDeliveryTime type that includes businessDays, cutoffTime, handlingTime, and transitTime properties. The data for these four properties can be managed with a new WPSSO Shipping Delivery Time for WooCommerce add-on.

Continue reading


LinkedIn Now Prefers oEmbed Data Instead of Open Graph

When you share a URL on a social site like Facebook, Twitter, LinkedIn, etc., that social site crawls the webpage in background to read the meta tags and structured data markup (aka Open Graph meta tags, Twitter Card meta tags, Schema JSON-LD, Schema microdata, etc.).

Social sites like LinkedIn generally require an image, a title, and a description to display a share. A few social sites like Pinterest and Twitter can also display additional information for products, recipes, mobile apps, videos, and more.

Until recently, the LinkedIn crawler read only Open Graph meta tags to get the webpage image, title, and description, but recently they’ve started reading oEmbed data as well, and if oEmbed data is available, LinkedIn prefers those values over the Open Graph values.

Continue reading


Why WordPress Image Sizes for Social Sharing and SEO?

All social and SEO plugins – except one that I know of – use the full size image URL from the WordPress media library when adding image meta tags to the webpage (ie. og:image, twitter:image, etc.), and/or adding images to Schema JSON-LD markup for the webpage. This can be problematic for several reasons…

  1. The image resolution may be too small.
  2. The image resolution may be too large and the file size too big.
  3. The aspect ratio (width or height) may exceed a maximum value.
  4. The image displayed on the social / search site is center cropped.

Continue reading


WPSSO Ditches WordPress & Gutenberg Notifications

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.

Continue reading


WPSSO – Why You Shouldn’t Upload Small Images

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. ;-)

Continue reading