SEO Tip #1 The Yoast Bug

Robin asked me to write a “tip of the day” today, I can’t remember what the topic she mentioned but I liked the idea so I’m going to run with it and begin with my first SEO Tip #1 The Yoast Bug. Thinking about what the first tip should be, I immediately thought about the worst issue I’ve seen in about half of the last 10 sites I’ve performed an seo audit on recently – yes it’s the infamous Yoast Bug! Even 5 months after the bug appeared and warnings began flooding WordPress forums we’re still seeing affected sites going unfixed, so in this article I’ll describe the Yoast Bug and help you diagnose if your site is safe and fix it if it’s not!

What is The Yoast Bug?

Simply put, it’s attachment pages. Even worse, it’s attachment pages that are indexed in your sitemap and likely Google’s index as well. If you use Yoast, like most WordPress users do, then you might not have ever noticed this obscure setting in your admin panel at SEO > Search Appearance > Media > Media Attachment & URLs

This is The Yoast Bug, sort of. It all really starts with Yoast Version 6.3.1 – everything was great. Then Yoast version 7.0 was released in March and all of a sudden large swathes of user’s setting for “Redirect attachment URLs to the attachment itself?” was turned off. It was a quiet change that was specific to only two versions of Yoast, however, for affected sites it caused a major issue.

Why was The Yoast Bug so disastrous?

The Yoast Bug was bad because it instantly created entries in your Yoast-driven sitemaps that pointed to attachment page urls – and these urls were no longer redirected to the parent post as they were in the previous versions. Some people might think at this point “great that’s more pageviews right?” yeah sure, but at what cost? When your attachment pages get indexed at Google a few things happen:

Average SERP (search engine results page) rank goes down.
User Experience plummets > visitors from search engines might get confused clicking a result link at Google and landing on a barren page.
Google will slap a thin-content penalty on your site (an attachment page is just your header, sidebars, footer and the image in the content area afterall).

The effect of all these factors results in lost traffic from search engines, most people affected by the bug saw a drop of around -50%. That’s a significant loss of traffic and potential revenue over such an easily fixed issue.

How can I find out if I’m affected?

First, check your setting in Yoast at SEO > Search Appearance > Media > Media Attachment & URLs, is the redirect turned on? If it’s on, you most likely are OK. Another way to check is by going to your Google Search Console account and opening the property for your live site, then go to Google Index > Index Status, you should see a graph like this:

See the big jump from March 10-11? That would be the day this site updated to the buggy version of Yoast and fell victim to the bug, now their indexed urls on Google are flooded with barren attachment pages. If you’re wondering how this particular sites traffic performed, nothing changed for about 3 weeks after the bug at which point all stats for search engine traffic began a marked downward spiral, check out this chart for their Search Console showing their clicks from Google search:

The preceding 12 months were sustained positive growth.

How can I fix the Yoast Bug?

You have two options, we recommend option 2 for the best results as it is the seo-friendlier option.

Option 1:

Go in your site admin to SEO > Search Appearance > Media > Media Attachment & URLs. Turn on the image redirect “Redirect attachment URLs to the attachment itself?” – set this to yes. This will automatically remove the attachment pages from your sitemap and those attachment page urls will redirect to the media file automatically. Eventually Google will de-index those urls and everything will be kosher, in the meantime expect Search Console to wig out and send you a lot of notices for 404s or other errors as it attempts to figure out what’s going on.

Option 2 (recommended):

Install this plugin Yoast SEO: Search Index Purge. It’s easy, the plugin automatically does its thing, so just install + activate and you’re done, for now. The index purge plugin will mark your attachment page urls as noindex which will prompt Google to de-index ASAP, in addition to the noindex it also redirects those urls to their media file. You’ll notice your attachment pages remain intact in your sitemap while this plugin does its thing, this is good because you want all those attachment pages to get crawled so googlebot will see the noindex tag and begin the purge process. Yoast recommends leaving the purge plugin running for 6 months, though in real world practice we’ve seen sites ready to go in 2-3 months. To know if you are ready to remove the Index Purge plugin just check your Search Console to see if your indexed urls has gone back to normal levels:

