Given that this blog runs on WordPress, I sometimes change the slug of a post to optimize it for SEO purposes. Usually, this involves shortening the slug or removing “stop” words like “the,” “and,” and “of.” If your blog is like most WordPress blogs, you have Yoast installed, and when you edit the slug in WordPress, Yoast will tell you it has created a redirect from the old URL to the new URL, and give you an option to undo it.

The question is: should you undo it?

In this case, I edited the blog post, wanting to change the URL from:

https://www.gmass.co/blog/how-to-sign-up-for-a-gmail-account/

to this shorter, easier-to-remember URL:

https://www.gmass.co/blog/sign-up-gmail/

It turns out, even if you choose to undo the Yoast redirect, the redirect still works.

Why?

Because WordPress automatically sets a redirect from an old slug to a new slug when you edit a post. I’m a WordPress purist, and when a plugin isn’t necessary, I avoid it. Yoast is necessary for other reasons, like being able to control the meta description, the title tag, and other social media header tags for the page, but since WordPress can inherently handle redirects when I edit the URL of a post, I don’t want Yoast to “interfere” with that redirect process.

How do you know whether Yoast or WordPress is doing the redirect?

It used to be that you could easily tell who was handling the redirect by using Chrome’s Developer Tools and looking at the exact Response Headers of the 301 redirect. If you went to the Network tab, and looked at the request of the URL that redirects, you would see this Response Header:

Yoast used to insert the X-Redirect-By header and set it to “Yoast SEO Premium” to let any prying eyes know that it, and not WordPress, handled the redirect. This behavior is no longer present though, and now, regardless of whether Yoast or WordPress does the redirect, the Response Headers are the same, showing WordPress as the source of the redirect:

It’s strange that the header doesn’t show what is actually causing the direct. This makes it difficult to troubleshoot redirection issues. Yoast itself has proposed a standard for this, and it’s possible that a recent WordPress core update is overriding Yoast’s ability to set this header.

If WordPress handles the redirects, why use the Yoast redirect feature?

While WordPress natively handles redirects for posts when you edited the slug, the benefit of Yoast’s redirect feature is that you can redirect any page to any other page even if it’s not related to editing a post.

In my example above, I shortened my URL from https://www.gmass.co/blog/how-to-sign-up-for-a-gmail-account to https://www.gmass.co/blog/sign-up-gmail by editing the slug directly in the post. But, what if I also wanted the even shorter URL www.gmass.co/blog/gmail to work and also redirect to the post? How would I do that without creating a post that’s connected to it? Using the Yoast SEO redirect manager, I can add an entry such that www.gmass.co/blog/gmail redirects to www.gmass.co/blog/sign-up-gmail.

The “old” URL is /blog/gmail but it really isn’t “old” because it never existed to begin with.

Also, note that the “New URL” doesn’t contain the “/blog/” designation. Normally it would, but my WordPress setup is a little differently because in my general settings, I have the WordPress install and site directory set to the same path, so Yoast adds the “/blog/” part automatically to whatever I enter. If I were to specify /blog/sign-up-gmail then it would actually redirect to /blog/blog/sign-up-gmail which, obviously, I don’t want.

So one benefit of using the Yoast redirect feature is that I can set a redirect rule without being connected to a particular post. In this case, I’m redirecting the “gmail” slug to an actual post, but if I wanted, I could also redirect it to the Gmail website itself.

The second benefit of the Yoast redirect feature is redirecting deleted posts. WordPress does not natively handle redirects for deleted posts. If you decide to delete a post but you want its URL to redirect because the post’s URL has been published on the Internet or included in emails, then you have to use a plugin like Yoast. If you don’t use a redirect plugin, WordPress will return a 404 (Not found) page once you move a post to the Trash.

If you’re using Yoast, when you delete a post, you’ll be asked if you want it to redirect it elsewhere, and if you choose to do so, that redirect entry will be added to the main Yoast redirect page.

Which takes priority, Yoast or WordPress redirects?

If you edit a post’s slug, and you don’t undo the Yoast redirect that is created, then a setting will go into the database for both WordPress and Yoast to redirect the URL. Yoast, however, operates on top of WordPress and its setting takes priority over the natural WordPress setting. So if a Yoast redirect exists, it’s Yoast that does the redirecting. If, however, later delete the redirect from the Yoast Redirect Manager, the redirect will STILL work, because the natural WordPress redirect setting still exists. This can be tested easily by manipulating the database.

Where in the database are WordPress redirects stored?

WordPress creates a row in the table wp_postmeta tied to the post’s ID value that saves any old slugs for the post, so that those can be identified and redirected when called from the browser. In my example above, the post’s ID is 14197, so if I run this MySQL query:

select * from wp_postmeta where post_id = 14197

I’ll see this:

Note the “_wp_old_slug” entry. The purpose of _wp_old_slug entries is also documented by others like StackExchange and WordPress.org.

You might also wonder where Yoast stores its own redirect information. This is a mystery. I searched my database everywhere, and I couldn’t find it. It’s possible that Yoast isn’t even using the MySQL database to store redirects. Perhaps they’re in an XML file within the Yoast folder under /plugins/ inside my WordPress installation. I’ll reach out to Yoast’s support and ask them, just out of curiosity, and will update this post if I find out.

Tips on analyzing the redirect in Chrome’s Developer Tools

1. Be sure Chrome isn’t caching the redirect, otherwise you’ll end up confused as ever. Do a hard reload to clear the cache.
2. Be sure to check the “Preserve Log” option, otherwise you’ll be pulling out your hair in frustration that the network log disappears as soon as a redirect happens. You want to see all the redirect action so you know what URL you started with and what URL you ended with, and exactly how you got there.
3. Each time you run the experiment, you probably want to “Clear the log” as well, so it’s easy to see the redirect results at the top.

Two Yoast Mysteries

It’s currently a mystery to me:

1. Why the Redirect-By header isn’t set to Yoast when Yoast, not WordPress, is responsible for the redirect.
2. Where in the WordPress MySQL database the Yoast redirects are stored. The WordPress redirects are stored in wp_postmeta.

Other redirect plugins

Yoast isn’t the only WordPress plugin that provides redirect functionality. There are others too, like Redirection and 301 Redirects. If you want more options, HubSpot has published a list of the best WordPress redirect plugins.

Here are my best practices

If I’m editing a post just to have a new, shorter, slug, I undo the Yoast redirect and let WordPress handle it naturally. WordPress does this in the database by adding a row to the wp_postmeta table.

If I’m deleting a post, WordPress doesn’t have a natural redirect option, so I do use Yoast for that.

If I want to create a random URL, not connected to a particular post, then I’ll use Yoast to handle the redirect.

Ajay Goel

Ajay is the founder of GMass and has been developing email sending software for 20 years.