Learn about 301 and 307 redirects: what they are, which ones to use, how to make them, and how to use them effectively.
Podcast: Play in new window | Download
Redirect types
When data is requested through the Internet, it usually includes extra information in the header. This could help with caching, identification, and redirection. A “response code” is a three-digit number that corresponds to behavior or a result. For example, you’re probably familiar with “404 error.” 404 is a response code that means “not found,” and it’s what you would get if the data you’re trying to load can’t be accessed.
When we talk about redirects by their numbers—301, 307, and such—we’re referring to technical differences in the response codes and how those are interpreted.
Here are what the most-relevant types of redirects do.
300 “conditional” (my nickname)
This is an interesting one you may have experienced without knowing it. A 300 redirect is offers multiple choices and redirects based on certain conditions. It’s like telling the Post Office to split and forward your mail based on the recipient.
For example, a 300 redirect could point visitors in the United States to one link, and visitors in the United Kingdom to another. Or, it could point Android users to one link but iOS users to another.
Cool, right? This is quite technical to implement, but some plugins can do this for you on some level.
301/308 permanent redirect
This is the most common redirect you hear us talking about in podcasting. This redirect is permanent and cacheable. It’s like telling the post office to forward all your mail and notify the sender of a change of address.
Being a permanent redirect, any search-engine ranking for the old URL will be passed to the destination. Apps should eventually stop looking at the old URL and start looking at the new URL. If the apps don’t update what URL they check, they do cache the destination URL. So if you changed where a permanent redirect goes, many apps might not follow it properly.
301 and 308 are both permanent redirects. The difference is technical. Whereas a 301 redirect can be interpreted slightly differently with GET and POST, a 308 redirect resubmits the GET or POST based on the original request. 308 redirects don’t support protocol changes, such as HTTP to HTTPS.
Most of the time we refer to a permanent redirect, it’s a 301, and that’s the kind of permanent redirect you should probably use.
302/303/307 temporary redirects
Temporary redirects are common and we should probably use them more often that we do. (More on my recommendations later.) A 302, 303, or 307 redirect is temporary and not cacheable. It’s like telling the post office to forward your mail to your vacation spot, but not notify anyone of a change of address.
Being a temporary redirect, search-engine ranking for the old URL will not be passed to the destination. Apps will usually follow temporary redirections but won’t update the URLs they check each time and won’t cache the destination URL. Thus, whenever you change where a temporary redirect forwards, all apps should follow.
The differences between 302, 303, and 307 temporary redirects are technical and similar to the differences between 301 and 308 permanent redirects. A 302 redirect was intended to be interpreted a particular way with GET and POST requests, but some apps forced one way or the other. Thus, the 303 and 307 redirects were created to remove the ambiguity. A 303 redirect forces a request as a GET (even if it was originally a POST), but a 307 passes it on in the same way it was requested.
302 redirects are still supported for backward compatibility, but 307 is the ideal temporary redirect.
304, 305, and 306
These other redirects are most likely too technical for podcasters to have to know. 306 is deprecated and 305 uses a proxy (but isn’t universally supported).
304 “not modified” is the interesting one because it communicates that the destination data has not been changed since a date in the HTTP headers. Theoretically, this is ideal for RSS feeds as it would prevent a client from loading an entire RSS feed to find new data. Instead, a 304 redirect would allow the client to compare only the last-modified dates and only continue loading the data if the dates didn’t match. However, this is rarely implemented in apps at this time.
When to use each redirect type
Maybe your head is spinning from all the different types of redirects, so here’s what you need to know for making your decisions.
Use 301 permanent for your URLs, SEO, and unchanging things
Treat 301 redirects as permanently as possible (even though the Internet is always changing). You almost can’t go wrong using 301 permanent redirects for stuff you own.
Here are my recommendations for when to use a 301 permanent redirects.
- Domain changes: http://olddomain.com ➜ http://newdomain.tv
- Protocol changes: http://myawesomepodcast.com ➜ https://myawesomepodcast.com
- Shortcuts for your own content: http://myawesomepodcast.com/100 ➜ http://myawesomepodcast.com/the-most-awesome-celebration-ever-episode-100
- SEO rank passing for updated content: http://myawesomepodcast.com/why-feedburner-and-soundcloud-are-awesome ➜ http://myawesomepodcast.com/why-you-should-not-use-feedburner-or-soundcloud
- URL/permalink structure changes: http://myawesomepodcast.com/page/about/contact ➜ http://myawesomepodcast.com/contact
- RSS feed changes: https://feed.horrible-podcast-hosting.com/myawesomepodcast ➜ http://myawesomepodcast.com/feed/podcast
Remember that a 301 redirect should only be used for what you intend to be permanent. Thus, I really don’t recommend it for affiliates, other people’s sites, live-streaming sites, and such. That’s when you should use temporary redirects.
Use 307 temporary for others’ URLs and changing things
Being temporary, 307 redirects are best for the things you know or suspect will change. You almost can’t go wrong using 307 temporary redirects for stuff you don’t own.
Here are my recommendations for when to use a 307 temporary redirects. Any of these could change at any time, by you or by whoever owns the destination URL.
- Affiliate URLs—the URL pattern may change, the company may change affiliate programs, or you may want to refer to a different store
- Resources on someone else’s site—they may change their URL structure, they may start or end an affiliate program, or you they may have updated something
- Live-streaming services—unless you use your own /live page on your site, you may be redirecting to different services each week, or they may give you a different URL for each event, or you may even want to stop embedding the live on your own site and sending everyone to a service’s site
- Anything else that you can’t control and that might change
Because 307 redirects are temporary and uncached, an app or visitor should be properly redirected each time they access the URL.
Where to make temporary and permanent redirects
Depending on your needs, you may want to make your redirects at the server level, with a WordPress (or other content-management system) plugin, or in a file on your site.
Server-side redirects
If you’re hosting on a server running Apache, most server-side redirects would be placed in a .htaccess file in your site root folder or through your control panel. If you’re hosting on a server running Nginx, most server-side redirects would be placed in a .conf file inside or accessible to the Nginx configuration. Either of these support regular expressions for advanced redirecting.
There are plenty of ways to do these, and they’re easy to get wrong and break your website, so you may need to ask your hosting company for help.
WordPress plugins
I use and recommend Pretty Link Pro for easily making your own 301 and 307 redirects. This doesn’t support very advanced stuff, but it’s really easy to use and has great features (including location-based redirects in Pretty Link Pro 2.0, automatic keyword-linking, and more).
For more advanced redirects, including regular expressions or exhaustive imports and exports, I recommend Redirection (free). This also works nicely to track and redirect page and post URLs you change. I’ve used this for redirect a large list of URL changes in one of my forums.
And for some clever, alternative methods of redirecting, including easily redirecting an existing page or post, or for some clever support for your own affiliate program, try Quick Page/Post Redirect Plugin (free). I’ve used making AffiliateWP work with LeadPages for Podcasters’ Society.
Files on your site
If you don’t want to risk breaking your site and you can’t use a plugin, you can create redirects inside of files on your site, but these may have to be named with .php (or another extension) at the end to be interpreted by your server.
Guidance on using redirects
For blogging and especially for podcasting, here are some of my general recommendations for using redirects.
Don’t go crazy
Redirects are powerful, but they are also best when simple. You may not need a redirect for everything you link to on your website.
Keep them simple
If you are making redirects to speak in your podcast, ensure the redirects are short, unambiguous, easy to understand when heard, and easy to type. Avoid symbols, hyphens, underscores, and leading zeros.
Be smart about numbers
Since making redirects are free, it’s okay to make multiple redirects for the same thing when you think there could be some confusion, such as whether numbers should be spelled out or used as numerals. Instead of complicating your call to action by explaining which way, simply make both ways to make it easy for your audience.
Stay lowercase
Although email addresses, domains, and top-level domains (.com, .net, .market, etc.) are case-insensitive, anything after the slash in a URL could be and probably is case-sensitive. Thus, /iTunes and /itunes may actually be different URLs on your server, especially a Linux server (which most of them are).
The best thing is to use only lowercase for your URLs
Say “slash”
I have a small pet peeve over unnecessary redundancies (think about what “PIN number” or “ATM machine” really mean, unabbreviated). “Forward slash” is another redundancy. The opposite of “backslash” is simply “slash.” People are quite familiar with what a slash is. Think of common uses, such as “n/a,” “and/or,” “c/o,” “s/h,” “his/her,” and fractions like “1/4.” In each of these, people either pronounce the symbol as “slash,” or wouldn’t pronounce it at all. Could you imagine someone saying, “and forward slash or”?
Also, people know what button to press on their keyboards to get a slash. You really don’t have to help them distinguish between a slash and a backslash. As they said in the 2001 Microsoft-depicting movie Antitrust, “Dust the colon and the backslash key! Only geeks use those keys.”
Rarely use subdomains
A subdomain would appears in a URL like this: http://subdomain.domain.tld.
Subdomains are a way for your domain or server to easily run completely different software or even connect with a completely different server. They might work nicely for live.myawesomepodcast.com or store.myawesomepodcast.com, but they can also be confusing.
Many people still wrongly assume domains require “www.” in them (that’s actually a subdomain, too!). So if you use a subdomain for a redirect, they may still prepend it with “www.” and then land on a broken page.
Point to valid, full URLs
You may be able to create a redirect on your domain like /live, but the destination URL must be complete with the protocol (“http://” or “https://”). Some apps—such as browsers, WordPress, or Google apps—will assume a protocol, but that doesn’t work for redirects. (how many times have you commented on a social network and your URL didn’t become a link? This is why!)
Bad: /live ➜ myawesomepodcast.com/live
Good: /live ➜ http://myawesomepodcast.com/live
You may be able to omit the domain if you’re making an internal redirect, such as /live ➜ /live-page, but it’s still a good practice to use full URLs.
Have really good reasons for speaking several URLs
When you can make your own redirects, it’s really easy to throw them all over in your podcast. But be concise, especially in important calls to action. The best thing to do is point your audience to your show notes (with an easy URL!) for all your links and resources.
Thank you for the podcast reviews!
- Sven Brandsma (Seffen99), from the Netherlands and Praatje Podcast, said, “… In my case, the audacity to podcast literally gave me the guts to pursue my dream of starting my own podcast. And It happened! I now have a Dutch podcast for over a year now. I present it with my best friend who is the co-host. Our podcast is about Video Games, Movies, Music and Technology. It’s called Praatje Podcast. Where “Praatje Pod” is kind of a Dutch synonym for small talk. Thanks you Daniel for all your wisdom, information and fun.”
Your written iTunes reviews encourage me and they help other people find the podcast. If you appreciate the podcasting information I share, please write your own review on iTunes or Stitcher!
Announcements
Need personalized podcasting help?
I no longer offer one-on-one consulting outside of Podcasters' Society, but request a consultant here and I'll connect you with someone I trust to help you launch or improve your podcast.
Ask your questions or share your feedback
- Comment on the shownotes
- Leave a voicemail at (903) 231-2221
- Email feedback@TheAudacitytoPodcast.com (audio files welcome)
Connect with me
- Subscribe to The Audacity to Podcast on Apple Podcasts or on Android.
- Join the Facebook Page and watch live podcasting Q&A on Mondays at 2pm (ET)
- Subscribe on YouTube for video reviews, Q&A, and more
- Follow @theDanielJLewis
Disclosure
This post may contain links to products or services with which I have an affiliate relationship and may receive compensation from your actions through such links. However, I don't let that corrupt my perspective and I don't recommend only affiliates.
As someone who presents technical material, I thought this episode was lacking.
You confession that you had to look up some of redirect numbers and use cases before presenting them, only served to make me question if you are qualified to speak on this technical matter in regards to podcasting.
I think not! You missed the mark.
Case in point: The number one reason for using redirects in podcasting is to provide a way to collect stats. Apple publishes an specification regarding the number of redirects allowed for a podcast, yet, this most important use case (and limit) for podcasting, was not even mentioned.
You referred to “Get” and “Post” requests many times, yet failed to even give a simple explanation as to what they are, and instead, passed it off as geek material. Most web requests requiring a redirect would be a “Get”, so these minimal terms deserve an minimal explanation.
Some of your explanations for redirects on the web server where largely incomplete.
For example, redirects can be also be handled locally – internally (using rewrites under apache for example).
You mention using the .htaccess file as a redirect method, and totally disregard using cgi scripting to supply a redirect.
On subdomains, you make the leap that “people still wrongly assume domains require www” then correctly state that “that’s actually a subdomain, too”, and then go on to advise against the use of subdomains.
Instead, if you use subdomains, you would want setup “www.subdomain.com” as well (to avoid the problem), then (possibly) use the redirect or rewrite engine to turn “www.subdomain.com” to simply “subdomain.com” (if you choose to).
Speaking on using the the redirect or rewrite engine, you can write your instructions in the .htaccess file (on apache for example) to easily handle both cases.
Note that subdomains are great for avoiding having to say “slash” in a podcast.
Case in point: it is much easier to say visit us at “go.howstuffsbroke.com” that to say “visit us at howstuffsbroke.com forward slash go” (although even I am guilty of doing that).
And subdomain do not actually need to work like a seperate domain, since redirects can be employed to simply turn “go.howstuffsbroke.com” into “howstuffsbroke.com/go/”. That is a really a fine feature of redirects that should have been covered.
I also thought your “pet peeve” portion of the show just went off on a tangent.
Note that one of my “pet peeves” is also speaking redundant information (something you do on purpose as a standard part of your podcast).
I could go on, but let me just say in closing that I thought this episode was poorly done, and I question your qualifications to speak or advise on the subject.
Your podcasts are often helpful and informative (thank you), but for this one if I could, I would be asking for a refund of my valuable time.
Please take no offense. You do ask for feedback, and I give it honestly (and without charge).
Joe C. Hecht
Thank you for taking the time to share the valuable feedback, Joe. It sounds like you’re already well-equipped to understand and use redirects in a way that serves your goals, so I can understand how this episode would not have helped you much.
I always do research before my episodes. I don’t think that indicates someone is unqualified to address the subject, because I would hope even a fully qualified person would still do research to verify the information.
I know I didn’t cover every single possibility or the go extremely in-depth on describing things. I wanted to provide what most podcasters need. For redirects, I think that’s convenience more than stats. After all, you can get stats from UTM links, but that’s not friendly to the audience, so it seems the audience-friendliness is the higher priority for most podcasters.
Yes, all those workarounds you mentioned are possible. They’re also more technical, harder to implement, and harder to maintain for most podcasters.
Thank you, again, for the feedback!
Hi Daniel, This is so weird, hearing our podcast (praatje podcast) in your show. I feel honored.
The funny thing is, that we recorded a show yesterday and we mentioned your feedback on my review. My best friend and I, really appreciate the fact that you played a sample of our podcast and found the audio quality ‘great’. So we thanked you in our recordings yesterday.
Then a little more information for those who are interessted what I was saying in the sound sample Daniel played. In the prelude Johan (the Co-Host) and I were synchronicing our microphones by counting back from 3 to 1 (in dutch) and then clapp our hands. It’s also a way for us to ‘get in the flow’. Then there is our intro leader and then I say (translated):
“Hello, you are listening to the Small Talk Podcast, the podcast about Video Games, Movies, Music and Technology. My name is Sven….”
Daniel, thanks again and if you like, I will send you the sound sample of our recording in which we thank you.
Kinds regards,
Sven Brandsma
You’re very welcome, Sven! This has inspired me to start doing similar things for others who write reviews.
How’d I do with the pronunciation? 🙂
Hi Daniel,
I gotta say, it takes a lot of courage to pronounce something in Dutch. Because it’s really difficult. You took the bold step and came a long way. When it comes to the word ‘Praatje’, well, that’s a tough one.
But don’t worry, I’ll explain it phonetically, so you’ll pronounce it like a true dutchman 🙂 Here we go:
So the word is: Praatje. You break the word into two parts while pronouncing it. Like this: Praa-tje.
Let’s break it down phonetically with common English words that sound the same:
When pronouncing ‘Praatje’, it sounds like this:
– Prada without ‘da’ with the accent on ‘a’
– The letter ‘t’
– And finaly Yes without the ‘s’
So pronouncing it phonetically is something like:
Pra-tye
Good luck with practicing 😉
Got it. Thanks!
Hey Daniel, I noticed you recommend Pretty Links Pro in this episode, whereas you previously seemed to be leaning towards Better Links Pro (in a previous blog entry, or maybe episode?). I’m curious if there is are some particular reasons or changes since. I’m really interested in EasyAzon and thought Better Links Pro might be a good compliment (same author), and I think the pricing is a bit better. But, if Pretty Links Pro does give some benefits I’d want, I should maybe reconsider. (The last time I looked, it didn’t seem that way.) Thanks.