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:
