WPSSO’s purpose is to create the best and most complete Schema markup, not to “streamline website management” at the cost of lower search/social ranking and click through rates. If there are errors in the Schema markup (ie. missing image, image too small, etc.) WPSSO will show an error message with information on how to fix the error. Serious errors that affect search/social ranking or create errors in Google’s search/merchant console, for example, cannot be dismissed and need to be resolved. If you prefer to hide or ignore errors about required values in your Schema markup and meta tags, then WPSSO is not the plugin for you (as you’ve found) – there are many other SEO plugins that focus on user experience instead of their resulting markup. If you’re looking for the best and most complete Schema markup, then WPSSO is the best choice for that – as the WPSSO description mentions, WPSSO fixes and prevents all the following Google errors (and many more – this is just a short list):
- A value for the headline field is required
- A value for the image field is required
- A value for the logo field is required
- A value for the publisher field is required
- Either “price” or “priceSpecification” should be specified (in “offers”)
- Invalid value in field “priceSpecification”
- The aggregateRating field is recommended
- The brand field is recommended
- The headline field is recommended
- The image field is recommended
- The review field is recommended
- Missing field “address”
- Missing field “aggregateRating”
- Missing field “brand”
- Missing field “businessDays”
- Missing field “cutoffTime”
- Missing field “deliveryTime”
- Missing field “hasMerchantReturnPolicy” (in “offers”)
- Missing field “image”
- Missing field “priceRange”
- Missing field “review”
- Missing field “shippingDetails” (in “offers”)
- Missing field “telephone”
- No global identifier provided (e.g. gtin mpn isbn)
- Not a known valid target type for the itemReviewed property
- Price Mismatched value (page crawl): (price [price])
js.
As a developer managing multiple WordPress sites, I initially gave WPSSO a try for its Schema support. Unfortunately, the plugin’s rigid design and overwhelming admin notices made it a poor fit for real-world scenarios.
On one site with hundreds of published pages, we added WPSSO late in development. Because many older images didn’t meet the recommended size, the plugin began displaying dozens — sometimes over a hundred — notices on every admin page load. I understand the importance of fixing Schema warnings, but being bombarded with non-dismissible messages makes the cleanup process frustrating and counterproductive.
On another site using WooCommerce, we built a custom product showcase that collects inquiries instead of processing payments. For UX and tracking purposes, we intentionally avoided using a standard checkout page. WPSSO, however, kept insisting on a missing payment page and refused to let us dismiss or silence the warning. Ironically, when I did set a fake checkout page to satisfy WPSSO, it broke key functionality in our lead funnel.
These are just two examples of how WPSSO enforces a one-size-fits-all approach that doesn’t accommodate edge cases or custom builds. Worse, the developer makes it clear they have no intention of addressing these concerns — users are told “if you don’t like it, use another plugin.”
I’ve since removed WPSSO from all projects. If your site setup deviates even slightly from standard patterns — or if you value control over your admin dashboard — you may want to look elsewhere.
WPSSO may report Schema markup and/or meta tag errors when editing or updating a published post. Generally there are no issues to report and no notices.
WPSSO can create update, informational, warning, and/or error notices – although only errors are shown automatically in the current version. An error message is typically about an issue that will affect search results or social engagement negatively. We do assume that this is important to our users.
I understand that some users have old sites with small images – unfortunately small images often cannot meet the minimum requirement of search engines and social sites. For example, a 600px container (which most people would consider a small size) on a website needs a 1200px image to display properly on high resolution displays. High resolution displays and responsive images have been around for many years now, but some old sites may not have been created using WordPress image size features as they should have (ie. a full size image is uploaded and themes/plugins request image sizes by name, which WordPress then creates as needed). In some cases 600px images have been uploaded to be displayed in 600px containers. That is unfortunate as the minimum size to meet all search and social requirements is 1200x1200px. If there are no images found attached, featured, or in a post, for example, WPSSO will show an error message as an image is required (and Google even prefers 3 different aspect ratios of each image). WPSSO does suggest a few ways to fix this, and even offers image upscaling, although upscaling can only be done up to a certain point. 🙂 We have a FAQ that outlines the reasons why uploading small image is not a good idea. https://wpsso.com/docs/plugins/wpsso/faqs/why-shouldnt-i-upload-small-images-to-the-media-library/
You mention the lack of a WooCommerce checkout page, which yes, WPSSO would report if a checkout page was missing and/or incorrect in the WooCommerce settings (ie. a checkout page ID that does not exist), as the WooCommerce checkout page requires specific Schema markup (the account, cart, checkout, and shop pages all require specific markup) and WPSSO must know which post ID is the checkout page. An issue has never been reported with this check, either in the WPSSO support forum or in the Premium support site, so I’m afraid that we cannot be aware of an edge case like you describe if it’s never reported.
js.
Thank you for the explanation — but I think you’re missing the actual point of my complaint.
The issue is not that WPSSO reports Schema or image-related errors. I understand the value of complete markup and proper image dimensions. What’s frustrating is how those notices are handled in the admin interface.
The notices are intrusive, repetitive, and impossible to dismiss. They appear directly in the post edit screen, cluttering the interface and disrupting normal workflow — especially on sites with legacy content. I might already be aware of the issue and plan to fix it later, but the plugin forces me to look at these alerts every single time, with no option to hide or pause them.
This kind of behavior doesn’t help productivity — it gets in the way. I’ve worked with many plugins over the years, and WPSSO is the only one that shows this level of inflexibility in its admin UI. It feels like you’re punishing users for not meeting your standard immediately, even when we have valid reasons.
Whether or not this affects SEO is not the point. I need to be able to work inside the WordPress admin without having to fight through a wall of yellow notices. It’s frustrating, it’s exhausting, and honestly, it makes WPSSO hard to use on real-world projects — regardless of how technically accurate the plugin might be.
It sounds like you are working on an old site with content that does not meet social and search site requirements (ie small or missing images, pages, etc.), while at the same time using a plugin like WPSSO that attempts to create complete and accurate meta tags and Schema markup for social and search sites.
I’m not sure if you see the inherent conflict there – you would either need to update your content, or use a plugin that isn’t so focused on the quality of the Schema markup and meta tags it produces.
js.
I understand the conflict you’re describing — and I never said I expected WPSSO to ignore markup issues.
But again, the problem isn’t with WPSSO checking for errors — the problem is with how those notices are displayed. I’m not trying to avoid fixing the issues. I’m actively working on improving content across multiple sites, but that doesn’t happen instantly, especially when dealing with legacy content or customized implementations.
What’s frustrating is that WPSSO floods the admin area with persistent, non-dismissible notices that actively get in the way of day-to-day work. It’s like being shouted at every time I open the dashboard — even when I already know what needs to be fixed and have plans to address it.
There’s a big difference between helpful feedback and disruptive behavior. Right now, WPSSO crosses that line — not because it cares about Schema quality, but because it refuses to let users work around known, ongoing issues during a transitional phase.
So to be clear: I’m not choosing bad content over good markup. I’m saying WPSSO makes the process of improving content harder than it needs to be.
And if you think I’m attacking you or leaving unfair criticism, you might want to look at your own support forum — there are plenty of other users frustrated by the exact same issue with notices.
-
This reply was modified 6 months, 3 weeks ago by
Tianyistudio.
If you’ve activated WPSSO on an old site that doesn’t use WordPress image size names (for example, where small image thumbnails were uploaded instead of full size images), you can expect at least two error notices when editing a post (for example, a missing Schema markup and Open Graph meta tag image) as WPSSO looks for proper images (see https://wpsso.com/docs/plugins/wpsso/faqs/how-does-wpsso-find-detect-select-images/) and doesn’t find any. WPSSO is a WordPress plugin that was designed around WordPress features, like properly coded themes that use image size names. Using the WordPress Media Library correctly also means that your theme can provide images for high resolution displays, responsive layouts for varying display sizes/shapes, and image sizes that Google, Facebook, etc. require. On a properly designed site, you wouldn’t see any notices from WPSSO unless you’d forgotten to add an image when publishing a post or forgotten some other basic WordPress or WooCommerce configuration settings – the checks that WPSSO performs are designed for this – as a reminder. If you’ve activated WPSSO on an old site that you know isn’t designed, coded, or been managed properly, WPSSO is likely to show a lot of error messages. The issue isn’t the WPSSO plugin, the issue is the site. You can deactivate WPSSO, fix the site and reactivate WPSSO, or ignore the site issues and use a different Schema and meta tag plugin that doesn’t rely on WordPress and WooCommerce being configured and used properly – there’s lots of choices for those.
js.
I think you’re still missing the core of my feedback.
I’m not refusing to fix the Schema issues. I fully understand the importance of proper image sizes and valid markup. But that’s not what I’m complaining about.
The real issue is that WPSSO forces error notices into the admin UI without giving users any way to hide, dismiss, or control them. On a site with hundreds of posts, this becomes a serious usability problem – not an SEO problem, a workflow problem.
You’ve said multiple times that “the issue is the site, not the plugin,” but that’s not a reasonable excuse. A good plugin should be able to deliver useful information without overwhelming or disrupting the admin experience. Constant, unremovable notices on every post edit screen is not good UX. It’s unnecessary, and frankly, it’s arrogant to assume users should either fix everything instantly or stop using your plugin.
Even just moving the notices to a less intrusive place, or giving a checkbox to hide them temporarily, would show that you care about user experience. But from your replies – and from the many similar complaints in your own support forum – it seems clear that you’re unwilling to listen.
If you think I’m the problem, I invite you to search your plugin’s support threads – this notice issue has been raised again and again by different users. The feedback is there. You’ve just chosen to ignore it.
I’m sorry, but that’s not a good look for a plugin that claims to care about “doing things the right way.”
I appreciate your insistence on standards and correctness — I really do. But let me try to reframe my feedback with a simple analogy:
Imagine I’m driving a car built by your company. Every time I go even 1 km/h over the speed limit, or don’t come to a perfect full stop at a stop sign — even when I briefly speed up to overtake or roll slightly over the line to yield for an emergency vehicle — the entire windshield turns yellow with a flashing notice that cannot be turned off.
When I report this experience, hoping for a practical solution, your answer is essentially:
“Speeding is dangerous. If you intend to speed or bend the rules, even momentarily, you shouldn’t be driving our car. That’s not our design flaw — it’s your driving behavior.”
Now I ask you:
Would you keep using that car? Would you recommend it to others?
Or would you simply wish for a more flexible dashboard, one that informs without punishing, and respects real-world usage?
That’s what I’ve been trying to communicate. I don’t object to WPSSO’s standards — I object to the way they’re enforced in the admin interface. A plugin designed for professionals should also respect real-world workflows, not just ideal implementations.
Again, I mean no disrespect — just hoping you can see the user’s side of this.
WPSSO will report an issue only if there is an issue – on most sites there are no issues to report, so no notices. Warning notices can be dismissed (they are contextual to the current editing page), but serious error notices cannot be dismissed – to “dismiss” an error message, the error needs to be fixed. For example, if you’ve published a post (not just saving a draft) without selecting an image (featured, custom, etc.), then WPSSO will show an error notice about the missing image so the error can be fixed at that moment (before Google crawls the published page and shows an error in the search console). WPSSO does not show any warning or error messages usually, and if it does, it’s often just an overlooked WordPress or WooCommerce setting.
What you’ve described is trying to use WPSSO on an old site that was not setup properly and you’re finding that WPSSO is reporting too many warnings and errors. As I’ve said, you have choices – you can deactivate WPSSO, fix the site and reactivate WPSSO (as WPSSO can’t create complete and accurate Schema markup and meta tags anyway, so there’s no use running it), or you can deactivate WPSSO, leave the site as-is and choose a different plugin. Considering the errors that WPSSO is reporting though, no matter the plugin, you probably won’t get very good Schema markup and meta tags from those other plugins either (they likely won’t report any issues though, which sounds like it may be preferable to you).
js.
Thank you again, but at this point it’s clear to me that you do understand the issue — you just choose not to acknowledge it.
As the saying goes: you can’t wake someone who is pretending to be asleep.
Your responses so far unfortunately confirm exactly what I mentioned in the beginning — that your default stance is essentially: “if you don’t like it, don’t use it.”
That’s your choice as a developer, and I respect it. But I also reserve my right as a user to share this experience publicly, as I believe others deserve to know what to expect.
No further replies from me.
If WPSSO is reporting serious issues with your site, you should fix your site. There is nothing to fix in WPSSO, it is reporting issues when issues are detected, and you have a choice to fix those issues or not. If you prefer not to fix serious issues, that affect the quality of the Schema markup and meta tags that WPSSO creates, then you’re probably better off with a different plugin – one that will work with a site that has serious issues. Either way, you probably won’t get good Schema markup and meta tags from any plugin without fixing those issues.
js.
