WordPress Redirection Plugin and Trailing Slashes

I am a huge fan of the WordPress Redirection plugin because I have found that it’s an easy way for non-technical folks to go in and set up 301 redirects so that all URLs are directing site visitors to whatever new content is appropriate. Recently, I ran into a small issue where some redirects that had been set up on a site I was migrating all led to 404 “page not found” errors. The reason? Inconsistent use of trailing slashes. What do I mean by a “trailing slash”? I’m referring to the slash ( / ) at the end of some URLs.

What Was Happening

Some of the redirects were working fine, but some weren’t. Upon closer inspection, I realized that some of the source URLs for the redirects had been set up without a trailing slash.

redirection-screenshotIn the screenshot above, I’m showing four possible combinations of source and target URLs in regards to the use of trailing slashes. Using a standard installation of WordPress with these scenarios will lead to the following results:

Scenario Result when navigating to the URL without a trailing slash. Result when navigating to the URL with a trailing slash.
Source URL does not have a trailing slash and target URL does.  successful redirect  404 error
Source URL has a trailing slash and target URL does not.  404 error  successful redirect
Source and target URLs both do not have trailing slashes.  successful redirect  404 error
Source and target URLs both have trailing slashes.  404 error  successful redirect

WordPress uses trailing slashes by default. If you go to any page on a standard WordPress site, remove that trailing slash from the end of the URL, and refresh the browser to go to this new version of the URL, you’ll notice that by default, WordPress reroutes traffic to URLs with a trailing slash. This means that with or without a slash, the target URLs we have set up will resolve to the correct URL.

With each test case we’ve set up in this example, we’ve learned that there are two patterns that lead to failed redirects:

  1. The source URL has a trailing slash, but the user navigates to the URL without a trailing slash.
  2. The source URL does not have a trailing slash, but the user navigates to the URL with a trailing slash.

Both of these scenarios make sense when you think about them in the context of how WordPress is set up. In both scenarios, the URL the user navigates to does not exist as far as the system is concerned, leading to the 404 errors. This means that the problem with these redirects lies with the configuration of the source URLs, not the target URLs.

The Solution

We need to make source URLs that account for the possibility that a user could navigate to the URL either with or without a trailing slash. We could make double the number of entries through the redirection plugin and manually specify each possible source URL, but this is a lot of work and could easily get unwieldy when dealing with lots of redirects. So, how should we set this up? Regular expressions to the rescue!

A regular expression (also known as a regex) is a text string that creates search patterns within a statement. Regular expressions are a broad and fascinating topic that are well beyond the scope of this post. For now, what we need to know is that the Redirection plugin allows for the use of regular expressions in setting up redirect queries and that we can use such a query to tell the browser that we’d like the source URL to redirect whether a site visitor inputs that URL with a trailing slash or not.

To make this work, we need to change two things in the set up of each entry:

  1. Check the “regex” box to tell the Redirection plugin that you are using regular expressions in the URLs you are entering.
  2. Add this code to the end of each source URL:

    This simple regular expression is basically telling the website to use the redirect whether the source URL has a trailing slash or not.

With these changes, your redirects should all work if the site visitor inputs the URL with a trailing slash or not. In the admin interface, the redirects in this example would appear like this:



15 Replies to “WordPress Redirection Plugin and Trailing Slashes”

  1. Hi,

    Thanks, but this won’t work if:




    it will loop endlessly and crash. Any suggestions?

    1. I’m sorry this didn’t work for you – I have tested all of the examples in this post multiple times and they are still all working on my blog. I did some research and found quite a few support forum posts on the Redirection plugin accidentally creating infinite loops. Here is a link to one of the more detailed posts I found: https://wordpress.org/support/topic/infinite-redirect-loop-after-changing-page-parent-twice?replies=6

      In all of the threads it seems that the solution to the problem that these folks were having was to disable monitoring of changes to posts in the Redirection plugins’ options settings. I hope this helps!

  2. This may or may not work when your redirects have dashes involved. For example, if you want /terms and /terms/ to forward to /terms-of-service/, you may end up with an infinite loop if you use /terms[/]? as your source. My test resulted in /terms-of-service/-of-service/-of-service/-of-service/-of-service/ (etc.). If you run into this issue, it might be simpler to have two redirects set up as /terms and /terms/. Hope this helps.

    1. I found it works if you add a slash (/), then the question (?) and then the dollar sign ($) – so /example/?$ works — using the brackets didn’t work for me.

  3. this is not working for me.

    source: /faq
    targeted url: /what-we-do/

    i am using this:

    source: ^/faq/?$
    targeted url: /what-we-do/

  4. Here’s the problem: a person with our group has put out promotional materials for an event with an invalid url on them. The invalid url is ( dccda.org/beermaze ). Of course, the valid url is dccda.org/beermaze/ with that pesky trailing slash. The invalid url doesn’t go anywhere. It’s just a blank page. I’m trying to find a way to redirect traffic from that invalid url to the valid one. I’ve tried the tricks above, but it doesn’t work, and I’m not even sure redirecting from a non existent url to a valid one is really even the point of the Redirection plugin. I don’t want to have to recall all of the promotional materials that this person put out there. I’d rather just make it work. Can you help me? Thanks

  5. All of these options are great, but I needed something more global and that wouldn’t affect actual files like .html, .asp, .js, .png, etc. and URIs that already had a slash. We used to use Yoast’s WordPress SEO plugin. But the current version no longer has an “enforce trailing slash” option in their permalinks section and I don’t find anything online except references to the feature in older versions. So, I found the following expression to work at least in all my testing. It works for any directory hierarchy. I’ve done a ton of searches in Google and none provided this solution, so hopefully this will help a few folks.

    Source: ^/([^\.]+[^/])$
    Target: /$1/

    Details: Using brackets means it’s looking for at least one character. By adding the hat and only one item inside, it means it’ll match any character but the one you have inside. We often use .* or .+ to capture all characters. So if you replace the period with the brackets, then you get a match for an entire URL as long as it doesn’t have a period anywhere in it. The plus sign requires at least one character to be present. That makes sure the homepage isn’t affected. Wrapping the hole thing but the first hat and slash puts the whole thing into a variable to pass along. You need the slash at the beginning to provide a boundary for the repeating wildcard and the last set of brackets basically look for the last character to be anything but a slash. I hope this helps folks!

    1. I have since learned my regex didn’t consider URLs with variables in them (i.e. ?utm_campaign=test). It was still adding an ending slash. Here is an update. It should deactivate (i.e. a URL won’t be matched) if a period or question mark is in the URL.


Leave a Reply

Your email address will not be published. Required fields are marked *