Say you have 20 or even 50 pages that needs permalink changes. How can you guarantee an automatic redirect formation for all of them afterwards?

In Drupal for example, one could install the module "Global redirect" that creates redirects automatically when permalinks (Aliases in Drupalese) are changed.

Is it even needed in WordPress?

  • This question is slightly off topic due to it being for a plugin recommendation however the answers below will solve your issue. – Adam Mar 9 '16 at 7:37
  • Do you need to change the link structure of the pages or only the slug of the pages but keeping the structure? – cybmeta Mar 9 '16 at 9:42

Say you have 20 or even 50 pages that needs permalink changes. How can you guarantee an automatic redirect formation for all of them afterwards?

The part of a post URL that can be edited in WordPress is called the "slug". For a URL like http://example.com/blog/abc-xyz, then the "abc-xyz" part would be the slug. The slug is initially formed from the post title, and it can be edited later if desired.

Now, when you change the slug of a post before it is published, then obviously it doesn't make any difference. When you change the slug of a post which has already been published, then WordPress saves that old slug as "postmeta" data, using a key called "_wp_old_slug". It does this for any number of old slugs. If you change it three times, then you have three old slugs saved for that post.

When following an old URL, the old slug being used won't match the current one, because it has been changed. Therefore the main post query will not find the new post. So, WordPress has a function to handle this for old slugs.

During the startup sequence, the wp_old_slug_redirect() function is called by the template_redirect action. If the normal query was successful, then the function returns and does nothing at all. However, if the query was unsuccessful, and a slug was provided in the URL, then this function performs a search of the postmeta looking for a match amongst those old slug values. If it finds a match, then it gets the newer correct URL (permalink) for that post, and sends back a 301 redirect for it.

So, short answer to your question: WordPress handles this case automatically. Built right in.

For reference, this functionality was added to WordPress in version 2.1.

  • That's a good point... +1 – Adam Mar 9 '16 at 11:51
  • 1
    That is why I asked to @Benia if it is needed to change the permalink structure or only the slug but keeping the structure. This answer is correct and very well explained (+1) but we don't if it fits the needs of the OP. – cybmeta Mar 9 '16 at 22:26

The easiest way is just go to your htaccess and use for the 20 pages.

Redirect 301 /oldpage http://www.theurl.com/page-to-redirect


NOTE: don't award the bounty to me, give it Jorin, using Redirect 301s in htaccess is typically the easiest way to go for a one off use-case like yours.

You can do this one of several ways...

Using htaccess (recommended)

Redirect 301 /old-permalink http://example.com/new-permalink

or using a RewriteRule declaration if you have common permalink paths

RewriteEngine On
RewriteRule ^some-common-path/(.*)/$ /new-common-path/$1 [L,R=301]

Using a plugin:

(both of which are pretty good for what they are)

Handling this with PHP logic in a dirty way:

function maybe_redirect_request() {

    $redirects = array(

        'old-permalink' => 'new-permalink',
        'old-permalink/page/2' => 'new-permalink/page/2',


    $request_uri = !empty($_SERVER['REQUEST_URI']) ? trim($_SERVER['REQUEST_URI'], '/\\') : '';

    if ( $request_uri && array_key_exists($request_uri, $redirects) ) {

        wp_redirect( home_url($redirects[$request_uri]), 301 ); 



add_action('init', 'maybe_redirect_request'); //or perhaps the "request" filter
  • Then one of the two plugins I mentioned are the better way to go if you want a GUI. However I do not believe they automatically resolve new URIs for you if you change a permalink structure. Using the GUIs is relatively pain free so that shouldn't be a problem. (note the two plugins I mentioned are two of many, there are others out there which you may like better, however I can only recommend what I have used on occassion that sufficed for the purpose). – Adam Mar 9 '16 at 7:40
  • 1
    pretend it is a -1. The bigger the .htaccess is, the slower every request is even if it for JS CSS or image. 301 should be generated only if the url was leading to a 404. In addition you can get into a big confusion about which slug can and can not be used, therefor simplistic hardcoding is not wise. – Mark Kaplun Mar 9 '16 at 9:26
  • Now my pretend feelings are hurt... :) but... you are correct, filling your .htaccess file or similar with anything more is likely ill advised. However it is worth noting that I personally have done as much as 50 Redirect 301's in my .htaccess file with no discernable difference in request time round trip - perhaps testing is advised. Also if there is a suitable alternative/replacement page and your URL has substantial link juice/traffic then a 301 redirect is fine... but not sure where you got the idea they should be used only for 404's? Not all 404's should be 301'd. – Adam Mar 9 '16 at 10:00
  • I agree it will be hard to measure the impact. It will probably have more impact on serving small static files then (any) impact on serving WP pages.and latency will swallow it in both cases, but still it means higher load on the server. As for 404, the idea is to reduce parsing of urls, especially if the 301 urls do not have too much traffic, so you check if you should redirect only after all other possibilities have failed, i.e. before you serve a 404 (not to always replace the 404, just to move the check to that specific context) – Mark Kaplun Mar 9 '16 at 10:37
  • You don't need to do this most of the time. WordPress handles redirects from changes made in WordPress automatically. You only need to do manual adjustment for special cases. – Otto Mar 9 '16 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy