Why the Yoast SEO bug shouldn’t have affected your SEO

Last March the famous Yoast SEO plugin for WordPress made a release that contained a bug which resulted in thin content pages being made accessible.

Over the weekend, Search Engine Journal wrote about it and the weeks before there were heated discussions going on on Twitter.

What happened exactly?

WordPress automatically generates a page for each image that you include on your website.

Yoast SEO has a setting that lets you redirect these image pages to the post page that the image is included on. This is a nice feature, because those image pages are thin content – they only contain an image. These pages don’t add any value, and just take up search engine’s crawl budget. That crawl budget is better spent on pages that actually matter to your business.

Due to a bug in Yoast, the settings for redirecting the image pages wouldn’t correctly be carried over when upgrading from an older version of the plugin to Yoast SEO 7.0-7.0.2. If you had set up these image pages to redirect, that setting would not always correctly convert to the new setting, leading to crawlable (and indexable depending on your other settings) image pages.

A quote from Yoast’s explanation about the bug:

“…As a result of that, lots and lots of attachment URLs got into Google’s index. Some of those sites are now suffering from Panda-like problems.”

Shortly after the release containing the bug was done, a new release was done with a bug fix, however the original settings could not be restored.

How can this have happened?

Well, shit happens. When people are involved, mistakes are made. That’s Murphy’s law.

But there are two things to consider:

1. The Yoast SEO team should put a better test process in place.
2. Website owners using Yoast SEO plugin should have checked their site after updating the plugin.

The Yoast SEO should put a better test process in place

This bug slipped through, but that wasn’t necessary at all. It’s not that hard to include static website testing in the development cycle.

The Yoast team should host a WordPress website where they never change any content or settings manually and then before publishing a new version of the plugin upgrade the plugin in this environment and monitor whether anything changed about the website.

ContentKing would have caught this easily. And using our APIs this could even be automated to support the Continuous Integration workflow.

To this end we’d like to contribute to minimizing these type of bugs from occuring by offering the Yoast SEO team a free ContentKing account that lets them monitor their test environments.

@Joost: if you’re reading this: I’d be happy to do a call with you and explain how ContentKing can be used in the development process. You can reach me at [email protected]

Website owners should have checked their sites after updating Yoast SEO plugin

If SEO is important to your business, you need to make sure that everything’s fine after a release is made.

And yes, updating a WordPress plugin is considered a release.

Updating WordPress too? YES!

And this goes beyond WordPress, this goes for every CMS.

If you care about your SEO:

1. Monitor your site for on-page SEO issues and changes using ContentKing.
2. Be especially vigilant after releases.

So, what would this have looked like in ContentKing?

I’m glad you asked, you would see a spike in new pages found on the dashboard:

And when you click on the green bar, you’ll jump to the Pages overview showing all new pages that were added:

Who’s to blame here?

Yoast is not the only one to blame here. So are you. If you care about your SEO, you need to go above and beyond that it’s in top shape. You need to monitor for any changes and issues in real-time, so when the shit hits the fan you’ll be alerted immediately.

No more SEO surprises. Give ContentKing a try.