Yoast: why I removed it from WordPress
Yoast is a popular plugin for WordPress that promises to improve your Search Engine Optimization. It offers tools and advice to tweak your posts and (hopefully) raise your ranking on Google and Bing, or make it more visible when shared on social media.
I’ve used it for several years on various sites, and with clients. When it was time to rebuild this site, I took a long, hard look at what it did and how that made my life better.
In this article I’m going to look at what Yoast does, what’s really needed for SEO and step through my thinking in building my own simpler plugin to replace it.
What does Yoast do?
To start with, Yoast doesn’t improve your SEO. What it does is look at your content, applies generic rules and offers “advice” on how to improve it. These recommendations cover:
- how “readable” the text is
- keyword presence
- internal and external links
- content structure.
It then provides a means for you to record and amend “meta data” that describes the content and its purpose. This includes:
- title and description used by Google, Bing etc
- customized “social sharing” cards for Facebook and Twitter
- Open Graph data describing the content’s purpose
When a post is saved, it generates a sitemap used by search engines to find content.
Finally, it adds the “meta data” to your site’s html when a post, page or index is presented to a visitor, search engine, bot and so on.
Is Yoast useful?
In my workflow Yoast isn’t as powerful as it claims. Content is created outside of WordPress, and by the time it arrives in the editor it’s already been through the SEO mill. All I’ve been using it for is setting up the Open Graph Protocol data, which WordPress doesn’t support.
The way Yoast stores data is also suboptimal. Each piece of data is saved as an individual field in the database, which requires excess resources to load. On a small site with low visitor numbers this might not be apparent, although it could become an issue as traffic grows.
Overall, I find Yoast is a plugin that carries a large overhead for little added value.
Building my own WordPress plugin
In keeping with my design philosophy of “keep it simple” what I need isn’t a fully featured SEO plugin. All I need is a way of recording the Open Graph meta data and presenting it in the HTML WordPress generates.
(The sitemap is now part of WordPress core, and you can read how I customized mine here.)
I created my first plugin to do this half a decade ago and have been tweaking it ever since. The rebuild of this site was an opportunity to revisit my code and rewrite it from the ground up.
The Open Graph Protocol is a data model used by many search engines and social media sites to describe content. Capturing and presenting this is the core function of my plugin.
The data I’m interested in is:
- the document title
- a short, 150 character description that’s presented in snippets, social media cards etc
- an instruction to search engines whether to index the content or not
- a content type from the Open Graph schema
- a canonical URL if I want this page’s SEO performance to be passed to another.
As I’m not using this data for searches, I store it as an array. That means all data is held in a single field in the WordPress database, and triggers one call for each save or pull.
Aside from being more efficient, it also makes the code easier to work with.
The Gutenberg editor
Instead of Yoast’s noisy, multi-tabbed interface, I created a simple form with minimal prompts and text. Defaults from the content and except for the canonical URL, can’t be blank.
I’ve also taken a decision not to create separate Twitter / Facebook fields. My hypothesis is the text the person sharing my content adds to their post will influence click-thru behavior more than text I’ve wasted time “customizing” to a particular platform.
The post/page indexes
While Yoast shows a “traffic light” scheme of how readable and SEO friendly a post is, I saw this as a distraction and of little value. As such, I chose not to add superfluous information to these pages.
Meta tags are generated dynamically using the wp_head hook. If a meta tag doesn’t have a value in the post’s record, it uses the post’s equivalent data.
Some meta tags are hardcoded in the wp_head hook function, which I will discuss in a future post.
I have added meta tags specific to Twitter’s “card” interface. When shared on Twitter, it should present a “large image card” with references to my Twitter account. Other social sharing platforms such as LinkedIn, Facebook and Tumblr appear more than comfortable with an Open Graph description.
Below: the meta tags generated by my code.
<meta name="og:locale" content="en_US" /> <meta property="og:title" content="Kobe Sports Park Revisited - [Ross Hori]" /> <meta name="og:description" content="While it might be home to a major baseball team, Kobe Sports Park has far more to offer: like adventure playgrounds and scenic walks." /> <meta property="og:url" content="https://ross-hori.com/2022/09/05/kobe-sports-park-revisited/" /> <link rel="canonical" href="https://ross-hori.com/2022/09/05/kobe-sports-park-revisited/" /> <meta property="article:published_time" content="2022-09-05T09:00:00+00:00" /> <meta property="article:modified_time" content="2022-09-14T08:37:01+00:00" /> <meta property="og:type" content="Article" /> <meta property="og:author" content="Ross Hori" /> <meta property="og:publisher" content="Ross Hori" /> <meta property="og:image" content="https://ross-hori.com/wp-content/uploads/2022/09/giant-slides-at-kobe-sports-park-scaled-1-684x1024.jpg" /> <meta property="og:image:width" content="684" /> <meta property="og:image:height" content="1024" /> <meta property="og:image:alt" content="Black and white photograph of a childrens slide coming down a hill side with another slide curving over the top" /> <meta name="twitter:title" content="Kobe Sports Park Revisited - [Ross Hori]" /> <meta name="twitter:description" content="While it might be home to a major baseball team, Kobe Sports Park has far more to offer: like adventure playgrounds and scenic walks." /> <meta name="twitter:site" content="@ross_hori" /> <meta name="twitter:creator" content="@ross_hori" /> <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:image" content="https://ross-hori.com/wp-content/uploads/2022/09/giant-slides-at-kobe-sports-park-scaled-1-684x1024.jpg" /> <meta property="twitter:image:alt" content="Black and white photograph of a childrens slide coming down a hill side with another slide curving over the top" /> <meta name="robots" content="index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1" />
I’m using the core WordPress sitemap, which I’ve customised. One part of this is using my plugin’s “should I index this page” flag to determine what should be on the default sitemap.
As this code will likely live beyond the life of the theme, it’s deployed as a plugin. The code’s structured so that the admin code is only loaded when the admin interface is active.
This slimmed down approach hasn’t required changes to my way of working. This may be because I was already bypassing Yoast and using other tools to validate much of my SEO work.
If you haven’t done this, these are the main areas to consider in your content workflow.
If you do the work to get SEO right before committing text to WordPress you’ll get better results faster. Identify your keywords and potential links in advance, use them sensibly in the text and structure it with headings, lists and other SEO essentials.
Do this during your drafting and editing, and you’ll soon produce readable, SEO friendly text faster than trying to fix problems Yoast thinks you have later.
Text that’s relatively easy to read can be tricky to get right. Yoast generated a score on the Flesch Reading Scale, which is a bit crude. You could look at alternative tools such as WebFx, which offers a free calculator.
How many times your target keywords appear per 100 words? This is the “keyword density”, and it’s a topic that’s been around as long as search engines. Some in the field claim it should be 2-3 times per hundred words, others say it doesn’t matter. My rule of thumb is 3-4 times in an article, as long as it doesn’t make it repetitive and boring.
If you want to find your keyword density do a word search in your text, then divide the total number of words by the number of instances of your keyword. Again, this is one of those tasks that tends to happen during drafting.
If you decide to remove Yoast from your site, you need to consider how you will manage SEO and social sharing. The key questions you should answer are:
- how do you change your workflow to validate SEO, readability etc before publishing?
- how will you insert Open Graph meta tags into your HTML for search engines and social sharing?
- what changes to the default WordPress sitemap are needed to expose only the content you want indexed?
There is also a technical consideration. After being deleted, Yoast leaves its data in the WordPress database. You may wish to clear this out, although I’d suggest waiting a few weeks in case you decide to reactivate it.
I’ve been using a home-spun SEO plugin for a few years, sometimes alongside and sometimes instead of Yoast. My data suggests as a final check Yoast is OK, but it doesn’t have a meaningful impact on SEO. That comes from all the things that happen before words are added to WordPress in keyword research, editing and structuring.
If you are going to remove it, I hope what I’ve outlined here helps you construct something more useful and focused.