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.
In 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:
- The source URL has a trailing slash, but the user navigates to the URL without a trailing slash.
- 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:
- Check the “regex” box to tell the Redirection plugin that you are using regular expressions in the URLs you are entering.
- 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:
Hi,
Thanks, but this won’t work if:
/test[/]?
/category/test
or:
/test[/]?
/category/test/
it will loop endlessly and crash. Any suggestions?
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!
The WordPress Redirection Plugin is a powerful tool for managing URL redirections, including the common issue of trailing slashes. By setting up rules within the plugin, you can ensure consistency, prevent 404 errors, and improve your site’s SEO performance. It’s a must-have for anyone looking to maintain clean, functional URLs on their WordPress site.
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.
You’re absolutely right – thanks for documenting this here Leslie!
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.
Hi
Thank you for the article. It solved my problem.
You’re welcome! I’m glad to hear it!
this is not working for me.
source: /faq
targeted url: /what-we-do/
i am using this:
source: ^/faq/?$
targeted url: /what-we-do/
2nd is working for me
Hi,
This worked for me as well. Thanks.
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
The destination URL needs to be full URL if switching to Regex – at least in my case
hii,
i’am Akhil Sharma
The WordPress Redirection Plugin is a powerful tool for managing URL redirections, including the common issue of trailing slashes. By setting up rules within the plugin, you can ensure consistency, prevent 404 errors, and improve your site’s SEO performance. It’s a must-have for anyone looking to maintain clean, functional URLs on their WordPress site.
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!
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.
^/([^\.\?]+[^/])$
In my case I didn’t need the brackets, just:
/page/?
Make sure to turn ‘regex’ on.
All you have to do is :
Generate the firs one rule to this:
Source: ^(.*)[^/]$
target: $0/
After this all the rules will be good, because firstly they will be adding slash to it, after that it will match any redirection you have with trailing slash
I was struggling with this issue and found an easier solution that does not require regex. Add the following to your .htaccess file
# Force trailing slash
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [L,R=301]
This will automatically force a trailing slash onto all urls before the redirection plugin gets to them.
Dear Madam, Is there any solution, that we can find without a plugin?
hii,
i’am Akhil Sharma
The WordPress Redirection Plugin is a powerful tool for managing URL redirections, including the common issue of trailing slashes. By setting up rules within the plugin, you can ensure consistency, prevent 404 errors, and improve your site’s SEO performance. It’s a must-have for anyone looking to maintain clean, functional URLs on their WordPress site.