This site is almost done purging attachment pages, maybe 3 more weeks and we should be safe to remove the purge plugin and call it a day on this issue. Important Note: After removing the Index Purge plugin it is imperative that you make sure your redirect is turned on at: SEO > Search Appearance > Media > Media Attachment & URLs.

Final thoughts about the Yoast Bug

It’s a very simple bug to fix, whether you skip the hubbub and just set the redirect or go through the extended process of using the index purge plugin, the main thing to take away from this issue is that it’s still a major problem on a lot of sites. The clients still running this major bug of course heard about the bug, everyone heard about the bug, they just thought they were okay about it or didn’t know exactly how to check. I hope this article has helped someone understand the bug better and figure out how to diagnose your site for the bug and apply a fix, feel welcomed to comment below if you have any further questions or comments 🙂

Bonus SEO tip

Since this is the first in a series, I’ll celebrate with a bonus tip! This tip comes hot out of the trenches of recent SEO Audits as one of the most common technical pagespeed issues: Fonts, specifically external fonts… How many of you have added multiple fonts to your site from places like Google Fonts? Would you be surprised these fonts are slowing your website down by 2 seconds or more? We’ve seen sites using Google’s external fonts imported using the easy tags like this: <link href=”https://fonts.googleapis.com/css?family=Lato:300|Open+Sans:400|Roboto+Condensed:400″ rel=”stylesheet”> It looks like a tiny little script to plop in your <head> right? Lets see what happens with those fonts applied to WordPressTechs: Before:

After:

Wow, a small loss in YSLOW but look at that load time! Pagespeed has nearly doubled just from adding 3 external Google fonts. If we added different font weights like light or bold or included italics it would have been even worse. In some sites we see upwards of 20 fonts causing massive loss in pagespeed.

How do I fix my slow fonts?

Install them locally on your hosting account and use them in your theme using @fontface and css styles for your content. To install is pretty simple:

Download the fonts, at Google Fonts you can download selections made by clicking the little download button in the upper right hand corner of the “fonts selected” section.
Unzip those fonts and head over to FontSquirrel’s webfont converter. Run those .tff files through the generator, when it’s done you’ll get a zip download of all your web-optimized fonts (a.woff and .woff2 file per .tff font).
Upload the .woff and .woff2 fonts to your hosting account, you can put these anywhere in your hosting account but we recommend adding them to your theme since that’s where they will be configured (example make a new folder at /wp-content/themes/your-theme/fonts).
Add the @font-face code to your theme’s style.css
Edit your theme’s style.css for entries related to content you want using your font (example: search for h1 to edit the css for h1 header tags)

Example @font-face Installation

Edit your theme’s style.css (in WP admin go to Appearance>Editor) and add this: @font-face { font-family: ‘lato’; src: url(‘https://yourwebsite.com/wp-content/themes/your-theme/fonts/lato-regular-webfont.woff2’) format(‘woff2’), url(‘https://yourwebsite.com/wp-content/themes/your-theme/fonts/lato-regular-webfont.woff’) format(‘woff’); font-weight: normal; font-style: normal; } Now to make something like my h1 and h2 tags use this new font I’d edit these entries in my style.css: h1, h2 { font-family: lato; } Now my h1 and h2 titles will use the font “lato” that I just installed and instead of downloading the font from Google the visitor will grab it right from my site, faster because they already have an open connection to my domain and downloading other files.

Font Speed Conclusion

Some may argue it’s not worth optimizing because the user only needs to download the fonts once and additional pages will have the fonts cached, while that’s true you also have to remember = first impressions are everything. If you landed on the WordPressTechs page for website optimization and the pagespeed was really slow, would you consider going forward with buying our service? Probably not. Everybody already knows that old webmyth “users close a window if the page doesn’t load in x seconds”, while that’s true for a lot of web surfers you also have the reputation-factor to consider, do you want a visitors first impression of your website to be that it’s slow loading? Additionally, for sites running ads you already have a long pageload, so trimming 2 or 3 seconds here or there can really make a big difference in your overall User Experience strategy, best not to let this tedious but fruitful fix go unchecked.