当网站地址变更时，需要将旧域名301重定向到新的URL地址，实际上就是把旧地址的访问请求重新引导到新域名上。301永久重定向无论是对用户还是搜索引擎都是比较友好的，对SEO完全没有不好的一面。通过旧网站的关键词排名和PR等级都会传递给新网站，网站更换了域名，用域名301永久重定向的方式告诉搜索引擎本网页已经永久性转移到新的域名，避免搜索引擎无法找到页面，网站对于搜索引擎相对比较友好。
域名重定向的好处有利于用户体验和搜索引擎抓取，301重定向跳转对搜索引擎的好处有、增加域名权重、对网页收录的优化、有利于网页PR传递、可促进搜索引擎优化效果、对用户体验表示友、避免造成404错误页面。使用301重定向把地址指向新的域名后，搜索引擎只对对新域名进行索引，同时将旧地址原有的链接转移搭配新域名下。正确的使用301永久性重定向命，对排名不会产生任何影响。
一、域名301重定向什么情况下使用
1、网站域名变更时，使用301永久重定向将旧域名重定向至新域名，挽回关键词排名和流量损失。
2、因某些原因需要删除网站中的个别目录时，比如我要删除好推建站的一级导航，这种情况就可以使用301永久重定向到网站首页。
3、多个域名需要指向同一个站点时，打算实现网址规范化，通过301永久重定向可以实现。
二、http中的重定向和请求转发的区别（包含JS跳转方法）
很简单，重定向是客户端行为，转发是服务器行为。转发属于一次请求，重定向属于第2次请求，转发地址栏不会发生改变，重定向地址栏会改变，转发在项目内，重定向 可以转到项目外。当使用转发时，JSP容器将使用一个内部的方法来调用目标页面，新的页面继续处理同一个请求，而浏览器将不会知道这个过程。 与之相反，重定向方式的含义是第一个页面通知浏览器发送一个新的页面请求。
1、调用方式?
我们知道，在servlet中调用转发、重定向的语句如下：
request.getRequestDispatcher("new.jsp").forward(request, response);//转发到new.jsp
response.sendRedirect("new.jsp");//重定向到new.jsp
在jsp页面中你也会看到通过下面的方式实现转发：
当然也可以在jsp页面中实现重定向：
<%response.sendRedirect("new.jsp");//重定向到new.jsp%>
2、本质区别
解释一
一句话，重定向是客户端行为，转发是服务器行为。为什么这样说呢，这就要看两个动作的工作流程：
转发过程：客户浏览器发送http请求----》web服务器接受此请求--》调用内部的一个方法在容器内部完成请求处理和转发动作----》将目标资源发送给客户；在这里，转发的路径必须是同一个web容器下的url，其不能转向到其他的web路径上去，中间传递的是自己的容器内的request。在客户浏览器路径栏显示的仍然是其第一次访问的路径，也就是说客户是感觉不到服务器做了转发的。转发行为是浏览器只做了一次访问请求。
重定向过程：客户浏览器发送http请求----》web服务器接受后发送302状态码响应及对应新的location给客户浏览器--》客户浏览器发现是302响应，则自动再发送一个新的http请求，请求url是新的location地址----》服务器根据此请求寻找资源并发送给客户。在这里location可以重定向到任意URL，既然是浏览器重新发出了请求，则就没有什么request传递的概念了。在客户浏览器路径栏显示的是其重定向的路径，客户可以观察到地址的变化的。重定向行为是浏览器做了至少两次的访问请求的。
解释二
重定向，其实是两次request,?
第一次，客户端request A,服务器响应，并response回来，告诉浏览器，你应该去B。这个时候IE可以看到地址变了，而且历史的回退按钮也亮了。重定向可以访问自己web应用以外的资源。在重定向的过程中，传输的信息会被丢失。
举例：response.sendRedirece（"loginsucess.jsp"）
请求转发是服务器内部把对一个request/response的处理权，移交给另外一个?
对于客户端而言，它只知道自己最早请求的那个A，而不知道中间的B，甚至C、D。?传输的信息不会丢失。
举例：
//Request Dispatcher dis=request.getRequestDispatcher（"loginsuccess"）
//dis.forward（request,response）:
前言
html ,js 可以实现页面跳转。
jsp , asp, php 也有各自页面跳转与重定向的方式。
下文针对js 和jsp 的页面跳转实现方式进行一个总结。
html 页面跳转方式
可以使用html 的meta 标签实现页面的跳转。
[html]?view plain?copy
1.?
2.?<!DOCTYPE?HTML?PUBLIC?"-//W3C//DTD?HTML?4.0?Transitional//EN">?
3.?
4.?
5.?New?Document?
6.?<META?NAME="Author"?CONTENT="oscar999">?
7.?<meta?http-equiv="refresh"?content="0;?URL=http://www.haotui.com.cn">?
8.?
10.?
11.?
12.?
13.?This?is?Test?Page?
14.?
15.?
这种用法比较常使用在：
新旧系统升级的状况下， 暂时保留旧系统，通过域名进入时自动转到新系统中。
JS 页面跳转方式
1. 使用window.location = "newurl"
[html]?view plain?copy
1.?
2.?<!DOCTYPE?HTML?PUBLIC?"-//W3C//DTD?HTML?4.0?Transitional//EN">?
3.?
4.?
5.?New?Document?
6.?<META?NAME="Author"?CONTENT="oscar999">?
7.?
8.?
9.?
10.?
11.?This?is?Test?Page.?
12.?
15.?
16.?
也可以使用 window.location.href = "http://www.haotui.com.cn";
2. 使用 window.navigate
[html]?view plain?copy
1.?
3.?window.loction.replace方式实现页面跳转
有3个jsp页面（1.aspx, 2.aspx, 3.aspx），进系统默认的是1.aspx，当我进入2.aspx的时候， 2.aspx里面用window.location.replace("3.aspx");
与用window.location.href ("3.aspx");
从用户界面来看是没有什么区别的，但是当3.aspx页面有一个"返回"按钮，调用window.history.go(-1); wondow.history.back();方法的时候，一点这个返回按钮就要返回2.aspx页面的话，区别就出来了，当用 window.location.replace("3.aspx");连到3.aspx页面的话，3.aspx页面中的调用 window.history.go(-1);wondow.history.back();方法是不好用的，会返回到1.aspx。
JSP跳转方式
JSP 跳转方式大约有三种：
1.?response.sendRedirect("newurl");
-- 此语句前不允许有out.flush()，如果有，会有异常：
java.lang.IllegalStateException: Can't sendRedirect() after data has committed to the client.
at com.caucho.server.connection.AbstractHttpResponse.sendRedirect(AbstractHttpResponse.java:558)
--跳转后浏览器地址栏变化
--如果要跳到不同主机下，跳转后，此语句后面的语句会继续执行，如同新开了线程，但是对response的操作已经无意义了
如果要跳到相同主机下，此语句后面的语句执行完成后才会跳转；
2. response.setHeader("Location","newurl");
[html]?view plain?copy
1.?response.setStatus(302);?
2.?response.setHeader("location","newurl");?
这种使用方式要结合 setStatus(302),?302 这个状态码就是告诉浏览器要重定向了。
1.?此语句前不允许有out.flush()，如果有，页面不会跳转。
2.?跳转后浏览器地址栏变化
3.?此语句后面的语句执行完成后才会跳转
此语句前不允许有out.flush()，如果有，会有异常：
跳转后浏览器地址栏不变，但是只能跳到当前主机下
此语句后面的语句执行完成后才会跳转?
跳转后得路径变为当前路径，图片不是绝对路径将无法显示
举例：
整个简单的例子：?两个文件 a.jsp 和 b.jsp .
[html]?view plain?copy
1.?
2.?
3.?<%@?page?language="java"?contentType="text/html;?charset=ISO-8859-1"?
4.?pageEncoding="ISO-8859-1"%>?
5.?<!DOCTYPE?html?PUBLIC?"-//W3C//DTD?HTML?4.01?Transitional//EN"?"http://www.w3.org/TR/html4/loose.dtd">?
6.?
7.?
8.?<meta?http-equiv="Content-Type"?content="text/html;?charset=ISO-8859-1">?
9.?Insert?title?here?
10.?
11.?
12.?Before:?This?is?a.jsp!?
13.?<%?
14.?//response.sendRedirect("b.jsp");?
15.?
16.?//response.setStatus(302);?
17.?//response.setHeader("location","b.jsp");?
18.?
19.?%>?
20.?
21.?<jsp:forward?page="b.jsp"/>?
22.?After:?This?is?a.jsp!?
23.?
24.?
对于jsp 而言， 就需要嚼一嚼Redirect 和 forward 的差别了。
就字面意思而已： Redirect 翻译成重定向， forward翻译成转发。
类别
概念
共享数据
应用
Redirect
URL重新定向：可以是任意的URL
不能共享request里面的数据
一般用于用户注销登录时返回主页面和跳转到其它的网站等等
Forward
页面的转发：只能是同一个Web应用程序的其他Web组件
转发页面和转发到的页面可以共性request里面的数据
一般用于用户登录的时候根据角色转发到相应的模块等等
三、http重定向301/302/303/307
301 永久重定向,告诉客户端以后应从新地址访问.
302 作为HTTP1.0的标准,以前叫做Moved Temporarily ,现在叫Found. 现在使用只是为了兼容性的处理,包括PHP的默认Location重定向用的也是302.
但是HTTP 1.1 有303 和307作为详细的补充,其实是对302的细化
303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。
307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。
测试的test.html代码,发起post请求到test.php页面中
test.php页面分别给出3种重定向处理,都跳到test2.php
test2.php打印出post的结果
(至于怎么写..自己查手册吧,PHP发送头很容易.)
1.....
2.301?=>?"HTTP/1.1 301 Moved Permanently",
3.302?=>?"HTTP/1.1 302 Found",
4.303?=>?"HTTP/1.1 303 See Other",
5.307?=>?"HTTP/1.1 307 Temporary Redirect",
6.....
测试结果:
301,302和303的处理结果是一样的,直接跳转到test2.php,post没有内容
307的会重新post请求到test2.php,并且给出页面提示
重定向实际使用是一个响应码（301或302或303或307）和一个响应头location，当浏览器收到响应的时候check响应码是3xx，则会取出响应头中location对应的url（重定向中url的编码问题），然后将该url替换浏览器地址栏并发起另一次HTTP事务。
关于301、302、303、307的区别，找不到好的文章，因此打算直撸HTTP 1.0规范和HTTP 1.1规范，结合一些实际的案例和tomcat实现，来说清楚这几个状态码的差异。
四、?https301重定向
原请求访问的是http://haotui.com.cn，然后返回302location=https://haotui.com.cn，从http转到https。不过关于响应行中302状态码的描述存在争议，在下文中会详细讨论。
五、tomcat重定向源码
六、http详细介绍
http 1.0规范中有2个重定向——301和302，在http 1.1规范中存在4个重定向——301、302、303和307，其中302是值得讨论讨论的。
1、 http 1.0
301状态码在HTTP 1.0和HTTP 1.1规范中均代表永久重定向，对于资源请求，原来的url和响应头中location的url而言，资源应该对应location中的url。对于post请求的重定向，还是需要用户确认之后才能重定向，并且应该以post方法发出重定向请求。
关于post请求重定向用户确认的问题，实际上浏览器都没有实现；而且post请求的重定向应该发起post请求，这里浏览器也并不一定遵守，所以说HTTP规范的实现并未严格按照HTTP规范的语义。
在301中资源对应的路径修改为location的url，在SEO中并未出现问题，但是在302中就出现了302劫持问题。
1、301永久移动
被请求的资源被分配了一个新的永久URL，并且任何未来对这个资源的引用应该使用该URL来完成。具有链接编辑能力的客户端应该在可能的情况下自动地将对request-URL的引用重新链接到由服务器返回的新引用。
新的URL必须由response.unless中的location字段给出，如果是HEAD请求，则响应的实体主体应该包含一个带有到新URL的超链接的短信。
如果使用POST方法接收到301状态代码以响应请求，则用户agnet不能自动重定向请求，除非用户可以确认，否则可能会改变发出请求的条件。
NOts：在收到301状态码后自动重定向POST请求时，一些现有的用户代理将错误地将其更改为GET请求。
在http 1.0规范中，302表示临时重定向，location中的地址不应该被认为是资源路径，在后续的请求中应该继续使用原地址。
规范：原请求是post，则不能自动进行重定向；原请求是get，可以自动重定向；
实现：浏览器和服务器的实现并没有严格遵守HTTP中302的规范，服务器不加遵守的返回302，浏览器即便原请求是post也会自动重定向，导致规范和实现出现了二义性，由此衍生了一些问题，譬如302劫持，因此在HTTP 1.1中将302的规范细化成了303和307，希望以此来消除二义性。
补充：302劫持——A站通过重定向到B站的资源xxoo，A站实际上什么都没做但是有一个比较友好的域名，web资源xxoo存在B站并由B站提供，但是B站的域名不那么友好，因此对搜索引擎而言，可能会保存A站的地址对应xxoo资源而不是B站，这就意味着B站出了资源版权、带宽、服务器的钱，但是用户通过搜索引擎搜索xxoo资源的时候出来的是A站，A站什么都没做却被索搜引擎广而告之用户，B站做了一切却不被用户知道，价值被A站窃取了。
2、302暂时移动
被请求的资源暂时驻留在不同的URL中。因为重定向可能偶尔会被改变，所以clinet应该继续使用请求URL来作为将来的请求。
URL必须由响应中的位置字段给出。除非是HEAD请求，否则响应的实体主体应该包含一个带有到新URL的超链接的短注释。
如果使用POST方法接收到302状态码以响应请求，则除非用户能够确认，否则用户代理不能自动重定向请求，因为这可能会改变发出请求的条件。
注意：在收到302状态码后自动重定向POST请求时，一些现有的用户代理将错误地将其更改为GRT请求。
2. http 1.1
301和http 1.0规范中保持一致，注意资源对应的路径应该是location中返回的url，而不再是原请求地址。
302在HTTP 1.1中，实际上302是不再推荐使用的，只是为了兼容而作保留。规范中再次重申只有当原请求是GET or HEAD方式的时候才能自动的重定向，为了消除HTTP 1.0中302的二义性，在HTTP 1.1中引入了303和307来细化HTTP 1.0中302的语义。
1、302found
被请求的资源暂时驻留在一个不同的URL中，因为重定向可能会被改变，客户端应该继续使用请求URL来做未来的请求，这个响应只有在缓存控制或者Expires头域指示的时候才能被缓存。
临时URL应该由响应中的位置字段给出。如果请求方法是HEAD，响应实体应该包含一个超链接到新URL的短超文本记录。
如果为了响应GET或HEAD以外的请求而接收到302状态码，除非用户能够确认，否则用户代理不能自动重定向请求，因为这可能会改变发出请求的条件。
注意：RFC 1945和RFC 2068指定客户端不允许更改重定向的请求上的方法。但是，大多数现有的用户代理实现将302视为303响应，对位置字段值执行GET原始请求方法的状态代码303和307已经被添加用于希望明确地清楚客户端期望哪种反应的服务器。
303在HTTP 1.0的时候，302的规范是原请求是post不可以自动重定向，但是服务器和浏览器的实现是运行重定向。
把HTTP 1.0规范中302的规范和实现拆分开，分别赋予HTTP 1.1中303和307，因此在HTTP 1.1中，303继承了HTTP 1.0中302的实现（即原请求是post，也允许自动进行重定向，结果是无论原请求是get还是post，都可以自动进行重定向），而307则继承了HTTP 1.0中302的规范（即如果原请求是post，则不允许进行自动重定向，结果是post不重定向，get可以自动重定向）。
2、303see other
对请求的响应可以在不同的URL下找到，并且应该在该资源上使用GET方法来获取。这个方法的存在主要是为了允许输出POST激活的脚本来将用户代理重定向到选定的资源。新的URL 不是原始请求资源的替代引用，303响应不能被缓存，但是对第二个（重定向的）请求的响应可能是可缓存的。
不同的URL应该通过响应中的位置字段求得。如果请求方法是HEAD，响应实体应该包含一个超链接到新URL的短超文本记录。
注意：很多HTTP-1.1用户代理不了解303的状态。当与这些客户端的互操作性是一个问题时，可以使用302状态代码。因为大多数用户代理对302响应做出反应，如303所述。
307在http 1.1规范中，307为临时重定向，注意划红线的部分，如果重定向307的原请求不是get或者head方法，那么浏览器一定不能自动的进行重定向，即便location有url，也应该忽略。
也就是307继承了302在HTTP 1.0中的规范（303继承了302在HTTP 1.0中的实现）。
3、307当代重定向
被请求的资源暂时驻留在一个不同的URL中。由于重定向可能偶尔被修改，所以客户端应该继续使用请求URL作为将来的请求。这个响应只有在cache-control或expires头域指示的情况下才能被缓存。
临时URL应该由响应中的位置字段给出。如果请求方法是HEAD，那么响应实体应该包含一个超链接到新URL（d）的短超文本记录，因为许多pre-HTTP / 1.1 用户代理不理解307状态。因此，注释应该包含用户在新的URL上重复原始请求所需的信息。
如果接收到307状态码以响应除GET或HEAD之外的请求，则用户代理不能自动重定向请求，除非用户可以确认它，因为这可能会改变发出请求的条件。
在HTTP 1.0规范中，302的规范并没有被服务器和浏览器遵守，即规范和实现出现了二义性，因此在HTTP 1.1中，将302的规范和实现拆分成了303和307。
浏览器对307状态的处理规划与302状态相同，之所以将值307引入到HTTP1.1中，是因为在最初的消息是POST的情况下，许多浏览器依旧错误地跟随302响应中的定向信息。浏览器应该只在接收到303响应状态时才从POST请求的重定向信息。引入这个新状态是为了去除二义性：如果接到303响应，则进行进行GET和POST请求的重定向,如果接收到307响应，对于GET请求的重定向，则继续进行，但对于POST请求的重定向，则不在继续下去。
七、HTTP状态码302、303、307区别
HTTP状态码3XX表示重定向，表明浏览器需要执行某些特殊的处理以正确处理请求。
301 Moved Permanently?
永久性定向。该状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。
302 Found?
临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。和301相似，但302表示的资源不是永久移动，只是临时性的。换句话说，已移动的资源对应的URI将来还有可能发生变化，比如，用户把uri保存为书签，但不会像301状态码出现时那样更新书签，而是仍旧保留返回302状态码的页面对应的uri
303 See Other?
该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源，=，?
303和302状态码有着相同的功能，但是303明确表示客户端应当采用get方法获取资源，这点与302状态码有区别。?
比如，当使用post方法访问CGI程序，其执行后的处理结果为希望客户端能以get方法重定向到另一个uri上去时，返回303状态码。虽然302也可实现相同的功能，但这里使用302状态码是最理想的。
当301、302、303响应状态码返回时，几乎所有浏览器都会把post改成get，并删除请求报文内的主体，之后请求会自动再次发送。?
301、302标准是禁止将post方法改变成get方法的，但实际使用时大家都会这么做。
307 Temporary Redirect?
临时重定向。该状态码与302有相同的含义。尽管302标准禁止post变化get，但实际使用时大家不遵守。?
307会遵照浏览器标准，不会从post变为get。但是对于处理响应时的行为，各种浏览器有可能出现不同的情况。
