They say history repeats itself. In the case of the great 301 vs 302 vs rel=canonical debate, it repeats itself about every three months. In today's Whiteboard Friday, Dr. Pete explains how bots and humans experience pages differently depending on which solution you use, why it matters, and how each choice may be treated by Google.
Click on the whiteboard image above to open a high-resolution version in a new tab!
Video Transcription
Hey, Moz fans, it's Dr. Pete, your friendly neighborhood marketing scientist here at Moz, and I want to talk today about an issue that comes up probably about every three months since the beginning of SEO history. It's a question that looks something like this: Aren't 301s, 302s, and canonicals all basically the same?
So if you're busy and you need the short answer, it's, "No, they're not." But you may want the more nuanced approach. This popped up again about a week [month] ago, because John Mueller on the Webmaster Team at Google had posted about redirection for secure sites, and in it someone had said, "Oh, wait, 302s don't pass PageRank."
John said, "No. That's a myth. It's incorrect that 302s don't pass PR," which is a very short answer to a very long, technical question. So SEOs, of course, jumped on that, and it turned into, "301s and 302s are the same, cats are dogs, cakes are pie, up is down." We all did our freakout that happens four times a year.
So I want to get into why this is a difficult question, why these things are important, why they are different, and why they're different not just from a technical SEO perspective, but from the intent and why that matters.
I've talked to John a little bit. I'm not going to put words in his mouth, but I think 95% of this will be approved, and if you want to ask him, that's okay afterwards too.
Why is this such a difficult question?
So let's talk a little bit about classic 301, 302. So a 301 redirect situation is what we call a permanent redirect. What we're trying to accomplish is something like this. We have an old URL, URL A, and let's say for example a couple years ago Moz moved our entire site from seomoz.org to moz.com. That was a permanent change, and so we wanted to tell Google two things and all bots and browsers:
- First of all, send the people to the new URL, and, second,
- pass all the signals. All these equity, PR, ranking signals, whatever you want to call them, authority, that should go to the new page as well.
So people and bots should both end up on this new page.
A classic 302 situation is something like a one-day sale. So what we're saying is for some reason we have this main page with the product. We can't put the sale information on that page. We need a new URL. Maybe it's our CMS, maybe it's a political thing, doesn't matter. So we want to do a 302, a temporary redirect that says, "Hey, you know what? All the signals, all the ranking signals, the PR, for Google's sake keep the old page. That's the main one. But send people to this other page just for a couple of days, and then we're going to take that away."
So these do two different things. One of these tells the bots, "Hey, this is the new home," and the other one tells it, "Hey, stick around here. This is going to come back, but we want people to see the new thing."
So I think sometimes Google interprets our meaning and can change things around, and we get frustrated because we go, "Why are they doing that? Why don't they just listen to our signals?"
Why are these differentiations important?
The problem is this. In the real world, we end up with things like this, we have page W that 301s to page T that 302s to page F and page F rel=canonicals back to page W, and Google reads this and says, "W, T, F." What do we do?
We sent bad signals. We've done something that just doesn't make sense, and Google is forced to interpret us, and that's a very difficult thing. We do a lot of strange things. We'll set up 302s because that's what's in our CMS, that's what's easy in an Apache rewrite file. We forget to change it to a 301. Our devs don't know the difference, and so we end up with a lot of ambiguous situations, a lot of mixed signals, and Google is trying to help us. Sometimes they don't help us very well, but they just run into these problems a lot.
In this case, the bots have no idea where to go. The people are going to end up on that last page, but the bots are going to have to choose, and they're probably going to choose badly because our intent isn't clear.
How are 301s, 302s, and rel=canonical different?
So there are a couple situations I want to cover, because I think they're fairly common and I want to show that this is complex. Google can interpret, but there are some reasons and there's some rhyme or reason.
1. Long-term 302s may be treated as 301s.
So the first one is that long-term 302s are probably going to be treated as 301s. They don't make any sense. If you set up a 302 and you leave it for six months, Google is going to look at that and say, "You know what? I think you meant this to be permanent and you made a mistake. We're going to pass ranking signals, and we're going to send people to page B." I think that generally makes sense.
Some types of 302s just don't make sense at all. So if you're migrating from non-secure to secure, from HTTP to HTTPS and you set up a 302, that's a signal that doesn't quite make sense. Why would you temporarily migrate? This is probably a permanent choice, and so in that case, and this is actually what John was addressing in this post originally, in that case Google is probably going to look at that and say, "You know what? I think you meant 301s here," and they're going to pass signals to the secure version. We know they prefer that anyway, so they're going to make that choice for you.
If you're confused about where the signals are going, then look at the page that's ranking, because in most cases the page that Google chooses to rank is the one that's getting the ranking signals. It's the one that's getting the PR and the authority.
So if you have a case like this, a 302, and you leave it up permanently and you start to see that Page B is the one that's being indexed and ranking, then Page B is probably the one that's getting the ranking signals. So Google has interpreted this as a 301. If you leave a 302 up for six months and you see that Google is still taking people to Page A, then Page A is probably where the ranking signals are going.
So that can give you an indicator of what their decision is. It's a little hard to reverse that. But if you've left a 302 in place for six months, then I think you have to ask yourself, "What was my intent? What am I trying to accomplish here?"
Part of the problem with this is that when we ask this question, "Aren't 302s, 301s, canonicals all basically the same?" what we're really implying is, "Aren't they the same for SEO?" I think this is a legitimate but very dangerous question, because, yes, we need to know how the signals are passed and, yes, Google may pass ranking signals through any of these things. But for people they're very different, and this is important.
2. Rel=canonical is for bots, not people.
So I want to talk about rel=canonical briefly because rel=canonical is a bit different. We have Page A and Page B again, and we're going to canonical from Page A to Page B. What we're basically saying with this is, "Look, I want you, the bots, to consider Page B to be the main page. You know, for some reason I have to have these near duplicates. I have to have these other copies. But this is the main one. This is what I want to rank. But I want people to stay on Page A."
So this is entirely different from a 301 where I want people and bots to go to Page B. That's different from a 302, where I'm going to try to keep the bots where they are, but send people over here.
So take it from a user perspective. I have had in Q&A all the time people say, "Well, I've heard that rel=canonical passes ranking signals. Which should I choose? Should I choose that or 301? What's better for SEO?"
That's true. We do think it generally passes ranking signals, but for SEO is a bad question, because these are completely different user experiences, and either you're going to want people to stay on Page A or you're going to want people to go to Page B.
Why this matters, both for bots and for people
So I just want you to keep in mind, when you look at these three things, it's true that 302s can pass PR. But if you're in a situation where you want a permanent redirect, you want people to go to Page B, you want bots to go to Page B, you want Page B to rank, use the right signal. Don't confuse Google. They may make bad choices. Some of your 302s may be treated as 301s. It doesn't make them the same, and a rel=canonical is a very, very different situation that essentially leaves people behind and sends bots ahead.
So keep in mind what your use case actually is, keep in mind what your goals are, and don't get over-focused on the ranking signals themselves or the SEO uses because all off these three things have different purposes.
So I hope that makes sense. If you have any questions or comments or you've seen anything weird actually happen on Google, please let us know and I'll be happy to address that. And until then, we'll see you next week.
Sometimes, these situations in the real world can be more complicated than in the SEO textbook. Have you run into cases where it wasn't clear whether 301, 302, or rel=canonical was the right choice? I'd like to hear some of your (hopefully not horror, but horror is acceptable) stories.
Great topic Pete. It's unfortunate we still have to address this in 2017, but I think some of Google's statements have been really misleading and caused a lot of poor decisions and uncertainty of late.
The only truly tough cases I've had were around content that had expired but may still hold interest from a historical analysis perspective (e.g. our older "ranking factors" surveys, which no longer applied, but some marketers or SEO folks might want to compare them out of interest or to see what's changed). Most of me wanted to 301 them to combine the ranking signals and to make sure visitors and engines got to the most recent version, but then there was the historical analysis value, and so we moved each old one to new URLs and kept the most recent version at the same URL. We haven't had to use rel=canonical on the old versions, but if there were ranking/traffic conflicts, that might be an issue, too.
Yeah, that kind of thing can be tough, definitely. You could link to the old versions from the current version and then rel=canonical the old versions to the new version, but it's a slightly mixed signal, and, if it works, you won't be allowing the old versions to come up in search results. If you 301, no one can see the old versions at all, so that's definitely more extreme.
First of all that W T F joke is amazing.
Second... about rel="canonical".
You correctly say that we must think about user intent, but I would prefer User Experience as a term, and I think that the best example to explain it is Pagination, using it as exception to the general rule you are explaining in the video.
In fact, we know that Google - albeit indicating as default solution the use of rel="prev"/"next" - in its same documentation says that, if some circumstances are respected (eg: PageSpeed), the best solution is having indicating the "view all" as canonical of the paginated URLs.
So, in that case, we will still show in our web design a traditional paginated list (or paginated article, for pageviews advertisement reason) to users, but only one "view all" page to Googlebot.
Excellent whiteboard, Dr. Pete! This particular topic is very timely for me as I just went through something at my work that involved lots of discussions about all this.
Several years ago we re-branded and thus changed our domains. At the time of the old brand, the site only had a few pages (home page, about, careers, etc.) When we re-branded we 301'd the old domain pages to the new pages. In the 2.5 years I've been here we've always 301'd these. However, in early January our developers accidentally introduced an old domain duplicate version of every page on our current site (~3K URLs) without a 301. Since all our content has self-referencing canonicals, we actually didn't see any impact to traffic or rankings. Google seemed to still be giving credit to the new domain even though there was an entire duplicate domain that existed that was not being 301'd.
In early February, I started noticing Google was picking up old domain links in Webmaster Tools. Upon discovering the old domain was live and not being 301'd anymore, I got our development team to quickly 301 everything to the appropriate new domain URL. Beginning the next day, we saw ranking + traffic drops and they continued to drop more and more everyday. 1 week later, after we had hit a super low traffic day for a Tuesday for us, I started digging into all the possible scenarios that could be causing this. I then discovered that the redirects our developer put in place were actually 302s and not 301s. I got him to revert them to 301s, and we slowly started to get back to our normal traffic. It took nearly 2 weeks to recover from these drops. However, we still have yet to recover 100% from the traffic losses.
I was curious to know if you or anyone else in the community have ever seen major traffic drops from accidentally 302'ing a different domain vs 301'ing it? Also, has anyone ever noticed Google having issues interpreting when a 3XX + a canonical are in place. In our situation, it seems like Google was not affected by the 301 + canonical. However, when the 302's were accidentally introduced, it seems like Google got confused and then ignored the canonicals.
Thoughts?
Yeah, definitely, especially in the past. This is where I get nervous when people over-generalize and say "302s pass PageRank!" and then leave it at that. There are absolutely situations where they don't pass PR properly and are a bit tool for the job. Over time, Google probably would've sorted your situation out, but in the short-term they were honoring your stated intent of "Hey, this is short-term."
"WTF", Slowly slowly Claps for that example...
Those, who knows about these would not face any problem but those who just entered in the field would be frustrate, what to do with these three confusing things.
Let's make it simple and clear -
301 - If you really don't want a page, just remove it & do 301.
302 - If you want a page but want to make it down temporary (Might be a product page that currently not in the stock and could be up in next few days), just do 302 . But make sure you decide quickly till when to keep that page down, you can not wait till one year or 6 months (As Dr. Peter said)
Rel=Canonical - For more than one same type of pages, you should use rel=canonical just to inform google bot that what is the priority page. So, they won't be confused between all same kind of pages.
Make sense ? It's quite simple if we understand it and we must decide first what we have to do with the pages rather than confusing between these.
Good luck and have a great weekend !
I actually thought that the WTF was for "Wednesday Thursday Friday" to show progression. Then it hit me that I am a little behind this morning and should probably refill my coffee.
The one bit of complexity, which I touch on in the video, is that there are situations where Google just doesn't seem to think you should use a 302 (like transitioning from http:-->https:) and may chose to interpret them as 301s even in the short-term. The devil is in the details, especially on large sites, but I mostly want people to understand that these three approaches are have fundamentally different implications.
In recent months I witnessed a not-small site migrate from http to https and they used 302 1:1 redirects, not 301.
About a month later, their traffic and rankings started suffering significantly.
Shortly after that, their home page fell off of the middle of 1st page of Google SERP for their most important keyword, where it had been for years, to beyond page 2.
Not too long after that, the devs changed the 302s to 301s.
About a month later, site traffic and rankings returned to previous levels, home page returned to middle of 1st page of Google SERP.
Those are the facts, and I have drawn a number of conclusions from this experience which I will not detail here, I'll just stick to the facts.
Argh. Yeah, that's why, when in doubt, I really think it's best to use the proper signal and not let Google sort it out for you. The fact that they *can* do something, in theory, doesn't mean they *will* do something, and it's not worth the risk.
Sadly, I've heard way too many http-->https migration horror stories :(
"Well, I've heard that rel=canonical passes ranking signals. Which should I choose? Should I choose that or 301? What's better for SEO?"
I asked nearly this question John Mueller in a german Webmaster Hangout - without that linkpassing thing.
He said: Don't use Canonicals as 301 - use a canonical as canonical.
He added: Otherwise Google could start to think about ... what did he mean ... and that leads to misinterpretation.
(I asked that question for some UX Reasons - I am not so interested in passing linkjuice or not with canonicals)
Hey Dr. Peter, Great Whiteboard Friday, you came just in time! Have made a couple of changes in my new blog and this saved me a 2 hour headache. Also, I had the same debate with my partner and you clarified a few points for us. Thanks for the awesome information, Sariel
Glad to hear I prevented a headache :)
I have a question. What if I create a better page with better on page SEO and stuff and want to over-rank my older page (with poor on page SEO and user experience)?
Should I use 301? If I use 301, I will need to delete old page and redirect it to a new one.
But what if I want users to be able to view older page too (for information), but I want google to show the new page in SERPS.
Which one should I use? Rel=canonical or 301 redirect?
Use a canonical tag, just as you would canonicalise a printer-friendly or mobile or AMP version.
Hello Ziyoda,
I guess you answered your question by yourself "Should I use 301? If I use 301, I will need to delete old page and redirect it to a new one."
It seems you want to keep both the pages, Old one for information to users and new one for Google bot and ranking purpose in SERP. So, just simply put a canonical tag (Rel=canonical) rather than 301.
Hope this helps !
Yeah, if it's important to be able to let people still visit the old page, then you don't want a 301 here. Rel=canonical is your best bet. It's hard to give a generic answer without understanding the pages, but fundamentally a 301 is going to keep anyone from visiting the old version and it will cease to exist from a user/bot perspective.
Excellent WTF WBF. I have a rel prev/next question for you.
One of our sites uses both pagination AND alphabetical sort for category pages. Each creates unique URLs (ex: "...?category=widgets&page=2", "...?category=widgets&alphaSort=B".
Can I use 2 sets of rel="next"/rel="prev" tags (1 for pagination & 1 for alpha-sort) without confusing Google?
Iv'e found its typically easiest to put a canonical on /cat?sort=alpha pointing to the root category, then having rel next on the root so /cat has a rel=next to /cat?page=1. then lastly when you have a combo of page and sort you just noindex it, eg. /cat?sort=alpha:page=1. Thought process here is that how often is /cat?sort=alpha:page=1 going to be useful to users or search engines and the rel=next will take care of getting the crawler to all the content available.
If anyone knows I am curios if the rel=canonical should be used for products options in an ecommerce page if the product is very similar. Say you have different pages for blue bead and red bead and green bead, because they are not all really the same. Should you use rel=cononical to a main bead product and on that page put links to the other beads (if you dont just want to make them a product option)
This is, in fact, a very classical use case of a canonical tag: You can first create a page displaying a white dress and then pages for the same dress in other colors, which will then point to the white dress page with a rel=canonical. This will help you to eliminate near-duplicate content (the various dresses are almost exactly the same save for the color).
First of all thanks a million for posting this and explaining this so well! Absolutely brilliant!
I wanted to ask a few things that I was a bit confused by in general.
Some questions:
Do a 301 from all http -> https versions.
Do a 301 (or .htacces rule?) from https://somewebsite.com to https://www.somewebsite.com/ (notice slash in the end).
Do a 301 (or .htacces rule?) from variants of the above also. For example https://www.somewebsite.com/index.html
Set the canonical to the preferred version.
This seems a bit never ending is there a quick way through the .htaccess file to do this. The amount of possible variants one needs to think about are a little bit staggering. (edit: I've read on another site that a general RewriteRule can be used for something like that?)
And last questions on this: What happens then for example if start going into pages. Every page would need a redirect to always have the correct url and trailing slash included. Example:
https://www.somewebsite.com/thisissomepage.html/ <<<< correct version (301 catch and canonical?)
Again I have probably not done enough research but I would assume there is a .htaccess rule to make sure the page is always
So basically this would be "right" way to do it:
I would be glad if you could shed some light on it if that is actually correct.
Many thanks again!
I'm afraid .htaccess rules are beyond the scope of blog comments and can be site-specific, but there are definitely ways to write http-->https redirects in .htaccess that will apply to the entire site (and not write them URL-by-URL). There are plenty of how-tos you can Google, but keep in mind that any rule you create has to co-exist with your existing rules, or you can end up with strange redirect chains.
If you have 301s in place, you don't also need rel=canonical. There are situations where you might have both impact the same page, but they would general serve different purposes.
Trailing slashes are generally not an issue you should add a redirect for these days, except in rare circumstances. Almost all modern browsers and crawlers will append them as needed. Don't add a rewrite/redirect rule for this unless you're having an issue.
Thanks Peter for the reply. Appreciate it!
I have a question Dr.Peter
Here is a case.
I changed one of page URL from
example.com to example.com/fr/
and implemented 301 redirect.
Then I changed again the page URL from
example.com/fr/ to a-example.com/fr/.
And implemented 301redirect.
This double 301 could give bad affect to the bot?
I wonder if I should change premier 301 "example.com to example.com/fr/"
to
"example.com to a-example.com/fr/"
or current redirect is fine.
Have I executed WTF?
This one makes me a little nervous, because international situations can be trick. It sounds like this could be a case for [rel="alternate" hreflang], but I'm not clear on what the intent is. So, take what I'm about to say with a grain of salt.
In most cases, Google will follow a chain of two 301-redirects without trouble. I'd be careful with long chains and, in a perfect world, I'd try to re-write your rules such that it's a single 301 (especially if this redirect rule impacts thousands of pages). If, for some reason, you need two 301s, though, I wouldn't lose sleep over it.
What happened to my website is firstly, we launched example.com but this website is strongly focus on french speaker in France so I created fr sub-folder and redirect to example.com/fr/ , secondly, I found spelling mistake on URL so I fixed it.
Through this entire process I implemented a chain of 301 redirect.
Thanks for your answer Dr.peter, it's clear now and am glad to hear your thoughts about this case. I can sleep without any concern.
It was awesome WF.
Hi Yukihiro,
could you please confirm me that you are talking of something like this?
1) you have a domain like domain.com
2) then you create a subfolder /fr/ in that same domain and 301 the root domain to the subfolder
3) then you create a new domain (your a-example.com), which has the same /fr/ subfolder
4) you redirect 301 domain.com/fr/ to the new a-example.com/fr/
If it so, then you should not have problems, albeit you're creating a small redirect chain:
domain.com > domain.com/fr/ > a-example.com/fr/.
The only question would be: what does happen to a-example.com/? Is it too redirected to a-example.com/fr/ or it is a completely different page in another language (eg.: you consolidated different language domains into a single multilingual one)?
Hi Ginaluca
Thanks for the comment. it helps me to understand what technically happened.
And yes what exactly happened my website is like you said
Firstly, we launched example.com but this website is strongly focus on french speaker in France so I created fr sub-folder and redirect to example.com/fr/ ,
Secondly,I found spelling mistake on URL so I fixed it.
so the page which has been changed its URL is same one page.
oh your comment gives me another question, which is I thought I did a chain of 301 redirect
domain.com > domain.com/fr/ > a-example.com/fr/
but actually domain.com/fr/ doesn't exist anymore since I fixed URL.
so this case domain.com should be redirected to a-example.com/fr/?
Would you mind give me your advise about this please?
Thanks a lot.
Great Article Dr. Pete.
I have a one doubt though. I changed all old urls to new urls in the domain (as old urls were full of gibberish). Content remained same. All those old urls had no backlinks at all. So am i supposed to redirect (301) these old urls to new ones? Or should I just ignore them? I am also getting lots of duplicate meta tags error messages in google search console as both url versions have same tags.
Yes, it really would be best to 301-redirect those old URLs, even without links. Otherwise, Google will be indexing both copies and might not know which ones should rank.
Thanks a lot for the article. Apart from the contents, it make me realize that I have duplicated content because my home page has two previsualizations of the two main sections (blog and forum).... I suppose I will have to use canonicals, isn't it?
Regards,
Czd
Great post, the WTF joke definitely made me giggle.
Yes the biggest issue I always have is what to do with historical content that has been updated with a new post. We don't want to lose the old content as it might interest some people; but we want people viewing the most recent content.
So our solution has been to add a canonical to the most recent, add a link for the users to the most recent article and add a date to the page title and H1 so it's clear. Then we just hope the Google understand!
I think that's a reasonable approach. Unfortunately, we can't completely have our cake and eat it, too. Focusing on a single piece of content (the newest) vs having the old content all available both have pros and cons.
Great explanation. Here I would like to share my experience related this topic:
My first experience:
We have launched our app supported website in the past which is called Split screen app for mac.
In this website we have created 3 versions pages for 1 product. Each pages are showing different price and additional features.
Pages versions names are like /pro and /ultimate. Now what happened in this situation Google always got confused which page is better to show when someone will search Split screen app into goolgle.
Google finally picked our home page and other two pages later de-indexed because only price and features are different on those pages. So later I used canonical tag to avoid confusion for bots and improved my rank.
My second experience was about 301 redirect.
One of the website I have created for client and added all existed content. At the end I forgot to redirect from old domain to new one.
That was my biggest mistake. After around 1 month my client's website was de-indexed in Google. In this case I didn't understand why this happened later I have received duplicate content panelty inside the Search console. After that I immediately set 301 redirection and cleared my panelty as well as solved all the problems.
So far I have these 2 kinds of experienced.
Hi Pete,
Great overview! Timely as well.
My client's new https site launches next week and I want to properly set up the .htaccess file, 302's and rel=canonical links and then INDEX each page.
Here is my issue: 10 pages of the site are "menus" of product and some content is duplicated.
2 of these menus are identical (A and B);
a) url "A" has content streaming in from a third party source via an embed code (70% of our Industry uses this 3rd party source to stream their menu). The streaming site ranks very high for our keywords.
Do I want to hide "A" content from bots on our website? Is the "website where our menu content will originate" receiving the SEO juice for this page? This page is view-able from all devices.
b) url "B" is a tabbed page with 8 separate product menus (C-J). This page is only view-able on desktop and tablet.
c) urls "C" through "J" contain content unique to the page/category; i.e., "C" dogs, "D" cats, "E" birds, "F" snakes, "G" cows, "H" monkeys, "I" elephants, "J" zebras. These pages are view-able from all devices.
For the best SEO and Page Rank result, do I want to promote the individual menu pages; C - J? I think so, as the product will change weekly and updates will be automatic to the tables. Product listed are categorized by type and have their own set of keywords/phrases.
If I INDEX the individual menu urls (menu pages C thru J), what is the best way to treat Menu "A" and "B"?
Thank you!
Sorry, this one's probably too complex for the comments - might be best to post in Q&A. It's sometimes hard to give good advice without seeing specific pages. My only concern is that it sounds like (A) is ranking well for you right now, so I'd be hesitant to remove it from the index. It certainly sounds like (C-J) have the most unique, high-quality content.
I'm a little confused about (B) containing (C-J). It might be a situation were you could use rel=prev/next and then (B) would be the "parent" but Google would also allow (C-J) to rank.
This was an excellent Whiteboard! Thank you for helping me understand the differences. Very well written!
Appreciate the 301 and 302 clarification. Thinking of moving in this direction or redirection soon.
Hey there Dr. Pete! I have a question about the 2nd scenario that you discussed. (302'ing HTTP to HTTPS) I have a client that did precisely that about 6 months ago--my question, now that I discovered that issue, would it be a good idea to go back and correctly change that to 301s? (It appears that Google is passing authority to the right version with the 302, but I still feel like it would be a good idea to implement that "correct" solution to this scenario.)
Thoughts?
That's a little tricky. In theory, yes, switching them to 301s is the right way to go. In practice, it's possible that the switch could cause some short-term ranking fluctuations (like any switch). It's low-risk and probably reduces your long-term risk, but do it on a low-traffic day :)
Awesome example of how we can easily mess up what Google intended to help! One quick question - when wanting to direct mobile users to m. and vice versa, is general consesus still that 302s are best?
Wow, you explained it splendidly well. The combination of bots and users have made the concept clearer. Well, I have some questions for your Dr. Pete and would be great if you clear my concept regarding these:
I have a client whose website got a SQL injection through which irrelevant pages have been built within the website. Additionally, those irrelevant pages have been linked from other blogs and websites as well (not sure how). As a result, the client’s website got ranked on various irrelevant keywords with the same irrelevant URLs. I have submitted a URL removal request through Google Webmaster. So my question is:
1. Do I need to transfer all those spammy URLs through 301 redirection? Or the URL removal request through Google Webmaster is workable?
2. Another concern is that most of the ecommerce websites have thousands of URLs. Most of the time the outdated product and category pages are being disabled. So in this case, what is the preferred solution either we unlink those pages from the website and keep the link active. Or disabled those pages and apply 301 redirection to its relevant pages.
Your thoughts?
Hey Pete, thanks for sharing the post. If one is going to do any of these three then its better do it right.
Great post explaining in depth 301 and 302. The point is that for a long time 301 are for permanent and 302 are for temporary redirects.
In e-commerce websites, we have to use canonical tag when we have 2 or more products with only slightly different descriptions may be we have a different capacity of a hard disk or different color of a pen, the descriptions are almost similar. While we require to have the pages for customers, it is best that we use canonical to prevent duplicate content issues as the content is almost the same
Freat presentation, Pete! Unfortunately you forgot 307 & 308 redirects: According to LinkResearchTools, they might be even better in terms of passing ranking power from an old to anew webpage. See this: https://www.linkresearchtools.com/case-studies/11-t...
So, this is a controversial topic, and unfortunately, it's very hard to tell. You can't really split test a 302 vs a 307, for example, so we end up with a lot of anecdotal evidence. I think most people are confused enough by the most common options, and experimenting beyond that is a very advanced subject (that can carry risk). Always interesting to see people's data on the results, but I hesitant to recommend some of those more complex, non-standard solutions, especially on beginner-oriented content.
Thank you for the information.
For temporary redirect, 302 redirect, what is the time frame Google will crawl it again?
Temporary means a week? A month? A year?
Unfortunately, this is variable, as best I know, and depends on the page's normal crawl frequency. It definitely wouldn't be a year. Google will attempt to re-crawl semi-regularly, especially for sites with decent authority.
It is shocking as well as funny that we believes since years that 302 doesn't pass page rank and suddenly we came to know that oh! we were wrong.
Sir I have situation with a question.
I have a page that only a logged in user can access, of if user is already logged in, page will pass a 200 status code but it user is not logged in it will redirect to login page with a 302 status code.
Is in this case page rank pass?
Hi Sandeep, actually Pete gave you the answer: check if the page is indexed and you'll know if the page rank was passed to it.
Cheers
Yeah, that's a tough one. Since that 302-redirect is going to be in place long-term, Google is probably going to start just attributing authority to the login page itself. I've seen disagreements on this topic, but ultimately the pages that require a login are unavailable to bots.
Some sites use the option to show partial content to search visitors, but require login for full content. This can get tricky, because you don't want the partial content to be thin (or you could run into other SEO problems). I'm afraif there's no easy or perfect solution here.
Thanks. I was wondering about 301 and 302 and actually thought they affected the pages in a similar way. Didn't have to use 302s yet, but now I know how they work :)
Great post Dr. Peter. This will clear many misunderstandings for sure.
I had a similar experience 3 months back while optimizing an eCommerce website, where it was required to have multiple pages (3 pages - almost identical) for the same product for better user experience and requirements. But it created duplicate content issue which was not good for the website's crawling budget and also other SEO factors. So, we decided to go with canonicalization method, which worked perfectly in that scenario. I even had a discussion with Cyrus Shepard on this and he suggested the same solution.
Thanks
This article was great, absolutely think its essential for all SEOs to watch this video.
I am dealing with a similar issue and I would like some input on how to approach it (thank you all in advance). My client is currently dealing with a HTTPS migration. I spoke with their dev teams and they have the HTTPs pages ready, but they do not want to implement 301s - lack of resources to have these in place - for the moment, they will not have 301s till the later part of the year. They suggested that they want to canonical the http version to the https version as the band-aid solution. What is the best way to approach this when migrating to HTTPS when you do not have 301s ready? It has put me in a constant battle on how to respond to this.
and what about 301 in htaccess file? I have a lot of redirect from my site (old pages that now are deleted). Can I remove very old 301 or must I live them on my file forever?
You can delete them when there is no more notable traffic on the old URLs and no external links pointing to them (internal links should be changed to the new page immediately and shall never point to a 301ed URL). In the meantime, you could write those who still hold links to the old URLs so that they can update them. Then you can kill the obsolete 301 relations.
Yeah, Toronado is right -- I'd hold off until you're sure the old versions aren't getting traffic and you've updated most of the links. Unfortunately, there no point where Google definitively considers a redirect permanent forever and stops going back to the old page. It's a gradual process.
Thanks for bringing the fantastic humour to the WBF on what is generally a pretty dull / dry ... yet serious topic!
Can you please address my concern.
What we have in our website is two duplicate pages of doctors profile.
one is https://www.skinandhairacademy.in/dermatologist-in-...
and another one is - https://www.skinandhairacademy.in/dr-a-maitra so to avoid the duplicate content we have implemented the canonical tags on both the pages giving the link of first URL in both, since we want first URL to be ranked better than the second one.
So my questions are..
1. Have we done the correct thing by putting the canonical URL both the pages?
2. If no what we have to do for the same?
NOTE - The second URL is a requirement from the client and we have to keep both the URLs.
Is the long URL the one you link to in your navigation? If so, your canonical tags seem to be set up properly.
One warning -- in some cases, Google may choose to ignore rel=canonical when a short/clean URL is pointing to a longer one, but if your other signals (like internal links) are consistent, you should be ok.
Dr. Peter - great WBF.
Use case for rel=canonical
We have many referral sources to our website and various pages (affiliates, display, email, SEM...). In tracking these various customer flows, we utilize classic analytic platforms (Google, Adobe...), and we have tracking code pass in the URL to be able to credit an action to a specific referral source. That creates multiple versions of the URL; hence, we utilize rel=canonical to let the search engines know the end state authoritative URL.
+1 for that W-T-F joke. Indeed that was my reaction to John Muller's statement on 302s and then suddenly everyone thinks they are the same. THANKS for clearly stating the obvious, so that we look at what 301, 302 and canonical tags are meant for and use them accordingly. Simple, yet SEOs get confused into the holy grail of ranking/juice/PR/whatever.
Great presentation Dr. Pete.
In relation to "how long is too long" for a 302 redirect to be in place, take the case of a split test using a 302 to send part of the traffic (e.g. 50%) to a version B URL. The length of the test may vary depending on how long it takes to reach statistical significance. It could happen to be 2 or 3 months, for example.
Have you ever experienced problems with 302s used for split tests resulting in Google being confused about what version to attribute ranking signals to?
Google is a bit vague in their recommendations about the length of a test:
The amount of time required for a reliable test will vary depending on factors like your conversion rates, and how much traffic your website gets; a good testing tool should tell you when you’ve gathered enough data to draw a reliable conclusion. Once you’ve concluded the test, you should update your site with the desired content variation(s) and remove all elements of the test as soon as possible, such as alternate URLs or testing scripts and markup. If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly. This is especially true if you’re serving one content variant to a large percentage of your users.
Thank you.
Unfortunately, I've definitely heard of issues with using redirects for split testing, especially long-term. I'd highly recommend finding an approach/system where the URL stays the sasme for both A and B. There are quite a few on the market now.
If that's not possible, at least canonical the variations back up to the main page. It'll boost the 302 signal a bit.
Great rundown, Dr Pete!
One area that I've always been curious on for 301 vs 302 in the use of IP based geo-redirection. Ideally sites wont use geo-redirects for vanity URLs, but the SEO team doesn't always win.
example:
I've found that google only finds the US version since they are crawling from California, and eventually starts to treat domain.com as domain.com/us and will show the root domain URL in SERP with /us/ meta data.
I've thought about switching the 302 to a 301 since its basically being treated that way anyway, and hopefully pass more of the link equity found on the vanity URL.
Any thoughts? keep in mind not using the vanity URL at all is not an option.
I'm afraid I'm not an international SEO expert and this can get hairy really quickly. It depends on the structure of the switching page. In some cases, hreflang is a possible solution (even if both sites are in English, you can set the regional settings for US/UK), but I'm not sure if you've got duplicates across the whole site, or just at the home-page level.
Another Great Whiteboard Friday !!
Thanks for sharing this information, you Just solved my problem, Man. I face same problem with my website and new I am able to remove all the errors.